Chaque système mainframe d'entreprise exécute deux langages étroitement liés que la plupart des développeurs modernes n'ont jamais écrits. Le COBOL implémente la logique métier, les calculs, le traitement des fichiers, les transformations d'enregistrements et les rapports réglementaires. Le JCL (Job Control Language) orchestre l'exécution de cette logique, définissant quels programmes s'exécutent, dans quel ordre, avec quels fichiers, sous quelles conditions et ce qui se passe en cas de succès ou d'échec. Aucun des deux langages ne va sans l'autre. Un programme COBOL ignore la provenance de ses fichiers d'entrée et la destination de ses fichiers de sortie ; le JCL répond à ces deux questions avant même la lecture du premier enregistrement.
Pour les organisations chargées de la maintenance, de l'audit ou de la modernisation des systèmes mainframe, la compréhension de la relation entre JCL et COBOL est essentielle. Elle est indispensable à toute action : analyse d'impact avant toute modification, documentation avant toute migration, transmission des connaissances avant le départ à la retraite d'un expert. Le traitement de la facturation nocturne, l'exécution par lots générant les rapports réglementaires trimestriels, la procédure de transfert de données d'un système à un autre : tous ces processus sont définis par JCL, exécutés par COBOL et maîtrisés uniquement par le nombre, de plus en plus restreint, d'ingénieurs ayant travaillé avec les deux langages.
Qu'est-ce que JCL ?
JCL signifie Job Control Language (langage de contrôle des tâches). Il s'agit du langage de script utilisé sur les systèmes mainframe IBM pour soumettre des tâches par lots à l'exécution. JCL ne traite pas les données directement. Il indique au système d'exploitation comment exécuter les programmes : quel programme lancer, quels fichiers rendre disponibles, quelles ressources mémoire et processeur allouer, que faire en cas d'échec d'une étape et dans quel ordre exécuter les différentes étapes d'une même tâche.
Chaque tâche JCL se compose de trois types d'instructions fondamentales :
L'instruction JOB identifie la tâche dans le système et définit les paramètres de comptabilité, de priorité et de planification.
L'instruction EXEC spécifie le programme ou la procédure à exécuter dans une étape.
L'instruction DD (Data Definition) définit les ensembles de données que le programme lira ou écrira, y compris leur emplacement, leur format et leur disposition.
jcl
//PAYBATCH JOB (ACCT#7), 'PAYROLL RUN',
// CLASS=A, MSGCLASS=X, NOTIFY=&SYSUID
//*
//STEP010 EXEC PGM=PAYROLL1
//STEPLIB DD DSN=PROD.PAYROLL.LOADLIB,DISP=SHR
//EMPFILE DD DSN=PROD.PAYROLL.EMPLOYEE,DISP=SHR
//TRANSACT DD DSN=PROD.PAYROLL.TRANS.D&&DATE,DISP=SHR
//PAYRPT DD SYSOUT=A
//SYSOUT DD SYSOUT=*
//SYSIN DD DUMMYDans cet exemple: PAYBATCH est le nom du poste, STEP010 c'est une étape du travail, PGM=PAYROLL1 Le nom du programme COBOL à exécuter est indiqué, et les instructions DD définissent chaque fichier auquel le programme peut accéder. Le programme COBOL PAYROLL1 ne sait pas ou se fiche d'où EMPFILE or TRANSACT Les fichiers proviennent de leur emplacement physique ; il les lit simplement par leur nom de domaine (ddname). Le JCL détermine l’emplacement physique, le format d’enregistrement et le mode d’accès avant le début de l’exécution.
Procédures cataloguées JCL (PROC)
Au lieu de rédiger le même modèle JCL pour chaque tâche, les équipes mainframe définissent des procédures cataloguées (PROC) qui encapsulent des modèles d'exécution réutilisables. Une PROC est un modèle stocké dans une bibliothèque de procédures ; chaque tâche y fait référence et modifie certains paramètres selon ses besoins.
jcl
//PAYPROC PROC RUNDATE=TODAY
//COMPILE EXEC PGM=IGYCRCTL,PARM='OBJECT,NODUMP'
//SYSIN DD DSN=PROD.COBOL.SRC(&MEMBER),DISP=SHR
//SYSOBJ DD DSN=&&OBJSET,DISP=(NEW,PASS),
// UNIT=SYSDA,SPACE=(TRK,(10,5))
//LKED EXEC PGM=IEWL,PARM='LIST,LET,XREF'
//SYSLIN DD DSN=&&OBJSET,DISP=(OLD,DELETE)
//SYSLMOD DD DSN=PROD.PAYROLL.LOADLIB(&MEMBER),
// DISP=SHR
// PENDAppel de la procédure depuis une tâche :
jcl
//COMPILE EXEC PAYPROC,MEMBER=PAYROLL1,RUNDATE=20251205Cette simple instruction EXEC se transforme en la procédure PROC complète lors de l'exécution, avec MEMBER et RUNDATE substitué partout &MEMBER et &RUNDATE Les PROC sont l'une des principales raisons de la complexité du mappage JCL-COBOL : un travail peut appeler des dizaines de programmes COBOL via une seule référence PROC, et les programmes réellement appelés dépendent de paramètres symboliques qui varient à chaque exécution.
Quelle est la différence entre JCL et COBOL ?
On cite souvent JCL et COBOL ensemble, mais leurs rôles sont totalement différents. Aucun ne remplace l'autre, et tous deux sont indispensables au fonctionnement du traitement par lots sur mainframe.
| Dimension | JCL | COBOL |
|---|---|---|
| Interet | Orchestre l'exécution | Implémente la logique métier |
| Ce que cela définit | Tâches, étapes, fichiers, conditions | Programmes, structures de données, calculs |
| Quand il fonctionne | Avant l'exécution du programme (configuration) et après (nettoyage) | Pendant l'exécution du programme |
| Lecture/écriture de données | Allocation de jeux de données via (instructions DD) | Instructions Via FILE SECTION et READ/WRITE |
| La gestion des erreurs | Codes de retour, exécution d'étapes conditionnelles | Gestionnaires d'exceptions, routines d'exécution d'erreurs |
| Portabilité | Spécifique à IBM z/OS | Portable sur différentes plateformes grâce aux compilateurs |
| Qui l'écrit | Programmeurs système, ingénieurs de traitement par lots | Développeurs d'applications |
| Équivalent moderne | Pipeline CI/CD + orchestration de conteneurs | Code de l'application (Java, Python, C++) |
Pour simplifier, voici comment appréhender cette relation : JCL représente la couche de déploiement et d’orchestration ; COBOL, la couche applicative. Dans un système cloud natif moderne, le rôle de JCL serait assuré par les manifestes de tâches Kubernetes, les scripts shell et les étapes du pipeline CI/CD. Le rôle de COBOL serait quant à lui assuré par les services applicatifs écrits en Java, Python ou Go.
Comment JCL invoque COBOL : la chaîne d’exécution
Le chemin d'exécution d'une tâche JCL vers COBOL suit une chaîne cohérente. Comprendre chaque étape est fondamental pour appréhender ce que doit représenter une correspondance JCL-COBOL.
Étape 1 : Soumission de la tâche. La tâche JCL est soumise au sous-système de saisie des tâches (JES). Le JES met la tâche en file d’attente et commence à lire ses instructions.
Étape 2 : Configuration des étapes. Pour chaque étape EXEC, le système recherche le programme spécifié dans la bibliothèque de chargement définie par l’instruction DD STEPLIB. Si aucune bibliothèque STEPLIB n’est spécifiée, le système effectue une recherche dans la bibliothèque de liens système.
Étape 3 : Allocation des jeux de données. Avant l’exécution du programme, le système alloue tous les jeux de données définis par les instructions DD de l’étape précédente. Cela comprend l’ouverture des fichiers, la vérification de l’existence des jeux de données d’entrée et la création des jeux de données de sortie.
Étape 4 : Exécution du programme. Le programme COBOL s'exécute. Il accède aux fichiers en utilisant les noms de fichiers définis dans le JCL. OPEN INPUT EMPFILE en COBOL correspond directement à l'instruction DD nommée EMPFILE dans JCL.
Étape 5 : Évaluation du code de retour. À la fin du programme COBOL, un code de retour est défini (généralement 0 pour succès, 4 pour avertissement, 8 pour erreur, 12 ou 16 pour erreur grave). JCL utilise COND paramètres ou IF/THEN/ELSE constructions permettant de déterminer si les étapes suivantes doivent être exécutées en fonction de ce code.
Étape 6 : Traitement des données. À l’issue de cette étape, le système traite les traitements des données définis dans chaque instruction DD : conserver, supprimer, cataloguer, décataloguer ou passer à l’étape suivante.
L'exemple suivant illustre l'aspect pratique de cette chaîne : le JCL à gauche, les éléments COBOL correspondants à droite :
jcl
//STEP020 EXEC PGM=ACCTREC
//STEPLIB DD DSN=PROD.ACCOUNT.LOADLIB,DISP=SHR
//INFILE DD DSN=PROD.ACCT.DAILY.INPUT,DISP=SHR ← maps to COBOL SELECT/ASSIGN
//OUTFILE DD DSN=PROD.ACCT.PROCESSED, ← maps to COBOL SELECT/ASSIGN
// DISP=(NEW,CATLG,DELETE),
// UNIT=SYSDA,SPACE=(CYL,(5,2),RLSE)
//RPTFILE DD SYSOUT=A ← maps to COBOL WRITE report
//SYSOUT DD SYSOUT=*Le programme COBOL ACCTREC contient:
Cobol
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT INFILE ASSIGN TO INFILE. *> maps to DD INFILE
SELECT OUTFILE ASSIGN TO OUTFILE. *> maps to DD OUTFILE
SELECT RPTFILE ASSIGN TO RPTFILE. *> maps to DD RPTFILE
DATA DIVISION.
FILE SECTION.
FD INFILE
RECORDING MODE IS F
BLOCK CONTAINS 0 RECORDS
RECORD CONTAINS 200 CHARACTERS.
01 ACCOUNT-RECORD.
05 ACCT-NUMBER PIC X(10).
05 ACCT-BALANCE PIC S9(13)V99 COMP-3.
05 ACCT-STATUS PIC X(2).Le SELECT INFILE ASSIGN TO INFILE La section FILE-CONTROL de COBOL se connecte à l'instruction DD nommée INFILE en JCL. Voici la relation de correspondance fondamentale : COBOL utilise des noms de fichiers logiques ; JCL les résout en ensembles de données physiques.
Codes d'erreur JCL : leur signification
Les codes d'arrêt anormal (abend codes) du JCL indiquent pourquoi une étape de travail s'est terminée de manière inattendue. Ils apparaissent dans la sortie du travail sous la forme : S000 (arrêt anormal du système) ou U0000 (codes d'erreur utilisateur). Leur compréhension est essentielle pour diagnostiquer les échecs des traitements par lots.
| Code d'erreur | Type | Cause commune |
|---|---|---|
| S001 | Système | Erreur d'E/S lors de la lecture ou de l'écriture d'un ensemble de données |
| S013 | Système | Incompatibilité d'attributs DCB, de longueur d'enregistrement ou de format entre JCL DD et COBOL FD |
| S0C4 | Système | Exception de protection du stockage : le programme a tenté d'accéder à une zone mémoire en dehors de sa région allouée. |
| S0C7 | Système | Exception de données : tentative d’opération arithmétique sur des données non numériques (erreur COBOL très courante). |
| S322 | Système | Délai dépassé : la tâche a duré plus longtemps que le paramètre TIME ne le permettait. |
| S806 | Système | Module de chargement introuvable, programme nommé dans EXEC PGM= introuvable dans aucune bibliothèque de chargement recherchée |
| S913 | Système | Violation de la sécurité d'accès aux données, RACF ou équivalent, accès refusé |
| U0000 | L'Utilisateur | Arrêt anormal défini par l'application, programme COBOL appelé STOP RUN avec code utilisateur |
| U4076 | L'Utilisateur | Erreur spécifique à IMS, échec d'accès à la base de données |
Le défaut de production le plus courant, S0C7Cette erreur se produit lorsqu'un programme COBOL tente d'effectuer des opérations arithmétiques sur un champ contenant des espaces ou des caractères non numériques. La cause typique est une incompatibilité entre le format de données attendu par le programme COBOL et les données réelles fournies par le JCL. C'est précisément ce type d'écart que la conversion JCL-COBOL permet de déceler avant qu'il ne provoque une panne critique en pleine production.
Le paramètre COND et l'exécution conditionnelle
JCL contrôle les étapes exécutées en fonction des codes de retour des étapes précédentes. COND paramètre:
jcl
//STEP010 EXEC PGM=VALIDATE,COND=(4,LT)
//STEP020 EXEC PGM=PROCESS, COND=(4,LT,STEP010)
//STEP030 EXEC PGM=CLEANUP, COND=(0,NE,STEP010)COND=(4,LT) signifie : ignorer cette étape si le code de retour d’une étape précédente est inférieur à 4. COND=(4,LT,STEP010) signifie : ignorer cette étape si le code de retour de STEP010 est inférieur à 4. COND=(0,NE,STEP010) signifie : ignorer STEP030 si le code de retour de STEP010 n'est pas égal à 0, c'est-à-dire n'exécuter le nettoyage que si STEP010 a réussi.
Le JCL moderne utilise le IF/THEN/ELSE/ENDIF construisez plutôt, ce qui est plus lisible :
jcl
//IF010 IF (STEP010.RC = 0) THEN
//STEP020 EXEC PGM=PROCESS
// ENDIF
//IF020 IF (STEP010.RC > 4) THEN
//STEP030 EXEC PGM=ERRORHANDLER
// ENDIFL'identification des chemins d'exécution conditionnels est l'un des aspects les plus critiques et pourtant les plus souvent négligés de l'analyse JCL vers COBOL. Un programme COBOL qui ne s'exécute qu'en cas d'échec d'une étape précédente peut gérer des erreurs, une logique de restauration ou des procédures de récupération ; autant de fonctionnalités totalement invisibles si l'on se contente d'examiner le code source COBOL sans le JCL qui le pilote.
JCL, COBOL et DB2 : l’architecture à trois couches
La plupart des systèmes transactionnels mainframe utilisent un troisième composant en plus du JCL et du COBOL : DB2, la base de données relationnelle d’IBM. Les programmes COBOL accèdent à DB2 via des instructions SQL intégrées (blocs EXEC SQL). Le JCL gère la connexion au sous-système DB2 et le DBRM (module de requête de base de données) grâce à des instructions DD spécifiques.
jcl
//DBRM DD DSN=PROD.DBRMLIB.DATA(ACCTREC),DISP=SHR
//SYSPRINT DD SYSOUT=*Cobol
WORKING-STORAGE SECTION.
EXEC SQL
INCLUDE SQLCA
END-EXEC.
PROCEDURE DIVISION.
MAIN-LOGIC.
EXEC SQL
SELECT ACCT_BALANCE, ACCT_STATUS
INTO :WS-BALANCE, :WS-STATUS
FROM ACCOUNT_MASTER
WHERE ACCT_NUMBER = :WS-ACCT-NUM
END-EXEC.
IF SQLCODE NOT = 0
PERFORM DB2-ERROR-ROUTINE
END-IF.Dans l'architecture JCL-COBOL-DB2, JCL fournit l'environnement d'exécution et l'accès aux données ; COBOL implémente la logique métier et interroge la base de données ; DB2 stocke et récupère les données conformément aux instructions SQL intégrées au programme COBOL. Une cartographie complète des dépendances de tout programme COBOL utilisant DB2 doit inclure non seulement les tâches JCL qui l'appellent, mais aussi les tables DB2 qu'il lit et écrit, les colonnes auxquelles il accède et les autres programmes qui accèdent aux mêmes tables, car toute modification du schéma d'une table affecte tous les programmes COBOL qui la référencent.
Pourquoi la conversion JCL vers COBOL est importante pour la modernisation
La conversion du JCL en COBOL n'est pas avant tout un exercice technique, mais avant tout une question de gestion des risques. Toute modification apportée à un système mainframe, qu'il s'agisse de modifier un paramètre JCL, d'ajouter une étape, de changer le nom d'un fichier ou de modifier le programme COBOL exécuté par un travail, a des conséquences qui dépassent le cadre du composant modifié. La seule façon d'appréhender précisément ces conséquences avant d'effectuer une modification est de disposer d'une cartographie complète de l'existant et de ses interconnexions.
Avant la migration : migrer des charges de travail par lots du mainframe vers le cloud nécessite de connaître les tâches JCL existantes, les programmes COBOL qu’elles appellent, les flux de données entre les étapes, la séquence d’exécution et les conséquences d’une erreur. Sans cette cartographie, l’équipe de migration travaille avec une documentation incomplète, voire inexistante. Des étapes sont oubliées, des dépendances sont découvertes en production et les dates de basculement sont repoussées.
Avant toute modification de code : un programme COBOL modifié sans vérifier quels travaux JCL l’appellent peut perturber le fonctionnement de travaux exécutés dans des conditions différentes ou avec des configurations de jeu de données différentes. Une modification de paramètre JCL, même apparemment locale, peut affecter le comportement d’un programme COBOL qui dépend d’attributs spécifiques du jeu de données. L’analyse d’impact exige de connaître l’intégralité de la chaîne JCL-COBOL-jeu de données avant toute modification.
Pour la transmission des connaissances : lorsqu’un développeur COBOL ayant maintenu un système de traitement par lots pendant vingt ans prend sa retraite, il emporte avec lui le modèle mental des liens entre les tâches JCL et les programmes COBOL. Une documentation structurée est le seul moyen de transmettre ce savoir à l’équipe suivante. Sans elle, les nouveaux développeurs héritent d’un système qu’ils ne peuvent pas modifier en toute sécurité.
Pour les audits de conformité : les audits réglementaires exigent souvent de démontrer que les calculs financiers, les transformations de données ou les contrôles d’accès fonctionnent conformément à la documentation. Si la correspondance entre JCL et COBOL n’est pas documentée, il est impossible de le démontrer sans procéder à une rétro-ingénierie du système sous la pression de l’audit.
Plateformes d'outils de gestion et d'analyse JCL
La nature multilingue des données de la Search Console pour cet article, avec des requêtes en italien, français, espagnol, japonais et allemand portant toutes sur les outils de gestion JCL, reflète la dispersion mondiale de la communauté informatique mainframe et la manière dont les équipes de chaque région sont confrontées au même problème : leur documentation JCL et COBOL est incomplète, obsolète ou inexistante.
Les outils disponibles pour l'analyse et la gestion du JCL se répartissent en trois catégories :
Outils natifs IBM : IBM propose le sous-système d’entrée de tâches (JES), la gestion des spools JES et l’environnement d’exécution par lots IBM z/OS. Ces outils gèrent l’exécution et la surveillance, mais ne permettent pas l’analyse ni la visualisation des dépendances entre programmes.
Les planificateurs de tâches tiers , tels que CA7, TWS (Tivoli Workload Scheduler) et ESP Workload Automation de Broadcom, gèrent l'ordonnancement par lots de milliers de tâches, offrent une planification basée sur les dépendances et signalent les défaillances. Ils comprennent les dépendances au niveau des tâches, mais n'analysent généralement pas les programmes COBOL exécutés à chaque étape.
Plateformes d'analyse statique de code et de cartographie des dépendances : outils qui analysent le code source JCL et COBOL afin de construire un modèle structurel des tâches qui appellent quels programmes, des programmes qui accèdent à quels jeux de données et du flux de données au sein du système. Ces plateformes offrent une visibilité intercouches que les planificateurs de tâches et les outils natifs IBM ne peuvent pas fournir : la relation entre une instruction DD JCL spécifique et l'entrée FILE-CONTROL COBOL correspondante, ou entre un programme COBOL qui écrit dans un jeu de données et la tâche suivante qui lit ce jeu de données en entrée.
SMART TS XL appartient à cette troisième catégorie et l'étend pour couvrir tous les langages de l'environnement d'entreprise, COBOL, JCL, PL/I, Assembleur, SQL, Java et autres, fournissant l'analyse structurelle interlangage qu'aucun outil monolangage ne peut fournir.
Comment SMART TS XL Correspondance entre JCL et COBOL à l'échelle de l'entreprise
La conversion manuelle JCL-COBOL est envisageable pour une tâche unique en trois étapes. Elle devient irréalisable pour une organisation gérant 50 000 tâches JCL, 200 000 programmes COBOL et des millions de références à des jeux de données accumulés sur quatre décennies. À cette échelle, il est impossible de retracer manuellement la relation entre une procédure (PROC) spécifique, les paramètres symboliques utilisés pour l'appeler, les programmes COBOL auxquels ces paramètres correspondent et les jeux de données auxquels ces programmes accèdent.
SMART TS XL Ce système analyse le code source JCL et COBOL, y compris les procédures avec substitution de paramètres symboliques, les procédures intégrées, les membres INCLUDE, les surcharges et la logique d'exécution conditionnelle, et construit un modèle de références croisées unifié représentant toutes les relations structurelles du système. Ce modèle est interrogeable, navigable et toujours à jour car il est régénéré à partir du code source plutôt que maintenu manuellement.
Le Extension JCL Cette fonctionnalité résout la substitution de paramètres symboliques pour afficher les programmes et les jeux de données réellement invoqués par chaque procédure, en tenant compte des substitutions appliquées par chaque tâche appelante. Une procédure qui utilise &PGMNAME en tant que paramètre symbolique, il apparaît dans le modèle comme l'ensemble des programmes concrets auxquels il se résout chez tous ses appelants, et non comme une référence non résolue.
La fonctionnalité de cartographie des dépendances applicatives construit le graphe complet, depuis la tâche JCL jusqu'au programme COBOL, en passant par la table DB2 et les programmes en aval, affichant ainsi chaque composant du système et toutes les connexions entre eux. Avant toute modernisation, l'équipe peut interroger le système pour savoir : quelles tâches appellent ce programme ? Quels jeux de données ce programme lit-il ? Quels autres programmes écrivent dans ces jeux de données ? Quelles tâches s'exécutent ensuite dans la séquence ?
La fonction d'analyse d'impact génère une liste exhaustive des conséquences de toute modification proposée : modifier ce copybook et visualiser chaque programme qui l'inclut ; modifier la disposition de cet ensemble de données et visualiser chaque instruction DD JCL qui y fait référence ; supprimer cette étape d'un travail et visualiser chaque étape en aval qui dépendait de sa sortie.
Pour les équipes confrontées à la conversion JCL-COBOL dans le cadre d'un modernisation de l'héritage programme, SMART TS XL fournit les bases dont les fournisseurs de modernisation, Astadia, TSRI, Advanced et autres, ont besoin avant tout travail de conversion : un inventaire structurel complet et précis de ce qui existe, afin que la portée de la conversion soit définie par l’analyse plutôt que par des suppositions.
La carte n'est pas le territoire, mais le point de départ
JCL et COBOL ne disparaîtront pas. Les systèmes de traitement par lots qui gèrent la paie, les demandes d'indemnisation, les rapports réglementaires et les transactions financières continueront de fonctionner sur les mainframes pendant la planification, l'approbation, le financement et l'exécution des migrations vers le cloud, un processus qui prend généralement des années plutôt que des mois. Durant cette période, il est indispensable de maintenir, de modifier et de maîtriser ces systèmes.
La conversion JCL vers COBOL n'est pas un projet ponctuel. C'est une pratique continue : il faut maintenir le modèle structurel à jour au fur et à mesure des modifications apportées aux programmes, de l'ajout de tâches et de la réorganisation des ensembles de données. Les équipes qui investissent dans cette pratique conservent la capacité d'apporter des modifications fiables à des systèmes que la plupart des acteurs du secteur considèrent comme des boîtes noires. Celles qui ne le font pas modifient des systèmes dont elles ne ont pas une visibilité complète, dans des environnements où une dépendance manquante ne provoque pas d'erreur de compilation, mais une panne de production à 3 h du matin lors de l'exécution nocturne des traitements par lots.
