Documentation de référence sur les commandes qsam

Mainframe Connector transcode les fichiers plats QSAM (Queued Sequential Access Method) dans des formats compatibles avec Google Cloud , et inversement à l'aide des commandes qsam. Les commandes qsam effectuent les opérations de transcodage suivantes :

• La commande qsam decode décode les données du mainframe en Google Cloud.
• La commande qsam encode encode les données Google Cloud pour le mainframe.

Ces opérations effectuent des transformations symétriques, c'est-à-dire qu'elles déplacent les mêmes données vers et depuis Google Cloud. Vous pouvez définir la structure d'un fichier QSAM dans un fichier copybook à l'aide de la définition de la structure de données COBOL. Vous pouvez également définir des transformations avancées à l'aide du fichier de configuration du transcodeur Mainframe Connector. Les schémas suivants décrivent ces opérations en détail.

Cette page vous offre un aperçu du processus de transcodage à l'aide des commandes qsam decode et qsam encode, des types physiques et logiques de données mainframe, ainsi que des mappages de types ORC (Optimized Row Columnar) et BigQuery.

Types physiques

Les types physiques définissent la façon dont les données de champ sont disposées sur un disque. Les types physiques sont convertis en types logiques Mainframe Connector, qui peuvent ensuite être mappés sur des types de base de données (ORC ou BigQuery).

Champs alphanumériques

Les champs alphanumériques sont utilisés pour traiter les chaînes alphanumériques. Les données sont traitées comme une série de caractères et stockées sous forme de chaînes avec un encodage spécifique, par exemple EBCDIC (Extended Binary Coded Decimal Interchange Code). Le processus de transcodage ne s'arrête pas en cas d'erreur lors de l'encodage ou du décodage des champs alphanumériques. Au lieu de cela, un caractère SUB pour l'encodage est placé à l'endroit où l'erreur s'est produite, et le processus de transcodage se poursuit.

Exemple

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

Format d'encodage

Les champs alphanumériques sont encodés comme suit :

• X champs sont définis par défaut sur l'encodage EBCDIC
• Les champs nationaux (N) sont définis par défaut sur l'encodage Unicode Transformation Format 16 bits (UTF-16 BE).
• Les champs UTF8 sont définis par défaut sur l'encodage UTF-8 (Unicode Transformation Format-8).

Le connecteur Mainframe est compatible avec la plupart des encodages de jeux de caractères codés sur un octet (SBCS) et sur deux octets (DBCS). Vous pouvez également définir votre propre encodage SBCS personnalisé, si nécessaire.

Champs binaires (COMPUTATIONAL)

Les champs binaires sont stockés sous forme d'entiers big-endian signés ou non signés. Mainframe Connector stocke toujours les champs binaires de manière logique sous forme d'entiers signés de 64 bits. Par conséquent, les entrées unsigned long ne doivent utiliser que les 63 bits inférieurs, sinon le processus de transcodage échoue.

Exemple

01 REC
  02 INT PIC S9(8) COMP

Champs à virgule flottante hexadécimaux (COMP-1, COMP-2)

Les champs hexadécimaux à virgule flottante (HFP) sont entièrement compatibles. Mainframe Connector utilise les formats simple et double précision pour les champs HFP.

Exemple

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

Champs décimaux compressés (COMP-3)

Les champs décimaux compressés sont entièrement compatibles. Lors du processus de transcodage, Mainframe Connector sélectionne le type logique le plus performant en fonction de la précision et de l'échelle spécifiées.

Exemple

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

Champ décimal zoné (DISPLAY)

Les champs décimaux zonés sont entièrement compatibles. Lors du processus de transcodage, Mainframe Connector sélectionne le type logique le plus performant en fonction de la précision et de l'échelle spécifiées.

Exemple

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

Listes (OCCURS)

Les listes sont des collections ordonnées d'éléments du même type. Le connecteur Mainframe est compatible avec les types de listes suivants :

• Listes fixes
• Listes dynamiques
• Listes dynamiques compressées

Listes fixes

Les listes fixes sont utilisées lorsque le nombre exact d'éléments qui feront partie de la liste est connu à l'avance et reste toujours le même. Les éléments d'une liste fixe peuvent être de taille variable.

Dans un copybook, les listes fixes sont définies comme suit :

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

L'image suivante montre la mise en page d'une liste fixe avec un nombre d'éléments de 5.

Listes dynamiques

Les listes dynamiques sont utilisées lorsque le nombre maximal d'éléments qui feront partie de la liste est connu à l'avance. Toutefois, le nombre réel d'articles est inconnu et dépend d'un autre champ. Les éléments d'une liste dynamique peuvent être de taille variable.

Voici les propriétés des listes dynamiques :

• Le champ "length" peut être converti en entier sans perte de précision.
• Le champ "length" (longueur) doit être défini sur scope.
• Le nombre minimal d'éléments n'est pas appliqué lors du processus de transcodage.

Dans un copybook, les listes dynamiques sont définies comme suit :

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).

L'image suivante montre la mise en page d'une liste dynamique avec un nombre maximal d'éléments de cinq.

Listes dynamiques compressées

Les listes dynamiques compressées sont utilisées lorsque le nombre maximal d'éléments qui feront partie de la liste dépend d'un autre champ et que les éléments sont compressés.

Voici les propriétés des listes dynamiques compressées :

• Le champ "length" peut être converti en entier sans perte de précision.
• Le champ "length" (longueur) doit être défini sur scope.
• Le nombre minimal d'éléments n'est pas appliqué lors du processus de transcodage.

Dans un copybook, les listes dynamiques compressées sont définies comme suit :

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

L'image suivante montre la mise en page d'une liste dynamique compactée.

Redéfinitions (REDEFINES)

Redefinitions est une fonctionnalité COBOL qui permet aux mêmes données d'avoir plusieurs possibilités de décodage. Lors du processus de décodage, les redéfinitions apparaissent sous forme de colonnes supplémentaires dans le tableau obtenu, et les données sont décodées plusieurs fois.

Les propriétés des redéfinitions sont les suivantes :

• Les redéfinitions des mêmes données sous-jacentes ne sont pas des champs frères et ne sont donc pas dans le champ d'application les unes des autres.
• Les champs redéfinis sont décodés lorsque le champ sous-jacent est décodé, et non lorsqu'ils sont déclarés. Le champ sous-jacent détermine également le champ d'application des champs redéfinis.
• Tous les champs redéfinis doivent avoir la même taille et être de taille fixe. Cela signifie que vous ne pouvez pas utiliser de champs de texte de longueur variable ni de listes dynamiques compressées dans les champs redéfinis.

Dans un copybook, les redéfinitions sont définies comme suit :

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).

L'image suivante montre la mise en page d'un champ redéfini.

Vous pouvez utiliser les redéfinitions de différentes manières, y compris les plus courantes suivantes :

• Afficher les mêmes données de deux manières différentes : il s'agit de la façon la plus courante d'utiliser les redéfinitions. Lors du processus d'encodage, l'ordre dans lequel les données sont renseignées n'est pas défini. Vous devez donc vous assurer que les données dans BigQuery conservent leur intégrité lorsqu'elles sont exportées.

  Exemple

  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).
  

• Utiliser une union étiquetée : les unions étiquetées sont un moyen courant d'utiliser des redéfinitions lorsque vous n'avez besoin que d'une seule des interprétations des données d'un enregistrement, en fonction d'un champ. Vous pouvez utiliser des indicateurs de valeur nulle pour marquer les interprétations inutiles comme nulles. Cela empêchera également leur analyse en raison de l'évaluation différée des indicateurs null. Les propriétés des unions taguées sont les suivantes :

  • Le processus d'encodage échoue si plusieurs redéfinitions sont définies.
  • Seuls les contrôles d'égalité et de non-égalité sont implémentés.

  Exemple

  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).
  

  Vous pouvez utiliser l'exemple suivant pour implémenter une union taguée :

  {
    "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": {}}
      }
    ]
  }
  

Types logiques

Pour transcoder des données vers et depuis plusieurs formats, Mainframe Connector convertit toutes les données en une représentation intermédiaire (RI) basée sur des types logiques. Les formats d'entrée et de sortie définissent la manière dont les données sont converties vers et depuis n'importe quel type logique. Le tableau suivant liste tous les types logiques compatibles avec Mainframe Connector.

Mappage des types ORC

Le tableau suivant fournit le mappage entre les types logiques Mainframe Connector et les types ORC.

Mappage des types BigQuery

Le tableau suivant présente la correspondance entre les types logiques Mainframe Connector et les types de données BigQuery.

Champ d'application du champ

Un champ est considéré comme dans le champ d'application d'un autre champ s'il remplit l'une des conditions suivantes :

• Champ frère défini avant le champ qui en a besoin.
• Champ d'un enregistrement parent défini avant le champ qui le requiert.