Discussion :

[yugseel]

Bonjour,

Je souhaiterais avoir de l'aide par rapport au problème suivant :

J'ai une table contenant un champ varchar de 32000 caractères.
Je souhaite le charger à l'aide d'un load data infile et un fichier.

Dans ce fichier, juste avant la chaine varchar à charger, il faut donner sa longueur, soit 32000. Seulement, on doit donner cette valeur sur 2 octets et en cobol, je ne trouve pas le moyen de stocker 32000 sur 2 octets. Comment puis je procéder ?

Merci d'avance

[Hédhili Jaïdane]

Bonjour.

Ta zone longueur doit être déclarée en 9(4) comp, et elle n'occupera que deux octets.

[yugseel]

Merci pour ta réponse.

Le problème est que lorsque je passe 32000 sur une zone S9(4) comp, il la tronque en 2000 avant de l'ecrire, et on se retrouve en hexa avec 07d0 au lieu de 7d00

Merci d'avance

[Hédhili Jaïdane]

Essaie S9(4) BINARY ou COMP-4.

En passant, précise nous ton OS et ton compilateur comme indiqué dans cette discussion : Règle Tag [SystèmeExploitation-VersionCompilateur]

[yugseel]

Non, ça ne fonctionne pas. J'ai l'impression qu'il n'y a pas de solutions.

Le 9(4) Binary stocke 2000 et le 9(4) comp-4 de même.

J'ai tenté le 9(5) comp-4 et on a 4 octets et non 2.

Et donc pour l'OS, il s'agit de Z/OS

[Mercure]

Code :

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

1
2
3
4
5
           BINARY ou COMP-4
Digits in PICTURE Clause   Storage Occupied
1 through 4                            2 bytes
5 through 9                            4 bytes
10 through 18                         8 bytes

Donc, définis une zone en PIC S9(5) BINARY (ou COMP-4, au choix)
puis redéfinis-la pour ne prendre en compte que les 2 octects les plus à droite :

Code :

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

1
2
3
4
5
01  MAZONEBIN4 PIC S9(5) BINARY.                            
01  FIL1   REDEFINES MAZONEBIN4.                            
     05  FIL2   PIC XX.                                     
     05  MAZONEBIN2X PIC XX.                                
     05  MAZONEBIN2 REDEFINES MAZONEBIN2X PIC S9(3) BINARY.

MAZONEBIN4 contiendra X'00007D00' sur 4 octets.
MAZONEBIN2X ou MAZONEBIN2 contiendra la même valeur X'7D00' mais sur 2 octets.

[yugseel]

Merci beaucoup ! ça fonctionne !

[Hédhili Jaïdane]

Pour OS/390 et VM : 32000 doit pouvoir tenir en S9(4) COMP, COMP-4 ou BINARY (2 octets).

S9(1) through S9(4) Binary half-word (2 bytes) -32768 through +32767

Pour éviter les troncatures de ce genre, il faut utiliser l'option de compilation TRUNC(BIN) ou déclarer la zone en COMP-5.

[Mercure]

Pour OS/390 et VM : 32000 doit pouvoir tenir en S9(4) COMP, COMP-4 ou BINARY (2 octets).

Oui, bien sûr. Sur 2 octets binaires, on peut compter en base 10 jusqu'à 65535, donc 32000 peuvent tenir.

Mais alors comment vas-tu alimenter une zone de 4 chiffres représentatifs ( S9(4) BINARY) ) avec une valeur composée de 5 chiffres (32000) ? C'est Cobol qui nous limite et on est coincés si on n'allonge pas la zone d'un octet supplémentaire.

[Hédhili Jaïdane]

...
Mais alors comment vas-tu alimenter une zone de 4 chiffres représentatifs ( S9(4) BINARY) ) avec une valeur composée de 5 chiffres (32000) ? C'est Cobol qui nous limite et on est coincés si on n'allonge pas la zone d'un octet supplémentaire.

Salut.

Pour être sûr je viens de re-tester avec Cobol/2 pas très loin de Cobol for OS/390 & VM pour l'essentiel, quand on déclare en 9(4) COMP-5 (l'équivalent de l'option TRUNC(BIN)), l'initialisation peut se faire par un VALUE ou un MOVE à partir d'un littéral numérique ou d'une variable.

Aux z/OSiste de confirmer.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
000410 77  A           pic 9999 comp-5 Value 32000.
000420 77  B           pic 9999 comp-5.
000420 77  C           pic 9999 comp-5.
000420 77  C0          pic 9(5) value 32900.
000620 Procedure Division.
000660     Display "A = " A.
           move 32800 to B.
000660     Display "B = " B.
           move C0 to C.
000660     Display "C = " C.

Résultats :

A = 32000
B = 32800
C = 32900

[Mercure]

En effet, cela doit fonctionner avec COMP-5, tu as raison, mais ce n'est pas du Cobol standard et cela peut s'avérer gênant par la suite.

[Hédhili Jaïdane]

En effet, cela doit fonctionner avec COMP-5, tu as raison, mais ce n'est pas du Cobol standard et cela peut s'avérer gênant par la suite.

COMP-5 ou l'option TRUNC(BIN) [option NOSTDTRUNC sur l'AS/400] avec BINARY, COMP, COMP-4.

Qu'est ce qu'on ferais sans les extensions qu'IBM a apportées au langage Cobol sur ses différentes plateformes.