Batch Processing and the Job Entry Subsystem (JES)

01 — Overview

What Is Batch Processing?

Batch processing is the execution of a program, or series of programs, against a defined set of data without requiring a person to interact with it while it runs. Think of it like a washing machine cycle, or a bakery: you load a batch, it processes, and you come back once it's done.

Batch vs. Live: Switch the Scenario

Toggle between a real overnight batch job and a real online transaction to see how differently they behave

Neither is "better" — a bank needs both: authorising your card in under two seconds right now, and reconciling every transaction from the entire day in one overnight run.

02 — The Orchestrator

What JES Actually Does

The Job Entry Subsystem, JES, is the component of z/OS responsible for managing the entire lifecycle of a batch job — from the moment it's submitted to the moment its output has been delivered and it's cleared from the system. If batch processing is the washing machine cycle, JES is the appliance itself, quietly managing the sequence of events that turns a submitted job into a completed one.

JES doesn't just move jobs through in the order they arrive, either. Alongside the Workload Manager, it handles scheduling and prioritisation — deciding which jobs get access to resources and when, based on job class, priority, and current system load. On a busy production system, there might be thousands of jobs moving through these phases at any given moment, and JES is what keeps that flow orderly rather than descending into chaos.

Job Class

A category grouping jobs with similar resource needs or execution characteristics. Installations configure how many jobs from each class can run at once.

Priority

Within a class, jobs are further ordered by priority — giving JES a clear basis for deciding which of potentially thousands of waiting jobs runs next.

Click through the five phases below to see what happens at each stage.

The Job Lifecycle

Click a phase to expand

1

Input

A job is submitted as a JCL stream. JES receives it, assigns a job name and number, and places it in the appropriate queue.

Job name & number assigned
Placed into input queue

2

Conversion

JES translates the submitted JCL into an internal format, checking it for basic syntax correctness along the way.

JCL parsed & validated

3

Processing (Execution)

The job is scheduled and dispatched, competing for CPU, memory, and I/O alongside every other job on the system.

Actual program logic executes
WLM & JES coordinate scheduling

4

Output

JES manages whatever the job produced — a printed report, a written dataset, or log messages — routing it wherever it needs to go.

SYSOUT routed / printed

5

Purge

Once output is delivered and temporary resources released, JES removes the job from the system entirely, freeing space for the next one.

Job removed from system

Live Job Queue Simulator

Submit jobs at different priorities and watch JES move them through Input → Conversion → Processing → Output → Purge — high-priority jobs get dispatched faster, exactly as JES would in production

Input

Conversion

Processing

Output

Purge

0 jobs submitted

03 — Deferred Processing

JCL Basics

Job Control Language is declarative — it describes what a job needs, not how to compute something. Click any line below to see what it actually does.

Annotated JCL Explorer

Click a line for a plain-English explanation

Tip

Click any line above to see what it does.

Writing your own JCL and want to check it's syntactically sound before you submit it? I built jclcheck.xyz — a free online JCL checker: paste in a job, and it validates statement ordering, DD rules, keyword syntax, and PROC symbolics, with plain-English errors and fixes. No mainframe connection required.

04 — Two Models

JES2 vs. JES3

IBM provides two different implementations of the Job Entry Subsystem. Both manage the same job lifecycle — they just coordinate very differently across a multi-system environment.

JES2 / JES3 Topology

SYS A
JES2

Own queue,
own decisions

SYS B
JES2

Own queue,
own decisions

SYS C
JES2

Own queue,
own decisions

Peer-to-peer. Each system in the sysplex runs its own JES2 instance. They communicate to coordinate work and share a common job queue view, but each makes many scheduling decisions independently. The more widely deployed model — valued for simplicity and flexibility.

Global
JES3

Makes all scheduling
decisions

Local
JES3

Carries out
the plan

Local
JES3

Carries out
the plan

Hub and spoke. One system acts as the global JES3, making scheduling decisions for the entire complex; other systems act as local instances carrying out that centrally coordinated plan. Gives stronger control over complex resource dependencies — found in a smaller number of large, long-established installations.

05 — Two Worlds, One Machine

Batch vs. Online (CICS)

CICS keeps transactions running continuously — short, discrete requests completing in a fraction of a second. JES-managed batch jobs have a defined beginning and end. They're complementary, not competitors.

CICS handles every card swipe throughout the day. A JES-managed batch job runs overnight to reconcile and post everything CICS captured. Same machine, two very different rhythms.

06 — Wrap Up

Summary

JES manages the entire lifecycle of a batch job — from submission through JCL-defined execution to output and purge — while CICS handles the online side. JES2's decentralised model and JES3's centralised one solve the same problem in different ways, and understanding both halves of this picture is key to understanding how a mainframe balances enormous overnight workloads with instant, everyday transactions.