The job entry subsystem (JES) helps z/OS receive jobs, schedule them for processing, and determine how job output is processed.

An initiator is a system program that processes JCL, sets up the necessary environment in an address space, and runs a batch job in the same address space. Multiple initiators (each in an address space) permit the parallel execution of batch jobs.

One goal of an operating system is to process work while making the best use of system resources. To achieve this goal, resource management is needed during key phases to do the following:

-    Before job processing, reserve input and output resources for jobs.

-    During job processing, manage spooled SYSIN and SYSOUT data.

-    After job processing, free all resources used by the completed jobs, making the resources available to other jobs.

z/OS shares with the Job Entry Subsystem (JES) the management of jobs and resources. JES receives jobs into the system, schedules them for processing by z/OS, and controls their output processing. JES is the manager of the jobs waiting in a queue. It manages the priority of the jobs and their associated input data and output results. The initiator uses the statements in the JCL records to specify the resources required of each individual job after it is released (dispatched) by JES.

During the life of a job, both JES and the z/OS base control program control different phases of the overall processing. Jobs are managed in queues: Jobs that are waiting to run (conversion queue), currently running (execution queue), waiting for their output to be produced (output queue), having their output produced (hard-copy queue), and waiting to be purged from the system (purge queue).

1. WARM

- This is the default start method.

- WARM specifies that JES2 is to continue processing jobs from where they were stopped.

- If the FORMAT option was also coded, then JES2 will ignore the WARM specification and perform a cold start.

2. COLD

- COLD specifies that JES2 is to be cold-started.

- All jobs in the system will be purged and all job data on the spool volumes will be scratched which means that the existing data in JES will be totally destroyed.

3. FORMAT

- FORMAT specifies that JES2 is to format all existing spool volumes.

- With FORMAT, JES2 automatically performs a cold start.

- If you add unformatted spool volumes, JES2 automatically formats them whether FORMAT is specified or not.

The default value is NOFMT which means that JES2 is not to format existing spool volumes unless JES2 determines that formatting is required.

z/OS uses a Job Entry Subsystem (JES) to receive jobs into the operating system, schedule them for processing, and to control their output processing. The actual execution of a job is handled by an initiator.

The process of job processing can be divided into the following five stages:

- Input Phase

- Conversion Phase

- Execution Phase

- Output Phase

- Purge Phase

For JES2 these phases represent:

1. Job Input phase

JES2 jobs can be entered on input devices such as card readers, remote terminals, or other programs. Jobs can also come from other nodes in a job entry network and from internal readers. (An internal reader is a program that other programs can use to submit jobs, control statements, and commands to JES2.)

As JES2 reads the input stream, it assigns a job identifier to each job and places each job’s

JCL, optional JES2 control statements, and data within the job (SYSIN data) onto DASD data sets called spool data sets. Simultaneous peripheral operations online (Spool) refers to the direct access device that contains the spool data sets. Spooling provides simultaneous processing and a temporary storage area for work that is not yet completed.

Later on, JES2 selects jobs from the spool data sets for processing and subsequent running.

2. Conversion phase

JES2 uses a converter program to analyze each job’s JCL statements and to perform a syntax check. It also determines if the JCL includes any procedure calls. If so, the converter takes the job’s JCL and merges it with the JCL from the procedure library (for example, SYS1.PROCLIB), and converts the composite JCL into internal text.

The internal text is stored in the spool data set. If, during the job conversion any JCL errors are detected, JES2 issues the proper error messages and queues the job for output processing. If JES2 detects no errors, it queues the job for further processing according to its priority within its job class.

3. Execution phase

Before work can be processed on a z/OS system, initiators have to be started. An initiator is started either by an operator or automatically by JES2 when the system is initialized. If an initiator is ready to process work, it requests a job from JES2.

JES2 selects jobs based on the job classes that are assigned to the initiator and the priority order in which the job classes should be searched. When JES2 selects a job, it passes it to the initiator. The initiator then invokes the interpreter to build control blocks from the internal text that the converter created for the job.

The initiator allocates the resources specified in the JCL for the first step of the job. This allocation ensures that the devices are available before the job step starts running. The initiator then starts the program requested in the JCL EXEC statement.

JES2 and the base control program communicate constantly to control system processing.

The communication mechanism, known as the subsystem interface, allows z/OS to request services of JES2. For example, a requestor can ask JES2 to find a job, do message or command processing, or open (access) a SYSIN or SYSOUT data set. Further, the base control program notifies JES2 of events such as messages, operator commands, the end of a job, or the end of a task.

4. Output phase

JES2 controls all output processing, that is, system messages that must be printed, as well as data sets requested by the user that must be printed or punched. After a job finishes, JES2 analyzes the characteristics of the job’s output in terms of its output class and device setup requirements; then JES2 groups data sets with similar characteristics. JES2 queues the output for print or punch processing.

JES2 selects output for processing from the output queue. It can contain output that is to be processed locally or output to be processed at a remote location (either a remote job entry (RJE) workstation or another node known as network job entry (NJE)). After processing all the output for a particular job, JES2 puts the job on the purge queue.

5. Purge phase

When all processing for a job completes, JES2 releases the spool space assigned to the job, making the space available for allocation to subsequent jobs. JES2 then issues a message to the operator indicating that the job has been purged from the system.

To run multiple jobs asynchronously, the system must perform a number of functions:

-    Select jobs from the input queues (JES does this).

-    Ensure that multiple jobs (including TSO users and other interactive applications) do not conflict in data set usage.

-    Ensure that single-user devices, such as tape drives, are allocated correctly.

-    Find the executable programs requested for the job.

-    Clean up after the job ends and then request the next job.

Most of this work is done by the initiator, based on JCL information for each job. The most complex function is to ensure there are no conflicts due to data set utilization. For example, if two jobs try to write in the same data set at the same time (or one reads while the other writes), there is a conflict. This event would normally result in corrupted data. The primary purpose of JCL is to tell an initiator what is needed for the job.

The prevention of conflicting data set usage is critical to z/OS and is one of the defining characteristics of the operating system. When the JCL is properly constructed, the prevention of conflicts is automatic. For example, if job A and job B must both write to a particular data set, the system (through the initiator) does not permit both jobs to run at the same time. Instead, whichever job starts first causes an initiator attempting to run the other job to wait until the first job completes.