D'où ma question "Autre chose, le fichier que tu as en entrée, vient-il du même environnement ? AIX ?" qui sous entendait un pb de conversion ASCII/EBCDIC.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
D'où ma question "Autre chose, le fichier que tu as en entrée, vient-il du même environnement ? AIX ?" qui sous entendait un pb de conversion ASCII/EBCDIC.
Je vois qu'on a tous pensé à la même chose. Il est possible de faire "à la main" une conversion ASCII-EBCDIC, mais encore faut-il savoir sur quoi ça s'applique. J'ai l'impression qu'il y a du packé lisible correctement - mais décalé - et des caractères ASCII - à convertir.
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
oui bien sur mais pour le moment j attend de voir ce qui me repond le gars du fichier foireux
Envoyé par el_slapper
j'espere avoir des reponses a tous car pour l instant je suis bien embeté avec mes montants completement illisible
Bonjour a tous,
de retour sur cette discussion;
je n'ai pas d'autre choix que de recevoir ce fichier tel quel !!!
y a t il un moyen de convertir cette zone packée pour decripter le contenu ? en cobol ou autre ?
merci par avance
A mon avis il ne faut surtout pas que l'appli réceptrice bidouille le fichier, il faut régler le problème à la source : les tables de transco (codepage produit ou autres...) doivent être d'équerre. Voit plutôt avec les équipes transverses, supports, le bureau technique, ou toute personne ayant le lead sur ce point. Imagine qu'un autre projet fasse le nécessaire pour que le mapping ASCII/EBCDIC soit OK, tu devras faire évoluer ton dev du jours au lendemain.
.
+1
le problème est probablement au niveau du transfert, pas de l'appli amont. Ne cherche pas à corriger l'appli amont(elle est certainement d'aplomb). Juste, fouille les processus de transfert, il doit y avoir des choses à corriger. Et ensuite, tu pourras travailler.
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
Par FTP, j'ai copié l'échantillon d'enregistrements du post #9 de ce fil dans une table (fichier) que j'ai définie conformément à la définition des enregistrements indiquée dans la pièce jointe au post #16 de ce même fil.
Voici la définition en question.
Voici cette même définition reprise pour créer la table par SQL sur l'AS400.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12
13
Voici ce que j'obtiens après FTP.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12
Le dump hexadécimal nous permet de voir où se situent les zones packées.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12FFFF0046145004B4444444B45044B54704B560487444414444 01482100F27F3040000000427F00380F3048F175F000090000 FFFF0046145004B4444444B45044B54704B060240444404444 01482100F27F2040000000427F00380F20476180F000070000 FFFF0046145004B4444444B45044B54704B782084444414444 01482100F27F2040000000427F00380F20428664F000020000 FFFF0046145004B4444444B45044146604B047A1B444454444 01482100F27F3040000000427F00003F304303E84000070000
On peut voir que le format de l'enregistrement n'est pas aligné avec leur contenu à partir de la rubrique MDT_CLD, qui est en position 13 dans le buffer. Cette rubrique est censée être une rubrique packée déclarée sur 4 octets ( occupant donc 3 octets dans la table ) sans décimales et on a de la "choucroute" à la place.
On ne pourra jamais rien faire de ces données si on n'a pas la définition exacte de chaque zone qui compose l'enregistrement.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
Au passage, mais cela n'a peut-être pas d'incidence sur le problème qui nous préoccupe, j'ai remarqué que la rubrique FELTLAENGDE est censée contenir la valeur "42" si je m'en tiens à la définition donnée, or elle contient "48". Est-ce normal ?
oui effectivement un mauvais copié/collé ! mais cela ne change rien au probleme, les lignes sans foutu pareil !
par contre pour la definition je n'ai pas d'autre car celle que j'ai donné c'est la seule qui m'a ete fourni par le site qui m'envoi le fichier !
maintenant reste a savoir comment il transfert le fichier avant de me le fournir !
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12
13
j'ai deja demandé mais aucune reponse a ce jour, je relance et je vous reviens.
en tout cas merci pour l'aide apportee
Refais un nouveau copié-collé ici mais plus étoffé que le précédent stp.
Voici un copié collé d'un fichier type que je suis sencé recevoir;
les trois premiers caractere num "356 ou 351" donne le type d'enregistrement
les deux suivant numerique egalement (12, 04 ou 11) donne le nombre de sections de l'enregistrement.
puis les deux d'apres ("01") c'est la section une, puis deux ......ect
les deux d'apres ("48" ou "42") caracterique le type d'enreg (valeur par defaut)
je joint la description du type "356" car j'avais joint en #16 celle du "351" !
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
J'ai transféré par FTP sur le serveur AS400 uniquement les 3 enregistrements "351" que tu as collés dans ton dernier message et analysé le dump hexadécimal de ces enregistrements pour me focaliser essentiellement sur eux. J'ai constaté trois choses :
- Les sections se trouvent à la queue leu leu dans les enregistrements.
- Les données contenues dans la section "01" de 2 enregistrements sur les 3 sont erronées.
- Les données des sections suivantes me semblent ok.
Si les positions 1 à 17 de la section 01 paraissent ok, les données ne sont plus conformes à la définition à partir de la position 18 (Mdt-cld). On dirait qu'il y a du binaire sur une longueur de 3, au lieu de "packé", ce qui semble très étrange. Ensuite, tout le reste de cette section de 51 caractères de long, est "choucrouté".
Sans données correctes, tu ne peux pas exploiter proprement les infos qu'on t'envoie. Rapproche toi encore de l'émetteur afin d'obtenir satisfaction.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12*...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+....0....+....1....+. 351040142 - âï © ©âï © © ?-©DKK0218âï - 000094288 0308 - d 0427 0000061488943100027âò·Ë N FFFFFFFFF0046145004B4444444B45001B44444B4444466BCDDFFFF45000461FFFFFFFFF4FFFF00461482FFFF01FFFFFFFFFFFFFFFFFFF4CB73D 3510401422100F27F3040000000427F30400000400000F04422021827F2100F000094288003082100F04F04277F00000614889431000272D33F5 351040142 - âï Í^ ©âï Í^ © ld DKK0218âï - 000094289 0308 - d 0427 0000000000112868542âÅ º?N FFFFFFFFF004614500754444444B45007544444B44440981CDDFFFF45000461FFFFFFFFF4FFFF00461482FFFF01FFFFFFFFFFFFFFFFFFF46196D 3510401422100F27F55F0000000427F55F0000040000334F422021827F2100F000094289003082100F04F04277F0000000000112868542279BF5 351040142 - âï h© ©âï i© © ÒÌéDKK0218âï - 000094291 0308 - d 0427 0000000000606395994â Ý N FFFFFFFFF0046145048B4444444B45048B44444B4444E76BCDDFFFF45000461FFFFFFFFF4FFFF00461482FFFF01FFFFFFFFFFFFFFFFFFF41A13D 3510401422100F27F0840000000427F0940000040000D864422021827F2100F000094291003082100F04F04277F000000000060639599421D2F5
ouais effectivement de la choucroute, ca m etonne pas du tout
j'ai deja envoyé une quantité de question a cet emeteur un tant soit peu mal adroit
sinon saurais tu me dire si les zones pachees sont en comp ou comp-3 ou autre ?
encore merci
si c'est du comp tout court, alors tout peut correspondre. Il faudra savoir fonctionellement quel genre de chiffres tu attends.
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
tu veux dire quoi par la tout peut correspondre?
j'attend un montant avec deux decimales apres la virgule : genre 1587.12 ...
Si ma mémoire est bonne, COMP-3 veut dire "packé" (ou décimal condensé) chez COBOL et COMP, c'est binaire.
Par exemple, la date qui figure dans le 1er enregistrement est packée et contient la valeur 020140601 (1er Juin 2014).
Le dump hexadécimal se lit colonne par colonne du haut vers le bas :
Je lis par colonne de haut en bas : zéro-deux, zéro-un, quatre-zéro, etc.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
Le " F ", c'est le signe + ou la valeur absolue (sous OS/400). Une valeur négative serait représentée par un " D ". Le signe des zones packées est toujours placé sur le dernier demi-octet de la zone.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
Pour le binaire, je reprends la valeur de MDT_CLD, qui est en position 13 dans le buffer. Cette rubrique est censée être une rubrique packée déclarée sur 4 octets ( occupant donc 3 octets dans la table ) sans décimales et on a de la "choucroute" (ou du binaire ?) à la place.
Même méthode de lecture que le packé. Je lis alors la valeur binaire codifiée en hexadécimal 0340B4 ( pour simplifier la lecture de la valeur équivalente 110100000010110100 représentée ici en base 2 (binaire)), c'est à dire 213172 en base 10 ou en décimal. Capice ?
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
j'ai eu la réponse concernant la facon dont sont packé les champs numeriques, a priori ce serai du comp-3 (bizarre ...)
mercure merci pour tes explications, neanmoins j'avoue ne pas a voir saisie la derniere partie !!
j'attend toujours ma reponse sur la maniere dont ils transferent ce fichier avant de me l'envoyer !
Code : Sélectionner tout - Visualiser dans une fenêtre à part Même méthode de lecture que le packé. Je lis alors la valeur binaire codifiée en hexadécimal 0340B4 ( pour simplifier la lecture de la valeur équivalente 110100000010110100 représentée ici en base 2 (binaire)), c'est à dire 213172 en base 10 ou en décimal. Capice ?
Relis ce que j'ai écrit. COMP-3 ou COMPUTATIONAL-3 est tout à fait correct et n'a rien de bizarre en Cobol pour déclarer des zones en packé ou en décimal condensé qui est l'appelation plus "officielle" .
Je veux dire que le contenu des zones déclarées en binaire dans les fichiers et dans les programmes (c'est à dire en COMP pour les Cobolistes) est affiché en hexadécimal mais uniquement pour simplifier leur lecture.
Ainsi, dans l'exemple du post précédent, si la zone en position 18 sur une longueur de 3 (ce 3 est déjà bizarre) est déclarée en binaire dans le fichier, son contenu a pour valeur "0340B4" . Ce contenu est affiché en hexadécimal au lieu de son "vrai" contenu binaire : "000000110100000010110100", c'est à dire 213172 en décimal.
Je veux dire que la valeur hexadécimale n'est affichée là que dans le but de simplifier la lecture. C'est en quelque sorte un artifice pour éviter de se mélanger les crayons à la lecture avec les 1 et les 0 du binaire.
Imagine un peu si tu ne voyais que des 1 et des 0 sur les enregistrements, cela deviendrait vite indéchiffrable.
Bonjour
J'ai l'impression de plusieurs problèmes
le transfert
Transférer de ascii vers ebcdic un fichier avec des zones "packées" est, à mon sens, une grosse erreur. Il y aura toujours des problèmes de conversion
- soit on développe dans l'environnement d'origine du fichier
- soit on corrige l'application pour avoir tout en étendu
- Soit on dépacke avant le transfert
- soit on fait sa petite conversion à la main (avec tous les risques possibles, comme un changement de codepasge à l'origine)
Le definition du fichier
dans un message tu dis que la zone FELTLAENGDE n'a pas la "bonne valeur.
Cette zone est apparement en format étendue. Un transfert ascii/ebcdic ne fera que convertir les caractères.
rien cette remarque me fait dire que tu n'as pas les bonnes informations à ta disposition. ET je ne vois pas comment te proposer une réponse simple.
Bonne journée
packed or not packed
Bonjour,
personnellement j'ai dans un coin, un petit "bricolo" cobol à exécuter en batch dans lequel je peux donner un nom de fichier (jcl/cl à refaire) ou bien je lui rentre directement une valeur dans une variable : je le recompile et je l'exécute.
çà me permet de gagner un temps fou, pour voir le comportement du cobol.
Donc amateurs : "à vos ardoises" ! C'est très simple.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager