|
Publicité ' | |||||||||||||||||||||||
|
|
#1 |
|
Invité régulier
![]() Inscription : septembre 2007 Messages : 38 ![]() |
Bonjour
Lors d'une lecture en parallèle de deux fichiers, je me heurte au problème suivant : - les enregistrements contiennent une rubrique de format S9(9) COMP-5 SYNC - lors de la comparaison rubrique par rubrique de tout l'enregistrement, je détecte des écarts sur celles se trouvant après la rubrique en COMP-5 SYNC - ces écarts ne sont pas des écarts réels : ils proviennent uniquement d'un décalage de deux caractères, comme si la rubrique en COMP-5 SYNC ne faisait pas systématiquement la longueur qu'elle est censée faire. Exemple d'enregistrement : 01 GROUPE. 05 RUB-1 PIC X. 05 RUB-2 PIC X(4). 05 RUB-3 PIC X(4). 05 RUB-4 PIC S9(9) COMP-5 SYNC. 05 RUB-5 PIC X(2). 05 RUB-6 PIC X(2). RUB-5 et RUB-6 apparaissent toujours en écart entre "source" et "cible" car le COMP-5 SYNC semble générer un décalage de deux caractères à la lecture du second fichier. Avez-vous déjà rencontré ce type de problème ? Merci par avance pour les informations que vous pourrez me transmettre. Dvi =============================================== Précisions : en utilisant un outil de visualisation du contenu du fichier, il apparaît que la valeur de la rubrique en COMP-5 SYNC est rgulièrement la même dans les deux fichiers. Ce serait donc la manipulation de cette donnée dans le programme qui entraînerait ce décalage. Principe : - lecture des deux fichiers en positionnant une clé de comparaison en début d'enregistrement (nouvel enregistrement = clé + zone banalisée contenant l'enregistrement d'origine) - lecture en parallèle des deux fichiers triés avec comparaison des clés créées précédemment puis, sur clés identiques, bascule de la zone banalisée vers la zone standard correspondant à l'enregistrement et comparaison rubrique par rubrique (c'est dans cette dernière étape que le décalage apparaît) =============================================== |
|
|
00
|
|
|
#2 |
|
Invité régulier
![]() Inscription : septembre 2007 Messages : 38 ![]() |
En travaillant en "zone à zone" plutôt qu'au niveau groupe (lors de l'alimentation de la rubrique puis de sa re-lecture), je ne rencontre plus le problème de décalage.
La solution semble trouvée mais je suis malgré tout preneur d'une explication "officielle" : - est-ce que le fait de mouvementer un groupe de niveau 05 vers un autre groupe de niveau 10 peut modifier la synchronisation réalisée par la rubrique en COMP-5 SYNC ? Merci par avance pour vos remarques. Dvi |
|
|
00
|
|
|
#3 | ||
|
Expert Confirmé
![]() Consultant/Formateur/Développeur AS/400, iSeries, System i et Cobol Inscription : juin 2007 Messages : 1 781 ![]() |
Bonjour.
C'est à cause de la clause SYNC (SYNCHRONIZED) qui ajoute des fillers (Slack bytes) pour aligner la rubrique sur un demi-mot, un mot, un double mot ou un quadruple mot à partir du début de l'enregistrement. Voir, par exemple, ce lien : http://publib.boulder.ibm.com/infoce...39370.htm#sync Si tu travailles au niveau de la zone, il n'y a aucun problème. Par contre si tu travailles au niveau de groupes qui n'ont pas la même description, y compris le SYNC, là tu vas avoir des problèmes à cause des slack bytes insérés par le compilateur. Examples : Code :
|
||
|
|
10
|
|
|
#4 | ||
|
Invité régulier
![]() Inscription : septembre 2007 Messages : 38 ![]() |
Merci pour ces informations.
Afin de toucher du doigt le problème, j'ai créé un petit programme pour tenter de voir à quel moment (avec quel type de move) pouvait apparaître un décalage. Tel que je l'ai écrit, le programme ne fait jamais apparaître de décalage. Pourrais-tu m'apporter des précisions sur les traitements qui entraîneraient un décalage potentiel, s'il te plaît ? Ou m'indiquer à quel niveau je fais erreur dans mon programme de test ? Merci Dvi Code :
|
||
|
|
00
|
|
|
#5 | ||
|
Expert Confirmé
![]() Consultant/Formateur/Développeur AS/400, iSeries, System i et Cobol Inscription : juin 2007 Messages : 1 781 ![]() |
En fait c'est à toi de nous dire si ça marche ou non et dans ce cas quelle est l'erreur et où.
Grossièrement, la règle est la suivante : à chaque fois que le compilateur rencontre un SYNC, il insère, juste devant et avec le même niveau, un filler de telle façon que la taille totale de toutes les zones précédentes la zone en SYNC, y compris les éventuelles insertions précédant dues au SYNC, et ce à partir du niveau 01, soit multiple de 4 (dans ton cas). Donc si ta zone en SYNC occupe le même emplacement à partir du niveau 01 et est précédée des mêmes zones en taille (et en type éventuellement). Dans le programme que tu donnes, les 3 premiers groupes sont définis de la même façon, donc le MOVE de groupes ou des zones élémentaires ne devrait pas poser de problèmes. Le 4è groupe est différent, même si ses groupes sont identiques, la taille du slack-bytes inséré sera donc différente puisqu'on commence à totaliser les longueurs à partir du niveau 01. Sauf que là, tu as de la chance puisque 200 est multiple de 4. Ton 3è MOVE doit donc marcher. Fais des DISPLAY de tes niveaux 01 et tu verras les alignements des zones. Regarde aussi ton listing de compilation, il devrait contenir les insertions du compilateur. En récap : - dans les 3 premiers groupes : 13/4 = 3 , reste = 1, donc on insère un filler de 3 octets (4 - 1 = 3) - dans le 4è groupe : 213/4 = 53, reste = 1 donc pareil, on insère un filler de 3 octets. Change ta zone de 200 en 199 et tu verras le décalage. Code :
|
||
|
|
10
|
|
|
#6 |
|
Invité régulier
![]() Inscription : septembre 2007 Messages : 38 ![]() |
Effectivement, j'ai fait en sorte de ne plus avoir un multiple de quatre avant le groupe AB9X et le décalage est apparu.
Je posterai le mini-prog et le résultat au plus tôt, pour permettre à ce que ça intéresse d'imager ma question. Par contre, je n'arrive pas à avoir un résultat de compil dans lequel apparaissent les fameux filler ajoutés ... Faut-il une option de compil particulière ? |
|
|
00
|
|
|
#7 |
|
Expert Confirmé
![]() Consultant/Formateur/Développeur AS/400, iSeries, System i et Cobol Inscription : juin 2007 Messages : 1 781 ![]() |
T'en fais pas trop, ton compilo ne doit pas générer les slack bytes dans le listing de compilation, mais il en tient compte dans la génération du dictionnaire des données et dans le calcul des offsets.
|
|
|
00
|
|
|
#8 | ||
|
Invité régulier
![]() Inscription : septembre 2007 Messages : 38 ![]() |
Code :
|
||
|
|
00
|
|
|
#9 | ||
|
Invité régulier
![]() Inscription : septembre 2007 Messages : 38 ![]() |
Code :
|
||
|
|
00
|
Copyright © 2000-2013 - www.developpez.com