Job Control Language

From Wikipedia, the free encyclopedia - View original article

Jump to: navigation, search

Job Control Language (JCL) is a scripting language used on IBM mainframe operating systems to instruct the system on how to run a batch job or start a subsystem.

There are actually two IBM JCLs: one for the operating system lineage that begins with DOS/360 and whose latest member is z/VSE; and the other for the lineage from OS/360 to z/OS. They share some basic syntax rules and a few basic concepts, but are otherwise very different.

Features common to DOS and OS JCL[edit]

Jobs, steps and procedures[edit]

In both JCLs 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 (commonly called procs) 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[edit]

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 in OS JCL 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 (see below) 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 begins with a pair of slashes and asterisk (//*).

Many JCL statements are too long to fit within 71 characters, but can be extended on to an indefinite number of continuation cards by:

The structure of the most common types of card is:

In-stream input[edit]

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.

DD statements can be used to describe in-stream data, as well as data sets. A DD statement dealing with in-stream data has an asterisk (*) following the DD identifier. JCL statements can be included as part of in-stream data by using the DD DATA statements.


This is best illustrated by a simple example. To copy a file on Unix one simply types in a command like:

 cp oldFile newFile 

In the OS/360 family one would use something like:


Differences between System/360 and PC environments:

Despite these difficulties, IBM considered it necessary to retain all the features of the original JCLs, to avoid customers having to rewrite all their JCL files.[citation needed] But it later introduced easier alternatives such as CLIST. Most users save as a procedure any set of JCL statements which is likely to be used more than once or twice.[citation needed]

DOS JCL[edit]

Positional parameters[edit]


In DOS JCL parameters are positional, which makes them harder to read and write:

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 (specifying where a new disk file should be stored) as a single DD statement in OS JCL.

Device dependence[edit]

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 a more modern type of device, many JCL files had to be changed.

Later members of the DOS/360 family reduced the number of situations in which model numbers were required.

OS JCL[edit]

Statements that are used in this JCL language are called JCL-Statements. OS JCL consists of three basic statements:

Right from the start, JCL for the OS family (up to and including z/OS) 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 over 20 years with only minor changes. These old jobs are often complex, and converting them to use the CLIST syntax would be tricky and time-consuming.

Although the CLIST syntax is easier to read, programmers still have to provide the same amount of information as they would using the old syntax.

Rules for Coding JCL Statements[edit]

Each JCL Statement is Divided into 5 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.

Keyword parameters[edit]

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

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 (how much disk space to allocate to a new file) and DCB (detailed specification of a file's layout) 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 (=).

Device independence[edit]

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 or UNIT=TAPE. Of course, if it mattered one could specify a model number or even a specific device address.

Parameterized procedures[edit]

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.


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:




Override capabilities[edit]

OS allows programmers to override in JCL some of the specifications of file structure which programs might contain. This facility is mostly used for creating new files. For example in


the new file will have a block size of 1000 bytes even if code in program MYPROG says the block size should be something else - so there's no need to change program MYPROG. On the other hand since this example does not specify the LRECL (record length) sub-parameter of DCB, the record length will be whatever MYPROG says.


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=(TRK,50,10), //           DCB=(LRECL=100,BLKSIZE=1000),DISP=(NEW,CATLG,DELETE) .... //MYPR02 EXEC PGM=.......... //INPUT01 DD DSN=*.MYPR01.NEWFILE  

Here, MYPR02 uses the file identified as NEWFILE in step MYPR01 (DSN means "dataset name" and specifies the name of the file).

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.


JCL files can be long and complex, and the language is not easy to read. (JCL has been described as "user hostile".) 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[edit]

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


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 (almost always sequential), and must have the same record length.

Conditional processing[edit]

OS expects programs to set a return code which specifies how successful the program thought it was. The most common conventional values are:[citation needed]

OS JCL refers to the return code as COND ("condition code"), 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 [without running the code]." To complicate matters further, the condition can only be specified after the step to which it refers. For example:



  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 (to avoid making changes to the existing JCLs where COND parm is used).

JCL utilities[edit]

JCL uses 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:

Job Entry Control Language[edit]

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."[4]

JECL is distinct from job control language (JCL), which instructs the operating system how to run the job.

There are different versions of JECL for the three environments.


An early version of Job Entry Control Language for OS/360 Remote Job Entry (Program Number 360S-RC-536) used the identifier  ..  in columns 1–2 of the input record and consisted of a single control statement: JED (Job Entry Definition). "Workstation Commands" such as LOGON, LOGOFF, and STATUS also began with  .. .[5]


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[edit]

The following JES2 JECL statements are used in z/OS 1.2.0.[6]

JECL statementFunctionExample
/*$commandEnters an operator (console) 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[edit]

The following JES3 JECL statements are used in z/OS 1.2.0[7]

JECL statementFunctionExample
//**commandEnters a JES3 operator (console) 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


For VSE JECL statements start with '* $$' (note the single space). 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 (used by VSE/POWER), the class in which the job is processed, and the disposition of the job (i.e. D, L, K, H).

JECL statement[8]FunctionExample
* $$ 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"
* $$ PUNSpecifies characteristics of spooled punch files* $$ PUN DISP=T,TADDR=280
* $$ SLIInserts data ("book") from source statement libray into the input stream* $$ SLI A.JCL1
* $$ DATAInserts data from the card reader into a book retrieved from the source statement library* $$ DATA INPUT1


  * $$ JOB JNM=NAME,DISP=K,CLASS=2    [some JCL statements here]    * $$ EOJ 

See also[edit]


  1. ^ CPU MIPS ratings
  2. ^ IBM PC
  3. ^ IBM-compatible computers History of PCs
  4. ^ Brown, Gary DeWard (2002). zOS JCL. John Wiley & Sons,. 
  5. ^ IBM Corporation (1968). IBM System/360 Operating System Remote Job Entry. 
  6. ^ IBM Corporation. "Job Entry Subsystem 2 (JES2) Control Statements". z/OS V1R2.0 MVS JCL. Retrieved February 25, 2013. 
  7. ^ IBM Corporation. "Job Entry Subsystem 3 (JES3) Control Statements". z/OS V1R2.0 MVS JCL. Retrieved February 25, 2013. 
  8. ^ IBM Corporation (1974). DOS/VS POWER/VS Installation and Operations.