JES2 (Job Entry Subsystem 2)

JES2 is the Job Entry Subsystem that receives jobs into z/OS, schedules them for execution, and manages their output. When you submit a job, JES2 reads it into the spool, places it on the job queue, and an initiator eventually selects it and runs it. Output from the job goes to the spool and can be viewed (e.g. via SDSF) or printed by writers. Understanding JES2 helps you understand why jobs wait in queue, how job class and priority work, and how to control and monitor batch work.

Explain Like I'm Five: What Is JES2?

Imagine a big office where lots of people hand in forms (jobs). Someone takes each form and puts it in a pile (the spool). Workers (initiators) look at the pile, pick forms they can do (by type and order), and take them to their desk to work on. When they finish, the answers go back into another pile (output). Other people (writers) take from that pile and send results to printers or screens. JES2 is the system that manages those piles and workers: it makes sure jobs get into the right queue, get picked in the right order, and that their output is stored and can be delivered.

What JES2 Does

JES2 has several main roles. First, it accepts job input: JCL and any in-stream data are read by the reader and written to the spool. The job then enters the job queue. Second, it schedules execution: initiators (one per active initiator address space) are assigned to job classes; each initiator selects jobs from the queue according to its class order and job priority, and initiates their execution. Third, it manages output: when a job step produces SYSOUT, that output is written to the spool and appears on the output queue; writers or other consumers (e.g. SDSF) read from the spool and route output to printers or displays. Finally, JES2 controls purging: when output is no longer needed, it can be purged from the spool. So from submission to purge, JES2 is in charge of the job's life outside of the actual program execution.

Main Components

The following table summarizes the main JES2 components and their roles.

The Spool

The spool is the heart of JES2 storage. It holds job input (the JCL and SYSIN data that was submitted), all SYSOUT data sets produced by the job (JESMSGLG, JESJCL, JESYSMSG, and user-defined output), and other JES-related data. The spool is usually on direct access storage (DASD). Because everything is on the spool, many jobs can be submitted without needing a physical card reader or printer per job; initiators and writers work from the spool. When you view job output in SDSF or a similar tool, you are viewing spool data. Output remains in the spool until it is purged (manually or by policy). Spool space is a shared resource; large or numerous jobs can fill the spool and affect the system, so monitoring spool usage is important.

Reader and Job Input

The reader is the component that accepts job input. In the past, input came from card readers; today it typically comes from TSO SUBMIT, RJE, FTP, or other interfaces that present data to JES2 as job input. The reader reads the input stream, identifies job boundaries (e.g. // at column 1), and writes the job (JCL and in-stream data) to the spool. The job then appears on the job queue and is eligible for selection by an initiator. So the path is: submit → reader → spool → job queue → initiator → execution.

Initiators and Job Selection

An initiator is a system task that gets work from JES2 and runs it. Each initiator is associated with one or more job classes in a defined order (e.g. class A, then B, then X). When an initiator is free, it looks at the job queue for jobs in its classes that are not held. It selects jobs in priority order within each class, and processes classes in the order configured for that initiator. So if an initiator is set up for A, B, X, it will take all available class A jobs (by priority, then FIFO) before taking class B jobs. This gives operators and installation settings control over which work runs first. The number of initiators limits concurrency: if you have 10 initiators and all are busy, an 11th job must wait until one finishes. Initiators are usually controlled via JES2 commands (start, stop, modify) or initialization parameters.

Job Class and Priority

Job class is specified on the JOB statement with the CLASS parameter (e.g. //MYJOB JOB ...,CLASS=A). It determines which initiators can run the job and, together with priority, in what order the job is selected. Priority can be set in JCL (e.g. PRTY parameter), by JES2 commands, or (on some systems) by time estimates. Within a class, higher-priority jobs are selected before lower-priority ones; among jobs with the same priority, selection is typically first-in-first-out. The following table clarifies how class and priority interact.

Output Queue and Writers

When a job or step completes, its SYSOUT data sets are on the JES2 spool and are associated with the job on the output queue. The output queue is the logical list of job output that is available to be viewed or printed. Writers are processes that read from the spool and send output to a destination—for example, a printer, a remote system, or a program that processes the output. SDSF and similar tools also read from the spool to display output on the screen. Until output is purged, it remains in the spool and can be reprinted or viewed again. Output is often identified by job name, job ID, and data set name (e.g. JESMSGLG, JESJCL, JESYSMSG, or a DD name).

JES2 vs JES3

IBM offers two job entry subsystems: JES2 and JES3. JES2 uses a peer-to-peer model: each z/OS system (or member in a sysplex) has its own JES2; each manages its own job input, job queue, and output. There is no single global job queue; work can be routed to a specific system or shared according to installation setup. JES3 uses a global processor: one (or more) global processors centralize job scheduling and can direct work to different systems in a complex. JES3 has different commands and tuning options. As of z/OS 3.1, IBM no longer includes JES3 in z/OS; only JES2 is shipped. Sites that used JES3 must migrate to JES2 or use a third-party JES3 replacement. For new work and most documentation, JES2 is the assumed subsystem.

How Your JOB Statement Relates to JES2

When you code a JOB statement, several parameters affect JES2 behavior. CLASS determines which initiators can run your job. PRTY (if supported) can influence priority. MSGCLASS (or MSGLEVEL) affects where JCL and system messages go (e.g. which output class). Other parameters might set accounting info, job name, or notify. The reader reads your entire job (all JCL and in-stream data) into the spool; the job is then on the job queue with the class you specified until an initiator picks it up.

1
2
3
//MYJOB    JOB (ACCT),'DESC',CLASS=A,MSGCLASS=H
//STEP1    EXEC PGM=IEFBR14
//SYSOUT   DD   SYSOUT=A

Here, CLASS=A means the job will run when an initiator that serves class A selects it. MSGCLASS=H routes JES and system messages to output class H. SYSOUT=A in the step sends that DD's output to the spool in class A (output class is separate from job class). After the job completes, its output is on the output queue and can be viewed or printed.

Step-by-Step: From Submit to Output

1. You submit the job (e.g. from TSO with SUBMIT, or from a scheduler). The JCL and any in-stream data are sent to JES2.
2. The JES2 reader accepts the input and writes it to the spool. The job is placed on the job queue with its class (from the JOB statement) and priority.
3. An initiator that is assigned the job's class becomes free and selects this job from the queue (according to class order and priority). The initiator initiates the job: the system runs the job steps, allocating data sets and executing programs.
4. As each step runs, any SYSOUT data sets are written to the spool. When the job completes, all of its output is on the output queue.
5. You (or a writer) view or print the output from the spool. When no longer needed, the output can be purged to free spool space.

Viewing and Managing Output

To see your job's output, you typically use SDSF (System Display and Search Facility) or an equivalent. You can list jobs by name or ID, open the job to see the output data sets (JESMSGLG, JESJCL, JESYSMSG, and any DD SYSOUT), and display or print them. JES2 commands (e.g. $DQ, $OJ) and operator panels also show job and output queue status. To free spool space, output can be purged after it is no longer needed; purge can be manual or automated by policy.

Best Practices

• Use an appropriate job class for the workload so that critical jobs run in classes with higher priority or dedicated initiators.
• Avoid holding jobs unnecessarily; held jobs consume queue space and can block other work if the class is shared.
• Monitor spool usage so that full spool does not prevent new jobs from being read or output from being written.
• Use MSGCLASS and SYSOUT classes consistently so that output is easy to find and route (e.g. to printers or archives).
• Understand your site's initiator setup (which classes each initiator serves and in what order) so you know why jobs might wait in queue.

Test Your Knowledge