Job Control Language

Job Control Language (JCL)
Company type	Programming language
Industry	Computer programming, Mainframe computing
Products	Job control scripting for IBM mainframe batch jobs

Job Control Language (JCL) serves as a programming language designed to script and initiate batch jobs on IBM mainframe computer systems. It directs which programs should execute and specifies the input and output files or devices. Additionally, JCL handles file retention policies, disk space allocation, tape mounting operations, conditions for skipping steps, and supplies accounting information for resource monitoring and job management.

There are two principal variations of JCL, distinguished by their platform heritage: one lineage extends from DOS/360 to z/VSE, while the other spans from OS/360 through z/OS, incorporating enhancements such as JES features and Job Entry Control Language (JECL). Although these versions share foundational syntax elements, their differences are considerable. The VM OS employs distinct command languages instead of JCL.

The phrase job control language is used generically to describe any programming language dedicated to job control, not solely IBM’s specific version.

Terminology

Important terms unique to JCL include:

Data set

A file residing on disk, tape, or other storage media, which can be either temporary or permanent in nature.

Partitioned data set (PDS)

A compilation of files typically utilized for source code, assembler macros (such as SYS1.MACLIB), system configuration files (SYS1.PARMLIB), and shared JCL procedures (SYS1.PROCLIB). A PDS functions similarly to an archive format (ZIP, tar) or a directory within a filesystem. It may also store executable elements like load modules. Once members are saved within a PDS, they cannot be altered directly but can be removed and replaced using tools like IEBUPDTE. Since 1989, an improved variant known as partitioned data set extended (PDSE) has been available.

Member

A single file contained inside a PDS, accessed by specifying the PDS name followed by the member name in parentheses, for example .

Unix system services (USS)

A POSIX-compatible Unix environment integrated into the MVS base control program, enabling native execution of Unix files, scripts, tasks, and applications on mainframe platforms without requiring virtualization.

Motivation

Mainframe computers were originally engineered for batch processing, necessitating particular configurations of main storage and dedicated peripherals such as magnetic tapes, exclusive disk volumes, and specialized printers. JCL was created to verify that all required resources are allocated prior to job execution. Unlike operating systems like Linux, where resource needs can be dynamically declared via command-line arguments, JCL mandates explicit listing of all datasets and devices needed. This approach allows the operating system’s job scheduler to reserve resources in advance, preventing situations where simultaneous jobs cause resource contention (deadlock) by holding some resources while waiting for others. By scheduling jobs with these constraints in mind, JCL enhances operational throughput and minimizes manual intervention by computer operators.

Jobs, steps and procedures

In both DOS and OS environments, the fundamental unit of work is the job stream, which consists of one or multiple steps—each representing a request to execute a particular program. For example, a job generating a management report might involve selecting records, sorting data through utilities, formatting output for clarity, and preparing it for display.

The initial "card" in both DOS and OS JCL is the JOB card, which:

Specifies the job’s identity.
Supplies billing details for computer service accounting.
Sets parameters influencing job execution such as its priority within the processing queue.

Procedures (procs) are predefined JCL scripts encompassing individual steps or collections of steps designed to simplify repetitive operations across various jobs. They help reduce development time and errors by enabling insertion of these standardized procedures with adjustable parameters into the job stream through a single card reference.

Basic syntax

Both DOS and OS JCL limit each line to a maximum of 80 characters, a restriction inherited from the original input method using 80-column punched cards. Although subsequent job submissions via disk or tape permitted longer records, any characters beyond column 80 were disregarded by the operating system.

In practical terms, only 71 characters per line are utilized; columns 73 through 80 are generally reserved for card sequence numbers to assist with error identification, while column 72 is usually left empty but can be used to indicate that the current card continues onto the next one.

All commands, parameter identifiers, and their values must be written in uppercase letters, with the exception of USS filenames.

Lines (apart from in-stream input) must begin with a slash "/", and every line processed by the OS starts with double slashes "//" in the first column. Notable exceptions include delimiter statements which commence with "/*" and comment lines that start with "//*" in OS JCL or an asterisk in DOS JCL.

Since many JCL statements exceed 71 characters, they are extended over continuation cards as follows:

OS JCL	DOS JCL
All continuation cards except the last end with a comma (`,`)	All but the final card end with a comma (`,`) and have a non-blank character in column 72
Continuation cards start with `//` in column 1 followed by at least one space	Continuation cards begin with spaces starting from column 15

The typical card format is as follows:

OS JCL	DOS JCL
`//` Immediately after `//`, a name field (or blank if unnamed) One or more spaces Statement type One or more spaces Parameters that vary depending on statement type, separated by commas without spaces.	`//` (or spaces if continuation) Statement type immediately following `//` with a space One or more spaces Resource name One or more spaces Parameters depending on statement type, positional first then keyword, separated by commas without spaces.

In-stream input

Both DOS and OS JCL provide support for in-stream input, enabling data "cards" to be handled directly by the application rather than by the operating system. Prior to widespread use of interactive terminals, disk files were created and modified by supplying data through cards.

Although DOS and OS JCL use different methods to mark the beginning of in-stream input, both conclude it with /* placed in column 1 on the card following the last data card, after which normal JCL processing resumes.

OS JCL:* DD statements may describe either in-stream data or datasets. For instance, //SYSIN DD * indicates that subsequent lines contain in-stream data. The DLM parameter allows specifying a custom delimiter (defaulting to "/*"), which lets JCL be interpreted as data—this is useful when copying procedures or submitting jobs via the internal reader.

Example:*

<syntaxhighlight lang="jcl" highlight="8,12,13"> //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 //* ^ job held for later execution //CPUHOG EXEC PGM=PICALC1K //OUTPUT DD DSN=PICALC.1000DGTS,SPACE=(TRK,1),DISP=(,KEEP) ZZ //* ^ delimiter specified by DLM=ZZ //DROPOLDR EXEC PGM=IEFBR14 //DELETE4 DD DSN=PICALC.4DGTS,DISP=(OLD,DELETE) //DELETE5 DD DSN=PICALC.5DGTS,DISP=(OLD,DELETE) </syntaxhighlight>

The PICALC1K program awaits manual release due to TYPRUN=HOLD
IEFBR14 executes immediately to delete two datasets

DOS JCL:* The in-stream data follows directly after the EXEC card without additional delimiters.

Complexity

Fred Brooks, who led the OS/360 development and authored The Design of Design, famously condemned JCL as "the worst computer programming language ever devised," attributing this harsh critique to the fact that its creators failed to regard JCL as a true programming language.

A significant portion of JCL's complexity stems from the extensive options available for defining dataset characteristics—such as file types, sizes, record formats, block sizes, device-specific parameters (like magnetic tape density), and labeling—unlike Unix-like systems where files are treated simply as byte streams without exposing hardware details. Although default settings exist, programmers frequently need to specify numerous parameters explicitly in JCL to preserve flexibility.

For instance, copying a file on a Unix system is simple: <syntaxhighlight lang="bash"> cp oldFile newFile </syntaxhighlight>

In contrast, performing the same task on OS/360 demands a comprehensive JCL script: <syntaxhighlight lang="jcl" highlight="3"> //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 </syntaxhighlight>

Additional complexity arises from the constraints of System/360 hardware and its batch-oriented design:

Early System/360 processors were less powerful and more costly than personal computers of the mid-1980s; memory was scarce (typically 16–32 KB), leading to prioritization of machine processing efficiency over user convenience.
Every job parameter must be explicitly declared in JCL—including conditional handling of datasets such as DISP=(NEW,CATLG,DELETE), which controls file creation or deletion depending on job outcomes.
Multi-user environments necessitated specifying billing information (JOB card), resource management (CLASS=L), and directing output (//SYSPRINT DD SYSOUT=*) to designated printers.

Subsequent releases like DOS/360 and OS/360 preserved most original JCL features with only minor simplifications to maintain compatibility with existing scripts. Users typically store frequently used JCL code blocks as procedures to facilitate job submission.

The syntax of OS JCL closely mirrors System/360 assembly macros, making it familiar territory for programmers experienced with assembly language.

Positional parameters

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

DOS JCL relies on positional parameters, which present challenges in readability and writing but simplify parsing by the system.

Programmers must memorize the precise order of each parameter within different statement types.
When optional parameters are omitted but subsequent ones are included, commas must be used to mark skipped positions without spaces, as demonstrated in the TLBL example above.

To mitigate this complexity, DOS JCL introduces a greater number of statements with fewer parameters each compared to OS JCL. For example, disk file storage details are specified individually via ASSGN, DLBL, and EXTENT statements—tasks that OS JCL consolidates into a single DD statement.

Device dependence

Early iterations of DOS/360 mandated specifying device model numbers for every disk or tape dataset—even for temporary or preexisting files—posing difficulties during hardware upgrades. Later versions of DOS/360 relaxed these device-specific requirements considerably.

Manual allocation of files

At the outset, DOS/360 required users to manually designate both the location and size of files on DASD. The EXTENT card specifies the volume, the initial absolute track, and the number of tracks allocated. In z/VSE environments, a file may extend across as many as 256 extents distributed over multiple volumes.

Operating System JCL

Operating System Job Control Language (OS JCL) consists of three primary types of statements:

JOB defines the beginning of a job and includes parameters such as billing information, priority levels, and resource constraints.
EXEC designates the program or procedure to be run within a job step and governs conditions for executing that step.
DD (Data Definition) outlines data files and their characteristics; these statements can be arranged in any order within a job step.

From its introduction with System/360 in 1964 through to z/OS, OS JCL has evolved to enhance flexibility and user experience. Despite updates, the foundational syntax remains widely used in long-duration jobs.

Guidelines for writing JCL statements

A JCL statement is structured into five distinct fields:

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

The Identifier-Field must be directly followed by the Name-Field without intervening spaces.

Identifier-Field (//): Marks the line as a JCL statement rather than data.

 - The first two columns contain //, except for delimiter lines (/*) and comment lines (//*).

Name-Field: Provides a unique identifier for system reference.

 - Starts at column 3 and includes 1 to 8 alphanumeric or national characters ($, #, @).  
 - The initial character must be alphabetic, followed by at least one blank space.

Operation-Field: Specifies the type of statement or command to be executed.

 - Positioned after the name field, surrounded by at least one blank on each side.  
 - Common values include JOB, EXEC, and DD.

Parameter-Field: Contains comma-separated parameters detailing items such as program names or dataset identifiers.

 - Comes after the operation field, preceded by at least one blank.

Comments-Field: Holds any commentary following parameters, also preceded by at least one blank.

Keyword-based parameters

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

Key parameters in OS JCL are expressed as keywords and can be listed in any sequence. Certain parameters include subordinate elements—for instance, SPACE (defining disk allocation) and DCB (specifying file layout). Sub-parameters may be positional (as seen in SPACE) or keyword-oriented (as in complex structures like DCB). Positional sub-parameters always precede keyword sub-parameters. Assignment of parameter values uses an equals sign (=).

Data access using DD statements

The DD statement connects a program’s internal dataset description with external storage devices such as disks, tapes, card readers, and printers. It identifies device types (e.g., '181', '2400-5', 'TAPE'), volume serial numbers associated with tapes or disks, and defines data file attributes through the DCB subparameter from the Data Control Block (DCB).

File metadata is derived from three sources: information on the DD statement itself, dataset labels present on storage media, and the DCB macro coded within the program. When a file is opened, these sources are combined with precedence rules: DD parameters override label information, while DCB settings take priority over both. The resulting description is then updated back onto the dataset label, which can cause errors if inaccurate DCB data is supplied.

Because it incorporates numerous parameters and device-specific details, the DD statement represents the most intricate component of JCL. One IBM manual dedicates more than 130 pages to this statement alone—over twice as much coverage compared to both JOB and EXEC statements combined.

Additionally, the DD statement allows embedding data directly within job streams to provide control information for utilities like IDCAMS and SORT or to supply input data to programs.

Device Independence

Since its inception, JCL on OS operating systems has prioritized device independence. When defining new files, devices could be specified in a generic manner (for example, UNIT=DISK, UNIT=TAPE, or UNIT=SYSSQ) without tying them to specific hardware details. However, it was possible to include exact model numbers or device addresses when precise identification was required.

Procedures

Procedures allow the consolidation of multiple "EXEC PGM=" and DD commands into a reusable unit, which can be invoked using "EXEC PROC=procname" or simply "EXEC procname" (since PROC= is the default for EXEC).

A Procedure Library serves as a repository where procedures can be stored in advance to facilitate efficient job control.

PROC & PEND

Procedures may be embedded directly within a job stream by concluding them with a // PEND statement. These embedded procedures can then be called by name as though they were stored in a procedure library.

Example: <syntaxhighlight lang="jcl" highlight="1,6"> //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 </syntaxhighlight>

Parameterized Procedures

From the beginning, OS JCL procedures supported parameters, operating similarly to macros or basic subroutines. This design significantly improved their reusability across diverse applications. <syntaxhighlight lang="jcl"> //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) .... </syntaxhighlight> Parameters denoted by ampersands "&" are supplied at the time the procedure is invoked. The PROC statement defines the procedure’s name and assigns default values to parameters, enabling one procedure to generate files with varying sizes and attributes: <syntaxhighlight lang="jcl"> //JOB01 JOB .......... //STEP01 EXEC MYPROC FNAME=JOESFILE,SPTYPE=CYL,SPINIT=10,SPEXT=2,LR=100,BLK=2000 //JOB02 JOB .......... //STEP01 EXEC MYPROC FNAME=SUESFILE,SPTYPE=TRK,SPINIT=500,SPEXT=100,LR=100,BLK=5000 </syntaxhighlight>

Referbacks

Within multi-step jobs, a subsequent step can utilize a referback to access a dataset defined earlier without redefining it: <syntaxhighlight lang="jcl"> //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 </syntaxhighlight> In this example, MYPR02 references the NEWFILE dataset established in step MYPR01. Note that dataset names (DSN) are restricted to 44 characters.

When combining job-specific JCL with procedures within a job stream, a job-defined step can refer back to a file fully described inside a procedure: <syntaxhighlight lang="jcl"> //MYJOB JOB .......... //STEP01 EXEC MYPROC Using a procedure //STEP02 EXEC PGM=......... Job-specific step //INPUT01 DD DSN=*.STEP01.MYPR01.NEWFILE </syntaxhighlight> Here DSN=*.STEP01.MYPR01.NEWFILE identifies the NEWFILE dataset from step MYPR01, which is part of the procedure called by STEP01. Referring to the invoking step name rather than the procedure itself allows multiple invocations of the same procedure within one job without causing naming conflicts.

Comments

JCL scripts often become lengthy and intricate, with syntax that can be challenging to interpret. OS JCL supports two methods for adding explanatory remarks:

Inline comments placed on the same line as a JCL command, extended by inserting a continuation character ("X") in column 72, followed by "// " beginning at columns 1 through 3 on the next line.
Standalone comment lines, which serve to clarify key points or segment complex JCL scripts into manageable sections.

<syntaxhighlight lang="jcl"> //MYJOB JOB .......... //* Lines dedicated solely to comments. //******** Commonly used to separate JCL listings into distinct parts ******** //STEP01 EXEC MYPROC Inline comment example //STEP02 EXEC PGM=......... Comment extended using continuation X // onto the following line. //INPUT01 DD DSN=STEP01.MYPR01.NEWFILE </syntaxhighlight>

Concatenating input files

OS JCL permits the chaining of multiple input datasets so they are treated as a single continuous file: <syntaxhighlight lang="jcl"> //INPUT01 DD DSN=MYFILE01,DISP=SHR // DD DSN=JOESFILE,DISP=SHR // DD DSN=SUESFILE,DISP=SHR </syntaxhighlight>

Because the second and third DD statements omit a name field, the system interprets them as concatenated datasets. These files must share the same fundamental type (typically sequential) and have compatible record lengths; however, block sizes may vary.

In earlier OS releases (prior to OS/360 R21.8), block sizes had to be specified either in descending order or with the largest block size declared explicitly on the named DD statement: <syntaxhighlight lang="jcl"> //INPUT01 DD DSN=MYFILE01,DISP=SHR,BLKSIZE=800 // DD DSN=JOESFILE,DISP=SHR (BLKSIZE ≤ 800) // DD DSN=SUESFILE,DISP=SHR (BLKSIZE ≤ 800) </syntaxhighlight>

Subsequent OS versions (from OS/MVS R3.7 onward) automatically detect and apply the maximum block size during dataset allocation.

A typical workaround involved specifying the device’s highest block size on the named DD statement to guarantee sufficient input buffer allocation: <syntaxhighlight lang="jcl"> //INPUT01 DD DSN=MYFILE01,DISP=SHR,BLKSIZE=8000 // DD DSN=JOESFILE,DISP=SHR (BLKSIZE ≤ 8000) // DD DSN=SUESFILE,DISP=SHR (BLKSIZE ≤ 8000) </syntaxhighlight>

Conditional processing

OS programs return codes that indicate their execution status:

0 = Normal completion
4 = Warning condition
8 = Error condition
12 = Severe error
16 = Terminal error

JCL employs the COND parameter ("condition code") to determine whether subsequent steps should execute. Contrary to many modern programming languages, if a condition evaluates as true, the step is bypassed—a concept summarized by the phrase "If true, skip." Conditions apply relative to preceding steps:

<syntaxhighlight lang="jcl"> //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>

The interpretation is as follows: 1. Execute STEP01 and record its return code. 2. Omit STEP02 if 4 is greater than STEP01’s return code. 3. Skip STEP03 if any prior return code is less than or equal to 8. 4. Run STEP04 only if STEP01 ended abnormally. 5. Execute STEP05 regardless of whether STEP03 ended abnormally.

Understanding COND parameters often benefits from reading conditions in reverse order—a logical inversion technique.

IBM later introduced IF constructs in JCL to simplify conditional logic while maintaining COND for compatibility with existing scripts.

Additionally, the COND parameter can be specified on the JOB statement itself; if its condition is met for any step within that job, processing halts immediately.

Utilities

In batch processing environments, jobs rely on a variety of IBM utility tools to facilitate data handling. These tools are categorized into three main groups:

Data Set Utilities – Responsible for creating, printing, copying, relocating, and deleting data sets.
System Utilities – Oversee management of catalogs and system-related information.
Access Method Services – Manage both Virtual Storage Access Method (VSAM) and non-VSAM data sets.

Ease of Use Challenges

OS JCL is widely recognized for its complexity and has been characterized as "unfriendly to users." Historically, many developers have steered clear of fully learning JCL, often replicating control cards without comprehensive understanding or leaving the task to dedicated experts. Programming literature traditionally emphasized programming languages rather than job execution control, reflecting this hesitance. For instance, a Fortran IV manual cautioned against composing 'DD' system control cards without assistance.

Nonetheless, mastering JCL can provide considerable benefits by enabling enhanced command over workload processing beyond default configurations. Some instructional materials reassure that the fundamental JCL competencies required by most programmers are attainable.

Job Entry Control Language

On IBM mainframe platforms, Job Entry Control Language (JECL) consists of command language statements that govern the spooling subsystem—namely JES2 or JES3 on z/OS or VSE/POWER within z/VSE. JECL defines parameters for job execution such as the destination network node, scheduling, and output routing.

JECL is distinct from job control language (JCL), which instructs the operating system on job execution procedures.

Different implementations of JECL exist depending on the environment.

OS/360

An early iteration of JECL for OS/360 Remote Job Entry used the marker .. in columns 1–2 and contained a single control directive: JED (Job Entry Definition). Commands issued from workstations like LOGON, LOGOFF, and STATUS also began with ...

pre-JES JECL

Prior to the formal designation of JECL, HASP provided comparable capabilities to JES JECL, utilizing a syntax such as /*.

z/OS

For JES2 under z/OS, JECL statements begin with /*, while JES3 statements start with //*, except for remote commands like /*SIGNON and /*SIGNOFF. The command sets differ markedly between JES2 and JES3.

JES2 JECL

Typical JES2 JECL commands in z/OS 1.2.0 include:

JECL statement	Purpose	Example
`/*$command`	Operator console command	`/*$S PRINTER3`
`/*JOBPARM`	Defines job-specific parameters	`/*JOBPARM TIME=10`
`/*MESSAGE`	Sends message to operator console	`/*MESSAGE CALL JOE AT HOME IF JOB ABENDS`
`/*NETACCT`	Specifies network job account number	`/*NETACCT 12345`
`/*NOTIFY`	Indicates notification recipient	`/*NOTIFY SAM`
`/*OUTPUT`	Configures SYSOUT dataset options	`/*OUTPUT FORMS=BILL`
`/*PRIORITY`	Assigns job priority level	`/*PRIORITY 15`
`/*ROUTE`	Directs output destination or execution node	`/*ROUTE PRT RMT5`
`/*SETUP`	Requests volume mounting or offline operation	`/*SETUP TAPE01,TAPE02`
`/*SIGNOFF`	Terminates remote session	`/*SIGNOFF`
`/*SIGNON`	Initiates remote session	`/*SIGNON REMOTE5 password`
`/*XEQ`	Specifies execution node location	`/*XEQ DENVER`
`/*XMIT`	Marks job or dataset for transmission to another node	`/*XMIT NYC`

JES3 JECL

The JES3 JECL commands utilized in z/OS version 1.2.0 include the following:

JECL Statement	Purpose	Sample
`//**command`	Issues a JES3 operator (console) command
`//*DATASET`	Denotes the start of an in-stream dataset
`//*ENDDATASET`	Indicates the conclusion of an in-stream dataset
`//*ENDPROCESS`	Marks the termination of a sequence of `//*PROCESS` commands
`//*FORMAT`	Defines options for `SYSOUT` datasets
`//*MAIN`	Sets parameters related to the job
`//*NET`	Establishes job relationships using JES3 dependent job control
`//*NETACCT`	Assigns an account number for a networked job
`//*OPERATOR`	Sends messages directly to the operator console
`//*PAUSE`	Halts the input reader temporarily
`//*PROCESS`	Identifies a job as non-standard
`//*ROUTE`	Determines the node where the job will execute
`/*SIGNOFF`	Terminates a remote session	`/*SIGNOFF`
`/*SIGNON`	Initiates a remote session

z/VSE

In VSE, JECL statements begin with '* $$' (preceded by a single space). These Job Entry Control Language commands define job boundaries and direct VSE/POWER on how to process jobs, including specifying job names, processing classes, and disposition codes such as D, L, K, and H.

JECL Statement	Purpose	Sample
`* $$ CTL`	Sets a default input class	`* $$ CTL CLASS=A`
`* $$ JOB`	Defines job characteristics	`* $$ JOB JNM=PYRL,PRI=9`
`* $$ EOJ`	Indicates the end of a job stream	`* $$ EOJ`
`* $$ RDR`	Inserts data from a 3540 diskette into the input stream	`* $$ RDR SYS005,'fname',2`
`* $$ PRT`	Specifies attributes for spooled print files (also known as "LST")	`* $$ PRT FNO=STD,COPY=2`
`* $$ PUN`	Defines characteristics for spooled punch files	`* $$ PUN DISP=T,TADDR=280`
`* $$ SLI`	Inserts data ("book") from a source statement library into the input stream	`* $$ SLI A.JCL1`
`* $$ DATA`	Inserts card reader data into a book retrieved from source statement library	`* $$ DATA INPUT1`

Illustration: <syntaxhighlight lang="jcl">

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

[Insert JCL statements here]

$$ EOJ

</syntaxhighlight>

Other systems

Various other mainframe batch platforms implemented job control languages with unique syntax differing from IBM's offerings, yet delivered comparable capabilities. These systems often used control cards distinguished by special markers such as an initial dollar sign, with commands like $JOB commonly designating the start of a job stream.

Interactive systems incorporate "command languages"—scripts such as PCDOS ".bat" files—that execute without user interaction but typically lack the extensive features found in JCL designed for unattended batch processing. On certain platforms, command languages used for interactive sessions are separate from those controlling batch jobs; for example, TSO on z/OS uses CLIST or Rexx for interactive commands while relying on JCL for batch operations. In contrast, some environments unify these languages within one framework.

Sources