To activate job control via priorities you must issue the TAC-PRIORITIES statement in the KDCDEF generation. In it you also specify the algorithms with which the individual dialog or asynchronous TAC classes are to be prioritized.
 | TAC-PRIORITIES statement in section "TAC-PRIORITIES - specify priorities of the TAC classes" |
DIAL-PRIO=
Priority with which the available processes of the application are to be distributed amongst the dialog TAC classes.ASYN-PRIO=
Priority with which processes for the asynchronous TAC classes with ready asynchronous jobs or interrupted asynchronous jobs are to be distributed.
You can select between the absolute, a relative or the same priority for both dialog and asynchronous TAC classes.
The following is always true, regardless of which algorithm you select:
The TAC class 1 of the dialog TAC classes has a higher or the same priority as TAC class 2, and this has a higher or the same priority as TAC class 3, etc.
For asynchronous TAC classes, class 9 has a higher or the same priority as TAC class 10, and this has a higher or the same priority as TAC class 11, etc.
If absolute priority is selected, then free processes of the application are always assigned the TAC class with the highest priority, meaning 1 (dialog) or 9 (asynchronously) as long as there are jobs waiting for this TAC class. Only after there are no more jobs waiting in the TAC class with the highest priority are waiting jobs of the TAC class with the next lower priority processed. When the load is high, absolute priorities leads to waiting jobs of a TAC class with a lower priority not being processed for a long time. If you want to prevent this, then you should use relative priorities.
If relative priority is selected, then jobs from TAC classes with higher priorities are processed more often than jobs from TAC classes with lower priorities, i.e. free processes are more often assigned higher priority TAC classes (e.g. 1) than lower priority TAC classes if there are jobs ready and available for this. If there ar e jobs available for all TAC classes, then class 1 is serviced twice as often as class 2, and class 2 is serviced twice as often as class 3 (and so on). The same is true for asynchronous TAC classes.
If same priorities is selected, then the same number of jobs (if there are any) from every TAC class are processed.
Jobs within the TAC classes, however, whose processing leads to program waits (TACs with PGWT=YES) are only processed if the maximum number of processes allowed to process the PGWT jobs has not yet been reached.
Reserving processes for dialog jobs outside of the TAC classes
When using priority control for the TAC classes, you can limit the number of processes that process the jobs of the TAC classes to keep some processes free for administrative tasks or internal UTM jobs.
This limitation is the same, however, for all asynchronous TAC classes and for all dialog TAC classes.
You limit the maximum number of processes for asynchronous TAC classes with
MAX ASYNTASKS=(atask_number,...) as described in chapter "Job control - priorities and process limitations".
You limit the number of processes for the dialog TAC classes with the FREE-DIAL-TASKS= operand of the TAC-PRIORITIES statement.
The number of processes specified in FREE-DIAL-TASKS is reserved for the processing of jobs that do not belong to any dialog TAC class. These jobs are asynchronous jobs and dialog jobs that are not assigned a dialog TAC class, and in particular are internal UTM tasks (establishing connections, sending acknowledgments, starting the MSGTAC routine, etc.). One of the internal UTM tasks is to pick up the incoming jobs for the UTM application at the job market and, if necessary, enter these in the job queues of the application. These “reserved processes“ then help to offload the job market. In particular, if many jobs sent to the application come from the network, then this will prevent a backlog in the network that may reach all the way back to the communication partner.
The number of processes you should reserve for this task depends on your application. It is recommended to reserve one or two processes for this task.
You can change the number of free processes via the administration.
| See the openUTM manual “Administering Applications”; KDCADMI operation code KC_MODIFY_OBJECT with object type KC_TASKS_PAR |
Example
The following maximum number of processes is specified in the KDCDEF generation:
MAX TASKS=7,ASYNTASKS=2TAC-PRIORITIES ...,FREE-DIAL-TASKS=3
If the application is then started with six processes (start parameter TASKS=6), then the following process numbers are available:
Three processes for processing jobs for the dialog TAC classes 1 through 8 (determined by: TASKS – FREE-DIAL-TASKS = 6 – 3 = 3)
Two (=ASYNTASKS) processes for processing jobs for the asynchronous TAC classes 9 through 16
One process for internal UTM tasks and dialog jobs for transaction codes that are not assigned any TAC class (determined by: FREE-DIAL-TASKS – ASYNTASKS = 3 – 2 = 1)
| For information on the use of TAC priorities in UTM cluster applications, see also the applicable openUTM manual “Using UTM Applications on Unix, Linux and Windows systems”, section "Using global memory areas" in the chapter "UTM cluster applications". |
