Jobbkontroll språk - Job Control Language

Job Control Language ( JCL ) er et navn for skriptspråk som brukes på IBM-hovedrammesystemer for å instruere systemet om hvordan du kjører en batchjobb eller starter et delsystem.

Mer spesifikt er formålet med JCL å si hvilke programmer som skal kjøres, bruke hvilke filer eller enheter for inndata eller utdata, og til tider å også indikere under hvilke forhold å hoppe over et trinn.

Det er to forskjellige IBM Job Control-språk:

• en for operativsystemlinjen som begynner med DOS / 360 og hvis siste medlem er z / VSE ; og
• den andre for linjen fra OS / 360 til z / OS , den siste inkluderer nå JES- utvidelser, Job Entry Control Language (JECL) .

De deler noen grunnleggende syntaksregler og noen få grunnleggende konsepter, men er ellers veldig forskjellige. Den VM operativsystem ikke har JCL som sådan; de CP og CMS komponenter har hver kommando språk .

Terminologi

Enkelte ord eller uttrykk som brukes i forbindelse med JCL, er spesifikke for IBM mainframe-teknologi.

• Datasett: et "datasett" er en fil; det kan være midlertidig eller permanent, og ligger på en diskstasjon, båndlagring eller annen enhet.
• Medlem: et "medlem" av et partisjonert datasett (PDS) er et individuelt datasett i et PDS. Et medlem kan nås ved å spesifisere navnet på PDS med medlemsnavnet i parentes. For eksempel kan systemmakroen GETMAIN i SYS1.MACLIB refereres til som SYS1.MACLIB (GETMAIN).
• Partisjonert datasett: et "partisjonert datasett" eller PDS er samling av medlemmer, eller arkiv, som vanligvis brukes til å representere systembiblioteker. Som med de fleste slike strukturer, kan et medlem, når det er lagret, ikke oppdateres; medlemmet må slettes og erstattes, for eksempel med IEBUPDTE- verktøyet. Partisjonerte datasett er omtrent analoge med ar-baserte statiske biblioteker i Unix-baserte systemer.
• USS: Unix-systemtjenester, et Unix-delsystem som kjører som en del av MVS, og lar Unix-filer, skript, oppgaver og programmer kjøre på en hovedramme i et UNIX-miljø.

Motivasjon

Opprinnelig var hovedrammesystemene orientert mot batchbehandling . Mange batchjobber krever oppsett, med spesifikke krav til hovedlagring , og dedikerte enheter som magnetbånd , private diskvolumer og skrivere konfigurert med spesielle skjemaer. JCL ble utviklet som et middel for å sikre at alle nødvendige ressurser er tilgjengelige før en jobb er planlagt å kjøre. For eksempel tillater mange systemer, for eksempel Linux, å identifisere nødvendige datasett som skal spesifiseres på kommandolinjen , og derfor er underlagt erstatning av skallet , eller genereres av programmet på kjøretid. På disse systemene har jobbplanleggeren av operativsystemet liten eller ingen anelse om kravene til jobben. I kontrast spesifiserer JCL eksplisitt alle nødvendige datasett og enheter. Planleggeren kan forhåndsallokere ressursene før jobben slippes. Dette hjelper til med å unngå " fastlåst ", der jobb A holder ressurs R1 og ber om ressurs R2, mens samtidig kjører jobb B holder ressurs R2 og ber R1. I slike tilfeller er den eneste løsningen at datamaskinoperatøren avslutter en av jobbene, som deretter må startes på nytt. Med jobbkontroll, hvis jobb A er planlagt å kjøre, vil ikke jobb B startes før jobb A fullfører eller frigjør de nødvendige ressursene.

Funksjoner som er felles for DOS og OS JCL

Jobber, trinn og prosedyrer

For både DOS og OS er arbeidsenheten jobben . En jobb består av ett eller flere trinn, som hver er en forespørsel om å kjøre ett bestemt program. For eksempel, før dagene med relasjonsdatabaser , kan en jobb med å produsere en utskrevet rapport for ledelsen bestå av følgende trinn: et brukerskrevet program for å velge de aktuelle postene og kopiere dem til en midlertidig fil; sorter den midlertidige filen i ønsket rekkefølge, vanligvis ved hjelp av et universalverktøy; et brukerskrevet program for å presentere informasjonen på en måte som er lett for sluttbrukerne å lese og inkluderer annen nyttig informasjon, for eksempel delsummier; og et brukerskrevet program for å formatere utvalgte sider av sluttbrukerinformasjonen for visning på en skjerm eller terminal.

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

• Identifiserer jobben.
• Gir vanligvis informasjon som gjør det mulig for datatjenesteavdelingen å fakturere riktig brukeravdeling.
• Definerer hvordan jobben som helhet skal kjøres, f.eks. Dens prioritet i forhold til andre jobber i køen.

Prosedyrer (ofte kalt procs ) er forhåndsskrevet JCL for trinn eller grupper av trinn, satt inn i en jobb. Begge JCL-ene tillater slike prosedyrer. Procs brukes til å gjenta trinn som brukes flere ganger i en jobb, eller i flere forskjellige jobber. De sparer programmerer tid og reduserer risikoen for feil. For å kjøre en prosedyre inkluderer man ganske enkelt et enkelt "kort" i JCL-filen som kopierer prosedyren fra en spesifisert fil, og setter den inn i jobbstrømmen. Procs kan også inkludere parametere for å tilpasse prosedyren for hver bruk.

Grunnleggende syntaks

Både DOS og OS JCL har en maksimal brukbar linjelengde på 80 tegn, for når DOS / 360 og OS / 360 først ble brukt, var hovedmetoden for å gi nye innganger til et datasystem 80-kolonnestansede kort . Det ble senere mulig å sende jobber via disk- eller båndfiler med lengre opptakslengder, men operativsystemets jobbinnleveringskomponenter ignorerte alt etter tegn 80.

Strengt tatt bruker begge operativsystemfamiliene bare 71 tegn per linje. Tegn 73-80 er vanligvis kortsekvensnumre som systemet skrev ut på sluttresultatrapporten og er nyttige for å identifisere plasseringen av eventuelle feil rapportert av operativsystemet. Tegn 72 er vanligvis tomt, men det kan inneholde et tegn som ikke er tomt for å indikere at JCL-setningen fortsetter til neste kort.

Alle kommandoer, parameternavn og verdier må være med store bokstaver, bortsett fra USS- filnavn.

Alle linjer bortsett fra in-stream-inngang (se nedenfor) må begynne med en skråstrek " / ", og alle linjene som operativsystemet behandler må begynne med to skråstreker // - begynner alltid i den første kolonnen . Imidlertid er det to unntak: avgrensningsuttalelsen og kommentaruttalelsen. En skillesetning begynner med en skråstrek og en stjerne ( /* ), og en kommentarsetning i OS JCL begynner med et par skråstreker og en stjerne ( //* ) eller en stjerne i DOS JCL.

Mange JCL-utsagn er for lange til å passe i løpet av 71 tegn, men kan utvides til et ubestemt antall fortsettelseskort ved å:

Strukturen til de vanligste korttypene er:

In-stream-inngang

DOS og OS JCL tillater begge in-stream-inngang, dvs. "kort" som skal behandles av applikasjonsprogrammet i stedet for operativsystemet. Data som skal oppbevares i lang tid vil normalt lagres på disken, men før bruk av interaktive terminaler ble vanlig var den eneste måten å opprette og redigere slike diskfiler på ved å levere de nye dataene på kortene.

DOS og OS JCL har forskjellige måter å signalisere starten på in-stream-inngang, men begge ender in-stream-inngang med /* i kolonne 1 på kortet etter det siste in-stream-datakortet. Dette gjør at operativsystemet gjenopptar behandlingen av JCL på kortet som følger /* kortet.

• OS JCL: DD-setninger kan brukes til å beskrive in-stream-data, samt datasett. En DD-setning som behandler in-stream-data har en stjerne (*) som følger DD-identifikatoren, f.eks //SYSIN DD * . JCL-setninger kan inkluderes som en del av in-stream-data ved å bruke DD DATA-setningene.

En operand med navnet DLM tillot å spesifisere en skilletegn (standard er "/ *"). Ved å spesifisere en alternativ skilletegn kan JCL leses som data, for eksempel for å kopiere prosedyrer til et biblioteksmedlem eller for å sende en jobb til den interne leseren .

• Et eksempel som sender en jobb til den interne leseren ( 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 vente (TYPRUN = HOLD) som slippes manuelt
2. To filer, PICALC.4DGTS og PICALC.5DGTS, slettes NÅ.

• DOS JCL: Bare skriv inn in-stream-data etter EXEC-kortet for programmet.

Kompleksitet

Mye av kompleksiteten til OS JCL kommer spesielt fra det store antallet alternativer for å spesifisere datasettinformasjon . Mens filer på Unix- lignende operativsystemer trekkes ut i vilkårlige bytesamlinger, med detaljene som i stor grad håndteres av operativsystemet, utsetter datasett på OS / 360 og dens etterfølgere filtyper og størrelser, opptakstyper og lengder, blokkstørrelser , enhetsspesifikk informasjon som magnetbåndtetthet og etikettinformasjon. Selv om det er standardverdier for mange alternativer, er det fortsatt mye å spesifisere av programmereren, gjennom en kombinasjon av JCL og informasjon kodet i programmet. Jo mer informasjon kodet i programmet, desto mindre fleksibel er det, siden informasjon i programmet overstyrer alt i JCL; dermed blir mest informasjon vanligvis levert gjennom JCL.

For eksempel, for å kopiere en fil på Unix- operativsystemet, vil brukeren skrive inn en kommando som:

cp oldFile newFile

Følgende eksempel, som bruker JCL, kan brukes til å 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 annen forklaring på kompleksiteten til JCL er de forskjellige forventningene til å kjøre en jobb fra de som finnes i en PC eller et Unix-lignende miljø.

• Low-end System / 360-prosessorer var mindre kraftige og dyrere enn midten av 1980-tallet PC-er som MS-DOS ble designet for. OS / 360 var ment for systemer med minimum minnestørrelse på 32 KB og DOS / 360 for systemer med minimum 16 KB. En 360/30 CPU - low-end da System / 360 ble kunngjort i 1964 - behandlet 1,8K til 34,5K instruksjoner per sekund. Den første IBM-PCen i 1981 hadde 16 KB eller 64 KB minne og ville behandle rundt 330K instruksjoner per sekund. Som et resultat måtte JCL være enkelt for datamaskinen å behandle, og brukervennlighet for programmerere var en mye lavere prioritet. I denne tiden var programmerere mye billigere enn datamaskiner.
• JCL ble designet for batchbehandling . Som sådan må den fortelle operativsystemet alt, inkludert hva du skal gjøre, avhengig av resultatet av et trinn. For eksempel DISP=(NEW,CATLG,DELETE) betyr "hvis programmet kjører vellykket, opprett en ny fil og katalogiser den, ellers slett den nye filen." Programmer som kjøres på en PC, er ofte avhengig av at brukeren rydder opp etter behandlingsproblemer.
• System / 360-maskiner ble designet for å deles av alle brukerne i en organisasjon. Så JOB kortet forteller operativsystemet hvordan fakturering av brukerens konto ( IS198T30500 ), hvilken forhåndsdefinert mengde lagring og andre ressurser som kan tildeles ( CLASS=L ), og flere andre ting. //SYSPRINT DD SYSOUT=* forteller datamaskinen til å skrive programmet rapport om standardskriver som er lastet med vanlig papir, ikke på noen annen skriver som kan være lastet med blanke sjekker. DISP=SHR forteller operativsystemet at andre programmer kan lese OLDFILE samtidig .

Senere versjoner av DOS / 360- og OS / 360-operativsystemene beholder de fleste funksjonene i den originale JCL - selv om det er gjort noen forenkling, for å unngå å tvinge kunder til å omskrive alle JCL-filene sine. Mange brukere lagrer som en prosedyre ethvert sett med JCL-utsagn som sannsynligvis vil bli brukt mer enn en eller to ganger.

Syntaksen til OS JCL er lik syntaksen til makroer i System / 360- monteringsspråket , og ville derfor vært kjent for programmerere i en tid da mange programmer ble kodet i monteringsspråk.

DOS JCL

Posisjonsparametere

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

DOS JCL-parametere er posisjonelle, noe som gjør dem vanskeligere å lese og skrive, men enklere for systemet å analysere.

• Programmereren må huske hvilket element som går i hvilken posisjon i alle typer utsagn.
• Hvis noen valgfrie parametere er utelatt, men senere er inkludert, må de utelatte parametrene være representert med komma uten mellomrom, som i TLBL-setningen ovenfor.

DOS JCL demper til en viss grad vanskelighetene med posisjonsparametere ved å bruke flere utsagn med færre parametere enn OS JCL. I eksemplet gjør ASSGN-, DLBL- og EXTENT-setningene det samme arbeidet (spesifiserer hvor en ny diskfil skal lagres) som en enkelt DD setning i OS JCL.

Enhetsavhengighet

I den opprinnelige DOS / 360 og i de fleste versjoner av DOS / VS måtte man spesifisere modellnummeret på enheten som skulle brukes for hver disk eller båndfil - til og med for eksisterende filer og for midlertidige filer som ville bli slettet på slutten av jobben. Dette betydde at hvis en kunde oppgraderte til mer moderne utstyr, måtte mange JCL-filer endres.

Senere medlemmer av DOS / 360-familien reduserte antall situasjoner der enhetsmodellnummer var påkrevd.

Manuell tildeling av filer

DOS / 360 krevde opprinnelig at programmereren spesifiser plassering og størrelse på alle filene på DASD . Den EXTENT kort angir volumet på hvilken den grad det ligger, og utgangs absolutte spor, og antallet spor. For z / VSE kan en fil ha opptil 256 utvidelser på forskjellige volumer.

OS JCL

OS JCL består av tre grunnleggende utsagnstyper:

• JOB uttalelse, som identifiserer start på jobben, og informasjon om hele jobben, for eksempel fakturering, prioritet og tids- og plassgrenser.
• EXEC uttalelse, som identifiserer programmet eller prosedyren som skal utføres i dette trinnet i jobben,
  og informasjon om trinnet, inkludert COND- anvisninger for å kjøre eller hoppe over et trinn.
• DD (Data Definition) uttalelser, som identifiserer en datafil som skal brukes i et trinn, og detaljert informasjon om den filen. DD uttalelser kan være i hvilken som helst rekkefølge innenfor trinnet.

Helt fra starten var JCL for OS-familien (til og med z / OS ) mer fleksibel og enklere å bruke.

Følgende eksempler bruker den gamle syntaksstil som ble gitt rett fra lanseringen av System / 360 i 1964. Den gamle syntaksen er fremdeles ganske vanlig i jobber som har kjørt i flere tiår med bare mindre endringer.

Regler for koding av JCL-uttalelser

Hver JCL-uttalelse er delt inn i fem felt:

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

Identifier-felt skal sammenkobles med Name-Field , dvs. det skal ikke være mellomrom mellom dem.

• Identifier-felt ( // ): Identifikasjonsfeltet indikerer for systemet at en uttalelse er en JCL-setning i stedet for data. Identifikasjonsfeltet består av følgende:
  • Kolonne 1 og 2 i alle JCL-setninger, unntatt skilletegn, inneholder //
  • Kolonne 1 og 2 i avgrensingsuttalelsen inneholder /*
  • Kolonnene 1, 2 og 3 i en JCL-kommentarsetning inneholder //*
• Navnefelt : Navnefeltet identifiserer en bestemt setning slik at andre utsagn og systemet kan henvise til den. For JCL-uttalelser bør den kodes som følger:
  • Navnet må begynne i kolonne 3.
  • Navnet er 1 til 8 alfanumeriske eller nasjonal ( $ , # , @ ) tegn.
  • Den første karakteren må være alfabetisk.
  • Navnet må følges av minst ett tomt.
• Operasjonsfelt : Operasjonsfeltet spesifiserer typen utsagn, eller, for kommandosetningen, kommandoen. Operasjonsfeltet skal kodes som følger:
  • Operasjonsfeltet består av tegnene i syntaksboksen for utsagnet.
  • Operasjonen følger navnefeltet.
  • Operasjonen må innledes og etterfølges av minst ett tomt.
  • Operasjonen vil være en av JOB , EXEC og DD .
• Parameterfelt : Parameterfeltet, også noen ganger referert til som operandfeltet, inneholder parametere atskilt med komma. Parameterfeltet skal kodes som følger:
  • Parameterfeltet følger operasjonsfeltet.
  • Parameterfeltet må innledes med minst ett tomt.
  • Parameterfeltet inneholder parametere som er nøkkelord som brukes i setningen for å gi informasjon som program- eller datasettnavnet.
• Kommentarfelt : Dette inneholder kommentarer . Kommentarfelt skal kodes som følger:
  • Kommentarfeltet følger parameterfeltet.
  • Kommentarfeltet må innledes med minst ett tomt.

Nøkkelordsparametere

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

Alle hovedparametrene i OS JCL-setninger identifiseres ved hjelp av nøkkelord og kan presenteres i hvilken som helst rekkefølge. Noen få av disse inneholder to eller flere underparametere, for eksempel SPACE (hvor mye diskplass som skal tildeles til en ny fil) og DCB (detaljert spesifikasjon av filens layout) i eksemplet ovenfor. Underparametere er noen ganger posisjonelle, som i SPACE , men de mest komplekse parametrene, for eksempel DCB , har søkeordsparametre.

Posisjonsparameter må gå foran søkeordparametere. Nøkkelordsparametere tilordner alltid verdier til et nøkkelord ved hjelp av likhetstegnet ( = ).

Datatilgang (DD-setning)

Den DD setningen brukes til referansedata. Denne uttalelsen knytter et programs interne beskrivelse av et datasett til dataene på eksterne enheter: disker, kassetter, kort, skrivere osv. DD kan gi informasjon som en enhetstype (f.eks. '181', '2400-5', ' TAPE '), et volum serienummer for bånd eller disker, og beskrivelsen av datafilen, kalt DCB underparameter etter Data Control Block (DCB) i programmet som brukes til å identifisere filen.

Informasjon som beskriver filen kan komme fra tre kilder: DD-kortinformasjonen, datasettetikettinformasjonen for en eksisterende fil lagret på bånd eller disk, og DCB-makroen som er kodet i programmet. Når filen åpnes, blir disse dataene slått sammen, med DD-informasjonen som går foran etikettinformasjonen, og DCB-informasjonen har forrang over begge. Den oppdaterte beskrivelsen blir deretter skrevet tilbake til datasettetiketten. Dette kan føre til utilsiktede konsekvenser hvis feil DCB-informasjon blir gitt.

På grunn av parametrene som er oppført ovenfor og spesifikk informasjon for ulike tilgangsmetoder og enheter, er DD-setningen den mest komplekse JCL-setningen. I en IBM referansehåndbok inneholder beskrivelsen av DD-setningen over 130 sider - mer enn dobbelt så mye som JOB- og EXEC-setningene til sammen.

Enhetsuavhengighet

Helt fra begynnelsen tilbød JCL for operativsystemfamilien en høy grad av enhetsuavhengighet. Selv for nye filer som skulle holdes etter utløpet av den jobben man kunne spesifisere enhetstypen i generelle termer, for eksempel UNIT=DISK , UNIT=TAPE eller UNIT=SYSSQ (tape eller disk). Selvfølgelig, hvis det gjaldt, kunne man spesifisere et modellnummer eller til og med en spesifikk enhetsadresse.

Prosedyrer

Prosedyrer tillater gruppering av en eller flere " EXEC PGM = " og DD- setninger og deretter påkalling av dem med " EXEC PROC = procname" -eller bare "EXEC procname"

Et anlegg kalt Procedure Library tillot prosedyrer for lagring.

PROC & PEND

Prosedyrer kan også inkluderes i jobbstrømmen ved å avslutte prosedyren med en // PEND uttalelse, og deretter påkalle den ved navn det samme var som om det var i et prosedyrebibliotek.

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

Parameteriserte prosedyrer

OS JCL-prosedyrer ble parametrisert fra begynnelsen, noe som gjorde dem til som makroer eller til og med enkle underrutiner, og dermed økte gjenbrukbarheten i en rekke situasjoner.

//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 eksemplet er alle verdiene som begynner med tegn " & " parametere som vil bli spesifisert når en jobb ber om at prosedyren skal brukes. PROC-setningen, i tillegg til å gi prosedyren et navn, lar programmereren også spesifisere standardverdier for hver parameter. Så man kan bruke den ene prosedyren i dette eksemplet for å lage nye filer i mange forskjellige størrelser og oppsett. 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 flertrinnsjobber kan et senere trinn bruke en tilbakeringing i stedet for å spesifisere en fil som allerede er spesifisert i et tidligere trinn. 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 bruker filen som ble identifisert som NEWFILE i trinn MYPR01 ( DSN betyr "datasettnavn" og spesifiserer navnet på filen. DSN kan ikke overstige 44 tegn).

I jobber som inneholder en blanding av jobbspesifikk JCL og prosedyreanrop, kan et jobbspesifikt trinn referere til en fil som ble spesifisert i en prosedyre, 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 betyr "bruk filen som er identifisert som NEWFILE i trinn MYPR01 i prosedyren som brukes trinn STEP01 for denne jobben". Ved å bruke navnet på trinnet som kalte prosedyren i stedet for navnet på prosedyren, kan en programmerer bruke den samme prosedyren flere ganger i den samme jobben uten forvirring om hvilken forekomst av prosedyren som brukes i referansen.

Kommentarer

JCL-filer kan være lange og komplekse, og språket er ikke lett å lese. OS JCL lar programmerere inkludere to typer forklarende kommentarer:

• På samme linje som en JCL-uttalelse. De kan utvides ved å plassere et fortsettelsestegn (konvensjonelt " X ") i kolonne 72, etterfulgt av " // " i kolonne 1–3 i neste linje.
• Linjer som bare inneholder kommentarer, ofte brukt til å forklare viktige punkter om den generelle strukturen til JCL i stedet for lokale detaljer. Bare kommentarer-linjer brukes også til å dele lange, komplekse JCL-filer i seksjoner.

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

Sammenkobling av inndatafiler

OS JCL lar programmerere sammenkoble ("chain") inndatafiler slik at de ser ut til programmet som en fil, for eksempel

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

Den andre og tredje setningen har ingen verdi i navnefeltet, så OS behandler dem som sammenkoblinger. Filene må være av samme grunnleggende type (nesten alltid sekvensielle) og må ha samme postlengde, men blokklengden trenger ikke være den samme.

I tidlige versjoner av operativsystemet (absolutt før OS / 360 R21.8) må blokklengden være i avtagende rekkefølge, eller brukeren må inspisere hver forekomst og legge til den navngitte DD-setningen den maksimale blokkeringslengden som er funnet, som for eksempel ,

//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 versjoner av operativsystemet (absolutt etter OS / MVS R3.7 med de riktige "valgbare enhetene") vil operativsystemet selv, under tildelingen, inspisere hver forekomst i en sammenkobling og erstatte den maksimale blokklengden som ble funnet.

En vanlig tilbakeslag var å bare bestemme den maksimale mulige blokkeringslengden på enheten, og spesifisere at på den navngitte DD-setningen, som i for eksempel

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

Hensikten med denne tilbakeslaget var å sikre at tilgangsmetoden ville tildele et inndatabuffersett som var stort nok til å imøtekomme alle og alle de spesifiserte datasettene.

Betinget behandling

OS forventer at programmene setter en returkode som spesifiserer hvor vellykket programmet trodde det var. De vanligste konvensjonelle verdiene er:

• 0 = Normal - alt OK
• 4 = Advarsel - mindre feil eller problemer
• 8 = Feil - betydelige feil eller problemer
• 12 = Alvorlig feil - store feil eller problemer, resultatene (f.eks. Produserte filer eller rapporter) skal ikke stole på.
• 16 = Terminalfeil - veldig alvorlige problemer, ikke bruk resultatene!

OS JCL refererer til returkoden som COND ("tilstandskode"), og kan bruke den til å bestemme om de vil kjøre påfølgende trinn. Imidlertid, i motsetning til de fleste moderne programmeringsspråk, utføres ikke betingede trinn i OS JCL hvis den spesifiserte tilstanden er sant - og dermed oppstår mnemonikken : "Hvis det er sant, gå videre [uten å kjøre koden]." For å komplisere saken ytterligere kan tilstanden bare spesifiseres etter trinnet 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. Kjør STEP01 , og samle returkoden.
2. Ikke kjør STEP02 hvis tallet 4 er større enn STEP01 returkoden.
3. Ikke kjør STEP03 hvis tallet 8 er mindre enn eller lik en tidligere returkode.
4. Kjør STEP04 bare hvis STEP01 unormalt avsluttet.
5. Løp STEP05 , selv om det ble STEP03 unormalt avsluttet.

Dette oversettes 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

Merk at ved å lese trinnene som inneholder COND utsagn bakover, kan man forstå dem ganske enkelt. Dette er et eksempel på logisk transponering . Imidlertid introduserte IBM senere IF-tilstand i JCL, noe som gjør kodingen noe enklere for programmerere mens de beholder COND parameteren (for å unngå å gjøre endringer i eksisterende JCL-er der de COND parm brukes).

Den COND Parameteren kan også angis på JOB setningen. I så fall utfører systemet "de samme returkodetestene for hvert trinn i en jobb. Hvis en JOB-uttalelsestestkodetest er oppfylt, avsluttes jobben."

Verktøy

Jobber bruker en rekke IBM-verktøy for å hjelpe deg med behandlingen av data. Verktøy er mest nyttige i batchbehandling. Verktøyene kan grupperes i tre sett:

• Verktøy for datasett - Opprett, skriv ut, kopier, flytt og slett datasett.
• Systemverktøy - Vedlikehold og administrer kataloger og annen systeminformasjon.
• Access Method Services - Prosess Virtual Storage Access Method (VSAM) og ikke-VSAM datasett.

Vanskeligheter med bruk

OS JCL er unektelig kompleks og har blitt beskrevet som "brukerfiendtlig". Som en instruksjonsbok om JCL spurte: "Hvorfor nøler til og med sofistikerte programmerere når det gjelder jobbkontrollspråk?" Boken uttalte at mange programmerere enten kopierte kontrollkort uten egentlig å forstå hva de gjorde, eller "trodde de utbredte ryktene om at JCL var fryktelig, og bare" harde "datatyper noen gang forsto det" og ga oppgaven med å finne ut JCL uttalelser til noen andre. En slik holdning fantes i lærebøker for programmeringsspråk, som foretrakk å fokusere på språket i seg selv og ikke hvordan programmene i det ble kjørt. Som en Fortran IV- lærebok sa da han oppførte mulige feilmeldinger fra WATFOR- kompilatoren: "Har du vært så tåpelig at du prøver å skrive dine egne 'DD' systemkontrollkort? Opphør og avslutt straks; løp, ikke gå, for å få hjelp. "

Likevel understreket noen bøker som gikk inn i JCL i detalj at når man først hadde lært det i det minste noe dyktig grad, fikk man frihet fra standardinnstillinger og mye bedre kontroll over hvordan et IBM-system behandlet arbeidsmengden. En annen bok kommenterte kompleksiteten, men sa: "vær hjertelig. JCL-evnen du får fra [forrige kapittel] er alt det som de fleste programmerere trenger."

Språk for jobboppføringskontroll

På IBM stormaskiner Job Entry Control Language eller JECL er sett av kommandospråkkontrollsetninger som gir informasjon for spoling delsystem - JES2 eller JES3 på z / OS eller VSE / POWER for z / VSE . JECL-utsagn kan "spesifisere på hvilken nettverksdatamaskin du skal kjøre jobben , når du skal kjøre jobben, og hvor du skal sende den resulterende utgangen."

JECL er forskjellig fra jobbkontroll språk (JCL), som instruerer operativsystemet hvordan å kjøre jobben.

Det finnes forskjellige versjoner av JECL for de tre miljøene.

OS / 360

En tidlig versjon av Job Entry Control Language for OS / 360 Remote Job Entry (Programnummer 360S-RC-536) brukte identifikatoren   ..   i kolonnene 1–2 i inngangsposten og besto av en enkelt kontrolluttalelse: JED (Job Entry Definition). "Workstation kommandoer" som LOGON , LOGOFF og STATUS begynte også med   ..  .

før JES JECL

Selv om begrepet ennå ikke hadde blitt utviklet, hadde HASP lignende funksjonalitet som det som skulle bli JESL til JES , inkludert /* syntaksen.

z / OS

For JES2 begynner JECL-uttalelser med /* , for JES3 begynner de med //* , bortsett fra fjernkontroll   /*SIGNON   og   /*SIGNOFF   kommandoer. Kommandoene for de to systemene er helt forskjellige.

JES2 JECL

Følgende JES2 JECL-setninger brukes i z / OS 1.2.0.

JES3 JECL

Følgende JES3 JECL-setninger brukes i z / OS 1.2.0

z / VSE

For VSE JECL-utsagn begynner med ' * $$ ' (merk enkeltrommet ). Jobbinnføringskontrollspråk definerer start- og sluttlinjene til JCL-jobber. Den gir råd om VSE / POWER hvordan denne jobben håndteres. JECL påstander definere navnet på jobben (brukt av VSE / STRØM), den klassen som jobben behandles, og anordningen av jobben (dvs. D , L , K , H ).

Eksempel:

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

[some JCL statements here]

* $$ EOJ

Andre systemer

Andre stormaskin batch -systemer hadde noen form for jobbkontroll språk både kalles det eller ikke; deres syntaks var helt forskjellig fra IBM-versjoner, men de ga vanligvis lignende muligheter. Interaktive systemer inkluderer " kommandospråk " - kommandofiler (for eksempel PCDOS ".bat" -filer) kan kjøres ikke-interaktivt, men disse gir vanligvis ikke et så robust miljø for å kjøre uten tilsyn som JCL. På noen datasystemer kan jobbkontrollspråket og det interaktive kommandospråket være forskjellige. For eksempel bruker TSO på z / OS-systemer CLIST eller Rexx som kommandospråk sammen med JCL for batch-arbeid. På andre systemer kan disse være de samme.

Se også

• dd (Unix) , Unix-program inspirert av DD
• IBM mainframe-verktøyprogrammer
• Batchbehandling
• Datasett (IBM mainframe) #Generation Data Group

Referanser

Kilder

• "z / OS V1R6.0 MVS JCL User's Guide" (PDF) (5. utg.). IBM. September 2004.
• "z / OS V1R7.0 MVS JCL Reference" (PDF) (11. utgave). IBM. April 2006.
• Johnston, Jerry (1. april 2005). "VSE: A Look on the Past 40 Years" . z / Journal . Thomas Communications. Arkivert fra originalen 4. mars 2009.
• "Computer Chronicles: 1972 - 1981" . ThinkQuest . Oracle Corporation . 1998. Arkivert fra originalen 21. juni 2009.
• DeWard Brown, Gary (7. juni 2002). zOS JCL (5. utgave). Wiley. ISBN   978-0-471-23635-1 .
• "JCL Statement Fields" . z / OS V1R11.0 MVS JCL Referanse z / OS V1R10.0-V1R11.0 . IBM. 2010.
• IBM Corporation (mars 2007). Introduksjon til den nye hovedrammen: z / VSE Basics (PDF) . ISBN   978-0-73-848624-6 . Hentet 06.12.2017 .
• Ashley, Ruth; Fernandez, Judi N. (1978). Jobbkontrollspråk: En selvlæringsguide . New York: John Wiley & Sons. ISBN   0-471-03205-0 .
• McQuillen, Kevin (1975). System / 360–370 Assembler Language (OS) . Fresno, California: Mike Murach & Associates. LCCN   74-29645 .
• Stern, Nancy; Stern, Robert A. (1980). Structured COBOL Programming (3. utg.). New York: John Wiley & Sons. ISBN   0-471-04913-1 .