Je ne doute pas que vous êtes des pros
J'ai vu dans ton fichier DUMP que tu avais encadré des valeurs hexa en rouge provoquant le décalage,
Il faudrait pouvoir lire le fichier hexa par hexa et le reconstruire correctement.
Je ne doute pas que vous êtes des pros
J'ai vu dans ton fichier DUMP que tu avais encadré des valeurs hexa en rouge provoquant le décalage,
Il faudrait pouvoir lire le fichier hexa par hexa et le reconstruire correctement.
J'ai accès au PC ou le logiciel qui contient les données est installé,
a quoi pourrait ressembler le fichier contenant la description des fichiers de données ?
Merci
Il faut faire une recherche sur le contenu. Mais tu dois avoir un maximum de PIC, comme ceux qui définissent les données dans le programme que je t'ai bricolé. Logiquement, il doit y en avoir beaucoup plus. Je dirais que COMP-3 est une bonne chaine de caractère à chercher(si ce PC est une brouette pleine de fichiers partout, ça risque de prendre pas mal de temps).
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.
Si le développeur a eu l'intelligence de mettre la description dans un fichier texte séparé, recherche aussi des fichiers avec un nom ressemblant à celui des fichier des données avec une extension en blanc, .txt, .cbl, .rcd, etc... ou contenant dans un select le nom du fichier des données.
Ce fichier doit contenir :
- peut être une ligne FD fichierdata....
- peut être un niveau 01
- et des lignes de niveau 02, 03, 04, 05 etc....
Ici il s'agissait d'un petit programme fait j'imagine rapidement pour répondre au besoin, mais je me permets de rappeler que dans un contexte plus général, il est préférable de ne jamais décrire les fichiers en FD mais seulement en working, et d'utiliser les instructions READ INTO et WRITE FROM.
J'ai déjà largement développé l'argumentaire sur ce sujet dans d'autres posts, donc pour faire court, c'est préférable car cancel garanti si utilisation avant open ou après close, le débugging est facilité et si vous utilisez des fichiers variables, le buffer (FD) est en chevauchement sur plusieurs records
Du coup
- en FD : juste un 01 FILLER PIC X(nnn) sauf si vous utilisez un KSDS auquel cas il faut décire la clef + un filler
- en WSS : la description complète à utiliser avec le READ INTO ou le WRITE FROM
Seul cas d'exception éventuel et très marginal : un fichier très variable par exemple de 20 à 25000 caractères, dans lequel il y a une très forte majorité de petits records et un grand nombre de record type différents (qui nécessitent donc beaucoup de zones de WSS peu utilisées)
En résumé, la FD c'est pour l'OS, la WSS c'est pour le développeur
Certes, mais ça fait trois ans que je n'ai plus accès à des sources, et j'ai donc du générer une moulinette à la volée, sur mon temps libre. J'ai fait au plus vite, pas pour figurer sur Stack Code Review. J'ai d'ailleurs précisé que mon programme était fort moche. Si j'avais du faire un programme de production, il aurait sans doute été trois à quatre fois plus long, avec des compteurs partout, des flags de gestion de lecture de fichier plus élaborés, avec effectivement des formats intermédiaires, voire des définitions dans des sources séparées via des COPY REPLACING, enfin bref, tout ce qui fait un vrai programme de production et pas un bricolage.
Mais là, pour le besoin ponctuel de Marco_Folio, sur mon temps libre, sans sources à pomper, je me suis contenté du strict minimum. Je n'avais pas 4 heures devant moi pour tout mettre aux normes - et pour expliquer tout ça.
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.
Voici a quoi ressemble les lignes du fichier avec le logiciel DataViewer :
Pouvez vous me faire un exemple que j'adapterai pour quand il y'a plusieurs zones à décompresser?
Merci
Ceux dont tu parlais ici El_Slapper:
MerciSi 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).
Bonjour.
Pour le signe, on n'a pas à trop se casser la tête à tester si la zone en entrée est positive ou négative et à décrire une zone signe en sortie. Il suffit de rajouter un SIGN LEADING SEPARATE à la zone en sortie.
03 MONTANT-I pic s9(9) comp-3.
.../...
03 MONTANT-O pic s9(9) SIGN LEADING SEPARATE.
.../...
MOVE MONTANT-I to MONTANT-O fera la conversion et placera le signe qu'il faut devant le montant.
Attention : la zone MONTANT-O tiendra sur 10 octets et non sur 9.
Si les zones sont nombreuses il faudrait penser à les décrire avec les mêmes noms dans les deux fichiers en entrée et en sortie et faire un MOVE CORRESPONDING (CORR).
Merci pour ces précisions,
Au final j'ai fait une fonction Windev qui va lire les valeurs compressées.
Tout fonctionne bien la lecture du fichier s'effectue sans décalage.
Je récupère dans une chaîne la valeur compressé et la convertie en Hexa.
Le seul problème qu'il me reste c'est faire la différence entre les 0 et les 2.
Par exemple : 122 en Hexa : 12 20 0F
Et 650 en Hexa 65 20 0F
Les 0 apparaissent en Hexa en 20 mais moi je lis caractère par caractère pour transcrire la valeur et je récupère 652 au lieu de 650.
Est ce que c'est un problème d"encodage du fichier?
Comment faire apparaitre les 0 sous la forme 00 en hexa et non 20?
Merci
Bonjour.
X'12 20 0F' hexa compressé = 12200 étendu non signé = X'31 32 32 30 30' hexa étendu non signé
et X'65 20 0F' hexa compressé = 65200 étendu non signé = X'36 35 32 30 30' hexa étendu non signé
Donc c'est bien 65200 et non 65000.
Pour info :
en ASCII :
X'00' = NUL = Low-Value ou zéro binaire
X'20' = ESPACE (SPACE)
X'30' = 0 (zéro)
Merci pour ces détails,
Le problème est que quand je consulte les données sur le logiciel la valeur est bien égale à 650 et non 652.
Y'a t'il une formule pour passer d'hexa compressé à hexa étendu?
C'est pas exactement une formule :
On va partir de l'exemple cité :
soit le nombre de 5 octets 65200, en ASCII, en hexadécimal il s'écrit X'3635323030', donc toujours sur 5 octets. L'idée du compressé est de supprimer ces 3 inutiles en prenant que la 2è moitié de chaque octet et en ajoutant un truc pour le signe, ça sera sur la 2è moitié du dernier octet de droite, ça nous donne alors la suite 65200S et on en fait des octets avec S = F/C/D :
X'65 20 0F' et ça nous fait que 3 octets, on en a gagné 2 au final. Si on ne sait pas que cette zone est compressée on va se planter dans l'interprétation de cette représentation , par exemple en considérant que le X'20' est l'espace alors qu'il s'agit des chiffres (digits) 2 et 0.
En recréant le fichier avec l'outil vutil32 je n'ai plus le problème, les 0 n'apparaissent plus en hexa avec la valeur 20.
Cette fois ça devrait être bon !
Merci a tous pour votre aide et votre réactivité !
On est dans un forum COBOL.
Ca dérive vers dataview et WinDev; logiciels autres.
J'ai surtout l'impression que WinDev lit des "trucs" en interprétant certaines choses (à définir) car:
* x'65 20 0F' ca te donne +65200 (ou +652,00) , regarde le poste de Hédhili Jaïdane. le x'20', ou Espace, semble ignoré, ce qui est problèmatique.
* les décalages sont là, quoique le logiciel te fera.
Je répète, sans une description stricte du fichier, tu ne seras jamais sur d'avoir le bon résultat en sortie.
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.
Partager