Récupérer la plus grande valeur d'un numérique condensé [Résolu]

[Mercure]

Dans ce cas, ton compilateur cobol microfoc... est complètement débile et ne tient pas compte des règles de base du Cobol ANS.

Quand tu définis une zone PIC S9(1), le S représente le signe et le 9(1) le nombre maxi de chiffres que peut comporter la zone. Dans ce cas, c'est 1 seul chiffre de -9 à +9.

Ton programme ne marchera jamais correctement sur des ordinateurs dignes de ce nom.

[Hédhili Jaïdane]

Et pourtant même les deux compilateurs Microsoft 4.5 et IBM Cobol/2 donnent le bon résultat attendu :

Exécuter essnum.EXE ? (O=Oui/N=Non, Défaut=N)
o

VDISPLAY : 0009.

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
000020 Identification Division.
000030 Program-Id. ESSNUM-CBL.
000040***************************************************************
000050*                                                             *
000060*     Test Numérique 9(1)   
000070*                                                             *
000080***************************************************************
000090*
000100 Author. H.JAIDANE.
000110 Environment Division.
000120 Configuration Section.
000130 Source-Computer. IBM-PS2.
000140 Object-Computer. IBM-PS2.
000150 Special-Names.
000160     Decimal-point is comma.
000180 Input-Output Section.
000190 File-Control.

000350*
000360 Data Division.
000370 File Section.
000520*
000530 Working-Storage Section.
       01  VCOMP-3       PICTURE 9(1) COMP-3 VALUE ZERO.
       01  VDISPLAY      PICTURE 9(4) VALUE ZERO.
005610 Procedure Division.
000000 TRAIT.
           ADD 9999 TO VCOMP-3.
           MOVE VCOMP-3 TO VDISPLAY.
           DISPLAY " VDISPLAY : " VDISPLAY ".".
000000     stop run.

[Mercure]

Envoyé par Hédhili Jaïdane

Et pourtant même les deux compilateurs Microsoft 4.5 et IBM Cobol/2 donnent le bon résultat attendu :

Et non, ce n'est pas le "bon" résultat attendu. En effet, le résultat de ton display est 9 et non pas 9999.

Il y a cadrage à droite dans la zone réceptrice VCOMP-3 et les 3 premiers 9 du nombre 9999 sont perdus, c'est à dire la partie la plus significative. Seul subsiste le 9 de l'unité car VCOMP-3 est défini sur un seul chiffre 9(1), peu importe son usage.

Disons que ces deux compilateurs sont un peu moins débiles que le Cobol Microfocus mais un peu seulement puisqu'ils acceptent d'additionner 9999 dans une zone trop petite pour contenir le résultat. Y-a-t-il au moins un warning à la compil ?

[Hédhili Jaïdane]

Envoyé par Mercure

Et non, ce n'est pas le "bon" résultat attendu. En effet, le résultat de ton display est 9 et non pas 9999.

Il y a cadrage à droite dans la zone réceptrice VCOMP-3 et les 3 premiers 9 du nombre 9999 sont perdus, c'est à dire la partie la plus significative. Seul subsiste le 9 de l'unité car VCOMP-3 est défini sur un seul chiffre 9(1), peu importe son usage.

Disons que ces deux compilateurs sont un peu moins débiles que le Cobol Microfocus mais un peu seulement puisqu'ils acceptent d'additionner 9999 dans une zone trop petite pour contenir le résultat. Y-a-t-il au moins un warning à la compil ?

Le résultat attendu est bien 9, mais comme on display la zone en 9(4), il y a affichage de 0009. La troncature a été bien faite au moment de faire l'addition de 9999 dans le 9(1), ce qui montre bien que cette zone 9(1) ne peut contenir qu'un seul digit.
Aucun warning de troncature signalé, d'autres compilateurs l'auraient fait sur l'addition.

Code :

1
2
3
ADD 9999 TO VCOMP-3.           ===> VCOMP-3 = 9
MOVE VCOMP-3 TO VDISPLAY.                       ===> VDISPLAY = 0009
DISPLAY " VDISPLAY : " VDISPLAY ".".  ===> 0009

Le compilateur MS 4.5 est le même à ce niveau de version que le MF contemporain, quant au Cobol/2, il est proche du Cobol/2 pour OS/390 et VM

[Carlozi]

Bonjour,

Je vous ai mis un tableau en pièces jointes des possibilités de range pour une déclaration en COMP.

Par exemple :

Déclaration PIC S9(1) COMP à PIC S9(4) COMP
Range -9999 à +9999
2 bytes

Je ne sais pas si j'interprète correctement, mais pour une déclaration en PIC S9(1), 2 octets seront utilisés en mémoire, d'où la possibilité de mettre 9999 avec mon compilateur "débile" sous UNIX en plus ! ?

Mais, j'utilise deux octets alors que je n'en déclare qu'un.... J'ai peur que ça écrase la variable qui suit en working, je vais vérifier...

[Carlozi]

Bon... Vous avez raison... Même si mon compilateur permet d'alimenter la variable déclarée en PIC 9(1) COMP-3 avec la valeur 9999 et d'afficher ce résultat.... il en est tout autre dans son utilisation... Dans son utilisation, je n'ai que la valeur 9.

PomPomPom...

Au final, je suis repassé en USAGE BINARY en testant en dur la valeur 255 (cf le problème initial).

Merci pour votre aide... quand j'aurai un peu de temps je reviendrai sur ce poste. J'ai appris des choses, c'est cool

[Luc Orient]

Envoyé par Hédhili Jaïdane

Le résultat attendu est bien 9, mais comme on display la zone en 9(4), il y a affichage de 0009. La troncature a été bien faite au moment de faire l'addition de 9999 dans le 9(1), ce qui montre bien que cette zone 9(1) ne peut contenir qu'un seul digit.
Aucun warning de troncature signalé, d'autres compilateurs l'auraient fait sur l'addition.

Code :

Le compilateur MS 4.5 est le même à ce niveau de version que le MF contemporain, quant au Cobol/2, il est proche du Cobol/2 pour OS/390 et VM

Même comportement sur le COBOL du Mainframe z/OS (Enterprise COBOL for z/OS Version 3).


Par contre, il existe avec le COBOL z/OS un nouveau format COMP-5 dit 'native binary' qui permet de s'affranchir de ce type de problématique.

These data items are represented in storage as binary data. The data items can contain values up to the capacity of the native binary representation (2, 4 or 8 bytes), rather than being limited to the value implied by the number of nines in the picture for the item (as is the case for USAGE BINARY data). When numeric data is moved or stored into a COMP-5 item, truncation occurs at the binary field size rather than at the COBOL picture size limit. When a COMP-5 item is referenced, the full binary field size is used in the operation

Et la séquence suivante :

Code :

1
2
3
4
MOVE ZERO TO VCOMP-5
ADD 9999 TO VCOMP-5
MOVE VCOMP-5 TO VDISPLAY
DISPLAY "VDISPLAY=" VDISPLAY

donne :

VDISPLAY= 9999

avec :

VCOMP-5  PIC S9 COMP-5

[Hédhili Jaïdane]

Envoyé par Carlozi

Bonjour,

Je vous ai mis un tableau en pièces jointes des possibilités de range pour une déclaration en COMP.

Ce tableau nous le connaissons par coeur depuis belle lurette et on le trouve dans toute la littérature Cobol.

Mais, j'utilise deux octets alors que je n'en déclare qu'un.... J'ai peur que ça écrase la variable qui suit en working, je vais vérifier...

Pour le S9(1) COMP (binaire ici), il sera stocké sur 2 octets mais ton programme ne verra toujours qu'un digit, si tu veux optimiser et bénéficier des autres digits, il faudrait le déclarer en S9(4) qui occupera le même espace.

Il n'y a aucun risque d'écrasement ou d'empiètement dans la WSS, ton compilateur saura se démerder. En plus il saura bien gérer les alignements nécessaires sur demi-mot ou simple mot pour les niveaux 01. Pour le niveau 77, il n'y a pas d'alignement.

Les risques d'extension (étalement) dans les diverses sections de la Data Division proviennent d'une mauvaise utilisation des pointeurs, et pour certains compilateurs, des indices des tableaux, des zones à longueur variable et du facteur de blocage.

[Mercure]

Envoyé par Carlozi

Bon... Vous avez raison... Même si mon compilateur permet d'alimenter la variable déclarée en PIC 9(1) COMP-3 avec la valeur 9999 et d'afficher ce résultat.... il en est tout autre dans son utilisation... Dans son utilisation, je n'ai que la valeur 9.
[...] Au final, je suis repassé en USAGE BINARY en testant en dur la valeur 255 (cf le problème initial).

A ce propos, je reviens sur ce que tu as dis au post #17 de ce fil.
Dans la mesure où le compilateur MF accepte HIGH-VALUE, je ne vois pas pourquoi il n'accepterait pas LOW-VALUE.
Je voudrais savoir la valeur que tu obtiens en mettant HIGH-VALUE et LOW-VALUE dans une zone déclarée en binaire.
Peux-tu refaire un essai tel qu'illustré au post #9 de ce fil sous Cobol MF en remplaçant simplement le MOVE X"00" par MOVE LOW-VALUE ?
_____________________________________________________________

Envoyé par Luc Orient

Par contre, il existe avec le COBOL z/OS un nouveau format COMP-5 dit 'native binary' qui permet de s'affranchir de ce type de problématique.

COMP-5 est quand même un cas particulier non standard qui ne semble fonctionner que pour z/OS. Dans le manuel ILE Cobol Language Reference de l'IBM i, je lis :

Envoyé par ILE Cobol Language Reference

COMP-5 : A COBOL reserved word that is not in Standard COBOL and is not supported by the ILE COBOL compiler. If used, a diagnostic message will be issued

Cependant, j'éviterais d'utiliser cet usage (COMP-5) particulier si j'ai des possibilités en programmation Cobol standard.
_____________________________________________________________

Envoyé par Hédhili Jaïdane

Il n'y a aucun risque d'écrasement ou d'empiètement dans la WSS, ton compilateur saura se démerder.

Certes ! Le compilateur réservera 2 octets de toute façon, mais, comme l'a remarqué Carlozi, si la zone est définie en PIC 9(1), seul l'octet le plus à droite sera accessible à la programmation.

[Carlozi]

Pour le S9(1) COMP (binaire ici), il sera stocké sur 2 octets mais ton programme ne verra toujours qu'un digit

C'est là bien mon problème...

il faudrait le déclarer en S9(4) qui occupera le même espace

Je n'ai vraiment qu'un digit.

Envoyé par Luc Orient

VCOMP-5  PIC S9 COMP-5

C'est bien ça le COMP-5, ça marche dans l'utilisation que j'ai de la variable sur 1 digit bien que ce ne soit aps très portable. Mais, c'est toujours le même problème, la zone est tronquée lors de son utilisation dans les programmes...

@Mercure : je referai le test sur le LOW-VALUE.

[Jean GVE]

Envoyé par Mercure

...Dans la mesure où le compilateur MF accepte HIGH-VALUE, je ne vois pas pourquoi il n'accepterait pas LOW-VALUE. ...

Attention, si la variable est déclarée BINARY ou COMP (et quel que soit le compilateur et la bécane cible, c'est COBOL) la valeur zéro, qui est une valeur possible, est codée zéro binaire et correspond donc à LOW-VALUE. Et, pour le cas de HIGH-VALUE, qui serait stocké en format xFFFF (sur 16 bits) cela correspond à une valeur arithmétique existante de -1 si la variable est signée ou de 65535 si elle ne l'est pas.
En résumé, HIGH-VALUE et LOW-VALUE n'est pas utilisable pour des variables numériques codées en binaire.
D'autre part, pour maîtriser réellement le nombre de digit réellement utilisés il vaut mieux faire le déclaration en PIC 9(n). ou en PIC 9(n) PACKED-DECIMAL. Le BINARY ou COMP pouvant être variable suivant la bécane cible et des paramètres d'optimisation demandés à la compilation (on peut se retrouver avec une zone mémoire sur 16, 32 voire 64 bits alors qu'on pense en avoir qu'un seul octet --Sur IBM je n'ai pas rencontré de problème de ce genre, c'était sur HP9000 il y a une douzaine d'années et un compilo un peu exotique il me semble, méfiance quand même--).
@+

PS: attention à la perte de performance, si l'on fait des calculs sur des valeurs DISPLAY ou PACKED-DECIMAL toutes les bécanes n'ayant pas les instructions matérielles pour cela (Opérateur Décimal) ces valeurs sont converties en binaire ou en flottant pour effectuer l'opération puis le résultat doit vers converti dans l'autre sens.

[Mercure]

Envoyé par Jean GVE

...HIGH-VALUE et LOW-VALUE n'est pas utilisable pour des variables numériques codées en binaire.

C'est connu. Revoir mon post #9 où je mets X'00' dans la zone redéfinie en X. A la place de X'00', je voudrais que Carlozi fasse un "MOVE LOW-VALUE XFF1" et dise ce qu'il obtient en retour.

[Carlozi]

Salut et merci pour votre participation.

@Mercure, j'ai un peu de temps, je fais le test maintenant

Résultat NUMDISPLAY = 255 !

Il y avait une façon encore plus simple :
DATA DIVISION.

Code :

1
2
3
4
5
6
7
8
9
10
WORKING-STORAGE SECTION.
    01 NOMBREX.
                05 NOMBRE9 9(4) USAGE BINARY.


PROCEDURE DIVISION.
    MOVE ZERO TO NOMBRE9.
    DISPLAY “NOMBRE9 : “ NOMBRE9.                     => Affiche 0 (la variable contient un zéro binaire).
    MOVE HIGH-VALUE TO NOMBREX.
    DISPLAY “NOMBRE9 : “ NOMBRE9.                     => Affiche un nombre de la forme 2^n – 1 (car la variable NOMBRE9 contient ce nombre).

Du coup c'est bon pour obtenir 255... problème bel et bien résolu.

Mais mon deuxième problème est de stocker ces deux octets... dans une zone alpha sur un caractère... et ce n'est pas possible

Y a-t-il une astuce?
Si je redécoupe une zone alphanumérique comme suit :

Code :

1
2
3
4
5
01 ZONEALPHANUM.
05 ALPHANUM PIC X(8).
01 ZONEALPHANUMBIN REDEFINES ZONELPHANUM.
05 ALPHANUM2 PIC X(07).
05 BINAIRE1 PIC 9(1) USAGE BIANARY.

Tu confirmes que j'aurai toujours le même problème dans l'utilisation en programme de ZONEALPHANUM qui ne contiendra que 8 octets et non 7 + 1 binaire? Sauf si les variables receptacles de ZONEALPHANUM sont déclarées de la même façon (avec un redefines)?

Et si je le fais comme ça :

Code :

1
2
3
01 ZONEALPHANUM.
05 ALPHANUM PIC X(7).
05 BINAIRE1 PIC 9(1) UASGE BINARY.

Le problème d'utilisation persiste-t-il? Je pense que non en fait tout dépend la variable qui recevra ZONELPHANUM....

[Carlozi]

Envoyé par Carlozi

Code :

Code :

La variable ZONEALPHANUM étant propagé dans beaucoup de programmes et de copies, j'ai fait un PIC X(1)... prenant les valeurs de 0 à Z... soit 36 valeurs au total.