Come mappare JCL in COBOL e perché è importante

Ogni mainframe aziendale esegue due linguaggi interconnessi che la maggior parte degli sviluppatori moderni non ha mai scritto. COBOL implementa la logica di business, i calcoli, l'elaborazione dei file, le trasformazioni dei record e la reportistica normativa. JCL (Job Control Language) orchestra l'esecuzione di tale logica, definendo quali programmi vengono eseguiti, in quale ordine, con quali file, in quali condizioni e cosa accade in caso di successo o fallimento. Nessuno dei due linguaggi è completo senza l'altro. Un programma COBOL non ha idea da dove provengano i suoi file di input o dove vada a finire il suo output; JCL risponde a entrambe le domande prima ancora che venga letto il primo record.

Per le organizzazioni che si occupano di manutenzione, audit o modernizzazione di sistemi mainframe, la comprensione della relazione tra JCL e COBOL non è una conoscenza di base facoltativa. È il prerequisito per tutto: analisi d'impatto prima di qualsiasi modifica, documentazione prima di qualsiasi migrazione, trasferimento di conoscenze prima che un esperto vada in pensione. Il job che elabora la fatturazione notturna, l'esecuzione batch che genera i report normativi trimestrali, la procedura che trasferisce i dati da un sistema all'altro: tutto ciò è definito da JCL, eseguito da COBOL e compreso solo dalla ristretta cerchia di ingegneri che hanno lavorato con entrambi i linguaggi.

Che cos'è JCL?

JCL è l'acronimo di Job Control Language. Si tratta del linguaggio di scripting utilizzato sui sistemi mainframe IBM per inviare job batch da eseguire. JCL non elabora direttamente i dati, ma indica al sistema operativo come eseguire i programmi: quale programma eseguire, quali file rendere disponibili, quali risorse di memoria e CPU allocare, cosa fare in caso di errore in una fase e in quale sequenza eseguire le diverse fasi all'interno di un singolo job.

Ogni job JCL è costituito da tre tipi fondamentali di istruzioni:

La dichiarazione JOB identifica il lavoro nel sistema e definisce i parametri di contabilità, priorità e pianificazione.

L'istruzione EXEC specifica il programma o la procedura da eseguire in una fase.

L'istruzione DD (Data Definition) definisce i set di dati che il programma leggerà o scriverà, inclusi la loro posizione, il formato e la loro destinazione.

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   DUMMY

In questo esempio: PAYBATCH è il nome del lavoro, STEP010 è una fase del lavoro, PGM=PAYROLL1 Il programma COBOL specifica il nome del programma COBOL da eseguire e le istruzioni DD definiscono ogni file a cui il programma può accedere. Il programma COBOL PAYROLL1 non sa o non gli importa dove EMPFILE or TRANSACT Provengono da una posizione fisica, li legge semplicemente tramite ddname. Il JCL risolve la posizione fisica, il formato del record e la modalità di accesso prima dell'inizio dell'esecuzione.

Procedure catalogate JCL (PROC)

Anziché scrivere lo stesso schema JCL per ogni job, i team mainframe definiscono procedure catalogate (PROC) che incapsulano modelli di esecuzione riutilizzabili. Una PROC è un modello memorizzato in una libreria di procedure; i singoli job vi fanno riferimento e sovrascrivono parametri specifici secondo necessità.

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
//         PEND

Chiamare la procedura PROC da un job:

JCL

//COMPILE  EXEC PAYPROC,MEMBER=PAYROLL1,RUNDATE=20251205

Questa singola istruzione EXEC si espande nell'intera PROC al momento dell'esecuzione, con MEMBER and RUNDATE sostituito ovunque &MEMBER and &RUNDATE appaiono. Le PROC sono uno dei motivi principali per cui la mappatura da JCL a COBOL è complessa: un job può richiamare decine di programmi COBOL tramite un singolo riferimento PROC, e i programmi effettivamente richiamati dipendono da parametri simbolici che variano a ogni esecuzione.

Qual è la differenza tra JCL e COBOL?

JCL e COBOL vengono spesso menzionati insieme, ma svolgono ruoli completamente diversi. Nessuno dei due sostituisce l'altro, ed entrambi sono necessari per il corretto funzionamento dell'elaborazione batch nei mainframe.

Dimensioni	JCL	COBOL
Missione	Orchestra l'esecuzione	Implementa la logica aziendale
Cosa definisce	Lavori, passaggi, file, condizioni	Programmi, strutture dati, calcoli
Quando funziona	Prima dell'esecuzione del programma (setup) e dopo (cleanup)	Durante l'esecuzione del programma
Legge/scrive dati	Tramite l'allocazione del dataset (dichiarazioni DD)	Tramite le istruzioni FILE SECTION e READ/WRITE
Gestione degli errori	Codici di ritorno, esecuzione condizionale dei passaggi	gestori di eccezioni, eseguire routine di errore
Portabilità	Specifico per IBM z/OS	Portatile su diverse piattaforme con compilatori
Chi lo scrive	Programmatori di sistemi, ingegneri di batch	Sviluppatori di applicazioni
Equivalente moderno	Pipeline CI/CD + orchestrazione dei container	Codice applicativo (Java, Python, C++)

Il modo più semplice per concettualizzare la relazione è il seguente: JCL rappresenta il livello di distribuzione e orchestrazione; COBOL rappresenta il livello applicativo. In un moderno sistema cloud-native, il ruolo di JCL verrebbe ricoperto dai manifest dei job di Kubernetes, dagli script di shell e dalle fasi della pipeline CI/CD. Il ruolo di COBOL verrebbe ricoperto dai servizi applicativi scritti in Java, Python o Go.

Come JCL richiama COBOL: la catena di esecuzione

Il percorso da un job JCL all'esecuzione in COBOL segue una sequenza coerente. Comprendere ogni passaggio è fondamentale per capire cosa deve rappresentare una mappatura da JCL a COBOL.

Fase 1: Invio del job. Il job JCL viene inviato al sottosistema di inserimento job (JES). Il JES mette in coda il job e inizia a leggerne le istruzioni.

Passaggio 2: Impostazione del passaggio. Per ogni passaggio EXEC, il sistema individua il programma specificato nella libreria di caricamento indicata dall'istruzione DD STEPLIB. Se non viene specificata alcuna STEPLIB, il sistema esegue la ricerca nella libreria di collegamento di sistema.

Fase 3: Allocazione dei dataset. Prima dell'esecuzione del programma, il sistema alloca tutti i dataset definiti dalle istruzioni DD in questa fase. Ciò include l'apertura dei file, la verifica dell'esistenza dei dataset di input e la creazione dei dataset di output.

Fase 4: Esecuzione del programma. Il programma COBOL viene eseguito. Accede ai file utilizzando i ddname definiti nel JCL, OPEN INPUT EMPFILE in COBOL corrisponde direttamente all'istruzione DD denominata EMPFILE in JCL.

Passaggio 5: Restituire la valutazione del codice. Quando il programma COBOL termina, imposta un codice di ritorno (in genere 0 per successo, 4 per avviso, 8 per errore, 12 o 16 per errore grave). JCL utilizza COND parametri o IF/THEN/ELSE costrutti per determinare se i passaggi successivi debbano essere eseguiti in base a questo codice.

Passaggio 6: Disposizione del dataset. Dopo questo passaggio, il sistema elabora le disposizioni del dataset definite in ogni istruzione DD: conservare, eliminare, catalogare, rimuovere dal catalogo o passare al passaggio successivo.

L'esempio seguente mostra come appare questa catena nella pratica: JCL a sinistra, i corrispondenti elementi COBOL a destra.

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=*

Il programma COBOL ACCTREC contiene:

cobolo

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

Migliori SELECT INFILE ASSIGN TO INFILE nella sezione FILE-CONTROL di COBOL si collega all'istruzione DD denominata INFILE in JCL. Questa è la relazione di mappatura fondamentale: COBOL utilizza nomi di file logici; JCL li risolve in dataset fisici.

Codici di errore JCL: cosa significano

I codici di terminazione anomala JCL (abend codes) identificano il motivo per cui una fase del job è terminata in modo imprevisto. Appaiono nell'output del job come S000 (interruzione di sistema) o U0000 (codici di errore utente). Capirli è essenziale per diagnosticare gli errori dei processi batch.

Codice di errore	Tipo	Causa comune
S001	Sistema	Errore di I/O durante la lettura o la scrittura di un dataset
S013	Sistema	Mancata corrispondenza degli attributi DCB, della lunghezza del record o del formato tra JCL DD e COBOL FD
S0C4	Sistema	Eccezione di protezione della memoria: il programma ha tentato di accedere a una porzione di memoria al di fuori della regione allocata.
S0C7	Sistema	Eccezione sui dati, tentativo di operazione aritmetica su dati non numerici (un errore molto comune in COBOL).
S322	Sistema	Tempo limite superato, l'operazione è stata eseguita per un tempo superiore a quello consentito dal parametro TIME.
S806	Sistema	Modulo di caricamento non trovato, il programma denominato in EXEC PGM= non è presente in nessuna libreria di caricamento cercata
S913	Sistema	Violazione della sicurezza di accesso al dataset, accesso negato RACF o equivalente
U0000	Utente	Arresto anomalo definito dall'applicazione, programma COBOL chiamato STOP RUN con un codice utente
U4076	Utente	Errore specifico di IMS, errore di accesso al database

L'anomalia di produzione più comune, S0C7Si verifica quando un programma COBOL tenta di eseguire operazioni aritmetiche su un campo che contiene spazi o caratteri non numerici. La causa tipica è una discrepanza tra il formato dati previsto nel programma COBOL e i dati effettivi forniti da JCL, che è esattamente il tipo di discrepanza che la mappatura da JCL a COBOL rivela prima che provochi un errore di produzione a mezzanotte.

Il parametro COND e l'esecuzione condizionale

JCL controlla quali passaggi vengono eseguiti in base ai codici di ritorno dei passaggi precedenti utilizzando il COND parametro:

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) significa: salta questo passaggio se il codice di ritorno di un passaggio precedente è inferiore a 4. COND=(4,LT,STEP010) significa: salta questo passaggio se il codice di ritorno di STEP010 è inferiore a 4. COND=(0,NE,STEP010) significa: salta STEP030 se il codice di ritorno di STEP010 non è uguale a 0, ovvero esegui la pulizia solo se STEP010 ha avuto successo.

Il JCL moderno utilizza il IF/THEN/ELSE/ENDIF invece di costruire, che è più leggibile:

JCL

//IF010    IF (STEP010.RC = 0) THEN
//STEP020  EXEC PGM=PROCESS
//         ENDIF
//IF020    IF (STEP010.RC > 4) THEN
//STEP030  EXEC PGM=ERRORHANDLER
//         ENDIF

La mappatura dei percorsi di esecuzione condizionale è uno degli elementi più critici e spesso trascurati nell'analisi da JCL a COBOL. Un programma COBOL che viene eseguito solo quando un passaggio precedente fallisce potrebbe gestire condizioni di errore, logica di rollback o procedure di ripristino, funzionalità completamente invisibili se si esamina solo il codice sorgente COBOL senza il JCL che lo gestisce.

JCL, COBOL e DB2: la struttura a tre livelli

La maggior parte dei sistemi transazionali mainframe prevede, oltre a JCL e COBOL, un terzo componente: DB2, il database relazionale di IBM. I programmi COBOL accedono a DB2 tramite istruzioni SQL incorporate (blocchi EXEC SQL). JCL gestisce la connessione al sottosistema DB2 e al DBRM (Database Request Module) tramite specifiche istruzioni DD.

JCL

//DBRM     DD   DSN=PROD.DBRMLIB.DATA(ACCTREC),DISP=SHR
//SYSPRINT DD   SYSOUT=*

cobolo

       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.

Nella architettura JCL-COBOL-DB2, JCL fornisce l'ambiente di runtime e l'accesso al dataset; COBOL implementa la logica di business e richiama il database; DB2 memorizza e recupera i dati in base alle istruzioni SQL incorporate nel programma COBOL. Una mappa completa delle dipendenze di qualsiasi programma COBOL che utilizza DB2 deve includere non solo i job JCL che lo invocano, ma anche le tabelle DB2 che legge e scrive, le colonne a cui accede e quali altri programmi accedono alle stesse tabelle, poiché una modifica dello schema di una tabella influisce su ogni programma COBOL che vi fa riferimento.

Perché la mappatura da JCL a COBOL è importante per la modernizzazione

La mappatura da JCL a COBOL non è principalmente un esercizio tecnico, bensì un esercizio di gestione del rischio. Ogni modifica a un sistema mainframe, che si tratti di modificare un parametro JCL, aggiungere uno step, cambiare il nome di un dataset o modificare il programma COBOL richiamato da un job, comporta conseguenze che vanno oltre il componente modificato. L'unico modo per valutare con precisione tali conseguenze prima di apportare una modifica è disporre di una mappa completa di ciò che esiste e di come ogni elemento è interconnesso.

Prima della migrazione : spostare i carichi di lavoro batch dal mainframe al cloud richiede la conoscenza dei job JCL esistenti, dei programmi COBOL che richiamano, dei dataset che fluiscono tra le fasi, della sequenza di esecuzione e di cosa accade in caso di errore in una fase. Senza questa mappa, il team di migrazione lavora con una documentazione incompleta o addirittura assente. Alcuni passaggi vengono saltati. Le dipendenze vengono scoperte in produzione. Le date di transizione slittano.

Prima di qualsiasi modifica al codice : un programma COBOL modificato senza verificare quali job JCL lo richiamano può compromettere il funzionamento di job eseguiti in condizioni diverse o con configurazioni di dataset differenti. Una modifica a un parametro JCL che sembra locale può influenzare il comportamento di un programma COBOL che si basa su attributi specifici del dataset. L'analisi d'impatto richiede la conoscenza dell'intera catena JCL-COBOL-dataset prima di apportare qualsiasi modifica.

Per il trasferimento di conoscenze : quando uno sviluppatore COBOL che ha gestito un sistema batch per vent'anni va in pensione, porta con sé il modello mentale di come i job JCL e i programmi COBOL si connettono. Una mappa documentata è l'unico meccanismo per trasferire tale conoscenza al team successivo. Senza di essa, i nuovi sviluppatori ereditano un sistema che non possono modificare in sicurezza.

Per le verifiche di conformità : le verifiche normative spesso richiedono di dimostrare che i calcoli finanziari, le trasformazioni dei dati o i controlli di accesso si comportino come documentato. Se la relazione tra JCL e COBOL non è documentata, dimostrarlo è impossibile senza effettuare un'ingegneria inversa del sistema sotto pressione da parte dell'organismo di verifica.

Strumenti di gestione e piattaforme di analisi JCL

La natura multilingue dei dati di Search Console per questo articolo, con query in italiano, francese, spagnolo, giapponese e tedesco tutte riguardanti strumenti di gestione JCL, riflette quanto sia distribuita a livello globale la comunità IT mainframe e quanto costantemente i team in ogni regione si trovino ad affrontare lo stesso problema: la loro documentazione JCL e COBOL è incompleta, obsoleta o inesistente.

Gli strumenti disponibili per l'analisi e la gestione dei JCL si suddividono in tre categorie:

Strumenti nativi IBM : IBM offre le funzionalità del Job Entry Subsystem (JES), la gestione dello spool JES e l'IBM z/OS Batch Runtime. Questi gestiscono l'esecuzione e il monitoraggio, ma non forniscono analisi o visualizzazione delle dipendenze tra programmi.

I sistemi di pianificazione di terze parti , come CA7, TWS (Tivoli Workload Scheduler) e ESP Workload Automation di Broadcom, gestiscono la pianificazione batch su migliaia di processi, offrono una pianificazione basata sulle dipendenze e segnalano gli errori. Sono in grado di comprendere le dipendenze a livello di processo, ma in genere non analizzano i programmi COBOL richiamati in ogni fase.

Piattaforme di analisi statica del codice e mappatura delle dipendenze : strumenti che analizzano il codice sorgente JCL e COBOL per costruire un modello strutturale che mostri quali job richiamano quali programmi, quali programmi accedono a quali dataset e come i dati fluiscono attraverso il sistema. Questi strumenti offrono una visibilità trasversale che gli scheduler di job e gli strumenti nativi IBM non possono fornire: la relazione tra una specifica istruzione JCL DD e la voce COBOL FILE-CONTROL corrispondente, oppure tra un programma COBOL che scrive su un dataset e il job successivo che legge tale dataset come input.

SMART TS XL appartiene a questa terza categoria e la estende fino a coprire ogni linguaggio nell'ambiente aziendale, COBOL, JCL, PL/I, Assembler, SQL, Java e altri, fornendo l'analisi strutturale multi-linguaggio che nessuno strumento mono-linguaggio è in grado di offrire.

Come SMART TS XL Mappatura da JCL a COBOL su scala aziendale

La mappatura manuale da JCL a COBOL è gestibile per un singolo job in tre fasi. Non lo è invece per un'organizzazione con 50,000 job JCL, 200,000 programmi COBOL e milioni di riferimenti a dataset accumulati in quattro decenni. La relazione tra una specifica PROC, i parametri simbolici utilizzati per invocarla, i programmi COBOL a cui tali parametri si risolvono e i dataset a cui tali programmi accedono non può essere tracciata manualmente su tale scala.

SMART TS XL Analizza il codice sorgente JCL e COBOL, inclusi PROC con sostituzione simbolica dei parametri, procedure in-stream, membri INCLUDE, override e logica di esecuzione condizionale, e crea un modello unificato di riferimenti incrociati che rappresenta ogni relazione strutturale nel sistema. Tale modello è interrogabile, navigabile e sempre aggiornato perché viene rigenerato dal codice sorgente anziché essere mantenuto come un documento aggiornato manualmente.

Migliori Espansione JCL La capacità risolve la sostituzione simbolica dei parametri per mostrare i programmi e i dataset effettivi richiamati da qualsiasi PROC, tenendo conto delle sovrascritture applicate da ogni job chiamante. Una PROC che utilizza &PGMNAME come parametro simbolico appare nel modello come tutti i programmi concreti a cui si risolve attraverso tutti i suoi chiamanti, non come un riferimento non risolto.

La funzionalità di mappatura delle dipendenze dell'applicazione crea un grafo completo, dal job JCL al programma COBOL, passando per la tabella DB2 e arrivando al programma a valle, mostrando ogni componente del sistema e ogni connessione tra di essi. Prima di qualsiasi modifica di modernizzazione, il team può interrogarsi su: quali job richiamano questo programma? Quali dataset legge questo programma? Quali altri programmi scrivono su questi dataset? Quali job vengono eseguiti successivamente nella sequenza?

La funzionalità di analisi dell'impatto genera un elenco dettagliato delle conseguenze per ogni modifica proposta: modifica questo copybook e visualizza ogni programma che lo include; modifica il layout di questo dataset e visualizza ogni istruzione JCL DD che vi fa riferimento; rimuovi questo passaggio da un job e visualizza ogni passaggio successivo che dipendeva dal suo output.

Per i team che devono affrontare la mappatura da JCL a COBOL come parte di un modernizzazione dell'eredità programma, SMART TS XL Fornisce le basi necessarie ai fornitori di soluzioni di modernizzazione, come Astadia, TSRI, Advanced e altri, prima di iniziare qualsiasi lavoro di conversione: un inventario strutturale completo e accurato di ciò che esiste, in modo che l'ambito della conversione sia definito tramite analisi anziché per supposizione.

La mappa non è il territorio, ma è il punto di partenza.

JCL e COBOL non scompariranno. I sistemi batch che elaborano le buste paga, gestiscono le richieste di risarcimento assicurativo, generano report normativi e regolano le transazioni finanziarie continueranno a funzionare sui mainframe mentre le migrazioni al cloud vengono pianificate, approvate, finanziate ed eseguite, un processo che in genere richiede anni anziché mesi. Durante questi anni, i sistemi devono essere mantenuti, modificati e compresi.

La mappatura da JCL a COBOL non è un progetto una tantum. È una pratica continua: mantenere aggiornato il modello strutturale man mano che i programmi vengono modificati, vengono aggiunti job e i dataset vengono riorganizzati. I team che investono in questa pratica mantengono la capacità di apportare modifiche con sicurezza a sistemi che la maggior parte del settore considera come scatole nere. I team che non lo fanno, invece, apportano modifiche a sistemi che non possono comprendere appieno, in ambienti in cui una dipendenza mancante non produce un errore di compilazione, ma un errore di produzione alle 3 del mattino durante l'esecuzione batch notturna.