JCL (Job Control Language) is a scripting language used on IBM mainframe operating systems (z/OS, OS/390, MVS) to instruct the operating system how to run batch jobs. It tells z/OS: what program to run, what data sets (files) to use, and how to allocate resources like memory and CPU time. JCL is the glue between business applications and the z/OS operating system.

The three main JCL statement types are:

1. JOB — The first statement in every job. Defines job name, accounting information, class, and priority.
2. EXEC — Identifies the program (PGM=) or catalogued procedure (PROC=) to execute in a job step.
3. DD (Data Definition) — Describes every data set (file) used by the job, including its name, organisation, space, and disposition.

Every JCL job must begin with a JOB statement, followed by one or more EXEC statements, each typically followed by DD statements.

A JCL statement occupies columns 1–80 of a record:

• Column 1–2: // (double slash) — identifies the line as a JCL statement
• Column 3–10: Name field (job name, step name, or DD name) — left-justified, 1–8 characters
• Column 12+: Operation (JOB, EXEC, DD) followed by parameters

Example:

A /* in columns 1–2 indicates the end of in-stream data. A * in column 3 (i.e., //*) is a JCL comment.

The JOB statement is the first statement in every JCL job and identifies the job to the operating system.

Key parameters:

• Accounting information — positional parameter, typically in parentheses
• Programmer name — positional parameter in quotes
• CLASS — job class determining execution priority and routing
• MSGCLASS — output class for the job log (sysout)
• NOTIFY — TSO user ID to notify on job completion
• REGION — maximum virtual storage the job can use
• TIME — maximum CPU time allowed
• TYPRUN=SCAN — syntax-checks JCL without executing it

Example:

The EXEC statement identifies the program or procedure to execute in a job step.

Two forms:

• EXEC PGM=programname — executes a load module directly
• EXEC PROC=procname or just EXEC procname — invokes a catalogued or in-stream procedure

Key parameters:

• PGM — name of the load module to execute
• PARM — passes a parameter string to the program (max 100 chars unless extended)
• COND — conditional execution based on return codes from previous steps
• REGION — memory allocation override for this step
• TIME — CPU time limit for this step

Example:

DISP (Disposition) is one of the most important DD parameters. It has three sub-parameters:

DISP=(status,normal-disposition,abnormal-disposition)

Status — the state of the data set when the step starts:

• NEW — data set does not exist, create it
• OLD — data set exists, exclusive control
• SHR — data set exists, shared access (multiple jobs can read)
• MOD — extend an existing sequential data set, or create if new

Normal disposition — what to do if the step completes normally:

• KEEP — keep the data set but don't catalogue
• CATLG — keep and catalogue
• DELETE — delete the data set
• PASS — pass to a later step in the same job

Abnormal disposition — what to do if the step abends:

• Same options as normal disposition
• If omitted, the normal disposition is used

Example: DISP=(NEW,CATLG,DELETE) — create new, catalogue on success, delete on abend.

• DISP=OLD requests exclusive control of the data set. No other job or step can access it simultaneously. Use OLD when you intend to update or write to the data set, to prevent concurrent access conflicts.
• DISP=SHR requests shared access. Multiple jobs can open the data set concurrently in read mode. If one job writes while another reads with SHR, data integrity is not guaranteed.

Rule of thumb: use SHR for read-only access, OLD for write or update operations.

The DD (Data Definition) statement describes a data set used by a program. Every dataset referenced in a program must have a corresponding DD statement (or the program will receive a JCL error for missing DD).

Key parameters:

• DSN / DSNAME — data set name
• DISP — disposition (see above)
• UNIT — device type (SYSDA for disk)
• SPACE — space allocation for new data sets (tracks, cylinders, or blocks)
• DCB — data set characteristics (RECFM, LRECL, BLKSIZE)
• SYSOUT — routes output to a sysout class instead of a data set
• DUMMY — nullifies the DD; reads return EOF immediately, writes are discarded
• * — in-stream data follows immediately after the DD statement

Example:

SYSOUT=* routes a program's output to the same output class specified by the MSGCLASS parameter on the JOB statement. It is the most common way to direct print output to the JES spool for viewing in SDSF or similar tools.

You can also specify a specific class: SYSOUT=A routes to output class A. The * is simply shorthand for "same as MSGCLASS."

IEFBR14 is a do-nothing IBM utility program — its entire source code is a single branch-and-return instruction. It is used when you need JCL to perform DD-level operations (allocate, catalogue, or delete data sets) without actually running any application logic.

Common uses:

• Allocate a new data set: EXEC PGM=IEFBR14 with a DD that has DISP=(NEW,CATLG)
• Delete a data set: EXEC PGM=IEFBR14 with a DD that has DISP=(OLD,DELETE)
• Uncatalogue a data set: DISP=(OLD,UNCATLG)

It always returns condition code 0.

REGION specifies the maximum amount of virtual storage (memory) that a job or step may use. It can be specified on both the JOB statement (applies to the entire job) and the EXEC statement (applies to that step only — overrides the JOB-level REGION for that step).

Syntax: REGION=nnnnK (kilobytes) or REGION=nnM (megabytes) or REGION=0M (unlimited, subject to system limits).

If a program tries to use more storage than REGION allows, it abends with S80A (region too small). Setting REGION=0M is common in modern z/OS where 64-bit addressing makes storage concerns less critical.

TIME specifies the maximum CPU time allowed for a job or step.

Syntax:

• TIME=(minutes,seconds) — e.g., TIME=(5,30) = 5 minutes 30 seconds
• TIME=1440 — special value meaning no time limit (1440 minutes = 24 hours)
• TIME=NOLIMIT — equivalent to 1440

If a job or step exceeds its TIME limit, it abends with S322 (time limit exceeded). TIME on the EXEC statement overrides TIME on the JOB statement for that step.

A condition code (return code) is a numeric value (0–4095) returned by a program to indicate success or failure. Conventions: 0 = success, 4 = warning, 8 = error, 12/16 = severe error.

The COND parameter on the EXEC statement controls whether a step executes based on the condition codes of previous steps.

Syntax: COND=(value,operator) — if the condition is true, the step is skipped.

Operators: GT, LT, EQ, NE, GE, LE

Example:

• COND=(0,NE) — skip this step if any previous step returned anything other than 0
• COND=(4,LT) — skip this step if any previous return code is less than 4 (i.e., skip if all OK)
• COND=(8,LE,STEP1) — skip if STEP1's return code is ≤ 8

COND=EVEN runs the step even if a previous step abended. COND=ONLY runs the step only if a previous step abended.

Both define load libraries where z/OS looks for programs to execute.

• JOBLIB — placed after the JOB statement (before any EXEC). Applies to all steps in the job. z/OS searches JOBLIB before the system linklist.
• STEPLIB — placed within an EXEC step (after the EXEC statement). Applies only to that step. STEPLIB overrides JOBLIB for that step — when STEPLIB is present, JOBLIB is not searched for that step.

Important: if neither JOBLIB nor STEPLIB is specified, z/OS searches only the system linklist (LNKLST).

In-stream data is data embedded directly within the JCL job stream, between a DD * statement and a /* delimiter.

The /* in columns 1–2 terminates the in-stream data. If the data itself might contain /*, use the DLM parameter to specify a different delimiter:

In-stream data is common for utility control statements (SORT, IDCAMS, IEBGENER).

SPACE allocates disk space for a new data set.

Syntax: SPACE=(unit,(primary,secondary,directory),RLSE)

• unit: TRK (tracks), CYL (cylinders), or blocksize
• primary: initial allocation amount
• secondary: additional extents allocated when primary is exhausted (up to 15 extents)
• directory: number of directory blocks (for PDS only)
• RLSE: release unused space at job end

Example: SPACE=(CYL,(5,2),RLSE) — allocate 5 cylinders initially, extend by 2 cylinders if needed, release unused.

A data set can have up to 16 extents total (1 primary + 15 secondary). If all extents are used and more space is needed, the job abends with B37 (out of space).

A GDG is a group of related, chronologically organised data sets. Each new version is a "generation."

Relative references:

• GDG(0) — current (latest) generation
• GDG(-1) — previous generation
• GDG(+1) — next generation (creates a new generation when used with DISP=NEW)

GDG Base must be defined first using IDCAMS DEFINE GDG. The base specifies the LIMIT (max generations to keep) and whether to SCRATCH (delete) or NOEMPTY old generations.

Usage:

GDGs are commonly used for daily backup files, audit trails, and rolling archives.

A PDS (Partitioned Data Set) is a data set divided into members, similar to a directory of files. Each member has an 8-character name. The PDS directory block at the beginning of the data set contains a list of member names and their locations.

Common uses:

• JCL procedures (JCLLIB)
• Source code libraries
• Load module libraries (executable programs)
• REXX or CLIST script libraries

Modern mainframe uses PDSE (Partitioned Data Set Extended) which removes the 16-member directory block limit and supports automatic compression.

DD reference to a PDS member:

These DCB sub-parameters describe the physical structure of a data set's records:

• RECFM (Record Format):

  • F — Fixed length records
  • FB — Fixed Block (most common for batch files)
  • V — Variable length records
  • VB — Variable Block
  • U — Undefined (load modules)

• LRECL (Logical Record Length): the length of each record in bytes. For FB files, all records are exactly LRECL bytes. For VB files, this is the maximum record length.

• BLKSIZE (Block Size): the physical block size on disk. Larger blocks = better I/O performance. BLKSIZE must be a multiple of LRECL for FB. Setting BLKSIZE=0 lets z/OS determine the optimal block size automatically.

Example: DCB=(RECFM=FB,LRECL=80,BLKSIZE=800) — fixed 80-byte records, 10 records per block.

DD DUMMY (or DD DSN=NULLFILE,DISP=SHR) creates a null data set:

• Reads from a DUMMY DD return an immediate end-of-file (EOF) condition
• Writes to a DUMMY DD are silently discarded

Common uses:

• Suppress optional output (e.g., suppress a SYSPRINT report during testing)
• Simulate a missing file without changing program code
• Performance testing without I/O overhead

Example:

DSN (or DSNAME) specifies the name of a data set. Rules:

• Maximum 44 characters total
• Made up of qualifiers (1–8 characters each) separated by periods
• Each qualifier: letters, digits, @, #, $, and hyphen (cannot start with a digit or hyphen)
• Maximum 22 qualifiers

Conventions vary by shop but typically follow: SYSTEM.USERID.APPNAME.TYPE.QUALIFIER

Example: MY.PROD.PAYROLL.DATA.D20260419

Special values:

• DSN=&&TEMPFILE — a temporary data set (double ampersand), automatically deleted at job end
• DSN=*.STEP1.DDNAME — a backward reference to a data set defined in a previous step

Temporary data sets are created for use within a single job and automatically deleted at job end.

Two naming methods:

1. DSN=&&name — explicitly named temporary data set. Can be referenced by name in later steps.
2. No DSN specified — system generates a unique name.

To pass a temporary data set between steps:

DISP=PASS in STEP1 keeps the data set available to subsequent steps. The system automatically deletes all unreferenced temporary data sets at job end.

Data set concatenation allows multiple data sets to be presented to a program as a single logical file. All data sets after the first DD share the same ddname but have no name in the name field.

The program reads through all three data sets sequentially as if they were one. Rules:

• All data sets should have the same RECFM and LRECL
• Maximum 255 data sets in a concatenation
• BLKSIZE is taken from the first DD; subsequent DDs may differ in physical block size but z/OS handles it

JCLLIB (procedure library concatenation) and STEPLIB concatenations work the same way.

JCLLIB defines one or more libraries where z/OS will search for catalogued JCL procedures (PROCs). It is placed after the JOB statement and before any EXEC statement.

When EXEC MYPROC is encountered, z/OS searches:

1. The libraries listed in JCLLIB ORDER= (left to right)
2. Then the system procedure libraries (PROCLIB concatenation)

Unlike JOBLIB/STEPLIB (which locate programs), JCLLIB locates JCL procedures.

Catalogued procedure: A pre-written JCL procedure stored as a member in a procedure library (PROCLIB or a JCLLIB library). Referenced by EXEC PROCNAME. Promotes reuse and centralised maintenance.

In-stream procedure: A procedure defined within the same JCL job, between //procname PROC and // PEND statements.

In-stream procedures cannot reference other procedures and must appear before their first use. They are useful for testing before promoting to a catalogued procedure.

To override a DD in a catalogued procedure, reference it as stepname.ddname:

Rules:

• The override DD must follow the EXEC statement that invokes the procedure
• All overrides for a given proc step must be grouped together
• You can override DCB, DISP, DSN, and most other parameters
• Specifying //stepname.ddname DD DUMMY suppresses a DD that was defined in the proc

For multi-step procedures, the step name in the procedure is used:

Symbolic parameters (denoted with &) allow procedures to accept values passed from the invoking JCL, making procedures reusable.

Definition in procedure:

Invoking with values:

System symbolic parameters (automatically set by JES):

• &SYSUID — current TSO user ID
• &SYSDATE — current date
• &SYSTIME — current time
• &SYSNODE — JES node name

Double && escapes to a single & in output (for temporary data set names).

The OUTPUT statement defines characteristics for SYSOUT data sets — controlling how printed output is handled by the JES output writer.

Key parameters:

• COPIES — number of copies to print
• DEST — output destination (printer name or remote node)
• CLASS — output class
• HOLD — YES/NO, holds output on the spool
• FORMS — forms name for special paper

The OUTPUT statement is referenced from DD statements using OUTPUT=*.outputname:

OUTPUT statements can be defined at the job level (before any EXEC) or at the step level.

TYPRUN=SCAN is a JOB statement parameter that tells z/OS to scan (syntax-check) the JCL without actually executing any steps. The job goes through JES2/JES3 interpretation and JCL validation but no programs run.

Use it during development to catch:

• Invalid statement syntax
• Missing required parameters
• Undefined procedure references
• Basic DD parameter errors

Example:

The JES job log will show any JCL errors found. Note: TYPRUN=SCAN checks syntax only — it cannot detect runtime errors or logic problems.

RESTART allows a job to restart from a specified step rather than from the beginning. Used to re-run jobs that failed partway through without repeating successfully completed steps.

Syntax: RESTART=stepname or RESTART=stepname.procstep

Important considerations:

• Data sets created in skipped steps must be available (not cleaned up)
• DISP=MOD may be needed to append rather than overwrite partially written output
• GDG relative references are resolved at JES input time, so (+1) generations from skipped steps may cause issues

RESTART=* restarts from the beginning (the default, same as not specifying RESTART).

A backward reference (also called a referback) lets a later DD statement reference a data set defined in a previous DD statement, without repeating all the parameters.

Syntax: DSN=*.stepname.ddname or DSN=*.stepname.procstepname.ddname

Example:

The backward reference *.STEP1.OUTPUT inherits the DSN, UNIT, and SPACE from the original DD. Only DISP needs to be re-specified (it defaults to OLD if omitted).

Backward references are commonly used with temporary data sets passed between steps.

The INCLUDE statement incorporates pre-written JCL segments (stored as PDS members) into a job stream at the point where the INCLUDE appears.

Syntax: // INCLUDE MEMBER=membername

The INCLUDE source library must be defined in a JCLLIB statement.

INCLUDE groups can contain DD statements, OUTPUT statements, or even EXEC steps. They promote JCL reuse for common DD concatenations, output routing, or standard step sequences. INCLUDEs cannot be nested.

The SET statement assigns a value to a symbolic parameter, making it available throughout the rest of the job (or within a procedure).

SET is useful for:

• Setting a date once and using it in multiple DSNs
• Switching between environments (PROD/TEST) with a single change
• Defining shared symbolic parameters used across multiple steps

A SET can be overridden by a later SET statement. Symbolic parameters set via SET cannot override values passed when invoking a procedure — procedure-invocation overrides take precedence.

JCL IF/THEN/ELSE/ENDIF allows conditional step execution based on return codes — a more readable alternative to the COND parameter.

Relational operators: EQ, NE, GT, GE, LT, LE, =, >, <

Special condition keywords:

• RC — return code
• ABEND — step abended (TRUE/FALSE)
• RUN — step actually ran (TRUE/FALSE)

IF/THEN/ELSE is generally preferred over COND because it is more readable and allows ELSE clauses, which COND does not support.

A job can be submitted from a running program by writing JCL to the INTRDR (Internal Reader) — a special SYSOUT destination that feeds JCL directly into JES for execution.

JCL DD statement:

From COBOL, write JCL records to the file defined by this DD name:

The Internal Reader processes the written JCL and submits it to JES as a new job. This technique is used for dynamic job generation — for example, creating personalised batch jobs at runtime based on data read from a database.

IEBGENER is an IBM utility that copies sequential data sets or PDS members. It is the workhorse copy utility for flat files.

Standard copy:

With control statements (SYSIN not DUMMY), IEBGENER can also:

• Select specific records
• Reformat records (change field positions, create headers/trailers)
• Copy PDS members to sequential files

SYSIN DD DUMMY means copy with no transformation.

IEBCOPY is the IBM utility for copying, merging, compressing, and selectively copying members of PDS or PDSE data sets.

Common uses:

1. Compress a PDS (reclaim space from deleted members):

2. Copy selected members between libraries:

,,R means replace if the member already exists in the target. Without R, existing members are not overwritten.

IDCAMS (Access Method Services) is the primary IBM utility for managing VSAM data sets and catalogues. Key functions:

• DEFINE CLUSTER — create a VSAM data set (KSDS, ESDS, RRDS, LDS)
• DEFINE GDG — create a GDG base
• DELETE — delete data sets and catalogue entries
• REPRO — copy data between VSAM and sequential files
• LISTCAT — list catalogue entries and attributes
• ALTER — change data set attributes
• PRINT — print VSAM data set contents

Example (delete and redefine a VSAM file):

SET MAXCC=0 resets the condition code after DELETE (which would be non-zero if the file didn't exist).

DFSORT (or Syncsort) is the mainframe sort/merge utility. It reads records, sorts or merges them, and writes output.

Key DD names:

• SORTIN — input data set
• SORTOUT — output data set
• SYSIN — control statements
• SYSOUT — messages
• SORTWK01–SORTWK16 — work data sets (optional; DFSORT manages them automatically)

Basic sort example:

FIELDS=(start,length,format,direction):

• CH = Character, ZD = Zoned Decimal, PD = Packed Decimal, BI = Binary
• A = Ascending, D = Descending

DFSORT can also MERGE, COPY (with INCLUDE/OMIT selection), INREC/OUTREC reformatting, and SUM to aggregate fields.

IKJEFT01 is the TSO terminal monitor program (TMP). Running it in batch allows TSO commands, CLIST scripts, and REXX execs to be executed in a batch job environment.

Common uses:

• Running REXX execs in batch
• Executing ISPF services in batch
• Running DB2 commands (DSN SYSTEM(DB2P))
• Running RACF commands
• Batch FTP using the TSO FTP client

• IEFBR14 — a no-op program used purely to trigger JCL DD processing (allocate/delete/catalogue data sets via DD dispositions). Returns CC=0 always. The standard modern choice.

• IEHPROGM — an older IBM utility for cataloguing, uncataloguing, scratching, and renaming data sets. Pre-dates IDCAMS. Largely superseded by IDCAMS for catalogue operations and IEFBR14 for simple allocations.

IEHPROGM uses the older CVOL (Control Volume) catalogue structure and is rarely seen in modern z/OS shops. IDCAMS is the preferred tool for all catalogue management. IEFBR14 is still heavily used for simple allocate/delete operations without needing IDCAMS syntax.

DSNTYPE specifies the type of data set to allocate:

• DSNTYPE=LIBRARY — allocates a PDSE (Partitioned Data Set Extended) instead of a traditional PDS
• DSNTYPE=PDS — explicitly requests a traditional PDS
• DSNTYPE=BASIC — basic sequential data set
• DSNTYPE=LARGE — large format sequential data set (>65535 tracks)
• DSNTYPE=EXTREQ — extended format required (striped data set)

PDSE (DSNTYPE=LIBRARY) is preferred over PDS in modern shops because:

• No compression needed (no wasted space from member deletions)
• No directory block limit
• Members can be shared between jobs more safely
• Supports program objects (load modules) with extended attributes

DB2 batch programs are run using the DB2 call attach facility through the DSN TSO command processor:

Key points:

• IKJEFT01 is used as the executing program (TSO TMP)
• DSN SYSTEM() connects to the DB2 subsystem
• RUN PROGRAM() specifies the application program
• PLAN() specifies the DB2 application plan (bound from DBRM)
• Program DD names are placed after SYSTSIN in the JCL step

System abend codes (Sxxx) indicate operating system errors:

User abend codes (Uxxxx) are set by application programs.

JCL Error: Detected before execution begins, during JES input processing. Causes the entire job to fail with JCL ERROR status.

Common JCL errors:

• Syntax errors (misspelled keywords, missing commas)
• Referencing an undefined DD name in a backward reference
• Procedure not found
• Invalid parameter values
• Missing required parameters

Program Abend (Abnormal End): Occurs during step execution. The job log shows the abending step, the abend code, and a dump (if SYSUDUMP or SYSABEND DD is present).

Common causes:

• S0C4 (storage violation) — subscript out of bounds, bad pointer
• S0C7 (data exception) — moving non-numeric data into numeric field
• SB37/SD37 — ran out of disk space
• S806 — load module not found at runtime (library issue at execution time vs JCLLIB issue)

JCL errors result in no steps running; abends result in the specific step failing.

Both DD names trigger a formatted storage dump when a program abends — essential for debugging.

• SYSUDUMP — produces a formatted dump of the failing task's virtual storage. Smaller and faster to produce. Most commonly used.
• SYSABEND — produces a dump of the task plus the z/OS nucleus. Much larger. Used when the abend is suspected to be in system code.
• SYSMDUMP — produces an unformatted dump to a data set for later processing by IPCS (Interactive Problem Control System). Used for complex debugging requiring IPCS analysis.

Best practice: always include //SYSUDUMP DD SYSOUT=* in every job step so you have dump data if an unexpected abend occurs.

If the DD is absent when a program abends, no dump is produced and debugging is much harder.

S806 means the program could not be found in any load library. This is a load failure — z/OS searched all available libraries and did not locate the requested load module.

Causes and fixes:

1. Program name misspelled in the EXEC PGM= parameter — verify spelling
2. Missing STEPLIB or JOBLIB — the load library containing the program is not referenced
3. Library not in LNKLST and no STEPLIB/JOBLIB — add STEPLIB pointing to the correct library
4. Wrong environment — pointing to a TEST library when you need PROD or vice versa
5. Program not compiled/linked yet — the source exists but the load module was never created
6. Authorisation issue — APF-authorized libraries must be APF-authorized; if not, the load is rejected

Check JOBLIB and STEPLIB DDs and verify the load module exists in those libraries using ISPF option 3.4.

All three are "out of space" abends for sequential or PDS data sets:

Fixes:

1. Increase primary allocation: SPACE=(CYL,(10,2)) instead of (1,1)
2. Add or increase secondary allocation: ensure secondary is specified
3. Use RLSE to free unused space in prior steps to prevent fragmentation
4. Delete and reallocate the data set with a larger allocation
5. Use DSNTYPE=LARGE for very large sequential data sets
6. Switch to VSAM for data sets that grow unpredictably

For production jobs, monitor space usage with LISTCAT and proactively increase allocations before they run out.

When a job shows "JCL ERROR" or no steps executed, follow this diagnostic path:

1. Check the JES job log (in SDSF, browse the job's JESMSGLG dataset) — JES error messages are in the JESJCL and JESYSMSG outputs.

2. Look for JCL error messages: messages starting with IEF, IEF2, or IEC indicate specific JCL problems. The message text explains the error.

3. Use TYPRUN=SCAN: add TYPRUN=SCAN to the JOB statement and resubmit. z/OS will only check syntax without executing.

4. Common issues to check:

   • Missing or misspelled procedure in JCLLIB
   • Referencing a data set that doesn't exist with DISP=OLD (use DISP=SHR or check if the data set exists)
   • Wrong JCLLIB (pointing to wrong procedure library)
   • Invalid characters in data set names
   • COND or IF condition skipping all steps from the start

5. Check IF/THEN blocks: an always-true IF condition that skips all subsequent steps will result in no steps running.

After a job runs, its SYSOUT (spool output) is in one of two states:

• HOLD: Output remains on the JES spool indefinitely, waiting for operator or user action. Not sent to a printer or purged. Used to review output before printing, or to prevent automatic purging of important output.

  • Can be set via: OUTPUT HOLD=YES statement, or operator command $HOJ jobname

• RELEASE: Output is released for processing — sent to the designated printer or output class handler, then purged after printing.

  • Release via: SDSF =R command, or operator command $AOJ jobname

HELD output is visible in SDSF's H (held output) panel. Output in the output queue (not held) is visible in the O panel.

Setting MSGCLASS=H on the JOB statement is a common convention to hold the job log in SDSF for review, preventing it from being automatically purged after the job ends.