Jak namapovat JCL na COBOL a proč na tom záleží

Každý podnikový mainframe běží na dvou propojených jazycích, které většina moderních vývojářů nikdy nenapsala. COBOL implementuje obchodní logiku, výpočty, zpracování souborů, transformace záznamů a regulační reporting. JCL (Job Control Language) orchestruje provádění této logiky a definuje, které programy se spouštějí, v jakém pořadí, s jakými soubory, za jakých podmínek a co se stane, když uspějí nebo selžou. Ani jeden jazyk není kompletní bez druhého. Program v COBOLu nemá tušení, odkud pocházejí jeho vstupní soubory ani kam směřuje jeho výstup; JCL odpovídá na obě otázky před přečtením prvního záznamu.

Pro organizace, které udržují, auditují nebo modernizují mainframeové systémy, není pochopení vztahu mezi JCL a COBOLem dobrovolnou základní znalostí. Je nezbytným předpokladem pro všechno: analýzu dopadů před jakoukoli změnou, dokumentaci před jakoukoli migrací, přenos znalostí před odchodem jakéhokoli odborníka do důchodu. Úloha, která zpracovává noční fakturaci, dávkové běhy, které generují čtvrtletní regulační zprávy, postupy, které přenášejí data z jednoho systému do druhého, to vše je definováno v JCL, prováděno v COBOLu a chápe ho pouze zmenšující se populace inženýrů, kteří s oběma pracovali.

Co je JCL?

JCL je zkratka pro Job Control Language (jazyk pro řízení úloh). Je to skriptovací jazyk používaný na sálových počítačích IBM k odesílání dávkových úloh ke spuštění. JCL sám o sobě nezpracovává data. Říká operačnímu systému, jak spustit programy: který program spustit, jaké soubory zpřístupnit, jakou paměť a zdroje CPU alokovat, co dělat, když krok selže, a v jakém pořadí spustit více kroků v rámci jedné úlohy.

Každá úloha JCL se skládá ze tří základních typů příkazů:

Příkaz JOB, identifikuje úlohu pro systém a definuje parametry účtování, priority a plánování.

Příkaz EXEC, určuje program nebo proceduru, která se má v kroku spustit.

Příkaz DD (definice dat)definuje datové sady, které bude program číst nebo zapisovat, včetně jejich umístění, formátu a dispozice.

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

V tomto příkladu: PAYBATCH je název práce, STEP010 je jeden krok práce, PGM=PAYROLL1 pojmenovává program v COBOLu, který se má spustit, a příkazy DD definují všechny soubory, ke kterým má program přístup. Program v COBOLu PAYROLL1 neví ani se nestará kde EMPFILE or TRANSACT Pokud pocházejí fyzicky, jednoduše je přečte podle názvu_ddname. JCL před zahájením provádění rozpozná fyzické umístění, formát záznamu a režim přístupu.

Katalogizované postupy JCL (PROC)

Spíše než psát stejný JCL vzor pro každou úlohu, týmy mainframe definují katalogizované procedury (PROC), které zapouzdřují opakovaně použitelné vzory provádění. PROC je šablona uložená v knihovně procedur; jednotlivé úlohy na ni odkazují a podle potřeby přepisují specifické parametry.

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

Volání PROC z úlohy:

JCL

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

Tento jediný příkaz EXEC se v době provádění rozbalí do celého PROC, přičemž MEMBER a RUNDATE nahrazeno kdekoli &MEMBER a &RUNDATE objeví se. PROCy jsou jedním z hlavních důvodů, proč je mapování z JCL do COBOLu složité: úloha může vyvolat desítky programů v COBOLu prostřednictvím jediné reference PROC a skutečně vyvolané programy závisí na symbolických parametrech, které se liší při každém spuštění.

Jaký je rozdíl mezi JCL a COBOLem?

JCL a COBOL se často zmiňují společně, ale plní zcela odlišné role. Ani jeden nenahrazuje ten druhý a oba jsou nezbytné pro fungování dávkového zpracování na mainframech.

Dimenze	Jcl	COBOL
Účel	Orchestruje provedení	Implementuje obchodní logiku
Co definuje	Úlohy, kroky, soubory, podmínky	Programy, datové struktury, výpočty
Když to běží	Před spuštěním programu (instalace) a po něm (vyčištění)	Během provádění programu
Čte/zapisuje data	Prostřednictvím alokace datových sad (příkazy DD)	Prostřednictvím příkazů FILE SECTION a READ/WRITE
Chyba při zpracování	Návratové kódy, podmíněné provedení kroku	Obslužné rutiny VÝJIMEK, chybové rutiny PERFORM
Přenositelnost	Specifické pro IBM z/OS	Přenositelnost napříč platformami pomocí kompilátorů
Kdo to píše	Systémoví programátoři, dávkoví inženýři	Vývojáři aplikací
Moderní ekvivalent	CI/CD kanál + orchestrace kontejnerů	Kód aplikace (Java, Python, C++)

Nejjednodušší způsob, jak si tento vztah představit: JCL je vrstva pro nasazení a orchestraci; COBOL je aplikační vrstva. V moderním cloudově nativním systému by roli JCL plnily manifesty úloh Kubernetes, skripty shellu a fáze kanálu CI/CD. Roli COBOLu by plnily aplikační služby napsané v Javě, Pythonu nebo Go.

Jak JCL volá COBOL: Řetězec provedení

Cesta od úlohy JCL k provedení v COBOLu sleduje konzistentní řetězec. Pochopení každého kroku je základem pro pochopení toho, co musí mapa JCL-COBOL zachycovat.

Krok 1: Odeslání úkolu. Úloha JCL je odeslána do subsystému pro zadávání úloh (JES). JES zařadí úlohu do fronty a začne číst její příkazy.

Krok 2: Nastavení kroků. Pro každý krok EXEC systém vyhledá pojmenovaný program v knihovně načítání určené příkazem STEPLIB DD. Pokud není zadána žádná STEPLIB, systém prohledá systémovou knihovnu linků.

Krok 3: Alokace datové sady. Před spuštěním programu systém alokuje všechny datové sady definované příkazy DD v daném kroku. To zahrnuje otevření souborů, ověření existence vstupních datových sad a vytvoření výstupních datových sad.

Krok 4: Spuštění programu. Program v COBOLu se spustí. Přistupuje k souborům pomocí názvů souborů definovaných v JCL. OPEN INPUT EMPFILE v COBOLu se mapuje přímo na příkaz DD s názvem EMPFILE v JCL.

Krok 5: Vyhodnocení návratového kódu. Když program v COBOLu skončí, nastaví návratový kód (obvykle 0 pro úspěch, 4 pro varování, 8 pro chybu, 12 nebo 16 pro závažnou chybu). JCL používá COND parametry nebo IF/THEN/ELSE konstrukty pro určení, zda by se na základě tohoto kódu měly spustit další kroky.

Krok 6: Umístění datové sady. Po tomto kroku systém zpracuje dispozice datové sady definované v každém příkazu DD: ponechat, odstranit, katalogizovat, odkatalogizovat nebo přejít k dalšímu kroku.

Následující příklad ukazuje, jak tento řetězec vypadá v praxi, JCL vlevo, odpovídající prvky COBOLu vpravo:

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

Program COBOL ACCTREC obsahuje:

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

Jedno SELECT INFILE ASSIGN TO INFILE v sekci FILE-CONTROL v COBOLu se připojuje k příkazu DD s názvem INFILE v JCL. Toto je základní mapovací vztah: COBOL používá logické názvy souborů; JCL je převádí na fyzické datové sady.

Kódy JCL Abend: Co znamenají

Kódy ukončení JCL (abnormální kódy ukončení) identifikují důvod neočekávaného ukončení kroku úlohy. Ve výstupu úlohy se zobrazují jako S000 (ukončení systému) nebo U0000 (uživatelské abend) kódy. Jejich pochopení je nezbytné pro diagnostiku selhání dávkových úloh.

Abend kód	Typ	Častá příčina
S001	Systém	Chyba I/O při čtení nebo zápisu datové sady
S013	Systém	Neshoda atributů DCB, délka záznamu nebo formátu mezi JCL DD a COBOL FD
S0C4	Systém	Výjimka ochrany úložiště, program se pokusil o přístup k paměti mimo alokovanou oblast.
S0C7	Systém	Výjimka dat, pokus o aritmetické operace s nečíselnými daty (velmi časté ukončení COBOLu)
S322	Systém	Časový limit překročen, úloha běžela déle, než povolil parametr TIME.
S806	Systém	Načítací modul nenalezen, program s názvem v EXEC PGM= se nenachází v žádné prohledané načítací knihovně
S913	Systém	Narušení zabezpečení přístupu k datové sadě, RACF nebo ekvivalentní odepření přístupu
U0000	Uživatel	Aplikačně definovaný abend, program v COBOLu s názvem STOP RUN s uživatelským kódem
U4076	Uživatel	IMS-specifické ukončení, selhání přístupu k databázi

Nejčastější výpadek výroby, S0C7, dochází, když se program v COBOLu pokouší o aritmetické operace s polem, které obsahuje mezery nebo nečíselné znaky. Typickou příčinou je nesoulad mezi očekávaným formátem dat v programu v COBOLu a skutečnými daty dodanými programem JCL, což je přesně ten druh nesouladu, který mapování JCL do COBOLu odhalí dříve, než způsobí půlnoční produkční selhání.

Parametr COND a podmíněné spuštění

JCL řídí, které kroky se spustí na základě návratových kódů z předchozích kroků pomocí COND parametr:

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) znamená: tento krok přeskočit, pokud je návratový kód předchozího kroku menší než 4. COND=(4,LT,STEP010) znamená: tento krok přeskočit, pokud je návratový kód STEP010 menší než 4. COND=(0,NE,STEP010) znamená: přeskočit STEP030, pokud návratový kód STEP010 není roven 0, tj. spustit čištění pouze tehdy, pokud STEP010 proběhl úspěšně.

Moderní JCL používá IF/THEN/ELSE/ENDIF konstrukt, který je čitelnější:

JCL

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

Mapování cest podmíněného spuštění je jedním z nejdůležitějších a nejčastěji opomíjených prvků analýzy JCL-COBOL. Program v COBOLu, který se spustí pouze v případě selhání předchozího kroku, může zpracovávat chybové podmínky, logiku vrácení zpět nebo procedury obnovy, což jsou funkce, které jsou zcela neviditelné, pokud se díváte pouze na zdrojový kód COBOLu bez JCL, který jej řídí.

JCL, COBOL a DB2: Třívrstvý stack

Většina transakčních systémů pro mainframy zahrnuje kromě JCL a COBOLu i třetí komponentu: DB2, relační databázi od IBM. Programy v COBOLu přistupují k DB2 prostřednictvím vložených příkazů SQL (bloky EXEC SQL). JCL spravuje připojení subsystému DB2 a DBRM (Database Request Module) prostřednictvím specifických příkazů DD.

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.

V balíčku JCL-COBOL-DB2 poskytuje JCL běhové prostředí a přístup k datovým sadám; COBOL implementuje obchodní logiku a volá databázi; DB2 ukládá a načítá data podle SQL kódu vloženého do programu COBOL. Kompletní mapa závislostí jakéhokoli programu COBOL, který používá DB2, musí zahrnovat nejen to, které úlohy JCL jej volají, ale i které tabulky DB2 čte a zapisuje, ke kterým sloupcům přistupuje a které další programy přistupují ke stejným tabulkám, protože změna schématu tabulky ovlivňuje každý program COBOL, který na ni odkazuje.

Proč je mapování z JCL do COBOLu důležité pro modernizaci

Mapování JCL na COBOL není primárně technický úkol. Je to úkol řízení rizik. Každá změna na mainframeovém systému, ať už se jedná o úpravu parametru JCL, přidání kroku, změnu názvu datové sady nebo úpravu programu COBOL, který úloha vyvolá, s sebou nese důsledky, které přesahují rámec změněné komponenty. Jediný způsob, jak přesně vymezit tyto důsledky před provedením změny, je mít kompletní mapu toho, co existuje a jak vše souvisí.

Před migracíPřesun dávkových úloh z mainframe do cloudu vyžaduje znalost existujících JCL úloh, které COBOL programy volají, které datové sady probíhají mezi kroky, jaká je sekvence provádění a co se stane, když kroky selžou. Bez této mapy pracuje migrační tým s neúplnou dokumentací nebo s žádnou dokumentací. Kroky se přehlížejí. Závislosti se objevují v produkčním prostředí. Termíny přechodu se posouvají.

Před jakoukoli změnou kóduÚprava programu v COBOLu bez kontroly, které úlohy JCL jej volají, může narušit úlohy, které běží za jiných podmínek nebo s jinými konfiguracemi datové sady. Změna parametru JCL, která se jeví jako lokální, může ovlivnit chování programu v COBOLu, který se spoléhá na specifické atributy datové sady. Analýza dopadu vyžaduje znalost celého řetězce JCL-COBOL-datová sada před provedením jakékoli změny.

Pro přenos znalostíKdyž vývojář COBOLu, který dvacet let udržoval dávkový systém, odchází do důchodu, odnáší si s sebou mentální model propojení úloh JCL a programů COBOLu. Dokumentovaná mapa je jediným mechanismem pro přenos těchto znalostí do dalšího týmu. Bez ní noví vývojáři zdědí systém, který nemohou bezpečně upravovat.

Pro audit shody s předpisyRegulační audity často vyžadují prokázání, že finanční výpočty, transformace dat nebo řízení přístupu se chovají tak, jak je zdokumentováno. Pokud není vztah mezi JCL a COBOLem zdokumentován, je prokázání této skutečnosti nemožné bez zpětného inženýrství systému pod tlakem auditu.

Nástroje pro správu a analytické platformy JCL

Vícejazyčná povaha dat ze služby Search Console pro tento článek, s dotazy v italštině, francouzštině, španělštině, japonštině a němčině, které se všechny ptají na nástroje pro správu JCL, odráží, jak globálně je rozptýlena komunita IT mainframeů a jak konzistentně týmy v každém regionu čelí stejnému problému: jejich dokumentace k JCL a COBOLu je neúplná, zastaralá nebo neexistuje.

Nástroje dostupné pro analýzu a správu JCL spadají do tří kategorií:

Nativní nástroje IBMIBM nabízí funkce subsystému pro zadávání úloh, správu spoolů JES a běhové prostředí IBM z/OS Batch Runtime. Tyto funkce se starají o provádění a monitorování, ale neposkytují analýzu závislostí mezi programy ani vizualizaci.

Plánovače úloh třetích stranCA7, TWS (Tivoli Workload Scheduler) a Broadcom's ESP Workload Automation spravují dávkové plánování napříč tisíci úlohami, poskytují plánování založené na závislostech a upozorňují na selhání. Chápou závislosti na úrovni úloh, ale obvykle neanalyzují programy v COBOLu volané v každém kroku.

Platformy pro statickou analýzu kódu a mapování závislostíNástroje, které analyzují zdrojový kód JCL a COBOL a vytvářejí strukturální model, který ukazuje, které úlohy volají které programy, které programy přistupují ke kterým datovým sadám a jak data tečou systémem. Tyto nástroje poskytují přehled napříč vrstvami, který plánovače úloh a nativní nástroje IBM nemohou: vztah mezi konkrétním příkazem JCL DD a položkou COBOL FILE-CONTROL, která se na něj mapuje, nebo mezi programem COBOL, který zapisuje do datové sady, a další úlohou, která tuto datovou sadu čte jako vstup.

SMART TS XL patří do této třetí kategorie a rozšiřuje ji tak, aby zahrnovala všechny jazyky v podnikovém prostředí, COBOL, JCL, PL/I, Assembler, SQL, Javu a další, a poskytuje tak strukturální analýzu napříč jazyky, kterou žádný jednojazyčný nástroj nemůže poskytnout.

Jak SMART TS XL Mapuje JCL na COBOL v podnikovém měřítku

Manuální mapování JCL do COBOLu je pro jednu úlohu zvládnutelné ve třech krocích. Není to zvládnutelné pro organizaci s 50 000 JCL úlohami, 200 000 COBOL programy a miliony odkazů na datové sady nashromážděné za čtyři desetiletí. Vztah mezi konkrétním procesem PROC, symbolickými parametry použitými k jeho vyvolání, COBOL programy, na které se tyto parametry vztahují, a datovými sadami, ke kterým tyto programy přistupují, nelze v tomto měřítku ručně sledovat.

SMART TS XL Analyzuje zdrojový kód JCL a COBOL, včetně PROC se symbolickou substitucí parametrů, procedur in-stream, členů INCLUDE, přepsání a logiky podmíněného provádění, a vytváří jednotný model křížových odkazů, který reprezentuje všechny strukturální vztahy v systému. Tento model je dotazovatelný, navigovatelný a vždy aktuální, protože je regenerován ze zdroje, nikoli udržován jako ručně aktualizovaný dokument.

Jedno Expanze JCL Funkce řeší symbolickou substituci parametrů a zobrazuje skutečné programy a datové sady vyvolané libovolným PROC, s ohledem na přepsání aplikovaná každou volající úlohou. PROC, který používá &PGMNAME jako symbolický parametr se v modelu objevuje jako všechny konkrétní programy, na které se vztahuje napříč všemi svými volajícími, nikoli jako nevyřešená reference.

Jedno mapování závislostí aplikací Funkce Capacity vytváří kompletní graf z úlohy JCL, přes program v COBOLu, tabulku v DB2 a následný program, a zobrazuje každou komponentu v systému a každé spojení mezi nimi. Před jakoukoli modernizační změnou se tým může zeptat: které úlohy tento program vyvolávají? Které datové sady tento program čte? Které další programy do těchto datových sad zapisují? Které úlohy se v pořadí spustí jako další?

Jedno analýza dopadu Tato funkce generuje vyjmenovaný rozsah důsledků pro jakoukoli navrhovanou změnu: upravit tuto sadu dat a zobrazit každý program, který ji obsahuje; změnit rozvržení této datové sady a zobrazit každý příkaz JCL DD, který na ni odkazuje; odebrat tento krok z úlohy a zobrazit každý následný krok, který závisel na jeho výstupu.

Pro týmy, které čelí mapování z JCL do COBOLu jako součást starší modernizace program, SMART TS XL poskytuje základ, který dodavatelé modernizace, Astadia, TSRI, Advanced a další, potřebují před zahájením jakýchkoli konverzních prací: kompletní a přesný strukturální inventář stávajících prvků, aby rozsah konverze byl definován analýzou, nikoli předpoklady.

Mapa není území, ale je výchozím bodem

JCL a COBOL nezmizí. Dávkové systémy, které zpracovávají mzdy, pojistné události, generují regulační zprávy a vypořádávají finanční transakce, budou i nadále běžet na mainframech, zatímco se budou plánovat, schvalovat, financovat a provádět migrace do cloudu, což je proces, který obvykle trvá roky, nikoli měsíce. Během těchto let je nutné systémy udržovat, upravovat a rozumět jim.

Mapování z JCL do COBOLu není jednorázový projekt. Je to kontinuální praxe: udržování strukturálního modelu aktuálního při úpravách programů, přidávání úloh a reorganizaci datových sad. Týmy, které do této praxe investují, si udržují schopnost s jistotou provádět změny v systémech, které většina odvětví považuje za černé skříňky. Týmy, které tak nečiní, provádějí změny v systémech, které nemohou plně vidět. V prostředích, kde přehlédnutá závislost nezpůsobí chybu kompilátoru, způsobí produkční selhání ve 3 hodiny ráno během nočního dávkového běhu.