Déplacer les données transcodées localement sur le mainframe vers Google Cloud

Cette page explique comment transcoder des données mainframe localement sur le mainframe dans un format compatible, puis comment transférer le contenu vers BigQuery. Le transcodage est le processus de conversion d'informations d'une forme de représentation codée à une autre. Cette page explique comment utiliser Mainframe Connector pour transcoder des données de mainframe au format ORC (Optimized Row Columnar), puis les enregistrer dans Cloud Storage.

Mainframe Connector propose trois façons de transcoder les données mainframe localement sur le mainframe.

Avantages des commandes qsam et vsam

Les commandes qsam et vsam offrent les avantages suivants :

  • Prise en charge des types de données composites, y compris la clause OCCURS (listes), la clause REDEFINES et les enregistrements imbriqués. Pour en savoir plus sur ces types de données, consultez la documentation sur le transcodage qsam et vsam.
  • Prise en charge de la configuration du processus de transcodage via un fichier de configuration du transcodeur. Cette fonctionnalité offre plus de flexibilité lors du décodage des données vers Google Cloudet de l'encodage des données vers le mainframe.
  • Prise en charge de la création d'un ensemble de données de débordement, qui est un tableau des erreurs de transcodage pouvant être utilisé pour l'inspection des erreurs.
  • Prise en charge de plusieurs formats d'entrée et de sortie. Cette fonctionnalité vous permet de charger vos données vers et depuis différents entrepôts de données.

Avant de commencer

Installez Mainframe Connector sur n'importe quel ensemble de données partitionné sur le mainframe que vous souhaitez utiliser comme bibliothèque de procédures (PROCLIB).

Déplacer les données transcodées localement sur le mainframe vers Google Cloud

Pour transcoder des données localement sur un ordinateur central, puis les transférer vers BigQuery, vous devez effectuer les tâches suivantes :

  1. Lisez et transcodez un ensemble de données sur un ordinateur central, puis importez-le dans Cloud Storage au format ORC (pour les autres formats compatibles uniquement avec les commandes qsam ou vsam, consultez TranscodeFormat). Le transcodage est effectué lors des opérations qsam decode, vsam decode ou gsutil cp (en fonction de la commande que vous choisissez), où un ensemble de données EBCDIC (Extended Binary Coded Decimal Interchange Code) de mainframe est converti au format ORC en UTF-8 lors de la copie dans un bucket Cloud Storage.
  2. Chargez l'ensemble de données dans une table BigQuery.
  3. (Facultatif) Exécutez une requête SQL sur la table BigQuery.
  4. (Facultatif) Exportez les données de BigQuery vers l'ordinateur central.

Les sections suivantes décrivent en détail comment transférer des données transcodées localement sur le mainframe vers Google Cloud à l'aide des commandes qsam ou vsam et de la commande gsutil cp.

Transcoder en local à l'aide des commandes qsam et vsam

Pour transcoder vos données de mainframe en local sur votre mainframe à l'aide des commandes qsam ou vsam, procédez comme suit :

  1. Créez un job pour lire l'ensemble de données sur votre ordinateur central et le transcoder au format ORC, comme indiqué dans la commande suivante. Lisez les données de l'ensemble de données INFILE et la mise en page de l'enregistrement à partir du DD COPYBOOK.

    Vous pouvez modifier le comportement par défaut du processus de transcodage Mainframe Connector en fournissant un fichier de configuration du transcodeur à l'aide de l'argument --transcode-configuration.

    • Si votre ensemble de données d'entrée est un fichier QSAM (Queued Sequential Access Method) avec une longueur d'enregistrement fixe ou variable, utilisez la commande suivante :

      //STEP01 EXEC BQSH
      //INFILE DD DSN=<HLQ>.DATA.FILENAME,DISP=SHR
      //COPYBOOK DD DISP=SHR,DSN=<HLQ>.COPYBOOK.CPY
      //CONFIG DD DISP=SHR,DSN=<HLQ>.CONFIG.SETTINGS
      //STDIN DD *
      BUCKET=BUCKET_NAME
      qsam decode --copybook dd:COPYBOOK --transcode-configuration dd:CONFIG dd:INFILE gs://$BUCKET/tablename
      /*
      
    • Si votre ensemble de données d'entrée est un fichier VSAM (Virtual Storage Access Method) avec une longueur d'enregistrement fixe ou variable, utilisez la commande suivante :

      //STEP01 EXEC BQSH
      //INFILE DD DSN=<HLQ>.DATA.FILENAME,DISP=SHR
      //COPYBOOK DD DISP=SHR,DSN=<HLQ>.COPYBOOK.CPY
      //CONFIG DD DISP=SHR,DSN=<HLQ>.CONFIG.SETTINGS
      //STDIN DD *
      BUCKET=BUCKET_NAME
      vsam decode --copybook dd:COPYBOOK --transcode-configuration dd:CONFIG dd:INFILE gs://$BUCKET/tablename
      /*
      

    Remplacez BUCKET_NAME par le nom du bucket Cloud Storage dans lequel vous souhaitez copier les données du mainframe.

    Pour éviter de spécifier des variables telles que les ID de projet et les noms de bucket dans chaque procédure JCL (Job Control Language), vous pouvez les ajouter dans BQSH PROCLIB et les référencer dans plusieurs procédures JCL en tant que variables d'environnement. Cette approche permet également d'assurer une transition fluide entre les environnements de production et hors production, car les variables spécifiques à l'environnement sont définies dans le PROCLIB BQSH de l'environnement.

    Dans cet exemple, DD DataPath est utilisé pour spécifier le chemin d'accès au copybook, à l'entrée et à la configuration du transcodage. Pour d'autres options, consultez DataPath.

    Si vous souhaitez consigner les commandes exécutées au cours de ce processus, vous pouvez activer les statistiques de chargement.

  2. Créez et envoyez une tâche de chargement BigQuery qui charge les partitions de fichier ORC depuis tablename.orc dans MY_DATASET.MY_TABLE, comme suit.

    Example JCL
    //STEP02 EXEC BQSH
    //STDIN DD *
    BUCKET=BUCKET_NAME
    PROJECT=PROJECT_NAME
    bq load --project_id=$PROJECT \
      myproject:MY_DATASET.MY_TABLE \
      gs://$BUCKET/tablename.orc/*
    /*
    

    Remplacez les éléments suivants :

    • BUCKET_NAME : nom du bucket Cloud Storage contenant les fichiers ORC que vous souhaitez charger dans BigQuery.
    • PROJECT_NAME : nom du projet dans lequel vous souhaitez exécuter la requête.
  3. (Facultatif) Créez et envoyez un job de requête BigQuery qui exécute une lecture SQL à partir du fichier DD QUERY. En règle générale, la requête est une instruction MERGE ou SELECT INTO DML qui entraîne la transformation d'une table BigQuery. Notez que le connecteur Mainframe enregistre les métriques des jobs, mais n'écrit pas les résultats des requêtes dans un fichier.

    Vous pouvez interroger BigQuery de différentes manières : de manière intégrée, avec un ensemble de données distinct à l'aide de DD ou avec un ensemble de données distinct à l'aide de DSN.

    Example JCL
    //STEP03 EXEC BQSH
    //QUERY DD DSN=<HLQ>.QUERY.FILENAME,DISP=SHR
    //STDIN DD *
    PROJECT=PROJECT_NAME
    LOCATION=LOCATION
    bq query --project_id=$PROJECT \
    --location=$LOCATION/*
    /*
    

    Remplacez les éléments suivants :

    • PROJECT_NAME : nom du projet dans lequel vous souhaitez exécuter la requête.
    • LOCATION : emplacement où la requête sera exécutée. Nous vous recommandons d'exécuter la requête dans un emplacement proche des données.
  4. (Facultatif) Créez et envoyez un job d'exportation qui exécute une lecture SQL à partir du fichier DD QUERY et exporte l'ensemble de données résultant vers un ordinateur central sous forme de fichier binaire.

    Vous pouvez modifier le comportement par défaut du processus de transcodage Mainframe Connector en fournissant un fichier de configuration du transcodeur à l'aide de l'argument --transcode-configuration.

    //STEP04 EXEC BQSH
    //OUTFILE DD DSN=<HLQ>.DATA.FILENAME,DISP=SHR
    //COPYBOOK DD DISP=SHR,DSN=<HLQ>.COPYBOOK.CPY
    //CONFIG DD DISP=SHR,DSN=<HLQ>.CONFIG.SETTINGS
    //QUERY DD DSN=<HLQ>.QUERY.FILENAME,DISP=SHR
    //STDIN DD *
    
    PROJECT=PROJECT_NAME
    qsam encode \
      dd:QUERY
      dd:OUTFILE
      --copybook dd:COPYBOOK
      --transcode-configuration dd:CONFIG
      --input-format=BIGQUERY \
      --input-parameter project_id=PROJECT_NAME \
      --input-parameter location=LOCATION/*
    /*
    

    Remplacez les éléments suivants :

    • PROJECT_NAME : nom du projet dans lequel vous souhaitez exécuter la requête.
    • LOCATION : emplacement où la requête sera exécutée. Nous vous recommandons d'exécuter la requête dans un emplacement proche des données.

    Les données sont exportées vers l'ensemble de données OUTFILE DD. La mise en page de l'enregistrement est décrite par le COPYBOOK DD. Pour connaître les autres options de chemins de configuration de copybook, d'outfile et de transcodage, consultez DataPath.

Transcoder en local à l'aide de la commande gsutil cp

Pour transcoder vos données de mainframe en local sur votre mainframe à l'aide de la commande gsutil cp, procédez comme suit :

  1. Créez un job pour lire l'ensemble de données sur votre ordinateur central et le transcoder au format ORC, comme indiqué dans la commande suivante. Lisez les données de l'ensemble de données INFILE et la mise en page de l'enregistrement à partir du DD COPYBOOK.

    L'ensemble de données d'entrée doit être un fichier QSAM (Queued Sequential Access Method) avec une longueur d'enregistrement fixe ou variable.

    //STEP01 EXEC BQSH
    //INFILE DD DSN=<HLQ>.DATA.FILENAME,DISP=SHR
    //COPYBOOK DD DISP=SHR,DSN=<HLQ>.COPYBOOK.FILENAME
    //STDIN DD *
    BUCKET=BUCKET_NAME
    gsutil cp --replace gs://$BUCKET/tablename.orc
    /*
    

    Remplacez BUCKET_NAME par le nom du bucket Cloud Storage dans lequel vous souhaitez copier les données du mainframe.

    Pour éviter de spécifier des variables telles que les ID de projet et les noms de buckets dans chaque procédure JCL, vous pouvez les ajouter dans la PROCLIB BQSH et les référencer dans plusieurs procédures JCL en tant que variables d'environnement. Cette approche permet également d'assurer une transition fluide entre les environnements de production et hors production, car les variables spécifiques à l'environnement sont définies dans le PROCLIB BQSH de l'environnement. Pour obtenir la liste complète des variables d'environnement compatibles avec Mainframe Connector, consultez Variables d'environnement.

    Dans cet exemple, l'entrée standard (STDIN) est fournie sous forme de données en flux continu à la DD STDIN. Vous pouvez également fournir cette entrée à l'aide d'un nom de source de données (DSN), ce qui facilite la gestion de la substitution de symboles.

    Si vous souhaitez consigner les commandes exécutées au cours de ce processus, vous pouvez activer les statistiques de chargement.

  2. Créez et envoyez une tâche de chargement BigQuery qui charge les partitions de fichier ORC depuis tablename.orc dans MY_DATASET.MY_TABLE, comme suit.

    Example JCL
    //STEP02 EXEC BQSH
    //STDIN DD *
    BUCKET=BUCKET_NAME
    PROJECT=PROJECT_NAME
    bq load --project_id=$PROJECT \
      myproject:MY_DATASET.MY_TABLE \
      gs://$BUCKET/tablename.orc/*
    /*
    

    Remplacez les éléments suivants :

    • BUCKET_NAME : nom du bucket Cloud Storage contenant les fichiers ORC que vous souhaitez charger dans BigQuery.
    • PROJECT_NAME : nom du projet dans lequel vous souhaitez exécuter la requête.
  3. (Facultatif) Créez et envoyez un job de requête BigQuery qui exécute une lecture SQL à partir du fichier DD QUERY. En règle générale, la requête est une instruction MERGE ou SELECT INTO DML qui entraîne la transformation d'une table BigQuery. Notez que le connecteur Mainframe enregistre les métriques des jobs, mais n'écrit pas les résultats des requêtes dans un fichier.

    Vous pouvez interroger BigQuery de différentes manières : de manière intégrée, avec un ensemble de données distinct à l'aide de DD ou avec un ensemble de données distinct à l'aide de DSN.

    Example JCL
    //STEP03 EXEC BQSH
    //QUERY DD DSN=<HLQ>.QUERY.FILENAME,DISP=SHR
    //STDIN DD *
    PROJECT=PROJECT_NAME
    LOCATION=LOCATION
    bq query --project_id=$PROJECT \
    --location=$LOCATION/*
    /*
    

    Remplacez les éléments suivants :

    • PROJECT_NAME : nom du projet dans lequel vous souhaitez exécuter la requête.
    • LOCATION : emplacement où la requête sera exécutée. Nous vous recommandons d'exécuter la requête dans un emplacement proche des données.
  4. (Facultatif) Créez et envoyez un job d'exportation qui exécute une lecture SQL à partir du fichier DD QUERY et exporte l'ensemble de données résultant vers un ordinateur central sous forme de fichier binaire.

    Example JCL
    //STEP04 EXEC BQSH
    //OUTFILE DD DSN=<HLQ>.DATA.FILENAME,DISP=SHR
    //COPYBOOK DD DISP=SHR,DSN=<HLQ>.COPYBOOK.FILENAME
    //QUERY DD DSN=<HLQ>.QUERY.FILENAME,DISP=SHR
    //STDIN DD *
    PROJECT=PROJECT_NAME
    DATASET_ID=DATASET_ID
    DESTINATION_TABLE=DESTINATION_TABLE
    bq export --project_id=$PROJECT \
      --dataset_id=$DATASET_ID \
      --destination_table=$DESTINATION_TABLE \
      --location="US" \
      --remoteHost <mainframe-connector-url>.a.run.app \
      --remotePort 443
    /*
    

    Remplacez les éléments suivants :

    • PROJECT_NAME : nom du projet dans lequel vous souhaitez exécuter la requête.
    • DATASET_ID : ID de l'ensemble de données BigQuery contenant la table que vous souhaitez exporter.
    • DESTINATION_TABLE : table BigQuery que vous souhaitez exporter.

    Les données sont exportées vers l'ensemble de données OUTFILE DD. La mise en page de l'enregistrement est décrite par le COPYBOOK DD.