Transaction Scheduling

The transaction scheduling algorithm is very sophisticated because it needs to make use of all the IMS and system resources in the most efficient manner possible. However, most users do not need to use the power of the scheduling algorithms because the resources available in IMS today (such as the number of message processing regions) are much greater than when these algorithms were designed several decades ago.

Scheduling Conditions

The following conditions must be met for successful transaction scheduling:

An MPR region must be available. Actually, the termination of a prior transaction running in an MPR region triggers the scheduling process.
A transaction input message must exist in the queue.
The transaction and its program are not in a stopped state.
Enough buffer pool storage is available to load the program specification block (PSB) and the referenced database control blocks, if not already in main storage.
The database processing intent does not conflict with an already active application program (for instance, if the active program's processing intent is declared as exclusive use). Processing intent is discussed in more detail in "Database Processing Intent" on page 212.

If the first transaction code with a ready input message does not meet all these conditions, the next available input transaction is interrogated. If no message can be scheduled, the scheduling process is stopped until another input message is enqueued. If the scheduling is successful, the IMS routines in the dependent region load the corresponding MPP and pass control to it.

Scheduling in a Dependent Region

The IMS scheduler assigns the application transaction processing to a dependent MPR. The number of MPRs available to an IMS system is 999 dependent regions.

The transactions are assigned to classes. The maximum number of transaction classes is set at system generation time by the MAXCLAS keyword of the IMSCTRL macro.

Class Processing

Each dependent MPR can run up to four transaction classes. The order in which they are specified is a priority sequence, which means that the transaction class named first is the highest and the one named last is the lowest. Each MPR can have a different sequence of the same or different transaction combinations. The classes are named on the PROC statement of the JCL that runs the MPR. Figure 13-7 shows an example of the MPR PROC statement JCL. The MPR can be run as a job or as a started task.

Figure 13-7. Example of MPR PROC Statement

 //IVP6TM11 EXEC PROC=DFSMPR,TIME=(1440), //         AGN=BMP01,             AGN NAME //         NBA=6, //         OBA=5, //         SOUT='*',              SYSOUT CLASS //         CL1=001,               TRANSACTION CLASS 1 //         CL2=006,               TRANSACTION CLASS 2 //         CL3=013,               TRANSACTION CLASS 3 //         CL4=000,               TRANSACTION CLASS 4 //         TLIM=10,               MPR TERMINATION LIMIT //         SOD=,                  SPIN-OFF DUMP CLASS //         IMSID=IMSY,       IMSID OF IMS CONTROL REGION //         PREINIT=DC,            PROCLIB DFSINTXX MEMBER //         PWFI=N                 PSEUDO=WFI //*

The classes that the MPR runs can be changed while the MPR is running through the /ASSIGN command. When the /ASSIGN command is executed, only those classes specified on the command are available to that MPR. The changes are maintained until the MPR is restarted, at which time the values on the startup JCL are used again. Figure 13-8 illustrates an example of an /ASSIGN CLASS command. Again, the order of classes on the command is the priority sequence of those classes.

Figure 13-8. Example of `/ASSIGN CLASS` Command

 /ASSIGN CLASS 1 4 6 9 TO REGION 1

You can use the /DISPLAY ACTIVE command to list the classes assigned to an MPR. Figure 13-9 on page 210 shows an example /DISPLAY ACTIVE command and its output.

Figure 13-9. Example of `/DISPLAY ACTIVE` Command

 /DIS ACTIVE      REGID JOBNAME   TYPE TRAN/STEP PROGRAM STATUS           CLASS       IMSY          1 SJIMSYM1  TP                       WAITING        1, 4, 6, 9  IMSY          2 SJIMSYM2  TP                       WAITING        2, 3, 5, 1  IMSY            BATCHREG  BMP   NONE   IMSY            FPRGN     FP    NONE   IMSY            DBTRGN    DBT   NONE   IMSY            SJIMSYDB  DBRC                       IMSY            SJIMSYDL  DLS     IMSY      VTAM ACB OPEN          -LOGONS DISABLED   IMSY      IMSLU=N/A.N/A            APPC STATUS=DISABLED    IMSY      OTMA GROUP=IMSCGRP   STATUS=ACTIVE       IMSY      APPLID=SCSIM6YA  GRSNAME=         STATUS=DISABLED   IMSY      LINE ACTIVE-IN -    1 ACTIV-OUT -    0   IMSY      NODE ACTIVE-IN -    0 ACTIV-OUT -    0   IMSY      *99298/155826*     IMSY

Note the following points about Figure 13-9:

There are two MPRs: SJIMSYM1 and SJIMSYM2.
The MPR named SJIMSYM1 runs classes 1, 4, 6, and 9.
The MPR named SJIMSYM2 runs classes 2, 3, 5, and 1.
Class 1 has the highest priority in MPR SJIMSYM1 and the lowest in MPR SJIMSYM2.

When an MPR searches for a transaction to schedule, it uses the following criteria:

The highest priority transaction ready in the highest priority class
Any other transaction in the highest priority class
The highest priority transaction ready in the second highest priority class
Any other transaction in the second priority class

This sequence of priorities is used for all the available classes for this MPR.

Note:

If a transaction has a class for which there are no MPRs currently allowed to run that class, the transaction is not scheduled and remains on the input queue.

Definition Macro Keywords That Affect Transaction Scheduling

The values you assign to a few macro keywords at system definition time can affect how IMS schedules transactions. The following sections describe some of these keywords.

PROCLIM Keyword Processing

IMS tries to increase throughput of the MPR by processing more than one message for the same transaction. This technique makes use of the fact that the program has already been loaded into the MPR's storage, and the PSB and DBD control blocks also have been loaded. The throughput of the number of messages processed by this MPR is increased because some of the overhead involved with reloading the program and control blocks is avoided.

At the completion of the transaction, IMS checks the value specified on the PROCLIM keyword of the TRANSACT macro for this transaction. The PROCLIM keyword specifies the number of messages (count) of this transaction code a program can process in a single scheduling, and the amount of time (in seconds) allowable to process a single transaction (or message). BMP programs are not affected by the PROCLIM keyword.

The MPR processes the number of messages allowed in the first value of this keyword before looking to see what other transactions are available for scheduling, which means the MPR can process more transactions without having to go through the scheduling logic for each transaction.

Parallel Scheduling

A transaction processes in only one MPR at a time unless parallel processing is specified. To allow more than one MPR to schedule a transaction type at a time, code SCHDTYP=PARALLEL on the APPLCTN macro. The SCHDTYP keyword specifies whether (PARALLEL) or not (SERIAL) this application program can be scheduled into more than one MPR or BMP region simultaneously. The default value is SERIAL. For example:

 APPLCTN PSB=DFSIVP1,PGMTYPE=(TP,1),SCHDTYP=PARALLEL

Unless there are application restrictions on processing the message in strict first-in, first-out sequence, parallel scheduling should be applied to all transactions. Parallel scheduling allows IMS to make the best use of IMS resources while providing the best possible response time to individual transactions.

The PARLIM keyword on the TRANSACT macro determines when a transaction is scheduled in another region. The PARLIM keyword specifies the threshold value to be used when SCHDTYP=PARALLEL is specified in the preceding APPLCTN macro instruction. When the number of messages on the queue for a transaction exceeds the value on the PARLIM, another region is used.

Use the MAXRGN keyword to restrict the number of MPRs that can process a transaction at any one time. Do so in order to avoid the situation of all the MPRs being tied up by a single transaction type.

Priority Keyword

The PRTY keyword on the TRANSACT macro sets the priority of a transaction, which indicates how to differentiate one transaction from another if they run in the same transaction class. A transaction of a higher priority is scheduled before a lower priority one. However, an MPR processes a transaction in a higher class (for this MPR, see "Scheduling in a Dependent Region" on page 208 for more details) before a transaction in a lower class regardless of the priority. A transaction priority increases after the number of transactions on the message queue exceeds the value set on the third parameter of the PRTY keyword. The priority will increase up to the value set on the second parameter of the PRTY keyword, which has the effect of trying to avoid a long queue on any single transaction code by giving the transaction code a higher priority.

Database Processing Intent

A factor that significantly influences the scheduling process is the intent of an application program toward the databases it uses. Intent is determined by examining the intent that is last associated with the PSB to be scheduled. At initial selection, this process involves bringing the intent list into the control region. The location of the intent list is maintained in the PSB directory. If the analysis of the intent list indicates a conflict in database usage with a currently active program in the dependent region, the scheduling process selects another transaction and tries again.

The database intent of a program at scheduling time is determined by the PROCOPT= parameters in the PCB.

A conflicting situation during scheduling occurs only if a segment type is declared exclusive use (PROCOPT=E) by the program being scheduled and an already active program references the segment in its PSB (any PROCOPT), or vice versa. PROCOPT=E only applies within a single IMS and is not effective in an IMSplex.

Scheduling a BMP or JBP Application

BMP and JBP applications are initiated in a standard z/OS address space via any regular job submission facility, from either:

TSO and submitting the job
A job scheduling system

However, during its initialization, the IMS scheduler in the control region is invoked to assure the availability of the database resources for the BMP or JBP application.

Scheduling Fast Path Transactions

Apart from standard IMS transactions, there are two types of Fast Path online transactions:

"Fast Path Exclusive Transactions" on page 213
"Fast Path Potential Transactions" on page 213

Fast Path Exclusive Transactions

Fast Path schedules input messages by associating them with a load balancing group. A load balancing group (LBG) is a group of Fast Path input messages that are ready for balanced processing by one or more copies of a Fast Path program. One LBG exists for each unique Fast Path message-driven application program.

The messages for each LBG are processed by the same Fast Path program. The EMH controls Fast Path messages by:

Managing the complete execution of a message on a first-in-first-out basis.
Retaining the messages that are received in the control program's storage without using auxiliary storage or I/O operations.
Supporting multiple copies of programs for parallel scheduling.
Requiring that programs operate in a wait-for-input mode.

Fast Path Potential Transactions

Fast Path potential transactions are a mixture of standard IMS full-function and Fast Path exclusive transactions.

The same transaction code can be used to trigger either a full-function or a Fast Path transaction, with an exit used to determine whether this instance of the transaction will be full-function or Fast Path.

Shared Queues

Scheduling of transactions in a shared-queues environment is similar to those in a non-shared-queues environment. All the checks, however, are across all the IMS systems in the shared-queues environment.

Related Reading: For further information on scheduling shared queues, see:

IMS in the Parallel Sysplex: Volume I: Reviewing the IMSplex Technology
IMS in the Parallel Sysplex: Volume II: Planning the IMSplex
IMS in the Parallel Sysplex: Volume III: IMSplex Implementation and Operations