Enhver mainframe i en virksomhed kører to sammenflettede sprog, som de fleste moderne udviklere aldrig har skrevet. COBOL implementerer forretningslogik, beregninger, filbehandling, posttransformationer og regulatorisk rapportering. JCL (Job Control Language) orkestrerer udførelsen af denne logik og definerer, hvilke programmer der kører, i hvilken rækkefølge, med hvilke filer, under hvilke betingelser, og hvad der sker, når de lykkes eller fejler. Ingen af sprogene er komplette uden det andet. Et COBOL-program aner ikke, hvor dets inputfiler kommer fra, eller hvor dets output går hen; JCL besvarer begge spørgsmål, før den første post læses.
For organisationer, der vedligeholder, reviderer eller moderniserer mainframe-systemer, er forståelse af JCL-til-COBOL-forholdet ikke valgfri baggrundsviden. Det er forudsætningen for alt: konsekvensanalyse før enhver ændring, dokumentation før enhver migrering, videnoverførsel før enhver ekspert går på pension. Jobbet, der behandler natlig fakturering, batchkørslen, der genererer kvartalsvise regulatoriske rapporter, proceduren, der fører data fra et system til et andet - alt dette er defineret af JCL, udført af COBOL og forstået kun af den krympende gruppe af ingeniører, der har arbejdet med begge dele.
Hvad er JCL?
JCL står for Job Control Language. Det er det scriptsprog, der bruges på IBM-mainframesystemer til at sende batchjob til udførelse. JCL behandler ikke selv data. Det fortæller operativsystemet, hvordan programmer skal udføres: hvilket program der skal køres, hvilke filer der skal gøres tilgængelige, hvilke hukommelses- og CPU-ressourcer der skal allokeres, hvad der skal gøres, hvis et trin fejler, og i hvilken rækkefølge flere trin skal køres i et enkelt job.
Hvert JCL-job består af tre grundlæggende sætningstyper:
JOB-sætningen identificerer jobbet for systemet og definerer parametre for regnskab, prioritet og planlægning.
EXEC-sætning , angiver det program eller den procedure, der skal udføres i et trin.
DD-sætningen (Data Definition) definerer de datasæt, som programmet vil læse eller skrive, herunder deres placering, format og 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 DUMMYI dette eksempel: PAYBATCH er jobbets navn, STEP010 er ét trin i arbejdet, PGM=PAYROLL1 navngiver det COBOL-program, der skal udføres, og DD-sætningerne definerer alle filer, som programmet kan tilgå. COBOL-programmet PAYROLL1 ved ikke eller er ligeglad med hvor EMPFILE or TRANSACT kommer fysisk fra, læser den dem blot efter ddname. JCL fortolker den fysiske placering, postformatet og adgangstilstanden, før udførelsen begynder.
JCL-katalogiserede procedurer (PROC'er)
I stedet for at skrive det samme JCL-mønster for hvert job, definerer mainframe-teams katalogiserede procedurer (PROC'er), der indkapsler genanvendelige udførelsesmønstre. En PROC er en skabelon, der er gemt i et procedurebibliotek; individuelle job refererer til den og tilsidesætter specifikke parametre efter behov.
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
// PENDKald af PROC fra et job:
jcl
//COMPILE EXEC PAYPROC,MEMBER=PAYROLL1,RUNDATE=20251205Denne enkelte EXEC-sætning udvides til den fulde PROC på udførelsestidspunktet, med MEMBER og RUNDATE erstattet hvor som helst &MEMBER og &RUNDATE PROC'er er en af de primære årsager til, at JCL-til-COBOL-kortlægning er kompleks: et job kan kalde snesevis af COBOL-programmer via en enkelt PROC-reference, og de faktiske programmer, der kaldes, afhænger af symbolske parametre, der varierer pr. kørsel.
Hvad er forskellen mellem JCL og COBOL?
JCL og COBOL nævnes ofte sammen, men de har helt forskellige roller. Ingen af dem erstatter den anden, og begge er nødvendige for at mainframe-batchbehandling kan fungere.
| Dimension | JCL | COBOL |
|---|---|---|
| Formål | Orkestrerer udførelse | Implementerer forretningslogik |
| Hvad det definerer | Job, trin, filer, betingelser | Programmer, datastrukturer, beregninger |
| Når den kører | Før programudførelse (opsætning) og efter (oprydning) | Under programudførelse |
| Læser/skriver data | Via datasætallokering (DD-udsagn) | Via FILE SECTION og READ/WRITE-sætninger |
| Fejl ved håndtering | Returkoder, betinget trinudførelse | UNDTAGELSES-håndterere, PERFORM-fejlrutiner |
| Overførsel | IBM z/OS-specifik | Bærbar på tværs af platforme med compilere |
| Hvem skriver det | Systemprogrammører, batchingeniører | Applikationsudviklere |
| Moderne ækvivalent | CI/CD-pipeline + containerorkestrering | Applikationskode (Java, Python, C++) |
Den nemmeste måde at konceptualisere forholdet på: JCL er implementerings- og orkestreringslaget; COBOL er applikationslaget. I et moderne cloud-native system ville JCL's rolle blive udfyldt af Kubernetes jobmanifester, shell-scripts og CI/CD-pipelinefaser. COBOL's rolle ville blive udfyldt af applikationstjenester skrevet i Java, Python eller Go.
Hvordan JCL aktiverer COBOL: Udførelseskæden
Vejen fra et JCL-job til COBOL-udførelse følger en ensartet kæde. Forståelse af hvert trin er fundamentet for at forstå, hvad et JCL-til-COBOL-kort skal indfange.
Trin 1: Jobindsendelse. JCL-jobbet indsendes til Job Entry Subsystem (JES). JES sætter jobbet i kø og begynder at læse dets sætninger.
Trin 2: Trinopsætning. For hvert EXEC-trin finder systemet det navngivne program i det indlæsningsbibliotek, der er angivet af STEPLIB DD-sætningen. Hvis der ikke er angivet nogen STEPLIB, søger systemet i systemets linkbibliotek.
Trin 3: Datasætallokering. Før programmet kører, allokerer systemet alle datasæt, der er defineret af DD-sætninger i trinnet. Dette inkluderer åbning af filer, verificering af, at inputdatasæt findes, og oprettelse af outputdatasæt.
Trin 4: Programudførelse. COBOL-programmet udføres. Det tilgår filer ved hjælp af de dd-navne, der er defineret i JCL, OPEN INPUT EMPFILE i COBOL knyttes direkte til den navngivne DD-sætning EMPFILE i JCL.
Trin 5: Evaluering af returkode. Når COBOL-programmet slutter, sætter det en returkode (typisk 0 for succes, 4 for advarsel, 8 for fejl, 12 eller 16 for alvorlig fejl). JCL bruger COND parametre eller IF/THEN/ELSE konstruktioner for at bestemme, om efterfølgende trin skal køres baseret på denne kode.
Trin 6: Datasætdisponering. Efter trinnet behandler systemet datasætdisponeringerne, der er defineret i hver DD-sætning: behold, slet, katalogiser, afkatalogiser eller videregiv til næste trin.
Følgende eksempel viser, hvordan denne kæde ser ud i praksis, med JCL til venstre og de tilsvarende COBOL-elementer til højre:
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=*COBOL-programmet ACCTREC indeholder:
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). SELECT INFILE ASSIGN TO INFILE i COBOLs FILE-CONTROL-sektion forbinder til DD-sætningen med navnet INFILE i JCL. Dette er den grundlæggende kortlægningsrelation: COBOL bruger logiske filnavne; JCL omdanner dem til fysiske datasæt.
JCL Abend-koder: Hvad de betyder
JCL-abendkoder (unormale slutkoder) identificerer, hvorfor et jobtrin afsluttedes uventet. De vises i joboutputtet som S000 (systemfejl) eller U0000 (brugerabend) koder. Det er vigtigt at forstå dem for at kunne diagnosticere fejl i batchjobs.
| Abend-koden | Type | Fælles årsag |
|---|---|---|
| S001 | Systemkrav | I/O-fejl ved læsning eller skrivning af et datasæt |
| S013 | Systemkrav | Uoverensstemmelse i DCB-attribut, uoverensstemmelse i postlængde eller format mellem JCL DD og COBOL FD |
| S0C4 | Systemkrav | Undtagelse for lagerbeskyttelse, program forsøgte at få adgang til hukommelse uden for dets allokerede område |
| S0C7 | Systemkrav | Datafejl, forsøg på aritmetik på ikke-numeriske data (meget almindelig COBOL-fejl) |
| S322 | Systemkrav | Tidsgrænse overskredet, jobbet kørte længere end tilladt af TIME-parameteren |
| S806 | Systemkrav | Indlæsningsmodul ikke fundet, program navngivet i EXEC PGM= ikke i noget søgt indlæsningsbibliotek |
| S913 | Systemkrav | Sikkerhedsbrud for adgang til datasæt, RACF eller tilsvarende nægtet adgang |
| U0000 | Bruger | Applikationsdefineret abend, COBOL-program kaldet STOP RUN med en brugerkode |
| U4076 | Bruger | IMS-specifik fejl, databaseadgangsfejl |
Den mest almindelige produktionsfejl, S0C7, opstår, når et COBOL-program forsøger at udføre aritmetiske beregninger på et felt, der indeholder mellemrum eller ikke-numeriske tegn. Den typiske årsag er en uoverensstemmelse mellem det forventede dataformat i COBOL-programmet og de faktiske data leveret af JCL, hvilket er præcis den slags uoverensstemmelse, som JCL-til-COBOL-kortlægning afslører, før den forårsager en produktionsfejl ved midnat.
COND-parameteren og betinget udførelse
JCL styrer hvilke trin der kører baseret på returkoder fra tidligere trin ved hjælp af COND parameter:
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) betyder: spring dette trin over, hvis returkoden for et af de foregående trin er mindre end 4. COND=(4,LT,STEP010) betyder: spring dette trin over, hvis STEP010's returkode er mindre end 4. COND=(0,NE,STEP010) betyder: spring STEP030 over, hvis STEP010s returkode ikke er lig med 0, dvs. kør kun oprydning, hvis STEP010 lykkedes.
Moderne JCL bruger IF/THEN/ELSE/ENDIF konstruktion i stedet, hvilket er mere læsbart:
jcl
//IF010 IF (STEP010.RC = 0) THEN
//STEP020 EXEC PGM=PROCESS
// ENDIF
//IF020 IF (STEP010.RC > 4) THEN
//STEP030 EXEC PGM=ERRORHANDLER
// ENDIFKortlægning af betingede udførelsesstier er et af de mest kritiske og oftest oversete elementer i JCL-til-COBOL-analyse. Et COBOL-program, der kun kører, når et tidligere trin fejler, kan håndtere fejltilstande, rollback-logik eller gendannelsesprocedurer, en funktionalitet, der er helt usynlig, hvis man kun ser på COBOL-kildekoden uden den JCL, der driver den.
JCL, COBOL og DB2: Trelagsstakken
De fleste mainframe-transaktionssystemer involverer en tredje komponent udover JCL og COBOL: DB2, IBMs relationsdatabase. COBOL-programmer tilgår DB2 via indlejrede SQL-sætninger (EXEC SQL-blokke). JCL administrerer DB2-undersystemforbindelsen og DBRM (Database Request Module) via specifikke DD-sætninger.
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.I JCL-COBOL-DB2-stakken leverer JCL runtime-miljøet og adgang til datasættet; COBOL implementerer forretningslogik og kalder databasen; DB2 lagrer og henter data i henhold til den SQL, der er integreret i COBOL-programmet. Et komplet afhængighedskort over ethvert COBOL-program, der bruger DB2, skal ikke blot omfatte, hvilke JCL-jobs der kalder det, men også hvilke DB2-tabeller det læser og skriver til, hvilke kolonner det tilgår, og hvilke andre programmer der tilgår de samme tabeller, fordi en skemaændring i en tabel påvirker alle COBOL-programmer, der refererer til den.
Hvorfor JCL-til-COBOL-kortlægning er vigtig for modernisering
At kortlægge JCL til COBOL er ikke primært en teknisk øvelse. Det er en risikostyringsøvelse. Enhver ændring af et mainframe-system, uanset om det drejer sig om at ændre en JCL-parameter, tilføje et trin, ændre et datasætnavn eller ændre det COBOL-program, et job kalder, har konsekvenser, der rækker ud over den ændrede komponent. Den eneste måde at vurdere disse konsekvenser præcist på, før man foretager en ændring, er at have et komplet kort over, hvad der findes, og hvordan alting forbinder.
Før migrering : Flytning af batch-arbejdsbelastninger fra mainframe til skyen kræver viden om, hvilke JCL-job der findes, hvilke COBOL-programmer de kalder, hvilke datasæt der flyder mellem trin, hvad udførelsessekvensen er, og hvad der sker, når trin fejler. Uden dette kort arbejder migreringsteamet ud fra ufuldstændig dokumentation eller slet ingen dokumentation. Trin bliver overset. Afhængigheder bliver opdaget i produktionen. Overførselsdatoer bliver forsinkede.
Før enhver kodeændring : Et COBOL-program, der er ændret uden at kontrollere, hvilke JCL-job der kalder det, kan afbryde job, der kører under forskellige forhold eller med forskellige datasætkonfigurationer. En ændring af JCL-parameteren, der synes lokal, kan påvirke opførslen af et COBOL-program, der er afhængig af specifikke datasætattributter. Konsekvensanalyse kræver kendskab til den fulde JCL-til-COBOL-til-datasæt-kæde, før der foretages nogen ændring.
Til videnoverførsel : Når en COBOL-udvikler, der har vedligeholdt et batchsystem i tyve år, går på pension, tager de den mentale model for, hvordan JCL-job og COBOL-programmer forbindes, med sig. Et dokumenteret kort er den eneste mekanisme til at overføre denne viden til det næste team. Uden det arver nye udviklere et system, de ikke sikkert kan modificere.
Til compliance-revision : Regulatoriske revisioner kræver ofte demonstration af, at finansielle beregninger, datatransformationer eller adgangskontroller fungerer som dokumenteret. Hvis JCL-til-COBOL-forholdet ikke er dokumenteret, er det umuligt at demonstrere dette uden at reverse engineere systemet under revisionspres.
JCL-administrationsværktøjer og analyseplatforme
Den flersprogede karakter af Search Console-dataene i denne artikel, med forespørgsler på italiensk, fransk, spansk, japansk og tysk, der alle spørger om JCL-administrationsværktøjer, afspejler, hvor globalt distribueret mainframe-IT-fællesskabet er, og hvor konsekvent teams i alle regioner står over for det samme problem: Deres JCL- og COBOL-dokumentation er ufuldstændig, forældet eller ikke-eksisterende.
De værktøjer, der er tilgængelige til JCL-analyse og -styring, falder i tre kategorier:
IBM-native værktøjer : IBM tilbyder Job Entry Subsystem-faciliteter, JES-spoolstyring og IBM z/OS Batch Runtime. Disse håndterer udførelse og overvågning, men tilbyder ikke analyse eller visualisering af afhængigheder på tværs af programmer.
Tredjeparts jobplanlæggere : CA7, TWS (Tivoli Workload Scheduler) og Broadcoms ESP Workload Automation administrerer batchplanlægning på tværs af tusindvis af job, leverer afhængighedsbaseret planlægning og advarer om fejl. De forstår afhængigheder på jobniveau, men analyserer typisk ikke de COBOL-programmer, der kaldes i hvert trin.
Statisk kodeanalyse og platforme til afhængighedskortlægning : Værktøjer, der analyserer JCL- og COBOL-kildekode for at opbygge en strukturel model af, hvilke job der kalder hvilke programmer, hvilke programmer der tilgår hvilke datasæt, og hvordan data flyder på tværs af systemet. Disse giver den tværgående synlighed, som jobplanlæggere og IBM-native værktøjer ikke kan: forholdet mellem en specifik JCL DD-sætning og den COBOL FILE-CONTROL-post, der er knyttet til den, eller mellem et COBOL-program, der skriver til et datasæt, og det næste job, der læser det datasæt som input.
SMART TS XL tilhører denne tredje kategori og udvider den til at dække alle sprog i virksomhedsmiljøet, COBOL, JCL, PL/I, Assembler, SQL, Java og andre, og leverer den tværsproglige strukturelle analyse, som intet enkeltsproget værktøj kan levere.
Hvordan SMART TS XL Kortlægger JCL til COBOL i virksomhedsskala
Manuel JCL-til-COBOL-kortlægning kan håndteres for et enkelt job med tre trin. Det er ikke håndterbart for en organisation med 50,000 JCL-job, 200,000 COBOL-programmer og millioner af datasætreferencer akkumuleret over fire årtier. Forholdet mellem en specifik PROC, de symbolske parametre, der bruges til at kalde den, de COBOL-programmer, disse parametre opløses i, og de datasæt, disse programmer tilgår, kan ikke spores manuelt i den skala.
SMART TS XL analyserer JCL- og COBOL-kildekode, inklusive PROC'er med symbolsk parametersubstitution, in-stream-procedurer, INCLUDE-medlemmer, overrides og betinget udførelseslogik, og opbygger en samlet krydsreferencemodel, der repræsenterer alle strukturelle relationer i systemet. Denne model er forespørgbar, navigerbar og altid aktuel, fordi den regenereres fra kildekoden i stedet for at vedligeholdes som et manuelt opdateret dokument.
JCL udvidelse Funktionen løser symbolsk parametersubstitution for at vise de faktiske programmer og datasæt, der kaldes af en hvilken som helst PROC, under hensyntagen til de tilsidesættelser, der anvendes af hvert kaldende job. En PROC, der bruger &PGMNAME som en symbolsk parameter vises i modellen som alle de konkrete programmer, den løser op til på tværs af alle dens kaldere, ikke som en uløst reference.
Funktionen til kortlægning af applikationsafhængigheder opbygger den fulde graf fra JCL-jobbet via COBOL-programmet, DB2-tabellen og downstream-programmet, og viser alle komponenter i systemet og alle forbindelser mellem dem. Før enhver moderniseringsændring kan teamet forespørge: hvilke job kalder dette program? Hvilke datasæt læser dette program? Hvilke andre programmer skriver til disse datasæt? Hvilke job kører derefter i sekvensen?
Effektanalysefunktionen genererer et opregnet omfang af konsekvenser for enhver foreslået ændring: rediger denne kopibog og se alle programmer, der inkluderer den; rediger dette datasætlayout og se alle JCL DD-sætninger, der refererer til det; fjern dette trin fra et job og se alle downstream-trin, der afhang af dets output.
For teams, der står over for JCL-til-COBOL-kortlægning som en del af en arvemodernisering program, SMART TS XL giver det fundament, som moderniseringsleverandører, Astadia, TSRI, Advanced og andre, har brug for, før ethvert konverteringsarbejde påbegyndes: en komplet og nøjagtig strukturel opgørelse over, hvad der eksisterer, så konverteringsomfanget defineres ved analyse snarere end ved antagelser.
Kortet er ikke territoriet, men det er udgangspunktet
JCL og COBOL forsvinder ikke. De batchsystemer, der behandler løn, håndterer forsikringskrav, kører regulatoriske rapporter og afregner finansielle transaktioner, vil fortsat køre på mainframes, mens cloud-migreringer planlægges, godkendes, finansieres og udføres, en proces, der typisk tager år snarere end måneder. I løbet af disse år skal systemerne vedligeholdes, modificeres og forstås.
JCL-til-COBOL-kortlægning er ikke et engangsprojekt. Det er en kontinuerlig praksis: at holde den strukturelle model opdateret, efterhånden som programmer ændres, job tilføjes, og datasæt reorganiseres. De teams, der investerer i denne praksis, bevarer evnen til at foretage sikre ændringer i systemer, som det meste af branchen behandler som sorte bokse. De teams, der ikke gør det, foretager ændringer i systemer, de ikke fuldt ud kan se, i miljøer, hvor en overset afhængighed ikke producerer en compilerfejl, hvilket resulterer i en produktionsfejl klokken 3 om natten under den natlige batchkørsel.
