Job Control Language


Job Control Language is a name for scripting languages used on IBM mainframe operating systems to instruct the system on how to run a batch job or start a subsystem.
More specifically, the purpose of JCL is to say which programs to run, using which files or devices for input or output, and at times to also indicate under what conditions to skip a step.
There are two distinct IBM Job Control languages:
They share some basic syntax rules and a few basic concepts, but are otherwise very different. The VM operating system does not have JCL as such; the CP and CMS components each have command languages.

Terminology

Certain words or phrases used in conjunction to JCL are specific to IBM mainframe technology.
Originally, mainframe systems were oriented toward batch processing. Many batch jobs require setup, with specific requirements for main storage, and dedicated devices such as magnetic tapes, private disk volumes, and printers set up with special forms. JCL was developed as a means of ensuring that all required resources are available before a job is scheduled to run. For example, many systems, such as Linux allow identification of required datasets to be specified on the command line, and therefore subject to substitution by the shell, or generated by the program at run-time. On these systems the operating system job scheduler has little or no idea of the requirements of the job. In contrast, JCL explicitly specifies all required datasets and devices. The scheduler can pre-allocate the resources prior to releasing the job to run. This helps to avoid "deadlock", where job A holds resource R1 and requests resource R2, while concurrently running job B holds resource R2 and requests R1. In such cases the only solution is for the computer operator to terminate one of the jobs, which then needs to be restarted. With job control, if job A is scheduled to run job B will not be started until job A completes or releases the required resources.

Features common to DOS and OS JCL

Jobs, steps and procedures

For both DOS and OS the unit of work is the job. A job consists of one or several steps, each of which is a request to run one specific program. For example, before the days of relational databases, a job to produce a printed report for management might consist of the following steps: a user-written program to select the appropriate records and copy them to a temporary file; sort the temporary file into the required order, usually using a general-purpose utility; a user-written program to present the information in a way that is easy for the end-users to read and includes other useful information such as sub-totals; and a user-written program to format selected pages of the end-user information for display on a monitor or terminal.
In both DOS and OS JCL the first "card" must be the JOB card, which:
Procedures are pre-written JCL for steps or groups of steps, inserted into a job. Both JCLs allow such procedures. Procs are used for repeating steps which are used several times in one job, or in several different jobs. They save programmer time and reduce the risk of errors. To run a procedure one simply includes in the JCL file a single "card" which copies the procedure from a specified file, and inserts it into the jobstream. Also, procs can include parameters to customize the procedure for each use.

Basic syntax

Both DOS and OS JCL have a maximum usable line length of 80 characters, because when DOS/360 and OS/360 were first used the main method of providing new input to a computer system was 80-column punched cards. It later became possible to submit jobs via disk or tape files with longer record lengths, but the operating system's job submission components ignored everything after character 80.
Strictly speaking both operating system families use only 71 characters per line. Characters 73-80 are usually card sequence numbers which the system printed on the end-of-job report and are useful for identifying the locations of any errors reported by the operating system. Character 72 is usually left blank, but it can contain a nonblank character to indicate that the JCL statement is continued onto the next card.
All commands, parameter names and values have to be in capitals, except for USS filenames.
All lines except for in-stream input have to begin with a slash "/", and all lines which the operating system processes have to begin with two slashes // - always starting in the first column. However, there are two exceptions: the delimiter statement and the comment statement. A delimiter statements begins with a slash and an asterisk, and a comment statement in OS JCL begins with a pair of slashes and asterisk or an asterisk in DOS JCL.
Many JCL statements are too long to fit within 71 characters, but can be extended on to an indefinite number of continuation cards by:
OS JCLDOS JCL
Ending all actual JCL cards except the last at a point where the syntax requires a comma Ending all actual JCL cards except the last at a point where the syntax requires a comma and a non-blank character in column 72
Starting each continuation card with // in column 1 and then at least 1 spaceStarting each continuation card with spaces and continuing in column 15

The structure of the most common types of card is:
OS JCLDOS JCL

  • //
  • Name field for this statement, following // with no space between. If this statement does not have a name at least one blank immediately follows the //.
  • Space
  • Statement type
  • Space
  • Parameters, which vary depending on the statement type, separated by commas and with no space between them.
  • //
  • Statement type for this statement, following // with a space between.
  • Space
  • Name of resource
  • Space
  • Parameters, which vary depending on the statement type, separated by commas and with no space between them. Positional parameters, followed by keyword parameters.

    • In-stream input

    DOS and OS JCL both allow in-stream input, i.e. "cards" which are to be processed by the application program rather than the operating system. Data which is to be kept for a long time will normally be stored on disk, but before the use of interactive terminals became common the only way to create and edit such disk files was by supplying the new data on cards.
    DOS and OS JCL have different ways of signaling the start of in-stream input, but both end in-stream input with /* at column 1 of the card following the last in-stream data card. This makes the operating system resume processing JCL in the card following the /* card.

    //SUBM EXEC PGM=IEBGENER
    //SYSPRINT DD SYSOUT=Z
    //SYSUT2 DD SYSOUT=
    //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=,DISP=
    ZZ
    //* ^ as specified by DLM=ZZ
    //DROPOLDR EXEC PGM=IEFBR14
    //DELETE4 DD DSN=PICALC.4DGTS,DISP=
    //DELETE5 DD DSN=PICALC.5DGTS,DISP=

    Much of the complexity of OS JCL, in particular, derives from the large number of options for specifying dataset information. While files on Unix-like operating systems are abstracted into arbitrary collections of bytes, with the details handled in large part by the operating system, datasets on OS/360 and its successors expose their file types and sizes, record types and lengths, block sizes, device-specific information like magnetic tape density, and label information. Although there are system defaults for many options, there is still a lot to be specified by the programmer, through a combination of JCL and information coded in the program. The more information coded in the program, the less flexible it is, since information in the program overrides anything in the JCL; thus, most information is usually supplied through JCL.
    For example, to copy a file on Unix operating system, the user would enter a command like:
    cp oldFile newFile
    The following example, using JCL, might be used to copy a file on OS/360:

    //IS198CPY JOB,'COPY JOB',CLASS=L,MSGCLASS=X
    //COPY01 EXEC PGM=IEBGENER
    //SYSPRINT DD SYSOUT=*
    //SYSUT1 DD DSN=OLDFILE,DISP=SHR
    //SYSUT2 DD DSN=NEWFILE,
    // DISP=,
    // SPACE=,
    // DCB=
    //SYSIN DD DUMMY

    A second explanation for the complexity of JCL is the different expectations for running a job from those found in a PC or Unix-like environment.
    Later versions of the DOS/360 and OS/360 operating systems retain most features of the original JCL—although some simplification has been made, to avoid forcing customers to rewrite all their JCL files. Many users save as a procedure any set of JCL statements which is likely to be used more than once or twice.
    The syntax of OS JCL is similar to the syntax of macros in System/360 assembly language, and would therefore have been familiar to programmers at a time when many programs were coded in assembly language.

    DOS JCL

    Positional parameters


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

    DOS JCL parameters are positional, which makes them harder to read and write, but easier for the system to parse.
    DOS JCL to some extent mitigates the difficulties of positional parameters by using more statements with fewer parameters than OS JCL. In the example the ASSGN, DLBL and EXTENT statements do the same work as a single DD statement in OS JCL.

    Device dependence

    In the original DOS/360 and in most versions of DOS/VS one had to specify the model number of the device which was to be used for each disk or tape file—even for existing files and for temporary files which would be deleted at the end of the job. This meant that, if a customer upgraded to more modern equipment, many JCL files had to be changed.
    Later members of the DOS/360 family reduced the number of situations in which device model numbers were required.

    Manual file allocation

    DOS/360 originally required the programmer to specify the location and size of all files on DASD. The EXTENT card specifies the volume on which the extent resides, the starting absolute track, and the number of tracks. For z/VSE a file can have up to 256 extents on different volumes.

    OS JCL

    OS JCL consists of three basic statement types:
    and information about the step, including CONDitions for running or skipping a step.
    Right from the start, JCL for the OS family was more flexible and easier to use.
    The following examples use the old style of syntax which was provided right from the launch of System/360 in 1964. The old syntax is still quite common in jobs that have been running for decades with only minor changes.

    Rules for Coding JCL Statements

    Each JCL Statement is divided into five fields:
    Identifier-Field Name-Field Operation-Field Parameter-Field Comments-Field
    ^ ^ ^ ^
    no space space space space
    Identifier-Field should be concatenated with Name-Field, i.e. there should be no spaces between them.

    //NEWFILE DD DSN=MYFILE01,UNIT=DISK,SPACE=,
    // DCB=,
    // DISP=

    All of the major parameters of OS JCL statements are identified by keywords and can be presented in any order. A few of these contain two or more sub-parameters, such as SPACE and DCB in the example above. Sub-parameters are sometimes positional, as in SPACE, but the most complex parameters, such as DCB, have keyword sub-parameters.
    Positional parameter must precede keyword parameters. Keyword parameters always assign values to a keyword using the equals sign.

    Data access (DD statement)

    The DD statement is used to reference data. This statement links a program's internal description of a dataset to the data on external devices: disks, tapes, cards, printers, etc. The DD may provide information such as a device type, a volume serial number for tapes or disks, and the description of the data file, called the DCB subparameter after the Data Control Block in the program used to identify the file.
    Information describing the file can come from three sources: The DD card information, the dataset label information for an existing file stored on tape or disk, and the DCB macro coded in the program. When the file is opened this data is merged, with the DD information taking precedence over the label information, and the DCB information taking precedence over both. The updated description is then written back to the dataset label. This can lead to unintended consequences if incorrect DCB information is provided.
    Because of the parameters listed above and specific information for various access methods and devices the DD statement is the most complex JCL statement. In one IBM reference manual description of the DD statement occupies over 130 pages—more than twice as much as the JOB and EXEC statements combined.

    Device independence

    From the very beginning, the JCL for the OS family of operating systems offered a high degree of device independence. Even for new files which were to be kept after the end of the job one could specify the device type in generic terms, e.g., UNIT=DISK, UNIT=TAPE, or UNIT=SYSSQ. Of course, if it mattered one could specify a model number or even a specific device address.

    Procedures

    Procedures permit grouping one or more "EXEC PGM=" and DD statements and then invoking them with "EXEC PROC=procname" -or- simply "EXEC procname"
    A facility called a Procedure Library allowed pre-storing procedures.

    PROC & PEND

    Procedures can also be included in the job stream by terminating the procedure with a // PEND statement, then invoking it by name the same was as if it were in a procedure library.
    For example:

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

    Parameterized procedures

    OS JCL procedures were parameterized from the start, making them rather like macros or even simple subroutines and thus increasing their reusability in a wide range of situations.

    //MYPROC PROC FNAME=MYFILE01,SPTYPE=TRK,SPINIT=50,SPEXT=10,LR=100,BLK=1000
    .....
    //NEWFILE DD DSN=&FNAME,UNIT=DISK,SPACE=,
    // DCB=,DISP=
    ....

    In this example, all the values beginning with ampersands "&" are parameters which will be specified when a job requests that the procedure be used. The PROC statement, in addition to giving the procedure a name, allows the programmer to specify default values for each parameter. So one could use the one procedure in this example to create new files of many different sizes and layouts. For example:

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

    Referbacks

    In multi-step jobs, a later step can use a referback instead of specifying in full a file which has already been specified in an earlier step. For example:

    //MYPROC................
    //MYPR01 EXEC PGM=..........
    //NEWFILE DD DSN=&MYFILE,UNIT=DISK,SPACE=,
    // DCB=,DISP=
    ....
    //MYPR02 EXEC PGM=..........
    //INPUT01 DD DSN=*.MYPR01.NEWFILE

    Here, MYPR02 uses the file identified as NEWFILE in step MYPR01.
    In jobs which contain a mixture of job-specific JCL and procedure calls, a job-specific step can refer back to a file which was fully specified in a procedure, for example:

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

    where DSN=*.STEP01.MYPR01.NEWFILE means "use the file identified as NEWFILE in step MYPR01 of the procedure used by step STEP01 of this job". Using the name of the step which called the procedure rather than the name of the procedure allows a programmer to use the same procedure several times in the same job without confusion about which instance of the procedure is used in the referback.

    Comments

    JCL files can be long and complex, and the language is not easy to read. OS JCL allows programmers to include two types of explanatory comment:

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

    Concatenating input files

    OS JCL allows programmers to concatenate input files so that they appear to the program as one file, for example

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

    The 2nd and third statements have no value in the name field, so OS treats them as concatenations. The files must be of the same basic type, and must have the same record length, however the block length need not be the same.
    In early versions of the OS the block length must be in decreasing order, or the user must inspect each instance and append to the named DD statement the maximum block length found, as in, for example,

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

    In later versions of the OS the OS itself, during allocation, would inspect each instance in a concatenation and would substitute the maximum block length which was found.
    A usual fallback was to simply determine the maximum possible block length on the device, and specify that on the named DD statement, as in, for example,

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

    The purpose of this fallback was to ensure that the access method would allocate an input buffer set which was large enough to accommodate any and all of the specified datasets.

    Conditional processing

    OS expects programs to set a return code which specifies how successful the program thought it was. The most common conventional values are:
    OS JCL refers to the return code as COND, and can use it to decide whether to run subsequent steps. However, unlike most modern programming languages, conditional steps in OS JCL are not executed if the specified condition is true—thus giving rise to the mnemonic, "If it's true, pass on through ." To complicate matters further, the condition can only be specified after the step to which it refers. For example:

    //MYJOB JOB...........
    //STEP01 EXEC PGM=PROG01
    ....
    //STEP02 EXEC PGM=PROG02,COND=
    ....
    //STEP03 EXEC PGM=PROG03,COND=
    ....
    //STEP04 EXEC PGM=PROG04,COND=
    ....
    //STEP05 EXEC PGM=PROG05,COND=
    ....

    means:
    1. Run STEP01, and collect its return code.
    2. Don't run STEP02 if the number 4 is greater than STEP01's return code.
    3. Don't run STEP03 if the number 8 is less than or equal to any previous return code.
    4. Run STEP04 only if STEP01 abnormally ended.
    5. Run STEP05, even if STEP03 abnormally ended.
    This translates to the following pseudocode:
    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
    Note that by reading the steps containing COND statements backwards, one can understand them fairly easily. This is an example of logical transposition.
    However, IBM later introduced IF condition in JCL thereby making coding somewhat easier for programmers while retaining the COND parameter.
    The COND parameter may also be specified on the JOB statement. If so the system "performs the same return code tests for every step in a job. If a JOB statement return code test is satisfied, the job terminates."

    Utilities

    Jobs use a number of IBM utility programs to assist in the processing of data. Utilities are most useful in batch processing. The utilities can be grouped into three sets:
    OS JCL is undeniably complex and has been described as "user hostile". As one instructional book on JCL asked, "Why do even sophisticated programmers hesitate when it comes to Job Control Language?" The book stated that many programmers either copied control cards without really understanding what they did, or "believed the prevalent rumors that JCL was horrible, and only 'die-hard' computer-types ever understood it" and handed the task of figuring out the JCL statements to someone else. Such an attitude could be found in programming language textbooks, which preferred to focus on the language itself and not how programs in it were run. As one Fortran IV textbook said when listing possible error messages from the WATFOR compiler: "Have you been so foolish as to try to write your own 'DD' system control cards? Cease and desist forthwith; run, do not walk, for help."
    Nevertheless, some books that went into JCL in detail emphasized that once it was learned to an at least somewhat proficient degree, one gained freedom from installation-wide defaults and much better control over how an IBM system processed your workload. Another book commented on the complexity but said, "take heart. The JCL capability you will gain from is all that most programmers will ever need."

    Job Entry Control Language

    On IBM mainframe systems Job Entry Control Language or JECL is the set of command language control statements that provide information for the spooling subsystem - JES2 or JES3 on z/OS or VSE/POWER for z/VSE. JECL statements may "specify on which network computer to run the job, when to run the job, and where to send the resulting output."
    JECL is distinct from job control language, which instructs the operating system how to run the job.
    There are different versions of JECL for the three environments.

    OS/360

    An early version of Job Entry Control Language for OS/360 Remote Job Entry used the identifier .. in columns 1-2 of the input record and consisted of a single control statement: JED. "Workstation Commands" such as LOGON, LOGOFF, and STATUS also began with .. .

    pre-JES JECL

    Although the term had not yet been developed, HASP did have similar functionality to what would become the JECL of JES, including /* syntax.

    z/OS

    For JES2 JECL statements start with /*, for JES3 they start with //*, except for remote /*SIGNON and /*SIGNOFF commands. The commands for the two systems are completely different.

    JES2 JECL

    The following JES2 JECL statements are used in z/OS 1.2.0.
    JECL statementFunctionExample
    /*$commandEnters an operator command/*$S PRINTER3
    /*JOBPARMSpecifies values for job-related parameters/*JOBPARM TIME=10
    /*MESSAGESends a message to the operator console/*MESSAGE CALL JOE AT HOME IF JOB ABENDS
    /*NETACCTSpecifies account number for network job/*NETACCT 12345
    /*NOTIFYSpecifies destination for notification messages/*NOTIFY SAM
    /*OUTPUTSpecifies SYSOUT dataset options/*OUTPUT FORMS=BILL
    /*PRIORITYSets job selection priority/*PRIORITY 15
    /*ROUTESpecifies output destination or execution node/*ROUTE PRT RMT5
    /*SETUPRequests volume mounting or other offline operation/*SETUP TAPE01,TAPE02
    /*SIGNOFFEnds remote session/*SIGNOFF
    /*SIGNONBegins remote session/*SIGNON REMOTE5 password
    /*XEQSpecifies execution node/*XEQ DENVER
    /*XMITIndicates job or dataset to be transmitted to another network node/*XMIT NYC

    JES3 JECL

    The following JES3 JECL statements are used in z/OS 1.2.0
    JECL statementFunctionExample
    //**commandEnters a JES3 operator command
    //*DATASETMarks the beginning of an in-stream dataset
    //*ENDDATASETMarks the end of an in-stream dataset
    //*ENDPROCESSMarks the end of a series of //*PROCESS statements
    //*FORMATSpecifies SYSOUT dataset options
    //*MAINSpecifies values for job-related parameters
    //*NETIdentifies relationships among jobs using JES3 dependent job control
    //*NETACCTSpecifies account number for network job
    //*OPERATORSends a message to the operator console
    //*PAUSEStops the input reader
    //*PROCESSIdentifies a non-standard job
    //*ROUTESpecifies the execution node for the job
    /*SIGNOFFEnds remote session/*SIGNOFF
    /*SIGNONBegins remote session

    z/VSE

    For VSE JECL statements start with '* $$'. The Job Entry Control Language defines the start and end lines of JCL jobs. It advises VSE/POWER how this job is handled. JECL statements define the job name, the class in which the job is processed, and the disposition of the job.
    JECL statementFunctionExample
    * $$ CTLEstablishes a default input class* $$ CTL CLASS=A
    * $$ JOBSpecifies attributes of a job* $$ JOB JNM=PYRL,PRI=9
    * $$ EOJMarks the end of a job* $$ EOJ
    * $$ RDRInserts a file from a 3540 diskette into the input stream* $$ RDR SYS005,'fname',2
    * $$ PRTSpecifies characteristics of spooled print files
    "LST' is a synonym for "PRT"    		* $$ PRT FNO=STD,COPY=2
    * $$ PUNSpecifies characteristics of spooled punch files* $$ PUN DISP=T,TADDR=280
    * $$ SLIInserts data from source statement library into the input stream* $$ SLI A.JCL1
    * $$ DATAInserts data from the card reader into a book retrieved from the source statement library* $$ DATA INPUT1

    Example:

    • $$ JOB JNM=NAME,DISP=K,CLASS=2
    • $$ EOJ

    Other systems

    Other mainframe batch systems had some form of job control language, whether called that or not; their syntax was completely different from IBM versions, but they usually provided similar capabilities. Interactive systems
    include "command languages"—command files can be run non-interactively, but these usually do not provide as robust an environment for running unattended jobs as JCL. On some computer systems the job control language and the interactive command language may be different. For example, TSO on z/OS systems uses CLIST or Rexx as command languages along with JCL for batch work. On other systems these may be the same.