Problem mit COBOL zur Variable comp-3 verschieben

8

Ich habe das folgende Problem in einem COBOL-Programm, das auf OpenVMS läuft.

Ich habe die folgende Variablendeklaration:

%Vor%

Und der folgende Code:

%Vor%

Welche Ausgaben:

%Vor%

Warum behalten FIELD-A und FIELD-B andere Werte als die, in die ich mich im zweiten Test bewege?

Ich habe andere Verschiebungen von DISPLAY zu COMP-3 Variablen in meinem Programm, wo ich dieses Verhalten nicht bekomme.

    
mmutilva 01.07.2010, 20:48
quelle

2 Antworten

4

In COBOL sind Daten auf Gruppenebene typenlos und werden ohne Umwandlung verschoben.

Daten auf Elementebene haben immer einen zugeordneten Datentyp. Getippt Die Daten werden so umgewandelt, dass sie dem Typ entsprechen des empfangenden Elements während eines MOVE .

In erster Instanz haben Sie MOVE einen literalen numerischen Wert ( 112011 ) für ein gepacktes Dezimalfeld, und der Compiler wandelt es dabei in den richtigen Datentyp um. So wie Sie es in jeder Programmiersprache erwarten würden.

In der zweiten Instanz haben Sie MOVE einen Literalwert für ein Gruppenelement. Da es sich um ein Gruppenelement handelt, kann der Compiler den beabsichtigten Datentyp nicht "wissen", so dass Gruppenbewegungen immer als Zeichendaten ausgeführt werden (keine numerischen Konvertierungen). Dies ist in Ordnung, wenn das empfangende Objekt eine PICTURE -Klausel hat, die mit Zeichendaten kompatibel ist - welche FIELD-A und FIELD-B von SUB-STRUCT-1 sind. Es gibt keinen Unterschied in der internen Repräsentation von 9 , wenn sie als PIC X und als PIC 9 gespeichert sind. Beide werden als USAGE DISPLAY angenommen.

Wenn Sie nun eine Gruppen-Level-Verschiebung von SUB-STRUCT-1 zu einem COMP-3 (Packed Decimal) durchführen, sagen Sie dem Compiler effektiv, dass er nicht von DISPLAY in das Format COMP-3 konvertiert. Und das ist was du bekommst.

Probieren Sie die folgenden Änderungen an Ihrem Code aus. Verwendung von REDEFINES erstellt ein numerisches Grundelement für den Umzug. COBOL wird das Richtige tun Datenkonvertierungen beim Verschieben von Elementardaten.

%Vor%

Und der folgende Code:

%Vor%

Vorsicht: Das Verschieben von Zeichendaten in ein Feld COMP-3 kann dazu führen, dass die gefürchtete SOC7-Datenausnahme aufhört, wenn auf das empfangende Objekt verwiesen wird. Dies liegt daran, dass nicht alle Bitmuster gültige COMP-3-Nummern sind.

    
NealB 02.07.2010, 12:23
quelle
2

Sie haben 2 Probleme.

COBOL hat mehrere numerische Datenstrukturen. Jeder hat seine eigenen Regeln.

Für PACKED DECIMAL (COMP-3)
• Die numerischen Komponenten der PIC-Klausel sollten IMMER eine ODD-Nummer ergeben. • Die Dezimalmarke "V" bestimmt die Platzierung des Dezimalpunkts. • Die MOVE- und mathematischen Funktionen des einzelnen Elements behalten die Dezimalwertausrichtung bei - Abschneiden auf hoher und niedriger Ebene ist möglich • Die Konvertierung des numerischen Datentyps (dezimale Zone in gepackt und binär in gepackt) wird für Sie erledigt.

z.B. S9 (5) V9 (2) COMP-3.
 einschließlich der 2 Dezimalstellen & gt; Die Länge wird berechnet als ROUND UP [(7 + 1) / 2] = 4 Bytes

%Vor%

einschließlich der 2 Dezimalstellen & gt; Die Länge wird berechnet als ROUND UP [(8 + 1) / 2] = 5 Bytes Aber das 1. ½ Byte ist nicht adressierbar

Das letzte halbe Byte der COMP-3-Felder ist die HEXIDECIMAL-Darstellung des Zeichens.
Die Vorzeichen-Halbbyte-Werte sind C = vorzeichenbehaftet positiv D = vorzeichenbehaftet negativ F = vorzeichenlos (nicht COBOL).

S9 (6) V9 (3) COMP-3 WERT 123.45. Die Länge wird wie folgt berechnet: ROUND UP [(9 + 1) / 2] = 5 Bytes
Enthält X'00 01 23 45 0C '
Beachten Sie die Dezimalausrichtung & amp; Zero Padding.

MOVE-Regeln auf Gruppenebene

COBOL Datenfeldstrukturen sind als hierarchische Strukturen definiert.

Das 01 H-L Gruppenfeld - & amp; jedes Untergruppenlevelfeld -

  1. Ist fast immer ein implizierter CHARACTER-String-Wert
  2. Wenn ein einzelnes Elementfeld eine 01- oder 77-Ebene ist, dann kann es numerisch sein.
  3. Einzelne Elementfelder, die unter einer Gruppen- oder Untergruppenebene als numerisch definiert sind, werden als numerisch behandelt, wenn sie als einzelnes Elementfeld referenziert werden.
  4. Numerische Regeln gelten. o Recht zu rechtfertigen o Dezimalstelle Ausrichtung o setze H-L (1/2 Bytes) mit Nullen auf o Numerische Datentypkonvertierung

Das Empfangsfeld einer MOVE- oder Mathematikberechnung bestimmt, ob eine numerische Datenkonvertierung stattfindet.

Numerische Datenkonvertierung Wenn Sie MOVE oder eine mathematische Berechnung mit einem beliebigen sendenden Feldtyp (Gruppe oder Element) für ein beliebiges empfangendes Elementfeld ausführen, das mit einer numerischen PIC-Klausel definiert wurde, wird für das empfangende Feld eine numerische Datenkonvertierung durchgeführt. S0C7-Abneigungen treten auf, wenn nicht numerische Daten MOVE 'd zu einem empfangenden numerisch definierten Feld ODER wenn mathematische Berechnungen mit nicht numerischen Daten versucht werden.

Keine numerische Datenkonvertierung Wenn Sie einen Feldtyp (Gruppe oder Element) in ein Gruppen- oder Untergruppenebenenfeld verschieben, erfolgt keine numerische Datenkonvertierung.
• Zeichen MOVE-Regeln gelten.
• Linksbündig & amp; Pad mit Leerzeichen.

Dies ist einer der Hauptgründe für nicht numerische Daten in einem numerisch definierten Feld.

Einer der primären Verwendungen einer Sendegruppenebene MOVE, die numerische Elementfelder enthält, auf eine Empfängergruppenebene, die numerische Elementfelder enthält (identisch zugeordnet), dient zur Neuinitialisierung numerischer Elementfelder unter Verwendung der 1 MOVE-Anweisung.

Eine Clear Mask - oder - eine Datenweitergabe MOVE ist auch für Table Clears möglich - wobei die Tabellengruppenebene größer als 255 Byte ist.

    
user396088 21.07.2010 19:27
quelle

Tags und Links