Deferred processing services

This section describes Deferred Processing, and how to implement and use it.

Description

Deferred Processing is a convenient way to group together jobs which are to be given "delayed services" such as overnight processing. This technique eliminates complex instructions to operators concerning when to hold or release jobs, and also ensures that Volume Lists contain the most current information available.

Suppose that you want to implement an overnight service class. Jobs submitted for overnight processing are to be processed after 10:00 PM, so they can be ready for the next business day. You have to do the following:

•  Set criteria to decide which jobs are to receive deferred processing. In this example users request the service by submitting jobs in class 'D'.
• Choose a class to be used as the class to "park" the deferred jobs. This is called a Deferred Class. The jobs are "parked" in the Deferred Class between the time they are submitted and the time you begin processing. The Deferred Class, like the Job Analysis class, is dedicated exclusively to ThruPut Manager. In this example, let's say it is '8'.

In your JAL logic, the first thing you should do is to detect jobs that are submitted for deferred processing. At the time of submission you only want JCL verification. You do not want Volume Lists or any other ThruPut Manager processing, since the job is not eligible for execution yet. Your JAL might look like this:

...
EVALUATE   DEFER ($INCLASS(D) & $CURCLASS(*))
...
IF (DEFER)      /*IS THIS FIRST PASS FOR OVERNITES?*/
    SET CLASS(8)  /*PARK JOB IN OVERNITE CLASS*/
    EXIT REQUEUE  /*EXIT IMMEDIATELY*/
ENDIF
...

The Job Property 'DEFER' represents jobs that have been submitted for overnight processing (the submission class is 'D') but they are being processed by ThruPut Manager for the first time (the current class '*' represents the primary Job Analyzer class).

Jobs submitted for "overnight" service can be "parked" in the "overnight" class immediately (in your JAL logic). In this way, because they have been processed by the Job Analyzer, their JCL has been verified to ensure there are no errors. Since you have requeued them in the overnight class they can be "reprocessed" by ThruPut Manager at the appropriate time.

At 10:00 PM, your operations group does the following:

• They assign the Deferred Class '8' to an initiator.

This way all the jobs that were "parked" in class '8' for deferred processing are reprocessed by ThruPut Manager. In your JAL (shown again below), the Job Property 'DEFER' is not true:

...
EVALUATE  DEFER ($INCLASS(D) & $CURCLASS(*))
...
   IF (DEFER)         /*IS THIS FIRST PASS FOR OVERNITES?*/
  SET CLASS(8)  /*ASSIGN PARKING CLASS*/
  EXIT REQUEUE  /*REQUEUE THEM IMMEDIATELY*/
ENDIF
...

The current class of the job is the Deferred Class '8', hence the EVALUATE statement returns a value of FALSE. This time the job can be fully processed by ThruPut Manager.

To stop accepting overnight jobs to be processed that night, your operations group does the following:

• They remove the Deferred Class '8' from the Job Analyzer initiator.

This approach works well but it can be improved. For jobs submitted for overnight processing that arrive in the system after 10:00 PM, there is no point in giving them two ThruPut Manager passes. They are eligible for processing as soon as they arrive. The external EVENT switch facility has been designed to help and complement this aspect of Deferred Processing. This is best illustrated by a simple example. The EVENT switch 'OVERNITE' (or any other name you find appropriate) is used to control the one-pass two-passes ThruPut Manager processing.

Your JAL might look like this:

...
EVENT  OVERNITE(OFF)  /*INITIAL STATE FOR EVENT*/
...
EVALUATE DEFER ($INCLASS(D) & $CURCLASS(*)) & OVERNITE
...
IF (DEFER)
  SET CLASS(8)   /*ASSIGN PARKING CLASS*/
  EXIT REQUEUE   /*REQUEUE THEM IMMEDIATELY*/
ENDIF
...

For the overnight jobs, the need for the second pass is established by the status of the EVENT OVERNITE switch. Now the procedure for initiating overnight processing is as follows:

At 10:00 PM, your operations group does the following:

• They assign the Deferred Class '8' to the Job Analyzer initiator.
• They set the OVERNITE EVENT switch to 'ON' with the ThruPut Manager command 'JAL EVENT ON OVERNITE'.

Because the OVERNITE switch is 'ON' the Job Property 'DEFER' returns a value of 'FALSE' so the overnight jobs are not placed in the "parking" class.

In situations where overnight processing is available, your installation may have a cut off point for submission. In this example, let us say it is 3:00 AM. Any job submitted for overnight processing after 3:00 AM is again "parked" until the following night.

To stop accepting work to be processed that night, at 3:00 AM your operations group does the following:

• They set the OVERNITE EVENT switch to 'OFF' with the ThruPut Manager command 'JAL EVENT OFF OVERNITE'.
• Then, they remove the Deferred Class '8' from the Job Analyzer initiator.

Deferred Processing Analyzers and Workload Manager

Once a $ACTIVATE has been done, there are multiple operating strategies available.

Using JES2 Initiators for Deferred Processing Classes

You can choose to continue just as you did before the $ACTIVATE. This is the simplest choice because there are no changes to the way things worked previously.

Using WLM Initiators for Deferred Processing Classes

If you allow WLM to manage the initiators for your Deferred Processing class, there are several considerations:

• You can assign the same service class you assigned for Job Analysis, or define a separate service class for the Deferred classes. Because deferred jobs by definition do not need immediate service, a separate service class can have less aggressive goals but still should deliver fast service to short-running transactions. The service class routine should ensure that jobs in the Deferred Processing job class are assigned the correct service class.
• Do not use this service class for purposes other than job analysis.
• WLM controls the number of Deferred Processing initiators only at the JESplex level. You can control the total number of Job Analyzers by setting the XEQCOUNT for the Deferred class, but control at the system level is not available.
• You can also control the availability of Deferred Processing initiators by defining a scheduling environment for the Deferred Processing class that is not always available.
• Because Deferred Processing accumulates jobs, consider the potential WLM reaction when the Deferred jobs are eligible for processing. For example, even if you choose to control the Deferred analysis by the availability of a scheduling environment, you might want to set the XEQCOUNT for the Deferred class to a value that ensures that WLM does not start too many initiators. You might also consider a service class that ignores queue time.

Implementation Summary

The steps for implementing Deferred Processing are:

• Determine at least one Deferred Job Analysis Class by using command /TM CLASS SET DEFER(8,9)

You need one Deferred Class per Deferred Service you want to implement. For example, if you want to provide overnight services and weekend services you need two Deferred Classes. See Command Reference Guide for TM CLASS command syntax.

• Code JAL to select jobs which should be deferred, and queue these jobs to a Deferred Job Analysis Class.
• When jobs which have been deferred are to be processed, add the Deferred Job Analysis Class to the initiator assigned to the Job Analyzer.
• When accepting Deferred Processing is to stop, remove the Deferred Class from the initiator assigned to the Job Analyzer.
• Determine if you want to control the flow of the Job Analysis for the Deferred Service with an EVENT switch.
• If EVENT is to be used, put the appropriate operating procedure in place to turn the chosen EVENT "on" and "off" at the appropriate times.
• Add logic to your JAL to test for the status of the EVENT switch and take actions accordingly.

Dependencies

You must ensure that procedures are in place to add the deferred class, or classes, to the Analyzer initiator at the appropriate time of the day.

Depending on your implementation, you could have dependencies on EVENTS.

TMSS Initialization Statements

Deferred Processing is not dependent on any TMSS initialization statements.

Facilities Summary