Introduction to JCL
Learn what Job Control Language (JCL) is, why every mainframe batch job depends on it, and get a first look at its three core statement types: JOB, EXEC, and DD.
Introduction
You now understand what mainframes are, how z/OS organizes work, and how datasets store and name data. But none of that explains how work actually gets started on a mainframe. When you want z/OS to run a program — read a dataset, produce a report, sort a file, execute a COBOL program — you cannot just double-click an icon or type a command at a shell prompt the way you might on a laptop. You have to describe the job, in a precise, structured language that z/OS understands: Job Control Language, universally known as JCL. This lesson is your first real look at it.
- What JCL is and what problem it solves
- Why batch jobs cannot run without it
- The three core JCL statement types: JOB, EXEC, and DD
- What a complete, minimal JCL job looks like
- The basic syntax rules JCL statements follow
- How a JCL job actually gets submitted and run
What is JCL?
JCL (Job Control Language) is a scripting language that tells z/OS three things about a piece of work: who is submitting it and under what accounting rules, what program or procedure should run, and which datasets that program should use while it runs. JCL does not contain business logic — it does not calculate anything or transform data itself. Its entire job is to describe a unit of work clearly enough that z/OS can locate the right program, connect it to the right data, and run it under the right conditions.
JCL has looked essentially the same, syntactically, since the 1960s — another example of the backward compatibility you learned about earlier in this course. A JCL job written decades ago is, in most respects, still recognizable and often still runnable today. That stability is deliberate: JCL is infrastructure that an enormous number of production systems depend on, so IBM has been extremely conservative about changing its core syntax.
If a compiled program is a chef who knows how to cook a specific dish, JCL is the order ticket: which chef to call, which ingredients (datasets) to hand them, where the finished dish should go, and who is paying for the meal. JCL never cooks anything itself — it only sets up the conditions for the program to do the actual work.
Why Every Batch Job Needs It
On z/OS, a batch job is a unit of work submitted to run without anyone interacting with it while it executes — no user sitting at a terminal answering prompts. Because nobody is present to click through menus or type file paths as the job runs, everything the job will need has to be spelled out in advance: which program to run, which datasets to read, which datasets to create or update, where messages and reports should go, and what should happen if a step fails. JCL is exactly that upfront specification. Without it, z/OS would have no way to know what a submitted job is even supposed to do.
This is also why JCL matters so much even if you never write a line of COBOL or any other application code. Systems programmers, operators, and support staff spend enormous amounts of time reading, writing, and troubleshooting JCL, because it is the layer where "what should run, using what data, in what order" is actually decided.
The Three Core Statement Types
Nearly every JCL job stream, no matter how complex, is built from combinations of just three statement types. Understanding what each one is responsible for is the single most important mental model in this entire unit — the next few lessons will each dedicate a full lesson to one of them, but here is the high-level preview.
| Statement | Starts With | Answers the Question |
|---|---|---|
| JOB | //jobname JOB | "Whose job is this, and under what rules should it run?" |
| EXEC | //stepname EXEC | "Which program or procedure should actually run in this step?" |
| DD (Data Definition) | //ddname DD | "Which real dataset does each file reference inside the program map to?" |
A job stream begins with exactly one JOB statement, but it can contain one or more EXEC statements (each one is called a "step"), and each step can have one or more DD statements supplying the data that step needs. Later lessons dig into each of these individually.
A Complete Minimal Job
It helps to see all three statement types together before studying them individually. Here is about as simple as a real JCL job gets: it runs IEFBR14, a special do-nothing IBM utility program that mainframe shops commonly use purely to create or delete datasets without running any real processing.
//STUDNT1A JOB (ACCT123),'J DOE',CLASS=A,MSGCLASS=X//STEP010 EXEC PGM=IEFBR14//NEWFILE DD DSN=STUDENT1.TEST.OUTPUT,// DISP=(NEW,CATLG,DELETE),// SPACE=(TRK,(5,5)),// DCB=(RECFM=FB,LRECL=80)Click Run to see what this code prints.
JCL Syntax Basics
JCL syntax rules trace back to the era of 80-column punch cards, and much of that legacy is still visible today. A few rules apply almost universally across every JCL statement you will write in this course.
- Every JCL statement begins with two forward slashes (//) in columns 1 and 2 — this is what marks a line as JCL rather than data.
- Column 3 onward holds the name field (jobname, stepname, or ddname), followed by at least one blank, then the statement type (JOB, EXEC, DD), then its parameters.
- Statement names (job names, step names, dd names) are limited to 8 characters and must start with a letter or a national character.
- Parameters are separated by commas with no embedded spaces; a space ends the parameter field and begins a comment.
- A statement can be continued onto the next line by ending the current line with a comma and starting the continuation in columns 4 through 16 of the next line, as the DD statement above shows.
- A comment line begins with //* and is ignored entirely by the system, useful for documenting a job stream for the next person who reads it.
//*--------------------------------------------------------//* Allocate a new test output dataset for STUDENT1//*--------------------------------------------------------//STUDNT1A JOB (ACCT123),'J DOE',CLASS=A,MSGCLASS=X//STEP010 EXEC PGM=IEFBR14//NEWFILE DD DSN=STUDENT1.TEST.OUTPUT,// DISP=(NEW,CATLG,DELETE),// SPACE=(TRK,(5,5)),// DCB=(RECFM=FB,LRECL=80)How a Job Gets Submitted
Once JCL is written and saved as a member of a partitioned dataset (or typed directly in an ISPF edit session), it has to be submitted before z/OS will act on it. From ISPF Edit, this is done with the SUBMIT command (often abbreviated SUB), which hands the job stream to JES2 or JES3 — the subsystem responsible for receiving, queuing, scheduling, and eventually running submitted jobs, and for routing their output once they finish. The job then goes through recognizable stages: input (received and queued), conversion (JCL is interpreted), execution (the program actually runs), and output (results and messages become available for review).
One reassuring property of JCL is that most syntax errors are caught during the conversion stage, before any program actually executes. If your JOB card has a typo or a DD statement references an invalid parameter, the job typically fails immediately with a clear JCL error message rather than running partway and leaving things in an inconsistent state.
Common Mistakes
- Forgetting that JCL columns matter — the // must start in column 1, and continuation lines must resume in columns 4 through 16, or the statement will not be recognized correctly.
- Confusing a JCL comment (//*) with a normal continued statement — a stray space after // without a following identifier can produce a confusing error.
- Thinking JCL performs calculations or logic itself — it only describes what should run and what data to use; all actual processing happens inside the program a step executes.
- Leaving a trailing space after a comma at the end of a line meant to be continued — anything after the required comma, including a stray space, breaks the continuation.
Best Practices
- Read new or unfamiliar JCL top to bottom once for structure (how many steps, what programs, what datasets) before trying to understand every parameter in detail.
- Comment job streams generously with //* lines, especially for anything that is not immediately obvious — future readers (including you) will thank you.
- Keep statement names short but meaningful (STEP010, STEP020) rather than cryptic, and leave numbering gaps in case a step needs to be inserted later.
- When troubleshooting a failed job, check the JCL statements themselves before assuming the problem is in the program — a large share of production issues are JCL, not code.
Frequently Asked Questions
Not in the traditional sense. JCL has no loops, conditionals, or variables of its own (beyond simple symbolic substitution in procedures, covered later). It is a job-description language: it tells z/OS what to run and what data to use, rather than performing computation itself.
You will still encounter JCL, because CICS regions themselves are started using JCL, and most systems staff regularly submit batch jobs (compiles, reports, utilities) even in shops that are heavily CICS-oriented. It is close to universal knowledge on the platform.
Because of the same backward-compatibility priority that shapes the rest of the mainframe platform. Decades of production job streams depend on the exact current syntax rules, so IBM has kept JCL's core structure stable rather than redesigning it.
In most cases, the job fails during the conversion stage, before any program runs, and JES produces a message identifying the statement and the problem. This early failure is a safety feature — it prevents a program from running with an incomplete or incorrect setup.
Key Takeaways
- JCL describes what should run and what data it should use — it does not perform processing logic itself.
- Every JCL job stream is built from combinations of three statement types: JOB, EXEC, and DD.
- JCL syntax is column-sensitive and comma-driven, a legacy of its punch-card origins that is still in force today.
- Jobs are submitted through JES2/JES3, which queues, converts, executes, and produces output for each job.
- Most JCL errors are caught early, during conversion, before any program actually runs.
Summary
JCL is the language that turns a program and a set of datasets into an actual, runnable unit of work on z/OS. You have now seen the three statement types that make up virtually every job stream, and walked through a complete minimal example line by line. In the next lesson, you will go deep on the first of those three: the JOB statement, including accounting information, job classes, and message routing.