Utilitaires d’ensemble de données IBM

Les programmes utilitaires sont des programmes pré-écrits, largement utilisés dans les mainframes par les programmeurs système et les développeurs d’applications pour répondre aux exigences quotidiennes, organiser et maintenir les données. Quelques-uns d’entre eux sont listés ci-dessous avec leurs fonctionnalités :

Nom de l’utilitaire	Fonctionnalité
IEHMOVE	Déplace ou copie des jeux de données séquentiels.
IEHPROGM	Supprimer et renommer des ensembles de données ; cataloguer ou décataloguer des ensembles de données autres que VSAM.<
IEHCOMPR	Compare les données dans des ensembles de données séquentiels.
IEBCOPY	Copiez, fusionnez, compressez, sauvegardez ou restaurez le PDS.
IEFBR14	Aucun utilitaire d’opération. Utilisé pour rendre le contrôle à l’utilisateur et terminer. Il est généralement utilisé pour créer un jeu de données vide ou supprimer un jeu de données existant. Par exemple, si un jeu de données est passé en entrée à un programme IEFBR14 avec DISP=(OLD,DELETE,DELETE), le jeu de données est supprimé à la fin du travail.
IEBEDIT	Utilisé pour copier des parties sélectionnées d’un JCL. Par exemple, si un JCL comporte 5 étapes et que nous devons exécuter les étapes 1 et 3 uniquement, un JCL IEBEDIT peut être codé avec un jeu de données qui contient le JCL réel à exécuter. Dans le SYSIN d’IEBEDIT, nous pouvons spécifier STEP1 et STEP3 comme paramètres. Lorsque ce JCL est exécuté, il exécute les STEP1 et STEP3 du JCL réel.
IDCAM	Créer, supprimer, renommer, cataloguer, décataloguer des ensembles de données (autres que PDS). Généralement utilisé pour gérer les ensembles de données VSAM.
IEBDG	Programme de générateur de données de test
IEBGENER	Programme séquentiel de copie/génération d’ensemble de données
IEBIMAGE	Créer un programme d’image d’imprimante (print)
IEBPDSE	Programme de validation PDSE
IEBPTPCH	Programme d’impression-perforation
IEBUPDTE	Mettre à jour le programme d’ensemble de données
IEHINITT	Initialiser le programme de bande
IEHLIST	Lister le programme de données système
IFHSTATR	Liste des programmes de données ESV

Ces programmes utilitaires doivent être utilisés avec les instructions DD appropriées dans un JCL afin d’obtenir la fonctionnalité spécifiée.

Ci-dessous un exemple JCL où le programme MYPROG est exécuté à l’aide du fichier d’entrée MYDATA.LCDC.INPUT et produit deux fichiers de sortie écrits dans le spool.

//COBBSTEP  JOB CLASS=6,NOTIFY=&SYSUID
//
//STEP10    EXEC PGM=MYPROG,PARM=ACCT5000
//STEPLIB   DD DSN=MYDATA.LCDC.LOADLIB,DISP=SHR
//INPUT1    DD DSN=MYDATA.LCDC.INPUT,DISP=SHR
//OUT1      DD SYSOUT=*
//OUT2      DD SYSOUT=*
//SYSIN     DD *
//CUST1     1000
//CUST2     1001
/*

Le module de chargement de MYPROG se trouve dans MYDATA.LCDC.LOADLIB.
Il est important de noter que le JCL ci-dessus ne peut être utilisé que pour un module COBOL non DB2.

Transmission de données aux programmes COBOL

L’entrée de données dans le programme batch COBOL peut se faire via des fichiers, le paramètre PARAM et l’instruction SYSIN DD. 

Dans l’exemple ci-dessus :

• Les enregistrements de données sont transmis à MYPROG via le fichier MYDATA.LCDC.INPUT.
  Ce fichier sera référencé dans le programme en utilisant le nom DD INPUT1.
  Le fichier peut être ouvert, lu et fermé dans le programme.
• Les données de paramètre PARM ACCT5000 sont reçues dans la section LINKAGE du programme MYPROG dans une variable définie dans cette section.
• Les données de l’instruction SYSIN sont reçues via l’instruction ACCEPT dans la division PROCEDURE du programme.
  Chaque instruction ACCEPT lit un enregistrement entier (c’est-à-dire, CUST1 1000) dans une variable de stockage de travail définie dans le programme.

Exécution d’un programme COBOL-DB2

Pour exécuter le programme COBOL DB2, un utilitaire IBM spécialisé est utilisé dans le JCL et le programme ; La région DB2 et les paramètres requis sont transmis en entrée à l’utilitaire.

Les étapes ci-dessous sont suivies lors de l’exécution d’un programme COBOL-DB2 :

• Lorsqu’un programme COBOL-DB2 est compilé, un DBRM (Database Request Module) est créé avec le module de chargement.
  Le DBRM contient les instructions SQL des programmes COBOL avec sa syntaxe vérifiée pour être correcte.
• Le DBRM est lié à la région DB2 (environnement) dans laquelle le COBOL s’exécutera.
  Cela peut être fait à l’aide de l’utilitaire IKJEFT01 dans un JCL.
• Après l’étape de liaison, le programme COBOL-DB2 est exécuté à l’aide de IKJEFT01 (à nouveau) avec la bibliothèque de chargement et la bibliothèque DBRM comme entrée du JCL.

//STEP001  EXEC PGM=IKJEFT01
//*
//STEPLIB  DD DSN=MYDATA.LCDC.DBRMLIB,DISP=SHR
//*
//input files
//output files
//SYSPRINT DD SYSOUT=*
//SYSABOUT DD SYSOUT=*
//SYSDBOUT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//DISPLAY  DD SYSOUT=*
//SYSOUT   DD SYSOUT=*
//SYSTSPRT DD SYSOUT=*
//SYSTSIN  DD *
    DSN SYSTEM(SSID)
    RUN PROGRAM(MYCOBB) PLAN(PLANNOM) PARM(paramètres du programme cobol) -
    LIB('MYDATA.LCDC.LOADLIB')
    END
/*

Dans l’exemple ci-dessus, MYCOBB est le programme COBOL-DB2 exécuté à l’aide de IKJEFT01. Veuillez noter que le nom du programme, l’ID du sous-système DB2 (SSID) et le nom du plan DB2 sont transmis dans l’instruction SYSTSIN DD. La bibliothèque DBRM est spécifiée dans la STEPLIB.

Pour exécuter un programme COBOL en mode batch à l’aide de JCL, le programme doit être compilé et un module de chargement est créé avec tous les sous-programmes.
Le JCL utilise le module de chargement et non le programme réel au moment de l’exécution.
Les bibliothèques de chargement sont concaténées et transmises au JCL au moment de l’exécution à l’aide de JCLLIB ou STEPLIB.

Il existe de nombreux utilitaires de compilateur mainframe disponibles pour compiler un programme COBOL.
Certaines entreprises utilisent des outils de gestion du changement comme Endevor, qui compile et stocke chaque version du programme.
Ceci est utile pour suivre les modifications apportées au programme.

//COMPILE   JOB ,CLASS=6,MSGCLASS=X,NOTIFY=&SYSUID             
//*            
//STEP1     EXEC IGYCRCTL,PARM=RMODE,DYNAM,SSRANGE
//SYSIN     DD DSN=MYDATA.LCDC.SOURCES(MYCOBB),DISP=SHR
//SYSLIB    DD DSN=MYDATA.LCDC.COPYBOOK(MYCOPY),DISP=SHR
//SYSLMOD   DD DSN=MYDATA.LCDC.LOAD(MYCOBB),DISP=SHR
//SYSPRINT  DD SYSOUT=*
//*

IGYCRCTL est un utilitaire de compilateur IBM COBOL.
Les options du compilateur sont transmises à l’aide du paramètre PARM.
Dans l’exemple ci-dessus, RMODE demande au compilateur d’utiliser le mode d’adressage relatif dans le programme.
Le programme COBOL est passé à l’aide du paramètre SYSIN et le copybook est la bibliothèque utilisée par le programme dans SYSLIB.

Ce JCL produit le module de chargement du programme en sortie qui sert d’entrée au JCL d’exécution.

Tout programme batch exécuté via un JCL nécessite une entrée de données, qui est traitée et une sortie est créée.
Il existe différentes méthodes pour alimenter le programme en entrée et écrire la sortie reçue d’un JCL.
En mode batch, aucune intervention de l’utilisateur n’est requise, mais les périphériques d’entrée et de sortie et l’organisation requise sont définis dans JCL et soumis.

Saisie de données dans un JCL

Il existe différentes manières d’alimenter les données d’un programme à l’aide de JCL et ces méthodes ont été expliquées ci-dessous :

Instream Data/Données Intégrées

Les données entrantes dans un programme peuvent être spécifiées à l’aide d’une instruction SYSIN DD.

//CONCATEX JOB CLASS=6,NOTIFY=&SYSUID
//* Exemple 1:
//STEP10 EXEC PGM=MYPROG
//IN1    DD DSN=FICHIER.INPUT1,DISP=SHR
//OUT1   DD DSN=FICHIER.OUTPUT1,DISP=(,CATLG,DELETE),
//       LRECL=50,RECFM=FB
//SYSIN  DD *
//CUST1  1000
//CUST2  1001
/*
//*
//* Exemple 2:
//STEP20 EXEC PGM=MYPROG
//OUT1   DD DSN=FICHIER.OUTPUT2,DISP=(,CATLG,DELETE),
//       LRECL=50,RECFM=FB
//SYSIN  DD DSN=FICHIER.SYSIN.DATA,DISP=SHR
//*

Dans l’exemple 1, l’entrée de MYPROG est transmise via SYSIN.
Les données sont fournies dans le JCL. Deux enregistrements de données sont transmis au programme. Veuillez noter que /* marque la fin des données SYSIN instream.

“CUST1 1000” est record1 et “CUST2 1001” est record2. La condition de fin de données est remplie lorsque le symbole /* est rencontré lors de la lecture des données.

Dans l’exemple 2, les données SYSIN sont conservées dans un ensemble de données, où FICHIER.SYSIN.DATA est un fichier PS, qui peut contenir un ou plusieurs enregistrements de données.

Saisie de données (Data Input) via des fichiers

Comme mentionné dans la plupart des exemples des chapitres précédents, les entrées de données dans un programme peuvent être fournies via des fichiers PS, VSAM ou GDG, avec le nom DSN et les paramètres DISP pertinents ainsi que les instructions DD.

Dans l’exemple 1, FICHIER.INPUT1 est le fichier d’entrée par lequel les données sont transmises à MYPROG.
Il est appelé IN1 dans le programme.

Sortie de données (Data Output) dans un JCL

La sortie d’un JCL peut être cataloguée dans un ensemble de données ou transmise au SYSOUT.
Comme mentionné dans le chapitre sur les instructions DD, SYSOUT=* redirige la sortie vers la même classe que celle mentionnée dans le paramètre MSGCLASS de l’instruction JOB.

Enregistrement des Logs Job

La spécification de MSGCLASS=Y enregistre la log du job dans JMR (Joblog Management and Retrieval).
La log du JOB entier peut être redirigé vers le SPOOL et peut être enregistré dans un jeu de données en donnant la commande XDC contre le nom du job dans le SPOOL.
Lorsque la commande XDC est donnée dans le SPOOL, un écran de création de jeu de données s’ouvre.
La log du job peut ensuite être enregistrée en donnant la définition PS ou PDS appropriée.

Les logs de job peuvent également être enregistrées dans un jeu de données en mentionnant un jeu de données déjà créé pour SYSOUT et SYSPRINT.
Mais l’intégralité de la log du job ne peut pas être capturée de cette manière (c’est-à-dire que JESMSG ne sera pas catalogué) comme cela se fait dans JMR ou XDC.

//EXINST JOB 1,CLASS=6,MSGCLASS=Y,NOTIFY=&SYSUID
//*
//STEP1    EXEC PGM=MYPROG
//IN1      DD DSN=MYDATA.LCDC.INPUT,DISP=SHR
//OUT1     DD SYSOUT=*
//SYSOUT   DD DSN=MYDATA.LCDC.SYSOUT,DISP=SHR
//SYSPRINT DD DSN=MYDATA.LCDC.SYSPRINT,DISP=SHR
//SYSIN    DD MYDATA.BASE.LIB1(DATA1),DISP=SHR
//*
//STEP2    EXEC PGM=SORT

Dans l’exemple ci-dessus, SYSOUT est catalogué dans MYDATA.LCDC.SYSOUT et SYSPRINT dans MYDATA.LCDC.SYSPRINT.

Dans l’exemple suivant, la dernière version de MYDATA.LCDC.FICHIER.GDG est utilisée comme entrée du programme et une nouvelle version de MYDATA.LCDC.FICHIER.GDG est créée comme sortie.

//CNDSAMP JOB CLASS=6,NOTIFY=&SYSUID
//*
//STP01   EXEC PGM=MYCOBB
//IN1     DD DSN=MYDATA.LCDC.FICHIER.GDG(0),DISP=SHR
//OUT1    DD DSN=MYDATA.LCDC.FICHIER.GDG(+1),DISP=(,CALTG,DELETE)
//        LRECL=100,RECFM=FB

Ici, si le GDG a été référencé par le nom réel comme MYDATA.LCDC.FICHIER.GDG.G0001V00, cela conduit à changer le JCL à chaque fois avant l’exécution.
L’utilisation de (0) et (+1) permet de substituer dynamiquement la version GDG pour l’exécution.

À l’aide de l’utilitaire IEFBR14, nous pouvons supprimer une seule version d’un GDG.

//GDGSTEP3   EXEC PGM=IEFBR14
//GDGDEL     DD  DSN=MYDATA.LCDC.FICHIER.GDG(0),
//           DISP=(OLD,DELETE,DELETE)

Dans l’exemple ci-dessus, la dernière version de MYDATA.LCDC.FICHIER.GDG est supprimée.
Veuillez noter que le paramètre DISP à l’achèvement normal du job est codé comme DELETE.
Par conséquent, le jeu de données est supprimé lorsque l’exécution du job est terminée.

IDCAMS peut être utilisé pour supprimer le GDG et ses versions associées à l’aide de la commande SYSIN DELETE(MYDATA.LCDC.FICHIER.GDG) GDG FORCE/PURGE.

• FORCE supprime les versions GDG et la base GDG.
  Si l’une des versions de GDG est définie avec une date d’expiration qui n’a pas encore expiré, celles-ci ne sont pas supprimées et, par conséquent, la base de GDG est conservée.
• PURGE supprime les versions GDG et la base GDG quelle que soit la date d’expiration.

Les versions GDG peuvent avoir des paramètres DCB identiques ou différents.
Un DCB modèle initial peut être défini pour être utilisé par toutes les versions, mais il peut être remplacé lors de la création de nouvelles versions.
Vous verrez donc sur cette page une création/modification de GDG.

//GDGSTEP1 EXEC PGM=IDCAMS
//SYSPRINT DD  SYSOUT=*
//SYSIN    DD  *
           DEFINE GDG(NAME(MYDATA.LCDC.FICHIER.GDG)   -
           LIMIT(7)                           -
           NOEMPTY                            -
           SCRATCH)
/*
//GDGSTEP2 EXEC PGM=IEFBR14
//GDGMODLD DD  DSN=MYDATA.LCDC.FICHIER.GDG,
//         DISP=(NEW,CATLG,DELETE),
//         UNIT=SYSDA,
//         SPACE=(CYL,10,20),
//         DCB=(LRECL=50,RECFM=FB)
//

Dans l’exemple ci-dessus, l’utilitaire IDCAMS définit la base GDG dans GDGSTEP1 avec les paramètres ci-dessous passés dans l’instruction SYSIN DD :

• NAME spécifie le nom du jeu de données physique de la base GDG.
• LIMIT spécifie le nombre maximum de versions que la base GDG peut contenir.
• EMPTY décatalogue toutes les générations lorsque la LIMITE est atteinte.
• NOEMPTY décatalogue la génération la moins récente.
• SCRATCH supprime physiquement la génération lorsqu’elle est décataloguée.
• NOSCRATCH ne supprime pas le jeu de données, c’est-à-dire qu’il peut être référencé à l’aide des paramètres UNIT et VOL.

Ici, dans GDGSTEP2, l’utilitaire IEFBR14 spécifie les paramètres DD du modèle à utiliser par toutes les versions.

IDCAMS peut être utilisé pour modifier les paramètres de définition d’un GDG, comme augmenter LIMIT, changer EMPTY en NOEMPTY, etc., et ses versions associées utilisant la commande SYSIN sont ALTER MYDATA.URMI.SAMPLE.GDG LIMIT(15) EMPTY.

Dans un JCL standardisé, le programme à exécuter et ses jeux de données associés sont placés dans une procédure cataloguée, qui est appelée dans le JCL.
Habituellement, à des fins de test ou pour résoudre un incident, il peut être nécessaire d’utiliser des ensembles de données différents de ceux spécifiés dans la procédure cataloguée.
Dans ce cas, le jeu de données de la procédure peut être remplacé dans le JCL.

//JCLINST JOB 1,CLASS=6,MSGCLASS=Y,NOTIFY=&SYSUID
//*
//JSTEP1    EXEC CATLPROC,PROG=CATPRC1,DSNME=MYDATA.URMI.INPUT
//          DATAC=MYDATA.BASE.LIB1(DATA1)
//STEP1.IN1 DD DSN=MYDATA.OVER.INPUT,DISP=SHR
//*
//* La procédure cataloguée est la suivante:
//*
//CATLPROC PROC PROG=,BASELB=MYCOBOL.BASE.LIB1
//*
//STEP1     EXEC PGM=&PROG
//STEPLIB   DD DSN=&BASELB,DISP=SHR
//IN1       DD DSN=MYDATA.URMI.INPUT,DISP=SHR
//OUT1      DD SYSOUT=*
//SYSOUT    DD SYSOUT=*
//SYSIN     DD MYDATA.BASE.LIB1(DATA1),DISP=SHR
//*
//STEP2     EXEC PGM=SORT

Dans l’exemple ci-dessus, le jeu de données IN1 utilise le fichier MYDATA.URMI.INPUT dans le PROC, qui est remplacé dans le JCL.
Par conséquent, le fichier d’entrée utilisé lors de l’exécution est MYDATA.OVER.INPUT.
Veuillez noter que le jeu de données est appelé STEP1.IN1. S’il n’y a qu’une seule étape dans le JCL/PROC, l’ensemble de données peut être référencé uniquement avec le nom DD.
De même, s’il existe plusieurs steps dans le JCL, l’ensemble de données doit être remplacé en tant que JSTEP1.STEP1.IN1.

//EXINST  JOB 1,CLASS=6,MSGCLASS=Y,NOTIFY=&SYSUID
//*
//STEP      EXEC CATLPROC,PROG=CATPRC1,DSNME=MYDATA.URMI.INPUT
//          DATAC=MYDATA.BASE.LIB1(DATA1)
//STEP1.IN1 DD DSN=MYDATA.OVER.INPUT,DISP=SHR
//          DD DUMMY
//          DD DUMMY
//*

Dans l’exemple ci-dessus, sur les trois jeux de données concaténés dans IN1, le premier est remplacé dans le JCL et le reste est conservé tel qu’il est présent dans PROC.