zone montant packée

**nenekes** · 04/08/2010, 17h33

bonjour a tous,

je recois un fichier avec un enreg d'une longueur de 46.

sur cette longueur du caractere 5 a 43, les infos sont compressés avec du comp-3.

ce qui m'interesse c'est (appelons la toto la zone) la zone toto(20:8) qui est un montant.

d apres l'appli qui m'envoi le fichier ce serai du 9(13)v9(2) comp-3.

donc moi je move cette zone dans une working avec le meme format puis j'additionne dans cette meme zone working les montants enreg par enreg en lecture sequentielle !

le probleme c'est que les montants que j obtiens contiennent des caracteres spaciaux et donc mes montant erronés!

y a t il un moyen propre pour recuperer ces montants please ?

merci par avance

**Luc Orient** · 04/08/2010, 18h16

Quel COBOL ? Quel OS ?

**nenekes** · 04/08/2010, 18h53

cobol V4.0 SP2
unix aix5.3

**el_slapper** · 05/08/2010, 10h56

Laisse moi résumer.

tu as :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
01 FICHIER.
    05 TOTO PIC 9(13)v9(2) comp-3
77 W-TOTO PIC 9(13)v9(2) comp-3
77 TOTAL-TOTO PIC 9(13)v9(2) comp-3
(.../...)

READ BLABLA INTO FICHIER
  NOT AT END
    MOVE TOTO TO W-TOTO
    ADD W-TOTO TO TOTAL-TOTO
END-READ

donc, tu est toujours en format packé pour ton total.

Si tu veux l'afficher, il te faut une variable de plus, au format display, genre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
77 TOTO-AFFICHAGE PIC -9(13)v9(2).
(.../...)
READ BLABLA INTO FICHIER
  NOT AT END
    MOVE TOTO TO W-TOTO
    ADD W-TOTO TO TOTAL-TOTO
  AT END
    MOVE TOTAL-TOTO TO TOTO-AFFICHAGE
END-READ

**nenekes** · 05/08/2010, 11h34

Merci pour ta reponse.

en fait j ai un montant dans chaque enreg de mon fichier et le dernier enreg contient normalement la somme de tous les montants precedement lus !

le truc est quand au fur et a mesure que je lis le fichier, j'additionne mes montants pour enfin les comparer avec le montants du dernier enreg.

c est la que ca coince car l addition au finale est pourrie !

comment puis-je additionner ces montants qui sont packés et comparer le resultat avec le dernier montant du dernier enreg ?

**Luc Orient** · 05/08/2010, 14h52

Envoyé par nenekes

...
en fait j ai un montant dans chaque enreg de mon fichier et le dernier enreg contient normalement la somme de tous les montants precedement lus !

Tu es sûr que le montant présent dans le dernier enregistrement a le même format que celui des autres enregistrements ?

On peut imaginer un format plus grand pour éviter d'éventuels problèmes de dépassement de capacité.

**nenekes** · 05/08/2010, 15h32

le format du montant du dernier enreg est 9(13)v9(2) non compressé, donc lisible normalement !

le vrai probleme est dans les precedents enregs ou le montant est compressé!

en plus c est une zone total de 46 compressé dont le montant se trouve en position (20 à 28) !!

je souhaite additionner tous ces montants pour ensuite comparer avec le montant du dernier enreg !

**el_slapper** · 06/08/2010, 12h52

Là, il nous faut une description complète de la ligne(COPY), plus un exemple en hexa d'une ligne complète(HEX ON). Il doit y avoir un détail qui tue, mais je ne vois pas.

**nenekes** · 17/08/2010, 13h22

hello,
j'etais en vacances imprevue!

pour revenir sur ce sujet qui reste d actualité;

je recois le fichier de la sorte (je prend une partie du fichier pour l exemple)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
0148 -âï ©       ©âï  ·ì " ©ìåe"    
0148 -âï ©       ©âï  ·ì " ©Ãˆ     
0148 -âï ©       ©âï  ·ì " ©Êh†d!    
0148 -âï ©       ©âï   Ä? © ËÞ©    ï

le montant est a priori ici;

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
©       ©
position 20 a 28

en hexa ca donne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
A9 20 20 20 20 20 20 20 20 A9

la copy que j utilise pour lire cette zone de 46 est tout simplement un PIC X(46).

cela vient peut etre de ma copy (j espere que non car cela m embeterai beaucoup!!!)

merci par avance de votre aide.

**Hédhili Jaïdane** · 17/08/2010, 16h26

Bonjour.

La représentation hexadécimale d'un nombre packé (Comp-3) doit ressembler à ceci :
00 00 01 23 45 67 8F pour le nombre 12345678 en pic 9(13) comp-3.
12 34 56 78 90 12 3F pour 1234567890123 en pic 9(13) comp-3.

A la place du F (le signe) on peut trouver C ou D quand le nombre est signé positif ou négatif. D'autres caractères représentant le signe peuvent exister dans la littérature (en fonction des compilateurs et des OS).

**bernard59139** · 18/08/2010, 06h42

Bizarre cette répétition de '20' (code hexa du SPACE en ascii) pour une zone devant contenir des chiffres.

Vérifie que le fichier soit celui que tu attends

**nenekes** · 18/08/2010, 10h38

aucun doute c est bien le fichier que j'attend, j'ai d ailleurs demandé si c etait possible de le recevoir avec cette zone non packee !

sinon cette zone contient bien un montant car je le vois en mode debug sur mon prog cobol mais en additionnant avec les autre lignes, ben ca part en sucette (des caracteres bizarre s'intercale dans les montants) !!

si qlq un a une bidouille a proposer ?

**el_slapper** · 18/08/2010, 11h11

effectivement bizarre tous ces "20", il ya anguille sous roche. Si ils sont là partout(tu peut faire un test sur ces 6 caractères et les comparer à SPACES), alors ton fichier en entrée est faux, ou au moins ne correspond pas à tes spécifications.

Tu as une définition complète de ton fichier en entrée? Genre ma définition avec les TOTO, mais la vraie? Parceque l'anguille me parait être planquée là, pas après sur tes additions.

**bernard59139** · 18/08/2010, 12h26

J'ai eu essayé plusieurs trucs , 20 20 20 ne correspond pas à une zone numérique packée ou pas

SI tu vois la zone en "debug", il y a 2 pistes possibles:

le programme fait quelque chose pour avoir cette zone (des MOVE, des décalages de zones, ...)
le copy cobol ne correspond pas au fichier

**Peut-êtreUneRéponse** · 18/08/2010, 15h20

La zone TOTO (20:8) commence à 20 et fait 8 de long. Quand tu dis :

Envoyé par nenekes

le montant est a priori ici;

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
©         ©
position 20 a 28

Il y a une erreur : position 20 à 28 = 9 de long.
Ensuite,

Envoyé par nenekes

en hexa ca donne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

A9 20 20 20 20 20 20 20 20 A9

Pour cette partie en hexa, tu nous donnes 10 de long ?!

Es-tu sûr qu'en HEX ON sur la zone 20:8 (position 20 à 27) du fichier en entrée tu as du X'20' ? Si oui le fichier est erroné pour certains enreg tu reçois du space à la place de certains montants attendus.

Quand tu dis :

Envoyé par nenekes

sinon cette zone contient bien un montant car je le vois en mode debug sur mon prog cobol

Peux-tu nous indiquer comment tu vois ces montant (Par DISPLAY, de quoi, défini comment ? quel est l'affichage que tu obtiens? Y a t-il un montant pour chaque enregistrement ?)

Il faudrait que tu donnes le COPYBOOK que tu utilises en entrée, la description des zones de working utilisés pour le calcul, et la manière dont tu fais ton calcul.

Autre chose, le fichier que tu as en entrée, vient-il du même environnement ? AIX ?

As-tu essayé de débuguer en affichant pour chaque enreg traité le montant reçu et le cumul de montants en passant par des zones en format d'édition convenable ?

.

**nenekes** · 19/08/2010, 18h34

donc deja effectivement faute de frappe il s agit de la pos 21 a 28.
dans mon prog cela se traduit par zone-montant(21:8).

le fichier que je recois ne vient certainement pas d'un OS AIX5 (peut etre du AS400), il s'agit d'une appli exterieur qui m'envoi ce fichier (pourri a mon sens mais il faudrait que je fasse avec !!! )

les mecs en face, ils m'envoient la structure qu'ils utilisent (fichier joint).

moi j'ai du creer une structure assez simple pour traiter ce fichier dans mon prog:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
016200 01                 KK51.                                                  K7P600
016300      10            KK51-TIKODE PICTURE  999.                     K7P600
016400      10            KK51-SECNBR PICTURE  99.                      K7P600
016500      10            KK51-SEC046 PICTURE  X(46).                   K7P600
016600      10            KK51-SEC022 PICTURE  X(22).                   K7P600
016700      10            KK51-SEC012 PICTURE  X(12).                   K7P600
016800      10            KK51-SEC031 PICTURE  X(31).                   K7P600
016900      10            KK51-SEC009 PICTURE  X(09).                   K7P600
017000      10            KK51-SEC007 PICTURE  X(07).                   K7P600
017100      10            KK51-SEC07A PICTURE  X(07).                   K7P600
017200      10            KK51-SEC07B PICTURE  X(07).                   K7P600
017300      10            KK51-SEC021 PICTURE  X(21).                   K7P600

donc dans ma section sec046 se trouve le montant en position 21 a 28.

en working j'ai essayé tout types de zones pour notamment traiter l'addition comme.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
01               WS00-MONTANT  PIC 9(13)V9(2) COMP-3.

ou encore

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

01               WS00-MONTANT  PIC 9(13)V9(2).

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
01               WS00-MONTANT  PIC 9(15)

j'ai passé le prog en debug est voici quand j'affiche ces zones montant en hexa;

sec046(21:8) --> 20 20 A9 E2 EF 0F 20 20 / dans le fichier j'ai (© ©)
working comp-3 --> 00 00 00 09 2F F0 00 0F / en debug apres move du fichier vers working j'ai (000000092??00,00).

et c'est comme ca pour tout les autres montants.

j'espere avoir donné assez de precision mais n hesitez pas a m en demander.

**el_slapper** · 20/08/2010, 13h45

Envoyé par nenekes

(.../...)
sec046(21:8) --> 20 20 A9 E2 EF 0F 20 20 / dans le fichier j'ai (© ©)
working comp-3 --> 00 00 00 09 2F F0 00 0F / en debug apres move du fichier vers working j'ai (000000092??00,00).

Juste ça, parceque j'ai pas le temps pour le lien :

"00 00 00 09 2F", c'est 92, non signé, en PIC 9(9ouplus)COMP-3
"F0", c'est un zéro normal, en EBCDIC.
"00 0F", c'est un zéro en PIC 9(2ou3)COMP-3

**Hédhili Jaïdane** · 20/08/2010, 15h24

Bonjour.

Pour moi "20 20 A9 E2 EF 0F 20 20" ne peut pas être la représentation hexadécimale d'un nombre décimal condensé (packed). Ni "20 20 A9 E2 EF 0F" d'ailleurs.
Puisque tu parles d'AS/400, je suis tenté de penser et même persuadé que tu as un problème de conversion EBCDIC/ASCII. Si les descriptions des données que tu donnes sont celles de fichiers AS/400, il y a fort à parier que la conversion s'est faite aveuglement caractère par caractère lors d'un transfert par FTP ou tout autre moyen (FTS, Client Access, etc...), or quand est confronté à des nombres, vus en tant qu'entité globale et non une chaine composée de caractères), ayant toute représentation autre que décimale étendue (ou à la limite en virgule flottante) , on doit les dépacker (les rendre en décimal étendu) avant de les convertir ou alors il ne faut pas les convertir.

**nenekes** · 20/08/2010, 18h15

donc finalement y a des chance que le fichier que je recois est ete mal transferé !

du coup de mon coté il n y a rien a faire !?

je vais essayer de savoir comment est generé ce fichier que je recois !

merci je ferai un retour.

bon week

**Hédhili Jaïdane** · 20/08/2010, 19h11

Envoyé par nenekes

...
du coup de mon coté il n y a rien a faire !?
....

Je n'ai pas dit ça non plus

zone montant packée

Cobol

Discussions similaires

Partager

Partager