Friday, September 22, 2017

What is a Job Entry Subsystem (JES)

The Job Entry Subsystem (JES) manages jobs within an z/OS system. This article discusses the various stages in the lifecycle of a job.

In my article on Job Control Language (JCL), we talked about how JCL is used. As we discussed in that article, a job is the smallest unit of work in z/OS. Also, everything that executes in z/OS requires JCL to run. There are two Job Entry Subsystems in z/OS: JES2 and JES3. This article is limited to discussions for JES2. You may want to view the Job Processing Cycle diagram in this article.

JES Devices

JES2 requires devices to read in the JCL statements. There are several ways to submit JCL. These devices can be hardware devices like readers, punchers, internal reader and remote lines. JCLs are submitted locally through reading devices and internal readers. The internal reader is a logical device that reads the JCL from DASD, tape or other devices attached to the system.

There are three types of internal readers: Batch jobs use the INTRDR. Started tasks are submitted through STCINRDR and TSO logins are submitted through TSOINRDR.

JES2 Job Conversion

When JES2 reads the JCL, it checks for syntax errors. If there are syntax errors, the job is terminated and sent to the output queue with a JCL error.

Input Queue

JES2 has an input queue. The queue holds all the jobs that had passed the conversion step. The input queue contains a queue entry for the job. There can be a maximum of 38 input queues in JES2, each processing a specific job class.

Job classes are determined from the CLASS parameter in the JCL. Jobs are queued within their class based on the priority and in the order they are placed on the queue. If a job with CLASS=A is submitted, the job is assigned a job number and placed on the queue that processes CLASS=A jobs. If another job comes in with a higher priority that this job, the new job goes higher up the queue.

An operator may change the class and priority of a job while it is in the input queue.

Once a job is in the queue, JES2 schedules the job for execution. Jobs can be submitted and then held for release at a later time. When a job is held, JES2 will not schedule the job.

Job Execution

Started tasks and TSO logins do not need initiators to execute. These are executed immediately. Batch jobs require initiators to execute. The number of initiators are defined to JES2 when JES2 starts. Initiators are assigned to process certain input queues.

An initiator can be assigned to process jobs in classes A, B, C. in this case, the initiator will process class A jobs first and will process Class B jobs only if there are no Class A jobs to execute. Class C jobs will be processed only if there are no Class A and Class B jobs.
Another initiator can be assigned to process C, B classes. In this case, the initiator will process Class C jobs first and will process Class B jobs only if there are no more Class C jobs.
During execution, a program may have to produce reports. Instead of directly writing to the printer, these reports are spooled. Spooling outputs makes processing more efficient.

An operator can change the classes that an initiator processes by entering commands to JES2. An operator may also cancel the job during its execution. Some of the reasons why an operator may cancel a job is when a program is looping, if the program is using a lot of resources, if a program is requesting a resource that is not available.

Outputs are sent to the corresponding output class. This class may be different from the class the JOB has.

Output Queue

When the job has finished execution, the outputs are queued. These can be printed or routed to other destinations. Printers are assigned classes that they can process. Once the output from a job is printed or routed, the output is purged from the queue.

Further Reading

If you wish to read more about how jobs are processed, you may read the JES2 Initialization and Tuning Guide.

No comments:

Post a Comment

Total Pageviews