openUTM provides two methods with which you can control the distribution of released UTM processes amongst the jobs ready for processing. This means that you can affect the order in which openUTM starts the processing of jobs on transaction codes.
By using one of the methods for job control, you can:
give important jobs higher processing priority
prevent many jobs of the same type from running at the same time, thereby causing the processing of other jobs to be delayed
prevent the blocking of job processing due to long-running jobs. Long-running jobs are services whose processing takes an extremely long time, e.g. because their program units are searching through data or they contain program waits (blocking calls such as PGWT).
in UTM cluster applications, prevent too many tasks from simultaneously accessing memory areas that are available globally in the cluster.
With both methods you must assign TAC classes to the transaction codes that are subject to a specific job control. You can then alternatively select one of the two methods for job control between TAC classes:
Priority control
The distribution the processes amongst the TAC classes is controlled by priorities. These priorities are used by openUTM to determine when the outstanding jobs are to be processed. You turn priority control on with the KDCDEF statement TAC-PRIORITIES.Process limitations
You limit the number of the processes that are allowed to process jobs of a certain TAC class simultaneously, or you specify how many processes are to remain free for processing jobs of other TAC classes. The process number can be specified individually for every TAC class. The KDCDEF control statement TACCLASS is provided for specifying the number of processes.
You cannot use the two methods together in an application, i.e. you must not use the control statements TAC-PRIORITIES and TACCLASS together in the KDCDEF generation.
Assigning transaction codes to TAC classes
openUTM differentiates between a total of 16 TAC classes. There are 8 classes each available for dialog and asynchronous transaction codes, classes 1 through 8 for dialog transaction codes and classes 9 through 16 for asynchronous transaction codes.
You specify the assignment of the transaction codes to the TAC classes in the KDCDEF generation.
 | TAC statement in section "TAC - define the properties of transaction codes and TAC queues" |
openUTM makes the following assignments for transaction codes to which you have not explicitly assigned a TAC class (no entry in TACCLASS=):
dialog transaction codes are not assigned to a TAC class
asynchronous transaction codes are assigned to TAC class 16
You should combine the transaction codes of similar types of services into one TAC class. A TAC class then represents a type of job in your application.
Which jobs are subject to job control?
Generally only jobs that have been placed in a job queue by openUTM are subject to job control.
Jobs for asynchronous transaction codes are always placed in a job queue first before openUTM selects them for processing.
Jobs for dialog transaction codes, on the other hand, are only placed in a queue in bottleneck situations, e.g. when the number of the available processes has been exhausted.
If the load on the application is low, then the dialog jobs are processed immediately because they will not block each other significantly and buffering in the queue would appear to slow the system.
For this reason, the methods for job control for asynchronous jobs are always used, while the methods for job control for dialog jobs are only used in bottleneck solutions.
In addition, the following jobs are not subject to job control:
Jobs for dialog transaction codes that are not assigned a TAC class. These jobs are always started immediately after they have been received from the transport system.
Jobs for the transaction codes KDCSGNTC, KDCMSGTC and KDCBADTC with which the event services (sign-on service, MSGTAC and BADTACS program) are started.
Distribution of resources amongst dialog, asynchronous and PGWT processing
In an initial stage of job processing you should - regardless of the methods used for job control - specify the maximum number of processes of the application that are allowed to process asynchronous jobs at the same time or to wait in Program Wait at the same time. In this manner you can prevent the dialog operation of your application from slowing down due to the processing of such jobs.
| MAX statement in section "MAX - define UTM application parameters" |
ASYNTASKS=(atask_number,...)
With atask_number you specify the maximum number of the processes of the application that may simultaneously process jobs for asynchronous TAC classes.
TASKS-IN-PGWT=
The maximum number of processes of the UTM application in which program units with blocking calls are allowed to run simultaneously. You must specify TASKS-IN-PGWT > 0 if you want to assign the PGWT=YES property to transaction codes or TAC classes.
The values specified for ASYNTASKS=(atask_number,...) and TASKS-IN-PGWT in the MAX statement are maximum values. When starting the application and in application mode, you can lower the number of processes via the administration to adapt to the current situation.
Default setting
If you do not create any TAC classes, i.e. you do not specify the TACCLASS operand in the TAC statement, then openUTM does not perform any special job control.
Program unit runs with blocking calls are not allowed then. Dialog jobs are processed in the order in which they arrive in openUTM.
If you do not issue a TACCLASS or a TAC-PRIORITIES statement in the generation, then openUTM automatically applies the methods used to limit the number of processes. All TAC classes are administrable, i.e. the UTM administrator can specify numbers of processes for the TAC classes.