Jobkontrol sprog - Job Control Language

Job Control Language ( JCL ) er et navn til scriptingsprog, der bruges på IBM mainframe- operativsystemer til at instruere systemet om, hvordan man kører et batchjob eller starter et delsystem.

Mere specifikt er formålet med JCL at sige, hvilke programmer der skal køres, ved hjælp af hvilke filer eller enheder til input eller output, og til tider også angive, under hvilke betingelser man skal springe et trin over.

Der er to forskellige IBM Job Control-sprog:

• en til operativsystemets slægt, der begynder med DOS / 360, og hvis seneste medlem er z / VSE ; og
• den anden for slægten fra OS / 360 til z / OS , hvor sidstnævnte nu inkluderer JES- udvidelser, Job Entry Control Language (JECL) .

De deler nogle grundlæggende syntaksregler og et par grundlæggende begreber, men er ellers meget forskellige. Den VM operativsystem ikke har JCL som sådan; de CP og CMS -komponenter har hver kommando sprog .

Terminologi

Visse ord eller sætninger, der bruges sammen med JCL, er specifikke for IBM mainframe-teknologi.

• Datasæt: et "datasæt" er en fil; det kan være midlertidigt eller permanent og placeret på et diskdrev, båndopbevaring eller anden enhed.
• Medlem: et "medlem" af et partitioneret datasæt (PDS) er et individuelt datasæt inden for et PDS. Et medlem kan fås ved at angive navnet på PDS med medlemsnavnet i parentes. For eksempel kan systemmakroen GETMAIN i SYS1.MACLIB refereres til som SYS1.MACLIB (GETMAIN).
• Partitioneret datasæt: et "partitioneret datasæt" eller PDS er samling af medlemmer eller arkiv, der typisk bruges til at repræsentere systembiblioteker. Som med de fleste sådanne strukturer kan et medlem, når det er gemt, ikke opdateres; medlemmet skal slettes og erstattes, f.eks. med IEBUPDTE- hjælpeprogrammet. Partitionerede datasæt er omtrent analoge med ar-baserede statiske biblioteker i Unix-baserede systemer.
• USS: Unix-systemtjenester, et Unix-undersystem, der kører som en del af MVS, og som tillader Unix-filer, scripts, opgaver og programmer at køre på en mainframe i et UNIX-miljø.

Motivering

Oprindeligt var mainframesystemer orienteret mod batchbehandling . Mange batchjob kræver opsætning med specifikke krav til hovedlagring og dedikerede enheder såsom magnetbånd , private diskvolumener og printere opsat med specielle formularer. JCL blev udviklet som et middel til at sikre, at alle nødvendige ressourcer er tilgængelige, før et job er planlagt til at køre. For eksempel tillader mange systemer, såsom Linux, at identifikation af krævede datasæt skal specificeres på kommandolinjen og derfor er underlagt erstatning med skallen eller genereres af programmet under kørselstid. På disse systemer har operativsystemets jobplanlægger kun ringe eller ingen idé om kravene til jobbet. I modsætning hertil specificerer JCL eksplicit alle krævede datasæt og enheder. Planlæggeren kan forhåndsallocere ressourcerne, inden jobbet frigives. Dette hjælper med at undgå " deadlock ", hvor job A har ressource R1 og anmoder om ressource R2, mens samtidig kørsel af job B indeholder ressource R2 og anmoder R1. I sådanne tilfælde er den eneste løsning, at computeroperatøren afslutter et af jobene, som derefter skal genstartes. Med jobkontrol, hvis job A er planlagt til at køre, startes ikke job B, før job A fuldender eller frigiver de krævede ressourcer.

Funktioner, der er fælles for DOS og OS JCL

Job, trin og procedurer

For både DOS og OS er arbejdsenheden jobbet . Et job består af et eller flere trin, som hver er en anmodning om at køre et specifikt program. F.eks. Før dagene med relationelle databaser kan et job med at producere en udskrevet rapport til ledelsen bestå af følgende trin: et brugerskrevet program til at vælge de relevante poster og kopiere dem til en midlertidig fil; sorter den midlertidige fil i den påkrævede rækkefølge, normalt ved hjælp af et universalværktøj; et brugerskrevet program til at præsentere informationen på en måde, der er let for slutbrugerne at læse og inkluderer anden nyttig information såsom undertotaler; og et brugerskrevet program til at formatere udvalgte sider af slutbrugerinformationen til visning på en skærm eller terminal.

I både DOS og OS JCL skal det første "kort" være JOB-kortet, som:

• Identificerer jobbet.
• Giver normalt oplysninger, der gør det muligt for computertjenesteafdelingen at fakturere den relevante brugerafdeling.
• Definerer, hvordan jobbet som helhed skal køres, f.eks. Dets prioritet i forhold til andre job i køen.

Procedurer (ofte kaldet procs ) er forudskrevet JCL til trin eller grupper af trin, indsat i et job. Begge JCL'er tillader sådanne procedurer. Procs bruges til at gentage trin, der bruges flere gange i et job eller i flere forskellige job. De sparer programmerer tid og reducerer risikoen for fejl. For at køre en procedure inkluderer man simpelthen et enkelt "kort" i JCL-filen, der kopierer proceduren fra en bestemt fil og indsætter den i jobstrømmen. Procs kan også omfatte parametre til at tilpasse proceduren til hver brug.

Grundlæggende syntaks

Både DOS og OS JCL har en maksimal anvendelig linjelængde på 80 tegn, for når DOS / 360 og OS / 360 først blev brugt, var hovedmetoden til at levere nyt input til et computersystem 80-søjles stansede kort . Det blev senere muligt at indsende job via disk- eller båndfiler med længere optagelængder, men operativsystemets jobafgivelseskomponenter ignorerede alt efter karakter 80.

Strengt taget bruger begge operativsystemfamilier kun 71 tegn pr. Linje. Tegn 73-80 er sædvanligvis kortsekvensnumre, som systemet udskriver på rapporten jobbet og er nyttige til at identificere placeringen af ​​eventuelle fejl rapporteret af operativsystemet. Tegn 72 efterlades normalt tomt, men det kan indeholde et ikke-tomt tegn for at indikere, at JCL-udsagnet fortsættes til det næste kort.

Alle kommandoer, parameternavne og værdier skal være med store bogstaver undtagen USS- filnavne.

Alle linjer undtagen in-stream-input (se nedenfor) skal begynde med et skråstreg " / ", og alle linjer, som operativsystemets processer skal begynde med to skråstreger // - altid startende i den første kolonne . Der er dog to undtagelser: afgrænsningserklæringen og kommentarerklæringen. En afgrænsningserklæring begynder med en skråstreg og en stjerne ( /* ), og en kommentarerklæring i OS JCL begynder med et par skråstreg og en stjerne ( //* ) eller en stjerne i DOS JCL.

Mange JCL-udsagn er for lange til at passe inden for 71 tegn, men kan udvides til et ubestemt antal fortsættelseskort ved at:

Strukturen af ​​de mest almindelige korttyper er:

In-stream input

DOS og OS JCL tillader begge in-stream-input, dvs. "kort", der skal behandles af applikationsprogrammet snarere end operativsystemet. Data, der skal opbevares i lang tid, lagres normalt på disken, men før brugen af interaktive terminaler blev almindelig, var den eneste måde at oprette og redigere sådanne diskfiler på ved at levere de nye data på kortene.

DOS og OS JCL har forskellige måder at signalere starten på in-stream-input, men begge ender in-stream-input med /* i kolonne 1 på kortet efter det sidste in-stream-datakort. Dette får operativsystemet til at genoptage behandlingen af ​​JCL på kortet efter /* kortet.

• OS JCL: DD-udsagn kan bruges til at beskrive in-stream-data såvel som datasæt. En DD-sætning, der beskæftiger sig med in-stream-data, har en stjerne (*) efter DD-identifikatoren, f.eks //SYSIN DD * . JCL-udsagn kan medtages som en del af in-stream-data ved hjælp af DD DATA-udsagnene.

En operand ved navn DLM tillod at specificere en afgrænser (standard er "/ *"). Ved at angive en alternativ afgrænser kan JCL læses som data, for eksempel for at kopiere procedurer til et biblioteksmedlem eller sende et job til den interne læser .

• Et eksempel, der sender et job til den interne læser ( INTRDR ), er:

//SUBM     EXEC PGM=IEBGENER
//SYSPRINT DD   SYSOUT=Z
//SYSUT2   DD   SYSOUT=(A,INTRDR)
//SYSIN    DD   DUMMY
//SYSUT1   DD   DATA,DLM=ZZ
//RUNLATR  JOB  ACCT,MANIX,CLASS=A.TYPRUN=HOLD
//* ^ a JOB to run later
//CPUHOG   EXEC PGM=PICALC1K
//OUTPUT   DD   DSN=PICALC.1000DGTS,SPACE=(TRK,1),DISP=(,KEEP)
ZZ
//* ^ as specified by DLM=ZZ
//DROPOLDR EXEC PGM=IEFBR14
//DELETE4  DD   DSN=PICALC.4DGTS,DISP=(OLD,DELETE)
//DELETE5  DD   DSN=PICALC.5DGTS,DISP=(OLD,DELETE)

1. Programmet PICALC1K vil afvente (TYPRUN = HOLD), der frigives manuelt
2. To filer, PICALC.4DGTS og PICALC.5DGTS slettes NU.

• DOS JCL: Indtast simpelthen in-stream-data efter EXEC-kortet til programmet.

Kompleksitet

En stor del af OS JCL's kompleksitet stammer især fra det store antal muligheder for at specificere datasætoplysninger . Mens filer på Unix- lignende operativsystemer er abstraheret i vilkårlige samlinger af bytes, hvor detaljerne i vid udstrækning håndteres af operativsystemet, udsætter datasæt på OS / 360 og dens efterfølgere deres filtyper og størrelser, recordtyper og længder, blokstørrelser , enhedsspecifik information såsom magnetbåndstæthed og etiketinformation. Selvom der er standardindstillinger for mange muligheder, er der stadig meget, der skal specificeres af programmøren gennem en kombination af JCL og information kodet i programmet. Jo mere information der er kodet i programmet, jo mindre fleksibel er den, da information i programmet tilsidesætter noget i JCL; således leveres de fleste oplysninger normalt via JCL.

For eksempel, for at kopiere en fil på Unix- operativsystemet, ville brugeren indtaste en kommando som:

cp oldFile newFile

Følgende eksempel, der bruger JCL, kan bruges til at kopiere en fil på OS / 360:

//IS198CPY JOB (IS198T30500),'COPY JOB',CLASS=L,MSGCLASS=X
//COPY01   EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1   DD DSN=OLDFILE,DISP=SHR
//SYSUT2   DD DSN=NEWFILE,
//            DISP=(NEW,CATLG,DELETE),
//            SPACE=(CYL,(40,5),RLSE),
//            DCB=(LRECL=115,BLKSIZE=1150)
//SYSIN  DD DUMMY

En anden forklaring på JCL's kompleksitet er de forskellige forventninger til at køre et job end dem, der findes i en pc eller et Unix-lignende miljø.

• Low-end System / 360 CPU'er var mindre kraftfulde og dyrere end midten af ​​1980'ernes pc'er, som MS-DOS blev designet til. OS / 360 var beregnet til systemer med en mindste hukommelsesstørrelse på 32 KB og DOS / 360 til systemer med et minimum på 16 KB. En 360/30 CPU - low-end, da System / 360 blev annonceret i 1964 - behandlede 1,8K til 34,5K instruktioner pr. Sekund. Den første IBM-pc i 1981 havde 16 KB eller 64 KB hukommelse og ville behandle omkring 330K instruktioner pr. Sekund. Som et resultat måtte JCL være let for computeren at behandle, og brugervenlighed af programmører var en meget lavere prioritet. I denne æra var programmører meget billigere end computere.
• JCL blev designet til batchbehandling . Som sådan skal det fortælle operativsystemet alt, herunder hvad man skal gøre afhængigt af resultatet af et trin. For eksempel DISP=(NEW,CATLG,DELETE) betyder "hvis programmet kører med succes, skal du oprette en ny fil og katalogisere den. Ellers skal du slette den nye fil." Programmer, der køres på en pc, afhænger ofte af brugeren for at rydde op efter behandlingsproblemer.
• System / 360-maskiner blev designet til at blive delt af alle brugerne i en organisation. Så JOB kortet fortæller operativsystemet, hvordan man fakturerer brugerens konto ( IS198T30500 ), hvilken foruddefineret mængde lagerplads og andre ressourcer der kan tildeles ( CLASS=L ) og flere andre ting. //SYSPRINT DD SYSOUT=* fortæller computeren til at udskrive programmet rapport om standard printer , der er fyldt med almindeligt papir, ikke på en anden printer, som kan belastes med blankocheck. DISP=SHR fortæller operativsystemet, at andre programmer kan læse OLDFILE på samme tid .

Senere versioner af operativsystemerne DOS / 360 og OS / 360 bevarer de fleste funktioner i den originale JCL - skønt der er foretaget en vis forenkling for at undgå at tvinge kunder til at omskrive alle deres JCL-filer. Mange brugere gemmer som en procedure ethvert sæt JCL-udsagn, som sandsynligvis vil blive brugt mere end en eller to gange.

Syntaksen for OS JCL svarer til syntaksen for makroer i System / 360- samlingssprog og ville derfor have været kendt for programmører på et tidspunkt, hvor mange programmer blev kodet i samlingssprog.

DOS JCL

Positionsparametre

//TLBL TAPEFIL,'COPYTAPE.JOB',,,,2
//ASSGN SYS005,200
//DLBL DISKFIL,'COPYTAPE.JOB',0,SD
//EXTENT SYS005,VOL01,1,0,800,1600

DOS JCL-parametre er positionelle, hvilket gør dem sværere at læse og skrive, men lettere for systemet at parse.

• Programmøren skal huske, hvilket element der går i hvilken position i alle typer udsagn.
• Hvis nogle valgfri parametre udelades, men senere er inkluderet, skal de udeladte parametre repræsenteres med kommaer uden mellemrum, som i TLBL-sætningen ovenfor.

DOS JCL mindsker i nogen grad vanskelighederne med positionsparametre ved at bruge flere udsagn med færre parametre end OS JCL. I eksemplet udfører ASSGN-, DLBL- og EXTENT-sætningerne det samme arbejde (angiver hvor en ny diskfil skal lagres) som en enkelt DD sætning i OS JCL.

Enhedsafhængighed

I den originale DOS / 360 og i de fleste versioner af DOS / VS måtte man angive modelnummeret på den enhed, der skulle bruges til hver disk eller tape-fil - selv for eksisterende filer og for midlertidige filer, som ville blive slettet på slutningen af ​​jobbet. Dette betød, at hvis en kunde opgraderede til mere moderne udstyr, måtte mange JCL-filer ændres.

Senere medlemmer af DOS / 360-familien reducerede antallet af situationer, hvor enhedsmodelnumre var påkrævet.

Manuel filallokering

DOS / 360 krævede oprindeligt, at programmøren angiver placeringen og størrelsen på alle filer på DASD . De EXTENT kort Angiver lydstyrken på hvilken udstrækning har bopæl, udgangs absolutte spor, og antallet af spor. For z / VSE kan en fil have op til 256 udvidelser på forskellige diskenheder.

OS JCL

OS JCL består af tre grundlæggende udsagnstyper:

• JOB erklæring, der identificerer start af jobbet og oplysninger om hele jobbet, såsom fakturering, køreprioritet og tids- og pladsgrænser.
• EXEC erklæring, der identificerer det program eller den procedure, der skal udføres i dette trin af jobbet,
  og information om trinnet, herunder COND- koder til at køre eller springe over et trin.
• DD (Data Definition) udsagn, der identificerer en datafil, der skal bruges i et trin, og detaljeret information om den fil. DD udsagn kan være i enhver rækkefølge inden for trinnet.

Lige fra starten var JCL til OS-familien (op til og med z / OS ) mere fleksibel og lettere at bruge.

De følgende eksempler bruger den gamle syntaksstil, der blev leveret lige fra lanceringen af System / 360 i 1964. Den gamle syntaks er stadig ret almindelig i job, der har kørt i årtier med kun mindre ændringer.

Regler for kodning af JCL-erklæringer

Hver JCL-erklæring er opdelt i fem felter:

 Identifier-Field Name-Field Operation-Field Parameter-Field Comments-Field
                 ^          ^               ^               ^
              no space     space          space           space

Identifier-felt skal sammenkædes med Name-Field , dvs. der skal ikke være mellemrum mellem dem.

• Identifier-felt ( // ): Identifikationsfeltet angiver over for systemet, at en erklæring er en JCL-sætning snarere end data. Identifikationsfeltet består af følgende:
  • Kolonne 1 og 2 i alle JCL-udsagn, undtagen afgrænsningserklæringen, indeholder //
  • Kolonne 1 og 2 i afgrænsningserklæringen indeholder /*
  • Kolonne 1, 2 og 3 i en JCL-kommentar indeholder //*
• Navnefelt : Navnefeltet identificerer en bestemt erklæring, så andre udsagn og systemet kan henvise til den. For JCL-udsagn skal det kodes som følger:
  • Navnet skal begynde i kolonne 3.
  • Navnet er en gennem 8 alfanumeriske eller nationale ( $ , # , @ ) tegn.
  • Det første tegn skal være alfabetisk.
  • Navnet skal efterfølges af mindst et tomt.
• Operation-Field : Operationsfeltet specificerer typen af ​​sætning eller kommandoen for kommandosætningen. Operation-Field skal kodes som følger:
  • Funktionsfeltet består af tegnene i syntaksfeltet til udsagnet.
  • Handlingen følger navnefeltet.
  • Forløbet skal være forud for og efterfulgt af mindst et tomt.
  • Operationen vil være en af JOB , EXEC og DD .
• Parameter-felt : Parameterfeltet, også undertiden benævnt operandfeltet, indeholder parametre adskilt af kommaer. Parameterfeltet skal kodes som følger:
  • Parameterfeltet følger driftsfeltet.
  • Parameterfeltet skal indledes med mindst et tomt.
  • Parameterfeltet indeholder parametre, som er nøgleord, der bruges i udsagnet til at give information, såsom program- eller datasættets navn.
• Kommentarfelt : Dette indeholder kommentarer . Kommentarfelt skal kodes som følger:
  • Kommentarfeltet følger parameterfeltet.
  • Kommentarfeltet skal være forud for mindst et tomt.

Nøgleordsparametre

//NEWFILE DD DSN=MYFILE01,UNIT=DISK,SPACE=(TRK,80,10),
//           DCB=(LRECL=100,BLKSIZE=1000),
//           DISP=(NEW,CATLG,DELETE)

Alle de vigtigste parametre i OS JCL-udsagn er identificeret ved nøgleord og kan præsenteres i enhver rækkefølge. Et par af disse indeholder to eller flere underparametre, såsom SPACE (hvor meget diskplads, der skal allokeres til en ny fil) og DCB (detaljeret specifikation af en fils layout) i eksemplet ovenfor. Underparametre er undertiden positionelle, som i SPACE , men de mest komplekse parametre, såsom DCB , har nøgleordssubparametre.

Positionsparameter skal være foran søgeordsparametre. Nøgleordsparametre tildeler altid værdier til et nøgleord ved hjælp af ligetegnet ( = ).

Dataadgang (DD-erklæring)

Den DD sætning bruges til at referencedata. Denne erklæring forbinder et programs interne beskrivelse af et datasæt til dataene på eksterne enheder: diske, bånd, kort, printere osv. DD kan give oplysninger såsom en enhedstype (f.eks. '181', '2400-5', ' TAPE '), et volumen serienummer til bånd eller diske og beskrivelsen af ​​datafilen, kaldet DCB underparameter efter Data Control Block (DCB) i det program, der bruges til at identificere filen.

Oplysninger, der beskriver filen, kan komme fra tre kilder: DD-kortoplysningerne, datasætets etiketoplysninger for en eksisterende fil, der er gemt på bånd eller disk, og DCB-makroen kodet i programmet. Når filen åbnes, flettes disse data, hvor DD-oplysningerne går forud for etiketoplysningerne, og DCB-oplysningerne har forrang for begge. Den opdaterede beskrivelse skrives derefter tilbage til datasættetiketten. Dette kan føre til utilsigtede konsekvenser, hvis der gives forkert DCB-information.

På grund af ovenstående parametre og specifik information for forskellige adgangsmetoder og enheder er DD-sætningen den mest komplekse JCL-sætning. I en IBM-referencehåndbog indeholder beskrivelsen af ​​DD-erklæringen mere end 130 sider - mere end dobbelt så meget som JOB- og EXEC-sætningerne tilsammen.

Enhedsuafhængighed

Helt fra starten tilbød JCL til OS-operativsystemfamilien en høj grad af enhedsuafhængighed. Selv for nye filer, der skulle opbevares efter afslutningen af ​​jobbet, kunne man angive enhedstypen i generiske termer, f.eks UNIT=DISK . UNIT=TAPE ,, Eller UNIT=SYSSQ (tape eller disk). Selvfølgelig, hvis det betyder noget, kunne man angive et modelnummer eller endda en bestemt enhedsadresse.

Procedurer

Procedurer tillader gruppering af en eller flere " EXEC PGM = " og DD udsagn og derefter påkaldelse af dem med " EXEC PROC = procname" -eller simpelthen "EXEC procname"

Et anlæg kaldet et procedurebibliotek tillod præ-lagringsprocedurer.

PROC & PEND

Procedurer kan også inkluderes i jobstrømmen ved at afslutte proceduren med en // PEND erklæring og derefter påkalde den ved navn, det samme var som om det var i et procedurebibliotek.

For eksempel:

//SUMPRINT PROC 
//PRINT    EXEC PGM=IEBGENER
//SYSUT1   DD   DSN=CEO.FILES.DAYEND.RPT24A,DISP=SHR
//SYSUT2   DD   SYSOUT=A
//SYSIN    DD   DUMMY
//         PEND
// EXEC SUMPRINT

Parameteriserede procedurer

OS JCL-procedurer blev parametreret fra starten, hvilket gjorde dem snarere ligesom makroer eller endda enkle underrutiner og dermed øget deres genanvendelighed i en lang række situationer.

//MYPROC PROC FNAME=MYFILE01,SPTYPE=TRK,SPINIT=50,SPEXT=10,LR=100,BLK=1000
.....
//NEWFILE DD DSN=&FNAME,UNIT=DISK,SPACE=(&SPTYPE,&SPINIT,&SPEXT),
//           DCB=(LRECL=&LR,BLKSIZE=&BLK),DISP=(NEW,CATLG,DELETE)
....

I dette eksempel er alle værdier, der begynder med ampersands " & " parametre, som vil blive specificeret, når et job anmoder om, at proceduren bruges. PROC-sætningen giver, udover at give proceduren et navn, programmøren mulighed for at specificere standardværdier for hver parameter. Så man kunne bruge den ene procedure i dette eksempel til at oprette nye filer i mange forskellige størrelser og layout. For eksempel:

//JOB01  JOB ..........
//STEP01 EXEC MYPROC FNAME=JOESFILE,SPTYPE=CYL,SPINIT=10,SPEXT=2,LR=100,BLK=2000
or
//JOB02  JOB ..........
//STEP01 EXEC MYPROC FNAME=SUESFILE,SPTYPE=TRK,SPINIT=500,SPEXT=100,LR=100,BLK=5000

Henvisninger

I job i flere trin kan et senere trin bruge en tilbageførsel i stedet for fuldt ud at angive en fil, der allerede er specificeret i et tidligere trin. For eksempel:

//MYPROC ................
//MYPR01 EXEC PGM=..........
//NEWFILE DD DSN=&MYFILE,UNIT=DISK,SPACE=(TRK,50,10),
//           DCB=(LRECL=100,BLKSIZE=1000),DISP=(NEW,CATLG,DELETE)
....
//MYPR02 EXEC PGM=..........
//INPUT01 DD DSN=*.MYPR01.NEWFILE

Her MYPR02 bruger den fil, der er identificeret som NEWFILE i trin MYPR01 ( DSN betyder "datasætnavn" og angiver filens navn; et DSN kan ikke overstige 44 tegn).

I job, der indeholder en blanding af jobspecifik JCL og procedureopkald, kan et jobspecifikt trin henvise til en fil, der var fuldt specificeret i en procedure, for eksempel:

//MYJOB JOB ..........
//STEP01 EXEC MYPROC             Using a procedure
//STEP02 EXEC PGM=.........      Step which is specific to this job
//INPUT01 DD DSN=*.STEP01.MYPR01.NEWFILE

hvor DSN=*.STEP01.MYPR01.NEWFILE betyder "brug den fil, der er identificeret som NEWFILE i trin MYPR01 i den procedure, der anvendes ved trin STEP01 for dette job". Brug af navnet på det trin, der kaldte proceduren i stedet for navnet på proceduren, giver en programmør mulighed for at bruge den samme procedure flere gange i det samme job uden forvirring om, hvilken instans af proceduren der bruges i referencen.

Kommentarer

JCL-filer kan være lange og komplekse, og sproget er ikke let at læse. OS JCL tillader programmører at inkludere to typer forklarende kommentarer:

• På samme linje som en JCL-erklæring. De kan udvides ved at placere et fortsættelsestegn (konventionelt " X ") i kolonne 72 efterfulgt af " // " i kolonne 1-3 i den næste linje.
• Linjer, der kun indeholder kommentarer, bruges ofte til at forklare vigtige punkter om JCL's overordnede struktur snarere end lokale detaljer. Kun kommentarer-linjer bruges også til at opdele lange, komplekse JCL-filer i sektioner.

//MYJOB JOB ..........
//*  Lines containing only comments.
//******** Often used to divide JCL listing into sections ********
//STEP01 EXEC MYPROC             Comment 2 on same line as statement
//STEP02 EXEC PGM=.........      Comment 3 has been extended and       X
//         overflows into another line.
//INPUT01 DD DSN=STEP01.MYPR01.NEWFILE

Sammenkædning af inputfiler

OS JCL tillader programmører at sammenkæde ("kæde") inputfiler, så de vises for programmet som en fil, for eksempel

//INPUT01 DD DSN=MYFILE01,DISP=SHR
//        DD DSN=JOESFILE,DISP=SHR
//        DD DSN=SUESFILE,DISP=SHR

2. og tredje udsagn har ingen værdi i navnefeltet, så OS behandler dem som sammenkædninger. Filerne skal være af samme grundlæggende type (næsten altid sekventielle) og skal have samme postlængde, men bloklængden behøver ikke være den samme.

I tidlige versioner af operativsystemet (bestemt før OS / 360 R21.8) skal bloklængden være i faldende rækkefølge, eller brugeren skal inspicere hver forekomst og føje til den navngivne DD-sætning den maksimale bloklængde, der findes, som f.eks. ,

//INPUT01 DD DSN=MYFILE01,DISP=SHR,BLKSIZE=800
//        DD DSN=JOESFILE,DISP=SHR (BLKSIZE assumed to be equal to or less than 800)
//        DD DSN=SUESFILE,DISP=SHR (BLKSIZE assumed to be equal to or less than 800)

I senere versioner af operativsystemet (bestemt efter OS / MVS R3.7 med de passende "valgbare enheder") ville OS selv under tildelingen inspicere hver forekomst i en sammenkædning og erstatte den maksimale bloklængde, der blev fundet.

En sædvanlig tilbagevenden var simpelthen at bestemme den maksimale mulige bloklængde på enheden og angive, at i den navngivne DD-sætning, som f.eks.

//INPUT01 DD DSN=MYFILE01,DISP=SHR,BLKSIZE=8000
//        DD DSN=JOESFILE,DISP=SHR (BLKSIZE assumed to be equal to or less than 8000)
//        DD DSN=SUESFILE,DISP=SHR (BLKSIZE assumed to be equal to or less than 8000)

Formålet med denne tilbageslag var at sikre, at adgangsmetoden tildelte et inputbuffersæt, der var stort nok til at rumme alle de specificerede datasæt.

Betinget behandling

OS forventer, at programmer indstiller en returkode, der specificerer, hvor vellykket programmet troede, det var. De mest almindelige konventionelle værdier er:

• 0 = Normal - alt i orden
• 4 = Advarsel - mindre fejl eller problemer
• 8 = Fejl - væsentlige fejl eller problemer
• 12 = Alvorlig fejl - store fejl eller problemer, resultaterne (f.eks. Producerede filer eller rapporter) bør ikke stole på.
• 16 = Terminalfejl - meget alvorlige problemer, brug ikke resultaterne!

OS JCL henviser til returkoden som COND ("betingelseskode") og kan bruge den til at beslutte, om de efterfølgende trin skal køres. Men i modsætning til de fleste moderne programmeringssprog udføres betingede trin i OS JCL ikke, hvis den angivne betingelse er sand - hvilket giver anledning til mnemonic , "Hvis det er sandt, skal du videresende [uden at køre koden]." For at komplicere forholdene yderligere kan betingelsen kun specificeres efter det trin, den henviser til. For eksempel:

//MYJOB JOB ...........
//STEP01 EXEC PGM=PROG01
....
//STEP02 EXEC PGM=PROG02,COND=(4,GT,STEP01)
....
//STEP03 EXEC PGM=PROG03,COND=(8,LE)
....
//STEP04 EXEC PGM=PROG04,COND=(ONLY,STEP01)
....
//STEP05 EXEC PGM=PROG05,COND=(EVEN,STEP03)
....

midler:

1. Kør STEP01 og indsaml returkoden.
2. Kør ikke, STEP02 hvis tallet 4 er større end STEP01 returkoden.
3. Kør ikke, STEP03 hvis tallet 8 er mindre end eller lig med en tidligere returkode.
4. Kør STEP04 kun hvis STEP01 unormalt sluttede.
5. Kør STEP05 , selvom STEP03 unormalt sluttede.

Dette oversættes til følgende pseudokode :

run STEP01
if STEP01's return code is greater than or equal to  4 then
    run STEP02
end if
if any previous return code is less than  8 then
    run STEP03
end if
if STEP01 abnormally ended then
    run STEP04
end if
if STEP03 abnormally ended then
    run STEP05
else
    run STEP05
end if

Bemærk, at man ved at læse de trin, der indeholder COND udsagn bagud, kan forstå dem ret let. Dette er et eksempel på logisk gennemførelse . Imidlertid introducerede IBM senere IF-betingelse i JCL, hvorved kodning blev lettere for programmører, mens COND parameteren blev bibeholdt (for at undgå at foretage ændringer i de eksisterende JCL'er, hvor de COND parm bruges).

Den COND parameter kan også angives på JOB erklæringen. I så fald udfører systemet "de samme returkodetests for hvert trin i et job. Hvis en JOB-sætning returkodetest er opfyldt, afsluttes jobbet."

Hjælpeprogrammer

Job bruger et antal IBM-hjælpeprogrammer til at hjælpe med behandlingen af ​​data. Hjælpeprogrammer er mest nyttige i batchbehandling. Hjælpeprogrammerne kan grupperes i tre sæt:

• Hjælpeprogrammer til datasæt - Opret, udskriv, kopier, flyt og slet datasæt.
• Systemværktøjer - Vedligehold og administrer kataloger og anden systeminformation.
• Access Method Services - Process Virtual Storage Access Method (VSAM) og ikke-VSAM datasæt.

Vanskeligheder ved brug

OS JCL er utvivlsomt kompleks og er blevet beskrevet som "brugerfiendtlig". Som en instruktionsbog om JCL spurgte: "Hvorfor tøver selv sofistikerede programmører, når det kommer til Job Control Language?" Bogen udtalte, at mange programmører enten kopierede kontrolkort uden virkelig at forstå, hvad de gjorde, eller "troede på de fremherskende rygter om, at JCL var forfærdelig, og kun 'die-hard' computertyper nogensinde forstod det" og gav opgaven med at finde ud af JCL-erklæringer til en anden. En sådan holdning kunne findes i programmeringsbøger, som foretrak at fokusere på selve sproget og ikke hvordan programmerne i det blev kørt. Som en Fortran IV- lærebog sagde, da han opregnede mulige fejlmeddelelser fra WATFOR- kompilatoren: "Har du været så tåbelig at prøve at skrive dine egne 'DD' systemkontrolkort? Stop og afstå straks; løb, gå ikke for hjælp. "

Ikke desto mindre understregede nogle bøger, der gik ind i JCL i detaljer, at når det først blev lært i mindst noget dygtig grad, fik man frihed fra standardindstillinger og meget bedre kontrol over, hvordan et IBM-system behandlede din arbejdsbyrde. En anden bog kommenterede kompleksiteten, men sagde: "tag hjertet. Den JCL-evne, du får fra [det foregående kapitel], er alt, hvad de fleste programmører nogensinde har brug for."

Sprog til kontrol af jobindtastning

På IBM-mainframesystemer er Job Entry Control Language eller JECL det sæt kommandosprogkontrolerklæringer , der giver information til spooling- undersystemet - JES2 eller JES3 på z / OS eller VSE / POWER til z / VSE . JECL-udsagn kan "specificere på hvilken netværkscomputer, jobbet skal køres , hvornår jobbet skal køres, og hvor det resulterende output skal sendes."

JECL adskiller sig fra jobkontrolsprog (JCL), som instruerer operativsystemet, hvordan jobbet køres.

Der er forskellige versioner af JECL til de tre miljøer.

OS / 360

En tidlig version af Job Entry Control Language til OS / 360 Remote Job Entry (programnummer 360S-RC-536) brugte identifikatoren ..   i kolonne 1–2 i inputposten   og bestod af en enkelt kontrolerklæring: JED (Job Entry Definition). "Workstation kommandoer" såsom LOGON , LOGOFF , og STATUS begyndte også med   ..  .

før JES JECL

Selv om udtrykket endnu ikke var blevet udviklet, havde HASP lignende funktionalitet som hvad der ville blive JECL for JES , herunder /* syntaks.

z / OS

For JES2 starter JECL-udsagn med /* , for JES3 starter de med //* undtagen fjernbetjening   /*SIGNON   og   /*SIGNOFF   kommandoer. Kommandoerne til de to systemer er helt forskellige.

JES2 JECL

Følgende JES2 JECL-udsagn bruges i z / OS 1.2.0.

JES3 JECL

Følgende JES3 JECL-udsagn bruges i z / OS 1.2.0

z / VSE

For VSE JECL-udsagn starter med ' * $$ ' (bemærk det enkelte mellemrum). Sprog for jobindtastning definerer start- og slutlinjerne for JCL-job. Det rådgiver VSE / POWER, hvordan dette job håndteres. JECL udsagn definere jobbet navn (bruges af VSE / POWER), den klasse, jobbet er behandlet, og dispositionen af jobbet (dvs. D , L , K , H ).

Eksempel:

* $$ JOB JNM=NAME,DISP=K,CLASS=2

[some JCL statements here]

* $$ EOJ

Andre systemer

Andre mainframe- batchsystemer havde en eller anden form for jobkontrolsprog, hvad enten det hedder det eller ej; deres syntaks var helt forskellig fra IBM-versioner, men de leverede normalt lignende muligheder. Interaktive systemer inkluderer " kommandosprog " - kommandofiler (såsom PCDOS ".bat" -filer) kan køres ikke-interaktivt, men disse giver normalt ikke et så robust miljø til at køre uovervågede job som JCL. På nogle computersystemer kan jobkontrolsproget og det interaktive kommandosprog være forskellige. For eksempel bruger TSO på z / OS-systemer CLIST eller Rexx som kommandosprog sammen med JCL til batcharbejde . På andre systemer kan disse være de samme.

Se også

• dd (Unix) , Unix-program inspireret af DD
• IBM mainframe-hjælpeprogrammer
• Batchbehandling
• Datasæt (IBM mainframe) #Generation Data Group

Referencer

Kilder

• "z / OS V1R6.0 MVS JCL Brugervejledning" (PDF) (5. udgave). IBM. September 2004.
• "z / OS V1R7.0 MVS JCL Reference" (PDF) (11. udgave). IBM. April 2006.
• Johnston, Jerry (1. april 2005). "VSE: Et kig på de sidste 40 år" . z / Journal . Thomas Communications. Arkiveret fra originalen den 4. marts 2009.
• "Computer Chronicles: 1972 - 1981" . ThinkQuest . Oracle Corporation . 1998. Arkiveret fra originalen den 21. juni 2009.
• DeWard Brown, Gary (7. juni 2002). zOS JCL (5. udgave). Wiley. ISBN   978-0-471-23635-1 .
• "JCL Statement Fields" . z / OS V1R11.0 MVS JCL Reference z / OS V1R10.0-V1R11.0 . IBM. 2010.
• IBM Corporation (marts 2007). Introduktion til den nye mainframe: z / VSE Basics (PDF) . ISBN   978-0-73-848624-6 . Hentet 06-12-2017 .
• Ashley, Ruth; Fernandez, Judi N. (1978). Jobkontrolsprog: En selvlæringsvejledning . New York: John Wiley & Sons. ISBN   0-471-03205-0 .
• McQuillen, Kevin (1975). System / 360–370 Assembler Language (OS) . Fresno, Californien: Mike Murach & Associates. LCCN   74-29645 .
• Stern, Nancy; Stern, Robert A. (1980). Structured COBOL Programming (3. udgave). New York: John Wiley & Sons. ISBN   0-471-04913-1 .