Discussion :

[nenekes]

bonjour a tous,

je cherche a savoir si l'on peut trouver un tuto ou autre definissant la taille reelle des rubrique declarées en cobol

Code :

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

1
2
3
4
5
6
7
8
par exemple 
01 toto PIC S9(13)v99 COMP-3 --> a quel taille (quelle est sa longueur?) ?

autre exemple
01 toto PICTURE  S9(15) COMPUTATIONAL-3. --> quel longueur ?

... ect

merci par avance

[Hédhili Jaïdane]

Bonjour.

Types des données numériques :
- Etendu = display
- Condensé = comp-3/packed-decimal : long = E(d/2)+1 :
(le plus efficace en terme de performance de calcul sur certaines machines)
- Binaire = binary (COMP-4 ) : long = 2(1à4), 4(5à9),8(10à18)
- Virgule flottante = comp-1, comp-2 : long = 4, 8

dans ton cas :

01 toto PIC S9(13)v99 COMP-3 --> a quel taille (quelle est sa longueur?) ?

13+2=15,
E(15/2)=E(7,5)=7,
7+1=8

autre exemple

01 toto PICTURE S9(15) COMPUTATIONAL-3. --> quel longueur ?

Même chose 8.

[nenekes]

super merci beaucoup !

a+

[Homer-ac]

Bonjour,
Rien à dire quant aux indications d'Hédhili. Sobre et très précis.
Je peux juste ajouter quelques précisions, spécifiquement avec Enterprise COBOL z/OS, pour ceux qui peuvent travailler avec.

Le binaire : on peut également coder BINARY / COMP ou COMP-5. COMP-5 a été ajouté au départ pour les données binaires externes, pour s'assurer que quelque soient les options de compilation installées, aucune troncation ne devrait intervenir dans un calcul. COMP-5 est donc équivalent à BINARY mais seulement si on utilise l'option de compilation TRUNC(BIN).

Les performances : Pour z/OS la remarque d'Hédhili se vérifie également le plus souvent. Ce n'était pas le cas en COBOL 1 ou le binaire prenait toujours l'avantage, mais le format packé (COMP-3) est devenu globalement le plus intéressant. Pas toujours cependant. Si on peut privilégier en particulier des picture S9(4) ou S9(8) COMP ou BINARY, mais sur des données de réception de même type, le code généré reste souvent plus performant. De moins en moins évident donc de donner des règles du bon choix si on ne peux pas vérifier les intruction générées en Assembleur. En particulier une Picture S9(9) Binary générera un code bien moins performant qu'avec la même en COMP-3. Bref, comme il y a de moins en moins de monde pour savoir interpréter le généré Assembleur, le COMP-3 devient également en z/OS un choix souvent plus judicieux par rapport au binaire et toujours par rapport au format Display dans les calculs. (En z/OS un calcul transitera de toutes façons toujours par la traduction de la donnée, soit en Binaire, soit en Décimal packé = COMP-3. Point de détail, le généré pour des calculs sur une PIC S9(9) binary est même pire que pour la même en format Display).

Enfin les longueurs : Enterprise COBOL z/OS a intégré une option de compilation ARITH(EXTEND) qui permet de faire à présent des calculs sur des données qui peuvent aller jusqu'à une Picture S9(31). Mais uniquement sur du Display ou du COMP-3. Dès lors qu'une donnée en Display passera de toutes façons par une traduction en Packé pour ces calculs, disons plus globalement dès que l'on dépassera une picture S9(8), j'y vois une raison de plus pour privilégier les calculs sur des définitions en COMP-3.

Les Longueurs encore : Enterprise COBOL z/OS fournit ume option de compilation 'MAP' le plus souvent activée sur les sites qui permet de connaître les longueurs réservées (groupes et détail) pour chaque donnée déclarée dans le programme. Une liste spécifique pour ça ressort à la compilation, en plus des réservations notifiées sur la droite des données déclarées. Il est donc facile de vérifier, tout particulièrement la longueur des zones groupes (0CLlng).

Nb. Je ne travailles pas sur des i/séries, mais, héritage IBM oblige, je suis bien convaincu que le processus de choix du généré Assembleur par le compilateur COBOL est du même ordre sur ces OS. Pas de calcul directement sur des données en étendu, du moins en ce qui concerne le généré en langage machine.

[Hédhili Jaïdane]

Salut Homer-ac

En Ile Cobol for iSeries :

...Of all USAGEs, USAGE COMP is the most efficient in terms of operational performance. For the ILE COBOL compiler, the COMPUTATIONAL phrase is synonymous with :
- USAGE COMP-4(Binary), if option COMPASBIN is specified
- Otherwise, PACKED-DECIMAL.

The maximum length of an external decimal item is 63 digits.

The maximum length of a packed-decimal computational item is 63 decimal digits.

Une remarque sur le COMP : Encore une belle Ibmerie, Comp qui a été toujours assimilé au binaire sur les machines IBM, est considéré, par défaut, comme du comp-3 dans le ILE Cobol sur iSeries.

L'AS/400 alias iSeries, alias, System i, alias Ibm Power i, travaille exclusivement en décimal-condensé (Comp-3) pour ses calculs internes.
Le seul type de décimal déclarable et utilisable dans le langage de contrôle CLP est le décimal-condensé (Comp-3). Les échanges de données numériques entre un programme CLP et les autres programmes écrits en HLL doivent obligatoirement se faire en décimal-condensé (Comp-3).

Cordialement.

[Homer-ac]

C'est intéressant ça : 63 digits !
Celà signifie qu'il n'y a aucune espèce de similitude entre l'Assembleur et donc par extention le microcode d'un z/OS ou d'un DOS VSE avec celui et des systèmes AS400 par exemple. en MVS les 31 digits s'expliquent par le généré d'une instruction sur du décimal condensé (Assembleur 370, on remonte donc aux origines de MVS) était sur 6 octets. 1er octet = code opération (Fx), octet suivant : 1 digit pour la longueur de la zone de réception, le second pour celle d'émission. 1 digit = 0 à 15 en binaire : soit lg 16 octets maxi, soit 31 digits plus le signe. Pour le moment COBOL z/OS s'appuie encore largement sur les instructions ASM 370 pour raisons de compatibilité ascendante j'imagine, ça changera sans doute, on est passé d'une grosse cinquantaine d'instructions de base en Assembleur 370 à environ 900 à ce jour (adressage 64 bits oblige, heureusement je serai sans doute à la retraite quand il faudra 'lire' un dump mémoire avec toutes ces instructions).

[Hédhili Jaïdane]

...'lire' un dump mémoire avec toutes ces instructions).

M'en parle pas