JES 2

JES 2 provides the facilities to ensure the jobs submitted are processed efficiently.

There are Checkpoints that ensure recoverability, RJE (Remote Job Entry) and NJE (Network Job Entry) systems for load sharing, spooling and monitoring for the job activity.

JES2 has a rich set of commands that can be entered at any console, or if you have the authority, via SDSF

JES2 commands need to be prefixed by a dollar sign $ but this can be substituted for another prefix.
For example a command to display a job with the ID of 18332 would be $DJ18832

There are special JES2 control statements that can be added to JCL overview, to allocate or change default values. In this case, the JCL line must start with /^ instead of the usual //

Most jobs will be submitted to JES2 through TSO or a scheduling package and will be sent to an internal reader, however RJE and NJE can also be used!

It's important to note that the jobs are not necessarily processed in the order that they are received in. The order of the jobs will depend on what class of JES2 Initiators are available and the priority of the jobs submitted. Only when two jobs have the same class and priority and would be "fighting" for an initiator does the time of submission come into consideration.

A batch job will usually create two types of output. One relating to reports or data produces by the user program, while the other has system information that is related to the processing of the job itself.

Each submitted job will be assigned a unique job number that it will keep until it is purged from the system.

Starting JES2

Normally, a JES2 start is specified in the IPL parameters and starts automatically. If the JCL procedure used for starting JES2 does not contain start-up options then you might be given a WTOR message like this

* id $HASP426 SPECIFY OPTIONS - JES2 z/OS 2.5 SSNAME=JES2

When broken down

Each site will have a standard reply to the Specify Options message in their procedures manual
Some of the more common ones can be seen below:

When not started at IPL, JES2 can be started from the console (with an MVS command)

S JES2

This will likely result in the need for one of the WTOR responses outlined above

For example

R 01,WARM,NOREQ

The completion of the JES2 startup cna be shown by the message $HASP492

if the REQ option was specified, then a $HASP400 ENTER REQUESTS message might appear. This will allow the operator to issue $S to start JES2 processing.

Starting JES2 in a MAS environment

When the first system has started EJS2 the startup of the subsequsnt members will be changed from a warm start to a quick start.

A quick start is similar to a warm start, where the output remains on the spool, but the job queue and output tables are not updated - making the startup faster.

Stopping JES2

Stopping JES2 processing without stopping JES2 iteslf

If you need to stop JES2 processing, but not shut it down (for example allowing it to continue accepting jobs on the internal reader) you can issue $P command.

This will stop all of the initiators, printers, punches, transmitters after they complete their current activity.

Even though no new work is allowed, JES2 will accept new jobs (and hold them)

Graceful shutdown of JES2

To gracefully shut down JES2 you can issue $PJES2
If there is any job processing that is ongoing or any devices are active JES2 will display information that JES2 cannot be removed because of it. If you have the authority, you can issue commands to attempt to end it.

Below are some messages that you might see when issuing $PJES2

Pasted image 20241207190835.png

Abnormal shutdown

Sometimes a clean shutdown of JES2 will not be possible

When some error conditions precede the shutdown of JES2, such as SQA shortages, there may be tasks left active on the system.
There are a few commands that can be used to terminate JES2 in an abnormal way

$PJES2,QUICK
$PJES2,TERM
$PJES2,ABEND
$PJES2,ABEND,FORCE

Those should be used after all other avenues of making the system dormant have been tried and found to be not effective.

QUICK will terminate JES with no regard for cross-system activity. It would be used when cross-system activity cannot be terminated normally. $DJES2 can be used to show cross-system activity

If JES2 still does not shot down you can use $PJES2,TERM this will allow the termination to disregard any active tasks. This will make it impossible fora warm start to happen, meaning that this should only be used where the system is to be re-IPLed

If somehow both of those options fail you can issue ABEND. This will terminate JES2 immediately and can be used to terminate JES2 and perform a hot start without an IPL when the need arises. The only activity that will be waited for is the completion of writing to a checkpoint, where this is based on a coupling facility.

After this, a WTOR message will likely be displayed, asking what type of abend should be performed. The responses to this include

ABEND,FORCE is your last resort. its results are unpredictable, it will likely damage JES2 resources, such as checkpoints. It should only be issued if you're going to be re-IPLing the system. You need to attempt a regular abend before, the system would not let you issue a forced one without tryin a normal one first

Sub notes