Discussion :

[escartefigue]

Le problème peut provenir d'une transco EBCDIC/ASCII par exemple (ou tout autre jeu de caractères), on rencontre souvent des soucis lors de transferts entre plateformes hétérogènes

[Marco_Folio]

Il semblerait qu'il y'ait des changements de syntaxe Cobol dans mon fichier texte, passant de la Version 1 à la version 2 (V1 V2 a la fin de certaines lignes)

Cela vous dit-il quelques chose?

[bernard59139]

Bonjour
Gaffe en traitant les fichiers "texte" avec du COMP dedans; ce n'est plus un vrai fichier "txt".

si une zone en comp contient les caractères CRLF (ou Cr ou Lf), la visualisation est "bizarre" via un editeur de texte.
Certains caractères peuvent perturber le programme, x'00' peut être interpréter comme une fin de chaine, ca dépend des langages et/ou des options.
comment est traité x'08' (ou backspace) etc .....

J'ai regardé vite fait le fichier, il n'a pas de structure fixe,
* les longueurs de records, ca dépend des lignes (ca doit dépendre de cr/lf présent dans des zones de comp).
* certaines colonnes ne sont pas du TEXTE alors que la ligne suivante, c'est du texte.

Et comme le suggère le collègue, il faut verifier l'encodage du fichier, ANSI <> ISO8859-1 <> utf-8 <> MS1252 , tous 4 utilisés par Windows.
Ultradit l'ouvre en MS1252.
Je ne connais pas le Cobol Windows pour aller plus loin.

Mais sans une description exacte du fichier, tu risques de passer énormément de temps du le sujet.

[Hédhili Jaïdane]

Bonjour.

Perso je ne pense pas qu'un changement en fin de ligne ait une quelconque incidence sur le décalage, j'ai pensé pluôt à un changement de structure du fichier entrant.
Ceci dit, et à titre d'exemple et en reprenant le dernier code posté,
- en supposant qu'il y a un changement de structure et qu'on peut identifier les enregistrements pour leur appliquer la structure adéquate
- Dans le code suivant, à adapter, je vais utiliser 2 structure qui diffèrent d'un caractère, si, par exemple, il y a un décalage à gauche d'un caractère, je vais utiliser 294 au lieu de 295, si au contraire, il y a un décalage à droite d'un caractère, je vais utiliser 296 au lieu de 295. Ensuite au lieu d'utiliser In-Digit1 j'utiliserais In-Digit2 :

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
FILE SECTION.
       FD  in-file.
       01  in-line1.
           05  In-Beginning1        PIC X(295).
           05  In-Digit1            PIC S9(9) COMP-3.
           05  In-End1              PIC X(250).
           05  In-Carriage-Return1  PIC X(2).
       01  in-line2.
           05  In-Beginning2        PIC X(294).
           05  In-Digit2            PIC S9(9) COMP-3.
           05  In-End2              PIC X(250).
           05  In-Carriage-Return2  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).
.../...
     * critère de selection 
         if .....
            Move In-Digit1 to out-digit
         else
            Move In-Digit2 to out-digit

[Marco_Folio]

Merci pour votre aide,

C'est une bonne idée pour corriger le décalage.

Je sais que le décalage intervient si la ligne d'avant est inférieur à 20 caractères.

Il faudrait tester la taille de la ligne, savez-vous comme cela se code en Cobol ?

Merci

[Hédhili Jaïdane]

ok, mais ça me parait pas trop orthodoxe comme critère.

- il y a bien la fonction LENGTH mais elle renvoie la longueur totale de la zone telle que définie dans le PIC sauf pour les zones à longueur variable ou en occurs depending.
Donc elle ne passera peut être pas.
faire : compute long = length (in-line)
long pic 9(9) display ou comp-3

- ou utiliser l'instruction INSPECT In-Line TALLYING compteur FOR CHARACTERS BEFORE INITIAL x"1310' [CR/LF]
compteur 9(5) display ou comp-3 à initialiser à 0 avant.

- ou utiliser une petite boucle et tu y vas à la mano.

Tout dépendra de ton compilo

[Marco_Folio]

Pouvez-vous l'intégrer à la moulinette en Cobol de El_Slapper car je ne maîtrise pas du tout ce langage et j'ai des erreurs dans tout les sens..

Merci

[el_slapper]

Franchement, COBOL n'est pas fait pour les fichiers de longueurs variables, donc je serais partisan de la troisième et dernière solution de notre modérateur préféré : travailler caractère par caractère.

Donc un fichier en entrée ou on ne prend qu'un seul caractère. Avec des variable mises à jour à chaque fois de "dernier caractère lu" et "avant-dernier caractère lu". Avec une rupture si ça fait X'1310'. Et un stockage de la ligne entre deux ruptures, avec compteur de longueur. Et ensuite, on applique le mapping que l'on veut. Mais c'est un gros truc à faire, et là, maintenant, je bosse.....

(ou alors un script Python ou VBA, mais j'ai un doute, avec tous ces caractères spéciaux, il y aurait un risque de mauvaise interprétation).

[Marco_Folio]

Oui c'est surement la meilleure des solutions ça sera plus précis

Merci de votre aide (quand vous aurez le temps )

[escartefigue]

Franchement, COBOL n'est pas fait pour les fichiers de longueurs variables, donc je serais partisan de la troisième et dernière solution de notre modérateur préféré : travailler caractère par caractère.

Et pourquoi donc ? il y a au contraire tout ce qu'il faut pour gérer le format variable au sein d'un programme COBOL (en tout cas avec les versions successives du mainframe jusqu'à Z/OS inclus), des difficultés peuvent se présenter hors COBOL et principalement quand on travaille sur un poste client, la plupart des outils mainframe prenant en compte parfaitement les fichiers variables

[Marco_Folio]

Dans mon fichier texte, les lignes ont bien toutes la même structure de données mais a un moment donné pour certaines d'entre elle il se produit un retour à la ligne alors qu'elle n'est pas terminé ce qui coupe la ligne en deux parties et au final fait que les lignes ne sont pas de même taille mais on voit bien que la structure des données de la ligne est la même.

[Hédhili Jaïdane]

Dans mon fichier texte, les lignes ont bien toutes la même structure de données mais a un moment donné pour certaines d'entre elle il se produit un retour à la ligne alors qu'elle n'est pas terminé ce qui coupe la ligne en deux parties et au final fait que les lignes ne sont pas de même taille mais on voit bien que la structure des données de la ligne est la même.

Certainement à cause de ce que disaient mes collègues à savoir un nombre en comp-3 qui contient un x"1310" interprété comme comme un CRLF.
Essaie avec/sans un LINE SEQUENTIAL dans le SELECT :

Code :

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

1
2
SELECT in-file ASSIGN "C:\Perso\input.txt"
               ORGANIZATION LINE SEQUENTIAL

[bernard59139]

Dans mon fichier texte, les lignes ont bien toutes la même structure de données mais a un moment donné pour certaines d'entre elle il se produit un retour à la ligne alors qu'elle n'est pas terminé ce qui coupe la ligne en deux parties et au final fait que les lignes ne sont pas de même taille mais on voit bien que la structure des données de la ligne est la même.

Tu as un retour à la ligne car une zone en COMP contient x'0D0A', donc un retour à la ligne suivante pour un fichier texte normal.
Tu veux traiter un fichier en mode "TXT" alors qui contient un peu de tout.

Pour passer, il faut lire par groupe d'octets (le groupe peut aller de 1 à n éléments) et reconstruire le tout.

Si cela est possible, la lecture devra se faire en mode "binaire" pour éviter toute conversion de caractères au moment du "read".

[Marco_Folio]

En effet avec le code :

Code :

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

ORGANIZATION LINE  SEQUENTIAL

Il n' y a plus de décalage après la décompression.

Bien joué ! On y est presque!

Une fois les valeur décompressées j'en ai certaines ou il y'a une lettre a la fin -0046524r en hexa "2D 30 30 34 36 35 32 34 72"

J'utilise la commande PIC S9(9) COMP-3.

Quelle est la différence avec PIC S9(9)V99 COMP-3 ?

En utilisant PIC S9(7) COMP-3 je ne récupère pas la valeur entièrement.

Merci

[bernard59139]

V99 c'est pour dire qu'il y a 2 chiffre après la virgule, cela va te prendre 1 octet supplémentaire en comp-3.

ceci étant dit, et en insistant, sans la description exacte du fichier, ce travail est impossible à faire sérieusement.
mes arguments:
- Le record 10, son format ne ressemble pas aux records précédents.
- Le record 11 à une longueur supérieure de 1 par rapport aux records précédents.

Et cela sur un fichier de 16 lignes.
Ce sent le fichier avec des records de taille variable avec des descriptions multiples (REDEFINE de zones).

bonne journée
a+

[el_slapper]

En effet avec le code :

Code :

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

ORGANIZATION LINE  SEQUENTIAL

Il n' y a plus de décalage après la décompression.
(.../...)

Cool, j'ai appris quelque chose.

Une fois les valeur décompressées j'en ai certaines ou il y'a une lettre a la fin -0046524r en hexa "2D 30 30 34 36 35 32 34 72"
(.../...)

Comme le dit Bernard, ça pue le fichier multiformat. la chaine hexa que tu nous a donné correspond exactement, en ASCII, à "-0046524r". Est-ce que tu l'as avant de passer dans la moulinette, ou après? Si c'est ce que tu as en entrée, alors "-0046524r" est bien le contenu du fichier. Si c'est de la sortie, il nous faut connaitre l'entrée.

[Marco_Folio]

"-0046524r" est la valeur que j'obtiens en sortie

Je prends l'exemple d'une autre valeur :

En hexa en entrée j'ai "31 02 7D" en sortie j'obtiens "2D 30 30 30 30 33 31 30 32 37" (-000031027)

La commande ORGANIZATION LINE SEQUENTIAL m'évite bien les décalages après les sauts de lignes mais certaines valeurs sont quand même faussées comme par exemple "+0105196=0" ou "+076500000" décalage vers la gauche qui enlève un chiffre.

[bernard59139]

Regarder le fichier joint, on voit très bien des différences et là ou le bazard commence.

Sans la description exacte du fichier, ce travail est impossible ou très difficile, avec un résultat qui risque de ne pas être celui désiré.
Comme il est surement question d'argent, je refuserai de faire le travail
a+

[Marco_Folio]

Merci pour le fichier, effectivement on voit bien ou a lieu le décalage.

Je n'ai malheureusement pas la description exacte du fichier

Je ne dispose de plus beaucoup de temps, connaissez vous des entreprises ou personnes sérieuses pouvant effectuer ce genre de travail?

[Hédhili Jaïdane]

Tous ceux qui sont intervenus dans cette discussion sont des pros et de grand calibre. Personnellement, et depuis le temps que triture des données dans tous les sens, je suis incapable de faire correctement ce genre de traitement dans ces conditions. Ceci dit ce n'est qu'un avis personnel.