problème avec mouvement COBOL à la variable

comp-3 Je vais avoir le problème suivant dans un programme COBOL en cours d'exécution sur OpenVMS.problème avec mouvement COBOL à la variable

J'ai la déclaration variable suivante:

 01 STRUCT-1. 
      02 FIELD-A  PIC S9(6) COMP-3. 
      02 FIELD-B  PIC S9(8) COMP-3. 

     01 STRUCT-2. 
      03 SUB-STRUCT-1. 
       05 FIELD-A PIC 9(2). 
       05 FIELD-B PIC 9(4). 
      03 SUB-STRUCT-2. 
       05 FIELD-A PIC 9(4). 
       05 FIELD-B PIC 9(2). 
       05 FIELD-C PIC 9(2).

Et le code suivant:

 * 1st Test:  
      MOVE 112011 TO FIELD-A OF STRUCT-1 
      MOVE 20100113 TO FIELD-B OF STRUCT-1 

      DISPLAY "FIELD-A  : " FIELD-A OF STRUCT-1 CONVERSION 
      DISPLAY "FIELD-B  : " FIELD-B OF STRUCT-1 CONVERSION 

     * 2nd Test: 
      MOVE 112011 TO SUB-STRUCT-1. 
      MOVE 20100113 TO SUB-STRUCT-2. 
      MOVE SUB-STRUCT-1 TO FIELD-A OF STRUCT-1 
      MOVE SUB-STRUCT-2 TO FIELD-B OF STRUCT-1 

      DISPLAY "SUB-STRUCT-1 : " SUB-STRUCT-1 
      DISPLAY "SUB-STRUCT-2 : " SUB-STRUCT-2 
      DISPLAY "FIELD-A  : " FIELD-A OF STRUCT-1 CONVERSION 
      DISPLAY "FIELD-B  : " FIELD-B OF STRUCT-1 CONVERSION

qui sort:

FIELD-A  : 112011 
FIELD-B  : 20100113 
SUB-STRUCT-1 : 112011 
SUB-STRUCT-2 : 20100113 
FIELD-A  : 131323 
FIELD-B  : 23031303

Pourquoi FIELD-A et FIELD-B valeurs maintien différent de ce que Je déménage à eux dans le deuxième test?

J'ai d'autres mouvements de DISPLAY à COMP-3 variables dans mon programme où je ne reçois pas ce comportement.

Source

2010-07-01 mmutilva

En COBOL, les données au niveau du groupe sont sans type et sont déplacés sans coulée.

données niveau de l'élément ont toujours un type de données associées. Dactylographiées données sont exprimés en fonction du type de l'élément de réception au cours d'une MOVE.

Dans la première instance MOVE une valeur numérique littérale (112011) à un champ décimal condensé et le compilateur le convertit au type de données correct dans le processus. Tout comme vous l'attendez dans n'importe quel langage de programmation.

Dans le second cas, vous MOVE une valeur littérale à un élément de groupe. Comme il s'agit d'un élément de groupe, le compilateur ne peut pas «connaître» le type de données prévu, donc il fait toujours des mouvements de groupe sous forme de données de caractères (pas de conversions numériques). Ceci est correct lorsque l'élément destinataire a une clause PICTURE qui est compatible avec les données de caractère - lesquelles FIELD-A et FIELD-B de SUB-STRUCT-1 sont. Il n'y a pas de différence dans la représentation interne d'un 9 lorsqu'il est stocké sous la forme PIC X et lorsqu'il est stocké sous la forme PIC 9. Les deux sont supposés USAGE DISPLAY.

Maintenant, quand vous faites un mouvement au niveau du groupe de SUB-STRUCT-1 à COMP-3 (Packed Decimal) vous dire effectivement le compilateur de ne pas convertir DISPLAY au format COMP-3. Et c'est ce que vous obtenez.

Essayez les modifications suivantes à votre code. L'utilisation de REDEFINES crée un élément élémentaire numérique pour le déplacement. COBOL effectuera les conversions de données appropriées lors du déplacement de données élémentaires.


     01 STRUCT-2.     
      03 SUB-STRUCT-1.   
       05 FIELD-A PIC 9(2). 
       05 FIELD-B PIC 9(4). 
      03 SUB-STRUCT-1N REDEFINES 
       SUB-STRUCT-1 PIC 9(6). 
      03 SUB-STRUCT-2.   
       05 FIELD-A PIC 9(4). 
       05 FIELD-B PIC 9(2). 
       05 FIELD-C PIC 9(2). 
      03 SUB-STRUCT-2N REDEFINES 
       SUB-STRUCT-2 PIC 9(8).

Et le code suivant:


     * 3RD TEST:           
      MOVE 112011 TO SUB-STRUCT-1.     
      MOVE 20100113 TO SUB-STRUCT-2.     
      MOVE SUB-STRUCT-1N TO FIELD-A OF STRUCT-1  
      MOVE SUB-STRUCT-2N TO FIELD-B OF STRUCT-1  
      DISPLAY "SUB-STRUCT-1 : " SUB-STRUCT-1   
      DISPLAY "SUB-STRUCT-2 : " SUB-STRUCT-2   
      DISPLAY "FIELD-A  : " FIELD-A OF STRUCT-1 
      DISPLAY "FIELD-B  : " FIELD-B OF STRUCT-1

Attention: données de caractère emménagez dans un champ COMP-3 peut vous donner l'exception des données SOC7 redoutée Abend lorsque l'élément de réception est référencé. C'est parce que tous les modèles de bits ne sont pas des numéros COMP-3 valides.

Source

2010-07-02 12:23:33 NealB

Homme, ça me ramène. Je me souviens quand nous voulions regarder le dernier octet des champs décimaux compressés, car un "04" signifiait que quelqu'un avait déplacé une valeur avec un espace EBCDIC. –

@David Thornley. Fermer ... L'espace EBCDIC est hexadécimal "40". Aujourd'hui, nous utilisons un test 'IF NUMERIC' sur des champs décimaux condensés pour vérifier ce genre de chose. Quelque chose qui confond beaucoup de programmeurs est que le 'MOVE' ne gonfle pas, mais n'importe quelle référence de calcul au champ après que cela finisse par donner une exception d'exception de données (SOC7 dans la terre d'IBM). La plupart des gens s'attendent à ce que le "MOVE" les fasse exploser. – NealB

Pas seulement à proximité: à l'époque, lorsque nous comptions des champs, le dernier octet faisait basculer les nœuds, de sorte qu'une chaîne se terminant par 404040 hexagone se terminait par une décimale condensée terminant 4404 hex. (Ce n'était pas réellement COBOL, mais l'IBM 360 a été spécifiquement conçu pour exécuter COBOL, ayant une seule instruction ASM qui a fait un MOVE formaté, donc je pense que mon expérience ASM est légèrement pertinente ici.) –

Vous avez 2 problèmes.

COBOL possède plusieurs structures de données numériques. Chacun a son propre ensemble de règles.

• Les composants numériques de la clause PIC doivent TOUJOURS correspondre à un numéro ODD. • Le marqueur décimal "V" détermine le placement de la virgule décimale. • Les fonctions MOVE et mathématique de l'élément maintiennent l'alignement de la valeur décimale - une troncature de niveau haut et bas est possible • La conversion de type de données numérique (zone décimale à & binaire en paquet) est gérée pour vous.

par exemple. S9 (5) V9 (2) COMP-3.
y compris les 2 positions décimales> longueur est calculée comme ROUND UP [(7 + 1)/2] = 4 octets

 S9(6)V9(2) COMP-3.

y compris les deux positions décimales> longueur est calculée comme ROUND UP [(8 + 1)/2] = 5 octets

Le dernier ½ octet des champs COMP-3 est la représentation HEXIDECIMAL du signe.
Les valeurs du signe ½ octet sont C = signé positif D = signé négatif F = non signé (non COBOL).

S9 (6) V9 (3) VALEUR COMP-3 123,45. La longueur est calculée comme ROND UP [(9 + 1)/2] = 5 octets
Contient X'00 01 23 45 0C '
Notez l'alignement décimal & Rembourrage zéro.

Groupe MOVE Niveau règles

COBOL structures de terrain sont données définissent comme des structures hiérarchiques.

Le 01 HL champ de groupe - & un champ de niveau sous-groupe -

est presque toujours une valeur de chaîne de caractères implicite
Si un champ d'élément individuel est un niveau 01 ou 77 - il peut être numérique.
Les champs d'élément individuels définis comme numériques sous un niveau de groupe ou de sous-groupe seront traités comme numériques s'ils sont référencés comme champ d'élément individuel.
Des règles numériques s'appliquent. o Droit justifier o alignement décimale o tampon H-L (½ bytes) avec des zéros o conversion de type de données numériques

Le champ de réception d'un calcul de déplacement ou mathématique détermine si une conversion de données numériques se produise. Si vous déplacez ou effectuez un calcul mathématique en utilisant un type de champ d'envoi (groupe ou élément) dans un champ d'élément individuel de réception défini à l'aide d'une clause PIC numérique --- alors la conversion de données numériques se produira pour la réception champ. S0C7 s'annonce lorsque des données non numériques sont déplacées vers un champ numériquement défini OU lorsque des calculs mathématiques sont tentés en utilisant des données non numériques.

Non Conversion de données numériques Si vous déplacez un type de champ (groupe ou élément) vers un champ de niveau de groupe ou de sous-groupe, il n'y aura AUCUNE conversion de données numériques.
• Les règles MOVE de caractères s'appliquent.
• Gauche Justifier & pad avec des espaces.

Ceci est l'une des principales causes des données non numériques dans un champ défini numériquement. L'une des principales utilisations d'un MOVE de niveau groupe d'envoi contenant des champs d'éléments numériques à un niveau de groupe récepteur contenant des champs d'éléments numériques (mappés de manière identique) consiste à réinitialiser des champs d'éléments numériques en utilisant l'instruction 1 MOVE.

Un masque d'effacement ou une propagation de données MOVE est également possible pour les effacements de tables - où le niveau de groupe de tables est supérieur à 255 octets.

Source

2010-07-21 19:27:33 user396088

Ceci est très largement absurde, et essayer d'en tirer beaucoup d'avantages est un exercice de perte de temps. –

problème avec mouvement COBOL à la variable

Répondre

Questions connexes