Discussion :

[Antichoc]

Salut,

Encore un nouveau problème COBOL.

Voila, j'ai une table contenant un varchar. Une copy cobol (appelons la COPCOB) représente ce varchar.

Je souhaites ajouter une nouvelle zone numérique dans cette copy (et donc dans le varchar)

J'ai donc ajouté le code suivant :

Code :

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

05 MA-ZONE PIC9 COMP-3 VALUE ZERO.

Je ne réalise aucun "move 0" dans mon programme lors des INSERT, seulement, une fois les enregistrements créés, la valeur est mise à SPACE et non à 0.

Ce programme utilise des sous modules.

Comment peut on controuner ce soucis ?

Merci pour votre aide !

[Hédhili Jaïdane]

Bonjour.
Tu peux nous indiquer ton OS, la version Cobol et la description de ta variable en varchar et son lien avec la zone numérique stp ?

[Antichoc]

Salut,

Je travaille Z/OS en Cobol V2

La zone de working explicité dans mon précédent fait parti de la copy décrivant la VARCHAR de ma table.

Cependant, je ne peux pas fournir l'intégralité de ce fichier (environ 400 zones)

Il est à noter que le problème évoqué ne se produit qu'en TP et non en batch ...

@+

[Hédhili Jaïdane]

Bon, je ne suis pas z/OS, mais je pense que tu devrais quand même renseigner ou initialiser ta zone num car si le buffer est initialisé avant les insert, il le serait à SPACES et non en fonction du type de chaque zone ??? (longueur variable ===> alphanum) comme le ferait l'instruction INITIALIZE.
Je te laisse entre les mains des z/OSistes s'ils sont disponibles.

PS: Tu veux bien modifier le titre pour qu'il colle bien à ta question. Je n'arrive pas à la résumer.

[Homer-ac]

+1.
Le précompilateur DB2 ajoute au début du programme ces propres séquences d'initialisation, il suffit de regarder les CALL ajoutés en début de procédure division.
De toutes façons, l'isolation autonome des fonctions logiques ou règles de gestion participe à la programmation structuée.
Ainsi le cas d'insertion d'une ligne DB2 devrait être isolée dans un paragraphes qui commence par initialiser TOUTES les host variables utiles. C'est la meilleure façon de faciliter la lisibilité et la maintenance du programme.
D'autre part c'est toujours une mauvaise idée que de mettre des Value dans des COPY COBOL puisqu'elles peuvent être éventuellement utilisées en Linkage.
Quant aux INCLUDE de DCLGEN, on doit malheureusement parfois les retoucher pour suppression du préfixe table et association des données et des indicateurs de champ nul mais pas plus.

[Antichoc]

Merci pour ces précisions,

je ne me ferais pas avoir la prochaine fois !

@+

[el_slapper]

(.../...)
D'autre part c'est toujours une mauvaise idée que de mettre des Value dans des COPY COBOL puisqu'elles peuvent être éventuellement utilisées en Linkage.
(.../...)

+1 avec le reste, mais je me permets d'intervenir là-dessus. Il est possible de distinguer des COPY "working" de COPY "linkage". Ca se fait là ou je bosse, on change un caractère dans le nom de la copy. Si ta remarque est totalement vraie pour les COPY "linkage"(le type le plus fréquent), une COPY dédiée à la working, elle, peut parfaitement inclure des VALUE.

Une copy "working" sera en général associée à une copy "code", d'ailleurs...alors qu'une copy "linkage" sera associée à un module appelé.

[Homer-ac]

Chaque site ses habitudes, on appel ça norme, sauf que l'on écrit très souvent ça : normes, au pluriel !
Personnellement je préfère : 1 sructure = une copie description (unique et sans value pour des raisons de non redondance) + copie code d'initialisation. Je sais qu'on utilise assez peu les copies en procédure division, ça peut pourtant être souvent pratique, étant entendu que puisque l'on peut à présent appeler les précompilateurs SQL et CICS en z/OS directement dans le step de compilation COBOL (IGYCRCTL), on peut même y mettre du SQL ou des ordres CICS.