View source for JCL (Job Control Language)

 {{Infobox programming language
| name                  = JCL
 | logo                  = 
 | paradigm =  scripting language
 |class                  =  
 |year                   = 1974
 |designer               = IBM
 |file_ext              = .jcl
 |typing                 = 
 |influenced             = 
 |operating system       =  DOS, JCL OS
 |influenced_by          = 
 |website                = 
}}

'''Job Control Language''' ('''JCL''')  is the control language for batch processing in a mainframe environment and is one of the scripting languages. The object of the JCL is to specify the programs to be executed, their sequence and a runtime environment (connection to physical hardware, so the input and output devices and files). Belonging to a concrete task programs or program sequences and the required environment are bundled using the JCL in so-called jobs that are defined as executable units under the multitasking. The jobs provide the actual application programs superordinate level is at system level and are comparable in this respect with the shell scripts in Unix or the batch files in MS-DOS or Windows.

This article describes the JCL under IBM z / OS. Other mainframe operating systems such as VSE also use JCL called languages, but have a very different syntax.

==Features common to DOS and OS JCL==

===Conception===

In the JCL, the unit is the job (the job), which consists of one or more steps (steps). Each step consists of running a specific program. Thus, a job which is to create a report could be composed of the following steps:

*Selecting the proper records using a program and storing the results in a temporary file;
*sorting of results using an appropriate utility;
*creation of the report itself using another program that does the math - totals, etc. - And the shaping of the relevant information;
*report display, etc.

Punch card corresponding to a command line JCL using basic password that is called "maps" (rest of the time when each line of script, program, etc. was supplied to the computer using a punch card). A JCL script will begin with the JOB card that enables:

*to give a name to the job;
*to identify the group that will receive the implementation report;
*define how the job should be executed

It is possible to create JCL scripts that may be called in other JCL scripts using if necessary the parameters. Such scripts are called procedures.

Note: By metonymy, the word also refers to the script JCL (job) itself. Thus, IBM environment, we do not talk JCL script but simply JCL (eg. Start or run a JCL)

===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.

All commands, parameter names and values have to be in capitals, except for UNIX System Services|USS filenames.

All lines except for in-stream input (see below) have to begin with a slash "<code>/</code>", and all lines which the operating system processes have to begin with two slashes <code>//</code> - 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 (<code>/*</code>), and a comment statement in OS JCL begins with a pair of slashes and asterisk (<code>//*</code>) 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:
{| class="wikitable"
|-
! OS JCL !! DOS JCL
|-
| Ending all actual JCL cards except the last at a point where the syntax requires a comma (<code>,</code>) || Ending all actual JCL cards except the last at a point where the syntax requires a comma (<code>,</code>) and a non-blank character in column 72
|-
| Starting each continuation card with <code>//</code> in column 1 and then at least 1 space || Starting each continuation card with spaces and continuing in column 15
|}

The structure of the most common types of card is:
{| class="wikitable"
|-
! OS JCL !! DOS JCL
|-
|
*<code>//</code>
*Name field for this statement, following <code>//</code> with no space between.  If this statement does not have a name at least one blank immediately follows the <code>//</code>.
*Space(s)
*Statement type
*Space(s)
*Parameters, which vary depending on the statement type, separated by commas and with no space between them.
||
*<code>//</code> (spaces if this is a continuation of a previous line)
*Statement type for this statement, following <code>//</code> with a space between.  
*Space(s)
*Name of resource
*Space(s)
*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 <code>/*</code> 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 <code>/*</code> card.

OS JCL
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, e.g. <code>//SYSIN DD *</code>. JCL statements can be included as part of in-stream data by using the DD DATA statements.

DOS JCL
Simply enter the in-stream data after the EXEC card for the program.

===Complexity===
Much of the complexity of OS JCL, in particular, derives from the large number of options for specifying Data set (IBM mainframe)|dataset information.  While files on unix-like operating systems are just an arbitrary collection of bytes, files on OS/360 and successors have defined file types and sizes, record types and lengths, block sizes and device-specific information such as Magnetic tape data storage|magnetic tape density and label information.  Although there are system defaults for many options there is still a lot that has 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, so most information is usually supplied through JCL.For example, to File copying|copy a file on Unix the user enters a command like:

<syntaxhighlight lang="bash">cp file dest</syntaxhighlight>

JCL like the following might be used to copy a file on 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

A second explanation for the complexity of JCL is the different expectations for running a job than are found in a IBM PC|PC or unix environment.
*Low-end System/360 CPUs were less powerful and more expensive than the mid-1980s PCs for which MS-DOS was designed. OS/360 was intended for systems with a minimum memory size of 32&amp;nbsp;KB and DOS/360 for systems with a minimum of 16&amp;nbsp;KB. A, IBM 2030|360/30 CPU&amp;mdash;low-end when System/360 was announced in 1964&amp;mdash;processed 5K to 13K instructions per secondThe first IBM PC in 1981 had 16&amp;nbsp;KB or 64&amp;nbsp;KB of memory and would process about 330,000 instructions per second As a result, JCL had to be easy for the ''computer'' to process, and ease of use by programmers was a much lower priority. In this era, programmers were much cheaper than computers.
*JCL was designed for batch processing so it has to tell the operating system everything, including what to do depending on the result of the step. For example, <code>DISP=(NEW,CATLG,DELETE)</code> means "if the program runs successfully, create a new file and catalog it; otherwise delete the new file."  Programs run on a PC frequently depend on the user to clean up after processing problems.
*System/360 machines were designed to be shared by all the users in an organization. So the <code>JOB</code> card tells the operating system how to bill the user's account (<code>IS198T30500</code>), what predefined amount of storage and other resources may be allocated (<code>CLASS=L</code>), and several other things. <code>{{nowrap|1=//SYSPRINT DD SYSOUT=*}}</code> tells the computer to print the program's report on the default printer (computing)|printer which is loaded with ordinary paper, not on some other printer which might be loaded with blank checks. <code>DISP=SHR</code> tells the operating system that other programs can read <code>OLDFILE </code>multiprogramming|at the same time.

Later versions of the DOS/360 and OS/360 operating systems retain most features of the original JCL&amp;mdash;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 Macro instruction|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===

<syntaxhighlight lang="bash" enclose="div">
 // TLBL TAPEFIL,'COPYTAPE.JOB',,,,2
 // ASSGN SYS005,200
 // DLBL DISKFIL,'COPYTAPE.JOB',0,SD
 // EXTENT SYS005,VOL01,1,0,800,1600
</syntaxhighlight>

DOS JCL parameters are positional, which makes them harder to read and write, but easier for the system to parse.
* The programmer must remember which item goes in which position in every type of statement.
* If some optional parameters are omitted but later ones are included, the omitted parameters must be represented by commas with no spaces, as in the TLBL statement above.

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 <code>DD</code> 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&amp;mdash;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 Direct-access storage device|DASD.  The <code>EXTENT</code> 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:
* <code>JOB</code> statement, which identifies the start of the job, and information about the whole job, such as billing, run priority, and time and space limits.
* <code>EXEC</code> statement, which identifies the program to be executed in this step of the job, and information about the step.
* <code>DD</code> (Data Description) statements, which identify a data file to be used in a step, and detailed info about that file. <code>DD</code> statements can be in any order within the step.

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.

===Rules for Coding JCL Statements===

Each JCL Statement is Divided into 5 fields.

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

<var>Identifier-Field</var> should be concatenated with <var>Name-Field</var>, i.e. there should be no spaces between them.

* <var>Identifier-Field</var> (<code>//</code>): The identifier field indicates to the system that a statement is a JCL statement rather than data. The identifier field consists of the following:
** Columns 1 and 2 of all JCL statements, except the delimiter statement, contain <code>//</code>
** Columns 1 and 2 of the delimiter statement contain <code>/*</code>
** Columns 1, 2, and 3 of a JCL comment statement contain <code>//*</code>
* <var>Name-Field</var>: The name field identifies a particular statement so that other statements and the system can refer to it. For JCL statements, it should be coded as follows:
** The name must begin in column 3.
** The name is 1 through 8 alphanumeric or national (<code>$</code>, <code>#</code>, <code>@</code>) characters.
** The first character must be an alphabetic.
** The name must be followed by at least one blank.
* <var>Operation-Field</var>: The operation field specifies the type of statement, or, for the command statement, the command. <var>Operation-Field</var> should be coded as follows:
** The operation field consists of the characters in the syntax box for the statement.
** The operation follows the name field.
** The operation must be preceded and followed by at least one blank.
** The operation will be one of <code>JOB</code>, <code>EXEC</code> and <code>DD</code>.

* <var>Parameter-Field</var>: The parameter field, also sometimes referred to as the operand field, contains parameters separated by commas. Parameter field should be coded as follows:
** The parameter field follows the operation field.
** The parameter field must be preceded by at least one blank.
** The parameter field contains parameters which are keywords that used in the statement to provide information such as the program or dataset name.

* <var>Comments-Field</var>: This contains comment (computer programming)|comments. <var>Comments-Field</var> should be coded as Follows:
** The comments field follows the parameter field.
** The comments field must be preceded by at least one blank.

===Keyword parameters===

<syntaxhighlight lang="bash" enclose="div">
 //NEWFILE DD DSN=MYFILE01,UNIT=DISK,SPACE=(TRK,80,10),
 //           DCB=(LRECL=100,BLKSIZE=1000),
 //           DISP=(NEW,CATLG,DELETE)
</syntaxhighlight>

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 <code>SPACE</code> (how much disk space to allocate to a new file) and <code>DCB</code> (detailed specification of a file's layout) in the example above. Sub-parameters are sometimes positional, as in <code>SPACE</code>, but the most complex parameters, such as <code>DCB</code>, have keyword sub-parameters.

Positional parameter must precede keyword parameters. Keyword parameters always assign values to a keyword using the equals sign (<code>=</code>).

===Data access===
The <code>DD</code> 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 (e.g. '181','2400-5','TAPE'), a Volume (computing)|volume serial number for tapes or disks, and the description of the data file, called the <code>DCB</code> subparameter after the Data Control Block (DCB)  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

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

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

<syntaxhighlight lang="bash" enclose="div">
 //MYPROC PROC FNAME=MYFILE01,SPTYPE=TRK,SPINIT=50,SPEXT=10,LR=100,BLK=1000
 .....
 //NEWFILE DD DSN=&amp;FNAME,UNIT=DISK,SPACE=(&amp;SPTYPE,&amp;SPINIT,&amp;SPEXT),
 //           DCB=(LRECL=&amp;LR,BLKSIZE=&amp;BLK),DISP=(NEW,CATLG,DELETE)
 ....
</syntaxhighlight>

In this example, all the values beginning with ampersands "<code>&amp;</code>" 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:

<syntaxhighlight lang="bash" enclose="div">
 //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
</syntaxhighlight>

===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:

<syntaxhighlight lang="bash" enclose="div">
 //MYPROC ................
 //MYPR01 EXEC PGM=..........
 //NEWFILE DD DSN=&amp;MYFILE,UNIT=DISK,SPACE=(TRK,50,10),
 //           DCB=(LRECL=100,BLKSIZE=1000),DISP=(NEW,CATLG,DELETE)
 ....
 //MYPR02 EXEC PGM=..........
 //INPUT01 DD DSN=*.MYPR01.NEWFILE
</syntaxhighlight>

Here, <code>MYPR02</code> uses the file identified as <code>NEWFILE</code> in step <code>MYPR01</code> (<code>DSN</code> 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:

<syntaxhighlight lang="bash" enclose="div">
 //MYJOB JOB ..........
 //STEP01 EXEC MYPROC             Using a procedure
 //STEP02 EXEC PGM=.........      Step which is specific to this job
 //INPUT01 DD DSN=*.STEP01.MYPR01.NEWFILE
</syntaxhighlight>

where <code>DSN=*.STEP01.MYPR01.NEWFILE</code> means "use the file identified as <code>NEWFILE</code> in step <code>MYPR01</code> of the procedure used by step <code>STEP01</code> 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. (JCL has been described as "user hostile".) OS JCL allows programmers to include two types of explanatory comment:
*On the same line as a JCL statement. They can be extended by placing a continuation character (usually "<code>X</code>") in column 72, followed by "<code>// </code>" in columns 1–3 of the next line.
*Lines which contain only comment, often used to explain major points about the overall structure of the JCL rather than local details. Comment-only lines are also used to divide long, complex JCL files into sections.

<syntaxhighlight lang="bash" enclose="div">
 //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
</syntaxhighlight>

===Concatenating input files===
OS JCL allows programmers to concatenate ("chain") 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 (almost always sequential), and must have the same record length.

===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:
*0 = Normal - all OK
*4 = Warning - minor errors or problems
*8 = Error - significant errors or problems
*12 = Severe error - major errors or problems, the results (e.g. files or reports produced) should not be trusted.
*16 = Terminal error - very serious problems, do not use the results!

OS JCL refers to the return code as <code>COND</code> ("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&amp;mdash;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:

<syntaxhighlight lang="bash" enclose="div">
 //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)
 ....
</syntaxhighlight>

means:
# Run <code>STEP01</code>, and collect its return code.
# Don't run <code>STEP02</code> if the number 4 is greater than <code>STEP01</code>'s return code.
# Don't run <code>STEP03</code> if the number 8 is less than or equal to any previous return code.
# Run <code>STEP04</code> only if <code>STEP01</code> abnormally ended.
# Run <code>STEP05</code>, even if <code>STEP03</code> 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 <code>COND</code> statements backwards, one can understand them fairly easily. This is an example of Transposition (logic)|logical transposition.
However, IBM later introduced IF condition in JCL thereby making coding somewhat easier for programmers while retaining the <code>COND</code> parameter.

===JCL utilities===
JCL uses a number of IBM mainframe utility programs|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:
* Data Set Utilities - Create, print, copy, move and delete data sets.
* System Utilities - Maintain and manage catalogs.
* Access Method Services - Process Virtual Storage Access Method (VSAM) and non-VSAM data sets.

==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 &amp;ndash; Job Entry Subsystem 2/3|JES2 or JES3 on z/OS or IBM Power (software)|VSE/POWER for VSE (operating system)|z/VSE.  JECL statements may "specify on which network computer to run the Job stream|job, when to run the job, and where to send the resulting output
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.

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

===z/OS===
For JES2 JECL statements start with <code>/*</code>, for JES3 they start with <code>//*</code>, except for remote &amp;nbsp;<code>/*SIGNON</code>&amp;nbsp; and &amp;nbsp;<code>/*SIGNOFF</code>&amp;nbsp; 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
{| class="wikitable"
|-
! JECL statement !! Function !! Example
|-
| <code>/*$''command''</code> || Enters an operator (console) command || <code>/*$S PRINTER3</code>
|-
| <code>/*JOBPARM</code> || Specifies values for job-related parameters || <code>/*JOBPARM TIME=10</code>
|-
| <code>/*MESSAGE</code> || Sends a message to the operator console || <code>/*MESSAGE CALL JOE AT HOME IF JOB ABENDS</code>
|-
| <code>/*NETACCT</code> || Specifies account number for network job || <code>/*NETACCT 12345</code>
|-
| <code>/*NOTIFY</code> || Specifies destination for notification messages || <code>/*NOTIFY SAM</code>
|-
| <code>/*OUTPUT</code> || Specifies ''SYSOUT'' dataset options || <code>/*OUTPUT FORMS=BILL</code>
|-
| <code>/*PRIORITY</code> || Sets job selection priority || <code>/*PRIORITY 15</code>
|-
| <code>/*ROUTE</code> || Specifies output destination or execution node || <code>/*ROUTE PRT RMT5</code>
|-
| <code>/*SETUP</code> || Requests volume mounting or other offline operation || <code>/*SETUP TAPE01,TAPE02</code>
|-
| <code>/*SIGNOFF</code> || Ends remote session || <code>/*SIGNOFF</code>
|-
| <code>/*SIGNON</code> || Begins remote session || <code>/*SIGNON REMOTE5 ''password''</code>
|-
| <code>/*XEQ</code> || Specifies execution node || <code>/*XEQ DENVER</code>
|-
| <code>/*XMIT</code> || Indicates job or dataset to be transmitted to another network node || <code>/*XMIT NYC</code>
|}

====JES3 JECL====
The following JES3 JECL statements are used in z/OS 1.2.0
{| class="wikitable"
|-
! JECL statement !! Function !! Example
|-
| <code>//**''command''</code> || Enters a JES3 operator (console) command ||
|-
| <code>//*DATASET</code> || Marks the beginning of an in-stream dataset ||
|-
| <code>//*ENDDATASET</code> || Marks the end of an in-stream dataset || 
|-
| <code>//*ENDPROCESS</code> || Marks the end of a series of &amp;nbsp;<code>//*PROCESS</code>&amp;nbsp; statements || 
|-
| <code>//*FORMAT</code> || Specifies &amp;nbsp;<code>SYSOUT</code>&amp;nbsp; dataset options || 
|-
| <code>//*MAIN</code> || Specifies values for job-related parameters ||
|-
| <code>//*NET</code> || Identifies relationships among jobs using JES3 ''dependent job control''  ||
|-
| <code>//*NETACCT</code> || Specifies account number for network job ||
|-
| <code>//*OPERATOR</code> || Sends a message to the operator console ||
|-
| <code>//*PAUSE</code> || Stops the input reader ||
|-
| <code>//*PROCESS</code> || Identifies a non-standard job ||
|-
| <code>//*ROUTE</code> || Specifies the execution node for the job ||
|-
| <code>/*SIGNOFF</code> || Ends remote session || <code>/*SIGNOFF</code>
|-
| <code>/*SIGNON</code> || Begins remote session ||
|}

===z/VSE===
For VSE JECL statements start with '<code>* $$</code>' (note the ''single'' space).  The Job Entry Control Language defines the start and end lines of JCL jobs. It advises VSE (operating system)|VSE/IBM Power (software)|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. <code>D</code>, <code>L</code>, <code>K</code>, <code>H</code>).

{| class="wikitable"
|-
! JECL statement!! Function !! Example
|-
| <code>* $$ CTL</code> || Establishes a default ''input class'' || <code>* $$ CTL CLASS=A</code>
|-
| <code>* $$ JOB</code> || Specifies attributes of a job || <code>* $$ JOB JNM=PYRL,PRI=9</code>
|-
| <code>* $$ EOJ</code> || Marks the end of a job || <code>* $$ EOJ</code>
|-
| <code>* $$ RDR</code> || Inserts a file from a 3540 diskette into the input stream || <code>* $$ RDR SYS005,'fname',2</code>
|-
| <code>* $$ PRT</code> || Specifies characteristics of spooled print files<br> "LST' is a synonym for "PRT" || <code>* $$ PRT FNO=STD,COPY=2</code>
|-
| <code>* $$ PUN</code> || Specifies characteristics of spooled punch files || <code>* $$&amp;nbsp;PUN&amp;nbsp;DISP=T,TADDR=280</code>
|-
| <code>* $$ SLI</code> || Inserts data ("book") from source statement library into the input stream|| <code>* $$ SLI A.JCL1</code>
|-
| <code>* $$ DATA</code> || Inserts data from the card reader into a book retrieved from the source statement library|| <code>* $$ DATA INPUT1</code>
|}

Example:

<syntaxhighlight lang="bash" enclose="div">
  * $$ JOB JNM=NAME,DISP=K,CLASS=2  [some JCL statements here]  * $$ EOJ
</syntaxhighlight>

==Sources==
* [https://en.wikipedia.org/wiki/Job_Control_Language JCL Wikipedia]
* [http://publibz.boulder.ibm.com/epubs/pdf/iea2b540.pdf z/OS V1R6.0 MVS JCL User’s Guide]
* [http://publibz.boulder.ibm.com/epubs/pdf/iea2b661.pdf z/OS V1R7.0 MVS JCL Reference]
* [http://www.zjournal.com/index.cfm?section=article&amp;aid=293 VSE: A Look at the Past 40 Years ]
* [http://library.thinkquest.org/22522/timeline3b_en.html Computer Chronicles: 1972 - 1981]
* [http://publib.boulder.ibm.com/infocenter/zos/v1r11/index.jsp?topic=/com.ibm.zos.r11.ieab600/iea2b69009.htm JCL Statement Fields]

[[ru:JCL (Job Control Language)]]