qsam-Befehlsreferenz

Mainframe Connector transcodiert QSAM-Dateien (Queued Sequential Access Method) in Google Cloud -kompatible Formate und umgekehrt. Dazu werden die qsam-Befehle verwendet. Mit den qsam-Befehlen werden die folgenden Transcodierungsvorgänge ausgeführt:

• Mit dem Befehl qsam decode werden Mainframe-Daten in Google Clouddecodiert.
• Mit dem Befehl qsam encode werden Google Cloud -Daten für den Mainframe codiert.

Bei diesen Vorgängen werden symmetrische Transformationen ausgeführt. Das bedeutet, dass dieselben Daten in Google Cloudverschoben werden und von dort verschoben werden. Sie können die Struktur einer QSAM-Datei in einer Copybook-Datei mithilfe der COBOL-Datenstrukturdefinition definieren. Sie können auch erweiterte Transformationen mit der Transcoder-Konfigurationsdatei für Mainframe Connector definieren. Die folgenden Diagramme beschreiben diese Vorgänge im Detail.

Auf dieser Seite finden Sie einen Überblick über den Transcodierungsprozess mit den Befehlen qsam decode und qsam encode, die physischen und logischen Typen von Mainframe-Daten sowie die ORC- und BigQuery-Typzuordnungen.

Physische Typen

Physische Typen definieren, wie Felddaten auf einer Festplatte angeordnet werden. Physische Typen werden in logische Mainframe Connector-Typen konvertiert, die dann Datenbanktypen (ORC oder BigQuery) zugeordnet werden können.

Alphanumerische Felder

Alphanumerische Felder werden zum Verarbeiten alphanumerischer Strings verwendet. Die Daten werden als eine Reihe von Zeichen behandelt und als Strings mit einer bestimmten Codierung gespeichert, z. B. EBCDIC (Extended Binary Coded Decimal Interchange Code). Der Transcodierungsprozess wird nicht beendet, wenn beim Codieren oder Decodieren alphanumerischer Felder Fehler auftreten. Stattdessen wird an der Stelle, an der der Fehler aufgetreten ist, ein SUB-Zeichen für die Codierung eingefügt und der Transcodierungsvorgang wird fortgesetzt.

Beispiel

01 REC
  02 STR      PIC X(10)
  02 NATIONAL PIC N(10)
  02 UTF8     PIC U(1) USAGE UTF-8

Codierungsformat

Alphanumerische Felder werden so codiert:

• X-Felder sind standardmäßig EBCDIC-codiert
• Felder vom Typ „National“ (N) werden standardmäßig mit UTF-16 BE (Unicode Transformation Format 16-bit Big Endian) codiert.
• UTF8-Felder werden standardmäßig mit Unicode Transformation Format-8 (UTF-8) codiert.

Der Mainframe Connector unterstützt die meisten Single-Byte-Zeichensätze (SBCS) und Double-Byte-Zeichensätze (DBCS). Bei Bedarf können Sie auch eine eigene benutzerdefinierte SBCS-Codierung definieren.

Binärfelder (COMPUTATIONAL)

Binärfelder werden als vorzeichenbehaftete oder vorzeichenlose Big-Endian-Ganzzahlen gespeichert. Der Mainframe Connector speichert binäre Felder immer logisch als signierte 64-Bit-Ganzzahlen. Daher dürfen für „unsigned long“-Eingaben nur die unteren 63 Bits verwendet werden. Andernfalls schlägt die Transcodierung fehl.

Beispiel

01 REC
  02 INT PIC S9(8) COMP

Hexadezimale Gleitkommafelder (COMP-1, COMP-2)

Hexadezimale Gleitkommafelder (HFP) werden vollständig unterstützt. Mainframe Connector verwendet sowohl das einfache als auch das doppelte Genauigkeitsformat für HFP-Felder.

Beispiel

01 REC
  03 HFP-SINGLE COMP-1.
  03 HFP-DOUBLE COMP-2.

Gepackte Dezimalfelder (COMP-3)

Gepackte Dezimalfelder werden vollständig unterstützt. Während des Transcodierungsprozesses wählt Mainframe Connector den leistungsstärksten logischen Typ basierend auf der angegebenen Genauigkeit und Skalierung aus.

Beispiel

01 REC
  02 DEC PIC S9(2)V9(8) COMP-3

Zonales Dezimalfeld (DISPLAY)

Zonierte Dezimalfelder werden vollständig unterstützt. Während des Transcodierungsprozesses wählt Mainframe Connector den leistungsstärksten logischen Typ basierend auf der angegebenen Genauigkeit und Skalierung aus.

Beispiel

01 REC
  02 DEC PIC S9(2)V9(8) DISPLAY

Listen (OCCURS)

Listen sind geordnete Sammlungen von Elementen desselben Typs. Der Mainframe Connector unterstützt die folgenden Listentypen:

• Feste Listen
• Dynamische Listen
• Gepackte dynamische Listen

Feste Listen

Feste Listen werden verwendet, wenn die genaue Anzahl der Elemente (Anzahl der Elemente), die Teil der Liste sein werden, im Voraus bekannt ist und diese Anzahl immer gleich bleibt. Die Elemente in einer festen Liste können eine variable Größe haben.

Feste Listen werden in einem Copybook so definiert:

       01 REC.
         02 LIST OCCURS 5 TIMES       PIC X(1).
         02 FLD                       PIC X(5).

Das folgende Bild zeigt das Layout einer festen Liste mit fünf Elementen.

Dynamische Listen

Dynamische Listen werden verwendet, wenn die maximale Anzahl von Elementen, die Teil der Liste sein werden, im Voraus bekannt ist. Die tatsächliche Anzahl der Artikel ist jedoch unbekannt und hängt von einem anderen Feld ab. Die Elemente in einer dynamischen Liste können unterschiedliche Größen haben.

Dynamische Listen haben folgende Eigenschaften:

• Das Feld „Länge“ kann ohne Genauigkeitsverlust in eine Ganzzahl konvertiert werden.
• Das Feld „Länge“ muss im Bereich liegen.
• Die Mindestanzahl an Artikeln wird während der Transcodierung nicht erzwungen.

Dynamische Listen werden in einem Copybook so definiert:

01 REC.
  02 LEN                      PIC S9(2) BINARY.
  02 LIST OCCURS 1 TO 5 TIMES
    DEPENDING ON LEN          PIC X(1).
  02 FLD                      PIC X(5).

Das folgende Bild zeigt das Layout einer dynamischen Liste mit maximal fünf Elementen.

Gepackte dynamische Listen

Gepackte dynamische Listen werden verwendet, wenn die maximale Anzahl von Elementen, die Teil der Liste sein werden, von einem anderen Feld abhängt und die Elemente gepackt sind.

Die Eigenschaften von gepackten dynamischen Listen sind:

• Das Feld „Länge“ kann ohne Genauigkeitsverlust in eine Ganzzahl konvertiert werden.
• Das Feld „Länge“ muss im Bereich liegen.
• Die Mindestanzahl an Artikeln wird während der Transcodierung nicht erzwungen.

Gepackte dynamische Listen werden in einem Copybook so definiert:

01 REC.
  02 LEN                       PIC S9(2) BINARY.
  02 LIST OCCURS UNBOUNDED
      DEPENDING ON LEN         PIC X(1).
  02 FLD                       PIC X(5).

Das folgende Bild zeigt das Layout einer gepackten dynamischen Liste.

Neudefinitionen (REDEFINES)

Redefinitions ist eine COBOL-Funktion, mit der dieselben Daten auf verschiedene Arten decodiert werden können. Während der Decodierung werden Neudefinitionen als zusätzliche Spalten in der resultierenden Tabelle angezeigt und die Daten werden mehrmals decodiert.

Die Eigenschaften von Neudefinitionen sind:

• Neudefinitionen derselben zugrunde liegenden Daten sind keine gleichgeordneten Felder und fallen daher nicht in den Bereich des jeweils anderen.
• Neu definierte Felder werden decodiert, wenn das zugrunde liegende Feld decodiert wird, nicht wenn sie deklariert werden. Das zugrunde liegende Feld bestimmt auch den Bereich der neu definierten Felder.
• Alle neu definierten Felder müssen dieselbe Größe und eine feste Größe haben. Das bedeutet, dass Sie in neu definierten Feldern keine Textfelder mit variabler Länge und keine gepackten dynamischen Listen verwenden können.

Neudefinitionen werden in einem Copybook so definiert:

01  Rec.
05  Field-1   PIC X(100).
05  Group-1 REDEFINES Field-1.
  10  Field-2 PIC 9(5) comp-3.
  10  Field-3 PIC X(96).
05  Group-2 REDEFINES Field-1.
  10  Field-4 PIC 9(4) comp-4.
  10  Field-5 PIC X(50).
  10  Field-6 PIC X(46).

Das folgende Bild zeigt das Layout eines neu definierten Felds.

Sie können Neudefinitionen auf viele Arten verwenden, darunter die folgenden häufigsten:

• Dieselben Daten auf zwei verschiedene Arten ansehen:Das ist die häufigste Verwendung von Neudefinitionen. Während der Codierung ist die Reihenfolge, in der die Daten eingefügt werden, nicht definiert. Sie müssen daher dafür sorgen, dass die Daten in BigQuery beim Exportieren ihre Integrität behalten.

  Beispiel

  01 REC.
    02 FULL-NAME                  PIC X(12).
    02 NAME REDEFINES FULL-NAME.
      05 FIRST-NAME               PIC X(6).
      05 LAST-NAME                PIC X(6).
  

• Tagged Union verwenden:Tagged Unions sind eine gängige Methode, um „Redefines“ zu verwenden, wenn Sie je nach Feld nur eine der Interpretationen der Daten eines Datensatzes benötigen. Mit Nullindikatoren können Sie unnötige Interpretationen als null kennzeichnen. Außerdem wird dadurch verhindert, dass sie aufgrund von Nullindikatoren mit Lazy Evaluations geparst werden. Die Eigenschaften von getaggten Unions sind folgende:

  • Der Codierungsvorgang schlägt fehl, wenn mehr als eine Neudefinition definiert ist.
  • Es werden nur Gleichheits- und Ungleichheitsprüfungen implementiert.

  Beispiel

  01  REC.
  05  TYPE      PIC X(5).
  05  DATA      PIC X(100).
  05  VARIANT-1 REDEFINES DATA.
    10  Field-2 PIC 9(4) comp-3.
    10  Field-3 PIC X(96).
  05  VARIANT-2 REDEFINES DATA.
    10  Field-4 PIC 9(4) comp-5.
    10  Field-5 PIC X(50).
    10  Field-6 PIC X(46).
  

  Mit dem folgenden Beispiel können Sie eine tagged union implementieren:

  {
    "field_override": [
      {
          "field": "VARIANT-1",
          "modifier": {
            "null_if": {
              "target_field": "TYPE",
              "non_null_value": "VAR1"
            }
          }
      },
      {
          "field": "VARIANT-2",
          "modifier": {
            "null_if": {
              "target_field": "TYPE",
              "non_null_value": "VAR2"
            }
          }
      }
    ],
    "transformations": [
      {
        "field": "DATA",
        "transformation": { "exclude": {}}
      }
    ]
  }
  

Logische Typen

Um Daten in mehrere Formate zu transcodieren, konvertiert Mainframe Connector alle Daten in eine Zwischenrepräsentation (Intermediate Representation, IR), die auf logischen Typen basiert. Mit Ein- und Ausgabeformaten wird definiert, wie Daten in einen beliebigen logischen Typ konvertiert werden. In der folgenden Tabelle sind alle logischen Typen aufgeführt, die vom Mainframe Connector unterstützt werden.

ORC-Typzuordnung

In der folgenden Tabelle sehen Sie die Zuordnung zwischen logischen Mainframe Connector-Typen und ORC-Typen.

BigQuery-Typzuordnung

In der folgenden Tabelle sehen Sie die Zuordnung zwischen logischen Mainframe Connector-Typen und BigQuery-Datentypen.

Feldumfang

Ein Feld gilt als im Bereich für ein anderes Feld, wenn es eines der folgenden ist:

• Ein gleichgeordnetes Feld, das vor dem Feld definiert wird, das es erfordert.
• Ein Feld in einem übergeordneten Datensatz, das vor dem Feld definiert wird, in dem es erforderlich ist.