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.

S’il existe plusieurs ensembles de données du même format, ils peuvent être concaténés et transmis en tant qu’entrée au programme sous un seul nom DD.
Voici un exemple de JCL :

//CONCATEX JOB CLASS=6,NOTIFY=&SYSUID
//*
//STEP10    EXEC PGM=SORT
//SORTIN    DD DSN=FICHIER.INPUT1,DISP=SHR
//          DD DSN=FICHIER.INPUT2,DISP=SHR
//          DD DSN=FICHIER.INPUT3,DISP=SHR
//SORTOUT   DD DSN=FICHIER.OUTPUT,DISP=(,CATLG,DELETE),
//          LRECL=50,RECFM=FB

Dans l’exemple ci-dessus, trois jeux de données sont concaténés et transmis en entrée au programme SORT dans le nom SORTIN DD.
Les fichiers sont fusionnés, triés sur les champs clés spécifiés, puis écrits dans un seul fichier de sortie FICHIER.OUTPUT dans le nom SORTOUT DD.