Récupérer les valeurs de zones compressées fichier Cobol

**Marco_Folio** · 22/08/2016, 16h19

Bonjour à tous,

je fais actuellement de la récupération de données de fichier Cobol (vison file 4).

Jusqu'à maintenant j'ai pu récupérer tout ce que je voulais avec l'outil vutil( commande -extract) mais je tombe actuellement sur des zones compressées (valeurs numériques signées).

Comme dit dans la discussion il n'est apparement pas possible de décompresser ses zones avec vutil.

Vutil ne te sera pas utile pour les zones compresées. Il faut les lire avec Cobol ( en C c'est possible aussi, mais il faut trouver le bon format ...)

.zip avec la doc html fait 20 Mo, voici le lien. Attention, c'est la doc de la version 7 avec windows, mais cela na change pas grand chose pour les fichiers et les utilitaires

https://www.yousendit.com/download/W...Rnd0TWtLSkE9PQ

Le lien est mort, quelqu’un aurait-il plus d'infos à ce sujet, comment récupérer ces zones compressées?

Merci !

**el_slapper** · 22/08/2016, 17h00

Il y a tout plein de formats numériques compressés différents. Si tu n'as pas la définition exacte de chacune de tes données, tu est mort. Ou alors tu vas passer trèèèèès longtemps à te farcir de l'hexadécimal.

Si tu l'as, alors une petite moulinette en open cobol ide devrait largement suffire, en mettant en sortie le même format qu'en entrée, juste en remplaçant supprimant tous les COMP et autres COMP-1(ou 2, ou 3 , ou 4). Enfin, si il y a du COMP-5, c'est de la virgule flottante, et tu est chocolat, mais qui serait assez fou pour faire de la virgule flottante en COBOL(à part les gens qui ont testé la possibilité de le faire?)?

**Marco_Folio** · 22/08/2016, 17h42

Merci de m'avoir répondu rapidement

Je ne trouve pas les COMP dont tu me parles, sont ils visibles après ou avant l'extraction avec vutil ?

Je sais que je dois récupérer un entier signé d'une taille de 9 caractères.

Je visualise bien cette valeur en utilisant le logiciel data viewer (avec la version d'essai j'ai que les 50 premières lignes) mais en passant par vutil (extract) puis un éditeur de texte la valeur n'apparait pas.

A la place des montants j'ai des caractères NUL P ou @ ou %.

Merci pour ton aide !

**Marco_Folio** · 22/08/2016, 17h57

Le format de compression est du COMP-3.

Aurais tu des exemples de moulinettes de ce genre en Cobol ? car je ne maîtrise pas ce langage..

Merci.

**el_slapper** · 22/08/2016, 21h44

Normal, c'est effectivement de l'hexa. D'ailleurs, il existe une autre solution, faire une moulinette dans un autre langage qui transforme le BCD du COMP-3 en un nombre clair et lisible. Je l'ai fait déjà 3 fois, dans différents langages. Le concept est qu'en COMP-3, chaque chiffre est codé sur un demi octet, avec une correspondance directe, et que le dernier demi octet est le signe : B ou D étant des moins, C ou F des plus. Par exemple, X'01 56 9F' se lit +1569, et X'91 31 8D' se lit -91318.

Mais puisqu'on est sur le forum COBOL, je me suis amusé à faire un petit exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
      ******************************************************************
      * Author:el_slapper 
      * Date:2016
      * Purpose:COMP-3 to standard extended
      ******************************************************************
       IDENTIFICATION DIVISION.
      *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
       PROGRAM-ID. MOUL-COMP.
       ENVIRONMENT DIVISION.
      *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
       INPUT-OUTPUT SECTION.
       FILE-CONTROL.
           SELECT in-file ASSIGN "C:\Perso\input.txt"
               ORGANIZATION SEQUENTIAL
               FILE STATUS IS in-status.
 
           SELECT OPTIONAL out-file ASSIGN "C:\Perso\output.txt"
               ORGANIZATION SEQUENTIAL
               FILE STATUS IS out-status.
      *-----------------------
       DATA DIVISION.
       FILE SECTION.
       FD  in-file.
       01  in-line.
           05  In-Beginning        PIC X(10).
           05  In-Digit            PIC S9(9) COMP-3.
           05  In-End              PIC X(10).
           05  In-Carriage-Return  PIC X(2).
 
       FD  out-file.
       01  out-line.
           05  Out-Beginning       PIC X(10).
           05  Out-Sign            PIC X(1).
           05  Out-Digit           PIC 9(9).
           05  Out-End             PIC X(10).
           05  Out-Carriage-Return PIC X(2).
      *-----------------------
       WORKING-STORAGE SECTION.
       01  Misc.
           05 in-status            PIC XX.
           05 out-status           PIC XX.
      *-----------------------
       PROCEDURE DIVISION.
      *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
       DECLARATIVES.
       in-file-error SECTION.
           USE AFTER ERROR ON in-file.
           DISPLAY "Error occurred while using input.txt." in-status
           GOBACK
           .
       out-file-error SECTION.
           USE AFTER ERROR ON out-file.
           DISPLAY "Error occurred while using output.txt." out-status
           GOBACK
           .
       END DECLARATIVES.
 
       mainline.
           OPEN INPUT in-file
           OPEN OUTPUT out-file
 
           PERFORM FOREVER
               READ in-file INTO in-line
                   AT END
                       EXIT PERFORM
               END-READ
               MOVE In-Beginning TO Out-Beginning
               IF   In-Digit < ZEROES
                   MOVE "-" TO Out-Sign
               ELSE
                   MOVE "+" TO Out-Sign
               END-IF
               MOVE In-Digit TO Out-Digit
               MOVE In-End TO Out-End
               MOVE In-Carriage-Return TO Out-Carriage-Return
               WRITE out-line
           END-PERFORM
 
           CLOSE in-file, out-file
           .
       END PROGRAM MOUL-COMP.

J'ai testé, ça marche.....Sauf que je n'ai pas de COMP-3 sous la main, donc je ne peux pas être totalement sûr. D'ailleurs, il est moche, mon programme, mais je suis rouillé, et je n'ai plus accès à mes exemples favoris depuis Avril 2013.

Plusieurs choses très importantes.

D'abord, les retours chariots. J'ai assumé que tu avais des retours chariots de deux caractères(CHR(13) & CHR(10)). En tout cas, c'est ce que moi j'ai eu. D'ou le dimensionnement à 2 des variables in-carriage-return et out-carriage-return. Il se peut que ça soit un seul. Dans ce cas, redimensionne les deux variables Carriage-Return en PIC X(1). Tu le verras à un décalage dans ton fichier de sortie, si ça n'est pas bon.

Ensuite, le format de fichier. Je t'ai mis une seule zone à transformer, c'est la zone digit. LE reste, c'est de la zone libre. Mon fichier exemple, c'est 10 caractères libres, puis le chiffre à transformer, puis 10 caractères libres. C'est à toi d'adapter à ton besoin exact.

Enfin, la taille de la zone à transformer. Tu m'as dit 9 chiffres. Je suis parti sur l'idée que c'était 9 chiffres en étendu. Mais, en COMP-3, ça ne fait que 5 caractères, puisque chaque chiffre ne prend qu'un demi caractère, et le signe un demi caractère aussi. Donc si c'est le cas, ton fichier en entrée fait 50 caractères, mais on passe de 5 à 9 caractères, et on ajoute le signe en lisible, ça fait 55 caractères en sortie.
Mais si en fait, c'est 9 caractères en COMP-3, ça nous fait du PIC S9(17) COMP-3. en entrée, et PIC 9(17). en sortie(ne pas oublier les points, le compilateur est canulant là-dessus). Et alors ton fichier en sortie fera 59 caractères.

Donc, installes OpenCobolIDE, crée un nouveau programme .cob avec le template program, efface tout, copie mon exemple à la place, remplace les noms et chemins de fichiers, ajuste les longueurs à ton besoin, sauvegardes, compiles, executes, et si tout va bien, tu auras un fichier de sortie. A toi de voir si il te plait. Sinon, donne moi plus de détails pour que je creuse.

(ou alors tu maitrises un autre langage à fond, tu sais y manipuler de l'octet en claquant des doigts, et ma description du COMP-3 te suffit - c'est au choix)

**Marco_Folio** · 23/08/2016, 10h13

Merci beaucoup pour tes explications, ton code marche à merveille !

Par contre dans mon fichier texte je sais que la valeur que je veux décompresser commence au 294 éme caractère de ma ligne.

j'ai donc fait :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
DATA DIVISION.
       FILE SECTION.
       FD  in-file.
       01  in-line.
           05  In-Beginning        PIC X(294).
           05  In-Digit            PIC S9(9) COMP-3.
           05  In-End              PIC X(10).
           05  In-Carriage-Return  PIC X(2).
 
       FD  out-file.
       01  out-line.
           05  Out-Beginning       PIC X(294).
           05  Out-Sign            PIC X(1).
           05  Out-Digit           PIC 9(9).
           05  Out-End             PIC X(10).
           05  Out-Carriage-Return PIC X(2).
      *-----------------------

Ca marche bien pour la 1ére ligne mais je ne vois pas de retour chariot dans mon fichier texte.

Je sais que les lignes de mon fichier font 556 caractères de long donc il faudrait que pour la première ligne on décompresse a partir du 294 éme caractère puis tout les 545 caractères (556 - 305) + 294

Voici a quoi ressemble une ligne dans mon fichier (après avoir décompressé la valeur, ici +000000125) :

001010310001000000201604110000000000*************0010000000425FZE 20 0000051221AFDRBRATADOR Odette Lot 7 +000000125 20160411 20160510 No 01 Cpt 00 10310001001045002002000007 0000000000 R

Aurai tu une idée de comment transcrire ça en Cobol?

Merci

**el_slapper** · 23/08/2016, 12h27

Alors....

Pour les retours chariots : tu est sous Windows?(parcequ'en Linux, je ne maitrises pas grand chose) Si oui, ouvre ton fichier avec un bête éditeur de texte. Si tu as tes lignes bien séparées, alors tu as des retours chariots. Mais ils se limitent parfois à un seul caractère. Cela dit, si tel est le cas, tu devrais avoir en sortie un fichier en "zigzag", avec chaque ligne qui est décalée d'un cran par rapport à la précédente. Or tu me dis que ça ne marche que pour une seule ligne. ça, ça m'inquiète un peu. Tu as quoi, exactement, en sortie?

Pour le format exact, si j'ai ien compris, il y a une seule valeur à décompresser? Tu as 556 caractères. Si le caractère 294 est le premier du compressé, alors la zone beginning fera 293 de long. Et la zone end, 556 - 293 - 5(la taille de la zone compressée), soit 258 caractères(et non pas 10 comme dans mon exemple). Il faut évidemment changer à chaque fois l'entrée ET la sortie.

Si tu as plusieurs zones à décompresser, alors il faut rajouter deux zones à chaque fois en entrée, et trois en sortie : la zone ""texte"" entre deux(inchangée, tu fais juste un move), la zone signe en sortie(à calculer à chaque fois), et la zone numérique proprement dite(le move fait le transfert et la conversion en même temps).

**Marco_Folio** · 23/08/2016, 14h32

Merci pour les précisions,

c'est bon j'arrive bien à tout récupérer en décalant de 250 caractères après chaque zone compressée.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
FILE SECTION.
       FD  in-file.
       01  in-line.
           05  In-Beginning        PIC X(295).
           05  In-Digit            PIC S9(9) COMP-3.
           05  In-End              PIC X(250).
           05  In-Carriage-Return  PIC X(2).
 
       FD  out-file.
       01  out-line.
           05  Out-Beginning       PIC X(295).
           05  Out-Sign            PIC X(1).
           05  Out-Digit           PIC 9(9).
           05  Out-End             PIC X(250).
           05  Out-Carriage-Return  PIC X(2).

Un grand merci ! Tu m'aura fait gagner énormément de temps en partageant ton expérience en Cobol !

**Marco_Folio** · 06/09/2016, 11h34

Bonjour,

Ton programme fonctionne très bien sur toutes les valeurs des fichiers que j'ai décompressés mais j'ai un dernier fichier un peu différent des autres.

Pour les 100 00 premières lignes tout se passe bien puis un décalage se crée d'un cran vers la gauche ce qui fausse la suite du fichier jusqu'à la fin.

Aurais tu une idée des caractères qui peuvent provoquer ce genre de décalage?

Merci

**escartefigue** · 06/09/2016, 17h15

Bonjour,

Pouvez vous communiquer une extrait du fichier en entrée, comportant une ligne OK et une ligne KO (par exemple la ligne 9 999 et la ligne 10 000)
en mettant en couleur la zone que vous souhaitez dépacker, et avec une police non proportionnelle, exemple courrier-new (de sorte à aligner les zones)

**Marco_Folio** · 06/09/2016, 17h53

Voici une ligne OK

41001001 0000006000000018201207010000000152*************100002279MBO 29 rem0012671ODBQJUILLET 12 CHELTIEL KARINE * 41103003011500000000000000000000000000 ’X €

Le soucis est que la zone a décompressée correspond à des caractères NUL dans mon fichier texte "NULSOH'XGS", Elle se situe a la fin de la ligne ou il y'a le 'X

Une ligne KO

41001001 0000006000000018201208010000000115*************100002474MBO 29 rem0014473ODBQAOUT 12 CHELTIEL KARINE * 41103003011500000000000000000000000000 ’X €

La zone a décompressée se situe également à la fin de la ligne au niveau du 'X
Elle correspond aux caractères "NULSOH'XGS" dans mon fichier texte.

Merci de votre aide

**Marco_Folio** · 07/09/2016, 10h57

Voici directement un extrait des fichiers textes, le premier est celui avant la décompression des valeurs.

Dans le 2éme fichier après la décompression le décalage apparaît a la ligne 12.

Merci aux cobolistes qui pourront y jeter un oeil !

**escartefigue** · 08/09/2016, 09h06

D'après ce que je vois en ouvrant le fichier d'entrée EcritACTU.txt avec ultraedit, il y a déjà des décalages dans ce fichier, les enregistrements ne sont pas alignés.

**Marco_Folio** · 08/09/2016, 09h49

Merci pour ta réponse, et d'avoir mentionné l'éditeur de texte ultraedit, il est très pratique !

Effectivement il y'a des décalages sur le fichier d'origine, sais tu comment je pourrais réaligner tout correctement?

Existe-t-il une fonction sur ultraedit car le fichier original fait 600 000 lignes

Merci !

**el_slapper** · 08/09/2016, 11h42

Le problème semble être la présence d'un caractère spécial dans le fichier, qui décale tout ce qu'il y a après. Ca ne me parait pas anodin du tout, il faudra savoir ce qu'il y avait à la place dans le fichier d'origine. En hexadécimal.

Une fois cette information détectée, on peut faire une moulinette dans un langage quelconque pour rétablir la vraie valeur, puis ensuite repasser ledit fichier dans ta moulinette corrigée. Mais sans cette information, on risque de perdre des données fonctionnelles.

**Marco_Folio** · 08/09/2016, 12h05

Voici la ligne a partir de laquelle apparait le décalage :

Code :

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

1
2
3
    41001001  0000006000000018201207010000000152*************100002279MBO     29      rem0012671ODBQJUILLET   12        CHELTIEL KARINE *       41103003011500000000000000000000000000                 ’X   €
                                                                   8  ’X   €                                                                   8   Q   Ÿ                                                                      00                                 gqui07                    Prelev.                           41103003   0000006000000018201207010000000000  
  V2

J'ai fait une capture d'écran pour avoir la ligne en hexa

**Hédhili Jaïdane** · 08/09/2016, 13h00

Bonjour.

- Il faudrait que tu aies une idée bien plus précise sur la structure du fichier en entrée parce qu'avec du tâtonnement tu risques de ne pas y arriver.
- S'il y a un changement dans la description, suite par exemple à un changement de version, il faudrait avoir des critères précis pour pouvoir identifier chaque type d'enregistrement et on pourra alors faire des redefines implicites en définissant plusieurs niveaux 01 du FD.
- Perso, en regardant la capture d'écran, je vois déjà d'autres nombres en comp-3 dans les 295 premiers caractères que tu as zappés.
- Certains de ces nombres en comp-3 semblent être du s9(7) et non du s9(9). Ils tiennent sur 4 octets.
- s9(7) comp-3 tient sur 4 octets alors qu'un s9(9) tiendra sur 5. [nb octets = E(digits/2) +1].

**Marco_Folio** · 08/09/2016, 14h09

Merci Jaïdane pour ces précisions.

Le problème est que je récupère les données d'un client et j'ai juste les fichier.vix (acucobol indexés).

A quoi reconnais tu en hexa qu'il y'a des valeurs compressées en COMP 3?

**Hédhili Jaïdane** · 08/09/2016, 15h13

Envoyé par Marco_Folio

Merci Jaïdane pour ces précisions.

Le problème est que je récupère les données d'un client et j'ai juste les fichier.vix (acucobol indexés).

Aucune idée sur la structure du fichier ou le programme qui le crée quel que soit le langage ? Dommage !

A quoi reconnais tu en hexa qu'il y'a des valeurs compressées en COMP 3?

Une suite d'octets (2 demi-octets) contenant que des chiffres avec un F/C/D dans le 2è demi octet du dernier octet.
Exemple : X'01 92 58 1D' = -192581, X'14 51 1F' = 14511
Attention : beaucoup de confusions peuvent être faites, surtout en ASCII, moins qu'en EBCDIC (monde IBM et des mainframes d'autres constructeurs).

Tu remarqueras que je n'ai pas considéré les X'20' précédant ces exemples généralement supposés êtres des SPACES mais pouvant très bien faire partie de nombres en Comp-3.

**Marco_Folio** · 08/09/2016, 15h34

OK merci pour cette explication.

Je sais juste pour la structure du fichier qu'il y'a 5 ou 6 valeurs numériques a récupérer par ligne entre les caractères 184 et 517.

Pour les autres fichiers je n'ai pas eu ce problème de décalage je me calais sur la valeur numérique avec mon programme cobol et il décrypter bien la valeur sans décalage jusqu'à la fin du fichier.

Après je ne suis pas un expert en Cobol peut être existe -t- il une ligne de code pour vérifier les décalages?

Récupérer les valeurs de zones compressées fichier Cobol

Cobol

Discussions similaires

Partager

Partager