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

[Carlozi]

Bonjour,

La plus grande valeur d'une variable (NUMCONDENSE) déclarée numérique condensé sur 1 caractère est 255 (dites-moi si je me trompe).

Je souhaite récupérer cette valeur dans un numérique non condensé(NUMNONCONDENSE) déclarée en 9(11).

J'ai essayé de mettre HIGH-VALUE dans NUMCONDENSE puis de récupérer NUMCONDENSE dans NUMNONCONDENSE.

J'ai un avertissement sur le MOVE HIGH-VALUE TO NUMCONDENSE à la compil', et en effet, après un affichage de NUMNONCONDENSE, elle ne contient pas la valeur 255.

Auriez-vous une solution?

Merci.

[Mercure]

Tu te trompes. En effet, la plus grande valeur décimale possible d'une zone définie sur un octet en décimal condensé (ou packé) est 9, soit X'9C' ou X'9F' (+9 ou |9|) en représentation hexadécimale signée ou non. Une zone packée contient deux chiffres par octet sauf son dernier octet (le plus à droite) qui est partagé entre le dernier chiffre de la valeur et le signe qui peut-être "C" (pour le signe plus sur z/OS, "F" pour également le signe plus sur IBM i ou valeur absolue sur z/OS, et enfin "D" sur les deux systèmes pour le signe moins.

En décimal étendu (non condensé), cette valeur maxi serait de 9 également, avec ou sans signe, soit respectivement X'C9' (+9 ou lettre "I"), X'F9' (chiffre 9) et X'D9' (-9 ou lettre "R").

Un simple MOVE suffit pour convertir la valeur de la zone en décimal condensé vers la zone en décimal étendu.

Tu ne peux pas mettre HIGH-VALUE (X'FF') dans ces zones telles qu'elles sont définies. C'est donc tout à fait normal que tu aies un message d'erreur à la compil.

Si tu veux obtenir 255 sur un octet, déclare ta zone en binaire (COMP ou BINARY).

[Carlozi]

Merci pour ta réponse.

Ok, je me suis trompé dans la formulation... "condensé" dans mon esprit signifie BINARY...

Donc je la déclare en BINARY et la valeur maximale sur un octet sera donc 255.

Y a-t-il alors possibilité de récupérer la valeur maximale de cet octet dans une variable déclarée en PIC 9(03) sans avoir à l'alimenter en dur par la valeur 255?

[Mercure]

Je ne vois pas le pb. Un simple MOVE suffit.
Le compilateur fera automatiquement la conversion et tu obtiendras X'F2F5F5' dans la zone cible définie en décimal étendu (PIC 9(3)).

[Carlozi]

En gros ce que j'avais intialement :
Working.

Code :

1
2
01 NUMBINAIRE PIC 9(01) USAGE BINARY.
01 NUMDISLPAY PIC 9(03).

Procedure.

Code :

1
2
MOVE HIGH-VALUE TO NUMBINAIRE
MOVE NUMBINAIRE TO NUMDISPLAY.

Ainsi, je pensais récupérer 255 dans NUMDISPLAY.

Sauf que le HIGH-VALUE ne passe pas à la compil'.

Comment puis-je récupérer 255, la valeur la plus grande que peut prendre NUMBINAIRE, dans NUMDISPLAY sans avoir à faire :

Code :

MOVE 255 TO NUMDISPLAY.

?

[Luc Orient]

Tu es sur quel OS ?

[Carlozi]

Un compilateur COBOL (Microfocus) intégré dans UNIX...

[Carlozi]

UP !

Pour l'instant j'ai mis la valeur 255 en dur...

Vraiment pas une idée?

[Mercure]

Cette demande semble bizarre.

Pourquoi veux-tu procéder ainsi ?

Edit :

Tu ne pourras jamais faire ce que tu veux faire avec une zone binaire définie de cette façon. En effet, 255 comportant 3 chiffres, tu dois définir ta zone binaire en au moins PIC 9(3) BINARY.
PIC 9(4) BINARY serait encore mieux puisque la réservation d'une zone binaire occupe toujours 2, 4 ou 8 octets.

Code :

1
2
3
4
5
6
Nombre de chiffres dans           Nombre d'octets
   la clause PICTURE              occupés en mémoire
                                      
    de 1 à 4                                  2
    de 5 à 9                                  4
    de 10 à 18                                8

Voici alors la bidouille que tu peux tenter :

Code :

1
2
3
4
5
6
7
8
9
10
11
 WORKING-STORAGE SECTION.               
 01  NUMBINAIRE PIC 9(4) BINARY.
 01  NUMALPHANUM redefines NUMBINAIRE.  
     05 XFF1 PIC X.                     
     05 XFF2 PIC X.                     
 01  NUMDISPLAY PIC 9(03).              
 PROCEDURE DIVISION.                    
 DEBUT.                                 
     MOVE HIGH-VALUE TO NUMALPHANUM.    
     MOVE X"00"      TO XFF1.           
     MOVE NUMBINAIRE TO NUMDISPLAY.

[Carlozi]

Pour l'instant la variable est déclarée en PIC 9(1) USAGE BINARY.
Mais demain elle pourrait passer en PIC 9(2) USAGE BINARY.
=> Pour éviter d'avoir à effectuer de la maintenance.

Si j'arrive à mettre la plus grande valeur dans celle de PIC 9(1), je n'aurai rien à modifier pour PIC 9(2) = pas de maintenance. si je mets 255 en dur, il faudra que demain, si elle passe en PIC 9(2), je fasse une maintenance...

[Mercure]

Voir mon post ci-dessus.

[Carlozi]

Code :

MOVE X"00"      TO XFF1.

A quoi correspond le X"00" => INITIALIZE?

[Mercure]

Envoyé par Carlozi

A quoi correspond le X"00" => INITIALIZE?

Non. Il s'agit de mettre un zéro binaire dans le premier octet (celui de gauche) de la zone NUMBINAIRE qui en compte deux. En Cobol Microfocus, je ne sais pas comment faire cela.

[Carlozi]

Ce n'est pas gagné cette histoire...

Le problème est contourné, c'est vrai mais il entraîne un autre problème : le zéro binaire.

Je vais envoyer une demande à Microfocus pour savoir comment obtenir la plus grande valeur d'un binaire sur 1 ou comment obtenir le zéro binaire.

Merci pour votre aide. Je posterai quand j'aurai la solution.

[Mercure]

Essaie LOW-VALUE.

Code :

MOVE LOW-VALUE  TO XFF1.

[Mercure]

Carlozi ,

ça marche ou pas avec low-value ?

[Carlozi]

Désolé Mercure, je poursuivais mon sujet sans rester bloqué sur ce problème.

Non, ça ne fonctionne pas avec LOW-VALUE.

De toute façon le "USAGE BINARY" me pose des problèmes ailleurs....

Je vais devoir déclarer la variable en COMP-3.

Ca va réduire la valeur maximale autorisée du coup mais ça sera suffisant si tu confirmes : la valeur maximale d'une variable déclarée en 9(1) COMP-3, c'est bien 99?

[Carlozi]

Oh, my bad

On peut stocker jusqu'à 99999 ! ! ! ! ! !
C'est le client qui va être content

Désolé pour ceux qui lisent et qui s'attendent à avoir la réponse du problème initial... le problème a été contourné pour être résolu.

[Mercure]

Envoyé par Carlozi

Je vais devoir déclarer la variable en COMP-3. Ca va réduire la valeur maximale autorisée du coup mais ça sera suffisant si tu confirmes : la valeur maximale d'une variable déclarée en 9(1) COMP-3, c'est bien 99?

Non, je ne confirme pas car c'est faux. Tu as des soucis de compréhension avec le nombre de chiffres représenté par la clause PICTURE et les valeurs mini et maxi que la zone peut contenir.

Une zone définie en PIC 9(1) COMP-3, ne peut contenir que 10 valeurs, chacune sur un seul chiffre, allant de 0 à 9 et c'est tout car la picture n'est pas signée.

Une zone définie avec une picture signée, PIC S9(1), peut contenir 19 valeurs toujours sur un seul chiffre, allant de -9 à +9.

Peu importe que la définition soit déclarée en COMP, BINARY, COMP-3, etc. Ce qui compte, c'est le nombre de 9 que comporte la clause PICTURE.

Code :

1
2
3
4
5
PIC 9       1 seul chiffre
PIC 99      2 chiffres 
PIC 999     3 chiffres
PIC 9999    4 chiffres
etc

[Carlozi]

Ben non....

Une variable déclarée en S9(1) COMP-3 peut contenir de -9999 à +9999 ; une variable déclarée en 9(1) COMP-3 peut contenir jusqu'à 9999.

Par exemple :

Working :

Code :

1
2
01  VCOMP-3       PICTURE 9(1) COMP-3 VALUE ZERO.
01  VDISPLAY      PICTURE 9(4) VALUE ZERO.

Procedure :

Code :

1
2
3
ADD 9999 TO VCOMP-3.
MOVE VCOMP-3 TO VDISPLAY.
DISPLAY " VDISPLAY : " VDISPLAY ".".

Le résultat :

VDISPLAY : 9999.