Discussion :

[Lemmings1406]

Bonjour à tous,

Un petit soucis que les développeurs de ma boite ont rencontré.

C'est sous un environnement Cobol/DB2 V8 sous Z/os 1.7.

En interrogeant une table avec des caractères signés sous SPUFI, la table est bonne. Jusque là, pas de problème. Ensuite un programme COBOL est déroulé, il interroge la table, récolte les info nécessaire et écrit le résultat dans un fichier et là, ça se complique, les "é" sont remplacé par "{" entre autre.

Je suis admin DB2 et j'ai réalisé la migration de la V7 à la V8, j'ai vérifié tout l'environnement, les CCSIDs des émulateurs, du DB2, des packages... rien trouvé.
Je tiens a préciser que le problème ne se produit que sur une seule partition, le même programme déroulé sur une autre partition donne un résultat correct.

Je viens donc faire appel à vos compétences. Est-ce que COBOL peut être mis en cause???

Merci à l'avance pour vos réponses.

PS: Si il y a des admins DB2 qui pensent à des vérifications à faire, je suis preneur.

[Homer-ac]

Bonjour,
Pas impossible que ça vienne d'Entreprise COBOL. Je pense a une option de compilation 'CODEPAGE' en particulier (1140 par défaut). Comme par chance c'est OK sur une LPAR, il sera surement intéressant de compiler un PGM de test sur les 2 et comparer les options de compilation, C'est listé en tête du listing de compilation (Find 'EFFECT' pour options in effect puis chercher CODEPAGE ou CP), il y a des chances que le CCSID soit différent sur les 2 Si il y a écart, vérifier le source (option de compile possible via une 'carte' CBL ou PROCESS en tète du source, le PARM de l'exec PGM IGYCRCTL de la compile et enfin les options d'install d'Enterprise COBOL. Puisque les options de compile sont dans le load module, il y a des chance que l'on puisse également y trouver le codepage mais je n'avais pas noté ça et je vais chercher.
nb. j'oubliais, un point important à vérifier, on utilise une précompile ou le coprocesseur SQL ? Si le coprocesseur SQL est utilisé, c'est avec SQLCCID ou NOSQLCCID ? Il faudrait vérifier en remplaçant l'un par l'autre, ou ça peut venir du fait que l'on fait une précompile DB2 sur une LPAR et via le copro SQL sur l'autre ?

[Lemmings1406]

Les PGM sont développés sur une autre partition et compilés puis sont envoyés en pré prod (où ça marche pas) et en prod (où ça marche). Il ne peut donc pas y avoir de différence dans les options de compilation.
J'ai réussit à avoir le source du pgm mais Cobol, c'est du chinois pour moi.

On utilise pas le mode Coprocesseur.

Ce doit être un problème de ccsid, c'est sûr mais d'où ça vient?

Merci pour cette première réponse.

[Homer-ac]

bonjour,
je n'y crois pas trop, COBOL est assez trivial comme langage (c'est pour ça qu'il génère un code minimal performant) mais tu peux m'envoyer en MP une extraction du source. Pas tout (inutile et personnel). Le début jusqu'à la File Section inclue, les exec sql, les appels à des fonctions (Move ou Compute Function) et à Language Environment (CALL 'CEE....'), sauf ce qui n'est pas à blanc en colonne 7 (commentaires, débug, sauts de page ...). C'est surtout les fonctions appelées qu'il peut être intéressant de vérifier.

[Lemmings1406]

Ok, je t'enverrai tout ça lundi, je suis au taf mais je migre en 1.9 donc pas trop de temps.

Merci pour ton aide

[Luc Orient]

C'est sans doute un problème de Code Page, mais où ? ... là est la question ...

Questions :

- Quelle est la version du compilateur COBOL utilisé ?

- Le fichier produit par le programme a une particularité quelconque ?

- Quand tu écris :

ça se complique, les "é" sont remplacé par "{" entre autre.

Comment est visualisé le fichier ? sous TSO/ISPF ?


Par contre, je ne comprends pas cette phrase :

En interrogeant une table avec des caractères signés sous SPUFI, la table est bonne.

qu'appelles tu des "caractères signés sous SPUFI" ?

[bernard59139]

En vrac, des trucs

• Dans le fichier de résultat, vérifier si les codes héxa sont identiques.
• Pour vérifier si c'est COBOL ou pas, fait un UNLOAD de la table et ensuite, un DSNTIAUL.
• Dans chacune des sessions de l'émulateur, vérifier le code page utilisé.
• Vérifier chacune des étapes du transferts. Je pense plus particulièrement aux transferts de fichiers qui, si mal paramétrés, altèrent le fichier.

[Homer-ac]

Bonjour,
On ne sait jamais, c'est parfois des trucs simples que l'on peut oublier de vérifier. Le plus souvent les Binds font partie du processus de livraison et dès lors on ne s'intéresse qu'aux RC ^= 0. Est-ce qu'une confrontation des SYSOUT de BIND a été fait sur les 2 LPAR ? Histoire de vérifier que le CCSID listé par DB2 qui ressort en regard du paramètre Encoding est absolument identique ?

[Lemmings1406]

Bonjour,

Je vais essayer de répondre à tout le monde:

Luc:

Cobol Version 410
Le fichier produit n'a pas de particularité si ce n'est une mise en forme pour une meilleure lisibilité.
Pour la phrase que tu ne comprends pas, les caractères contenus dans la table sont bons mais une fois écris dans le fichier en sortie, ils ne le sont plus.

Bernard:

Les codes hexa entre supfi et le fichier produit ne sont pas les mêmes pour les caractères posant problème.
J'ai déjà fait un Unload/Load Replace, la table est toujours ok.
Pour les émulateurs, j'ai déjà demandé, ils m'ont assuré que c'était ok chez, je ne peux malheureusement pas aller vérifier moi-même.
Pour le dernier point, il n'y a pas de transfert de fichier.

Homer:

J'ai pas eu le temps encore d'aller chercher ce que tu me demandais
J'ai comparé les sysout entre les 2 partitions, elles sont identiques. CCSID = 297


Je me suis même amusé un faire un REXX qui va interroger la table DB2 et qui met en forme le fichier en sortie. Les caractères ne sont pas modifiés entre ce que l'on peut voir dans Spufi et dans le fichier.

Exemple d'une ligne qui pose problème avec sa conversion Hexa:

Dans Spufi:

033310000535é0000000000000
FFFFFFFFFFFFCFFFFFFFFFFFFF
03331000053500000000000000

Après extraction via pgm cobol (ce n'est pas la même ligne mais ça ne change rien):

7101019600000600{000000000
FFFFFFFFFFFFFFFF5FFFFFFFFF
71010196000006001000000000

Après exécution de mon rexx:

019630000300é0000000000000
FFFFFFFFFFFFCFFFFFFFFFFFFF
01963000030000000000000000

[bernard59139]

Comme cela à l'air de venir du cobol, une autre suggestion

• Une mauvaise définition des zones en Cobol

Bonne soirée.

[Homer-ac]

Pour la suggestion de Bernard, c'est une réponse tentante mais c'est le même LOAD donc avec des options de compile et un DCLGEN identiques ! Ce qui peut avoir un impact serait des appels dynamiques : CALL ou fonctions COBOL mais il semble que l'y n'y a rien de ça. Ecart dans les données peut être qui se traduirait par des réaffectation de signes par COBOL ?. La seule remarque est que par SPUFI ou REXX on fait du SQL dynamique, c'est du statique dans le COBOL. S'il s'agit d'un cas isolé ce serait effectivement peut être intéressant de vérifier la réaction du même PGM avec les données de la prod. Eventuellement d'écrire un PGM COBOL de test qui passe le même SELECT que dans le REXX. Je verrais bien un test avec l'option SQLCCSID et NOSQLCCSID mais ça n'explique pas qu'à CCSID égal on ait un comportement différent d'un même LOAD sur 2 LPAR ?

[Luc Orient]

Si c'est le même LOAD, alors il faut peut être chercher ce qui change d'une partition à l'autre, et peut être du coté des DB2 ...

Puisque il s'agit de deux LPAR différentes alors les DB2 sont différents non ?

[Lemmings1406]

Re,


Pour Luc:

Ce sont 2 LPARS différentes et donc 2 Db2 Différents mais la config est strictement identique. Du moins, d'après ce que j'ai vérifié. Je recommence tout à zéro aujourd'hui et je vais comparé tous les paramètres entre la prod et la pré-ex.

[bernard59139]

Bonjour

j'ai été un peu trop vite, verifier la desription des zones dans le programme et dans les sous-programmes.

Et vérifier aussi que ce soit le bon LOAD qui soit exécuté. Ca parait idiot, mais il faut vérifier.

[Homer-ac]

J'avais pensé à cette hypothèse Bernard, mais le bind a été vérifié et ça ne passerait pas à l'exécution avec un timestamp DB2 différant. J'ai proposé à Lemings1406 qui ne connait pas Cobol de m'envoyer le DCLGEN utilisé (il n'y a qu'une table ou vue) pour lui renvoyer un COBOL d'extraction de la table sur fichier qu'il pourrait compiler et tester sur place (je n'ai jamais entendu parler tel pb et ça vaut le coup d'y consacrer un peu de temps), histoire de croiser et vérifier s'il s'agit bien d'un PB Cobol. Il y a cette option de précompilation SQLCCSID qu'il me semble utile de vérifier (avec et sans : NOSQLCCSID). J'ai l'impression que toutes les hypothèses ont été émises sur ce pb. Reste Cobol. Je n'y crois pas trop, les valeurs hexa semblent écarter des histoires de signes. Données ? mais c'est bon sous spufi. Reste à tester en SQL statique avec un pgm qui pourrait être compilé sur la LPAR qui cloche pour pouvoir éventuellement jouer sur les paramêtres de compile pour reproduire et/ou écarter l'erreur ?
Il y a aussi cette option de compilation CODEPAGE de COBOL qui semble pouvoir interagir avec SQLCCSID mais je n'ai pas encore trouvé dans la doc Enterprise Cobol 4.1 (la dernière version z.OS) si et ou elle se retrouve dans le load, à l'instar des bitmaps positionnées pour chacune des options.

nb. pour Lémings1406 je suis un peu étonné par la position du X'51' par rapport aux autres lignes qui vont bien. Nettement après le X'C0' que l'on trouve sur les 2 lignes OK, typique de signe d'une donnée signée en PIC S9(n). Si ça ce trouve, c'est un écrasement mémoire dans le programme qui ne ressort curieusement pas partout, sans rapport avec un codepage, surtout que la même colonne de la ligne en erreur ressort signée à F. Une raison de plus pour vérifier d'un peu plus près le DCLGEN généré pour COBOL.
re nb. dernière remarque sans objet (j'aurais pu vérifier !): le décalage est probablement lié à une différence de présentation. X'C0' correspond à '{' EBCDIC, c'est bien un pb. de CCSID.

[Homer-ac]

Bon, j'ai trouvé. Le CCSID est bien inscrit dans le load. C'est plus l'info qui m'intéressait que sa place. Ca garantit que l'exécution diu Cobol est indépendante de la version COBOL installée. Heureusement, il ne manquerait plus que ça ! On retrouve donc dans le Load le CCSID comme toutes les autres options de compilation de COBOL.
Si Lemmings1406 veut vérifier :
Dans le Load, le code COBOL commence toujours par X'47FO F028' (Branch en 40 du R15)
En +X'68', la date et l'heure de compilation (YYAAMMJJHHMMSS)
Suit la version cobol en étendu dur 6 octets (F0F4F0F1F0F0) : en +X'76'
Puis le CCSID en regard de l'option CODEPAGE ; en +x'7C' (X'0474' = 1140)
Normalement ce codepage est plutôt pour des conversions UNICODE ou du parsing XML dans COBOL, Seulement il y a un également un impact sur les host variables passées à SQL si on utilise l'option de précompile : SQLCCSID. C'est plutôt au niveau du COPROCESSEUR SQL que ça se passe, je vérifierai demain si on retrouve ça au niveau de l'exec des précompilateurs SQL actuels. Une compilation d'un PGM quelconque avec les procédures en usage sur le site devrait facilement renseigner Lemmings1406 à ce sujet.

[xfanx]

Sur mon site, nous avons eu pas mal de problèmes de codepage inter Lpar entre des 1147 et des 1148.
A mon souvenir, jamais Cobol n'est intervenu à ce niveau sur les transco. Par contre, ce que tu décris me rappelle une de nos erreurs.

SPUFI avant d'afficher les résultat analyse et identifie le codepage de l'émulateur utilisé et fait les transco necessaire à l'affichage des données. Aussi, dans mon cas, bien que nous ayons des data en 1147 au lieu de 1148, via SPUFI nous ne voyions pas d'erreur puisque notre émulateur 3270 etait en 1147 aussi. Par contre à l'exécution des programmes (bien que comme toi les CCSID des packages soient corrects), nous avions beaucoup de problemes de transco puisque nous attendions du 1148.

donc, si tu es dans le meme cas d'erreur que nous avons aussi rencontré, pour moi tes données dans les tables DB2 sont dans un code page différent de ce que tu attends et ce n'est pas cobol qui est en erreur surtout si tu es sure du CCSID de ton package et du tablespace.
le seul moyen de le verifier est de mette ton émulateur dans le meme code page que ce qui est sensé etre dans tes tables DB2 et de verifier à l'exécution de SPUFI et dans la consultation des SYSOUT de DISPLAY.

[Lemmings1406]

Bonjour à tous et merci pour vos recherches et réponses,

Je reviens d'un long Weekend et mes chers développeurs m'ont laissé un petit mail pour me dire que dans la pré-compilation, ils avaient le paramètre CCSID(500) et me demandent si le problème pouvait venir de là???

Il diffuse la nouvelle version compilées ce matin, on verra bien mais normallement, ça devrait rentrer dans l'ordre.

Je vous tiens au courant

[bernard59139]

Bonjour

Avez -vous trouvé?

je suis très interessé par tout problème concernant les ccid et autres codes pages.

bonne continuation
B59

[Lemmings1406]

Bonjour et désolé pour ce silence. Je n'ai pas eu de nouvelles de la part des personnes concernées. Mais que j'ai la confirmation que tout est rentré dans l'ordre, je vous fais signe.