You specify the method used to control job processing in this UTM application with the TACCLASS control statement. This means that you specify the criteria used by openUTM to start the jobs for transaction codes that have been assigned a TAC class.
The specification of these criteria can also be done using the TACCLASS statement or the TAC-PRIORITIES statement.
A TAC class consists of a subset of the generated transaction codes of the application. These TACs are divided into TAC classes using the TACCLASS= operand of the TAC statement.
By generating at least one TACCLASS statement, you specify that job processing in your application is controlled by the limitation of the number of processes for the individual TAC classes. You may not issue any TAC-PRIORITIES statements in this case, then.
The TACCLASS statement allows you to define how many processes of the UTM application are allowed to work at the same time for the TACs of a TAC class. You can also specify in the PGWT operand whether or not blocking calls (e.g. the KDCS call PGWT) are allowed or not in program unit runs that are started by transaction codes of the TAC class. You may only assign the PGWT=YES property, i.e. blocking calls are allowed, to one dialog and one asynchronous TAC class.
The number of processes of a TAC class that you specify in the TACCLASS statement can be changed by the administrator. See the openUTM manual “Administering Applications” for details.
You can thus control the load on the UTM application exerted by the program units of individual TACs. For example, you can prevent long-running program units from blocking the application. If asynchronous services are used for distributed processing, then you can avoid situations where all the application processes available for asynchronous processing are allocated by this service.
Default values
All TAC classes are created implicitly in the KDCDEF generation if you generate a transaction code with the TAC ...,TACCLASS= statement, or if you generate a TAC class with TACCLASS.
If you do not issue any TAC-PRIORITIES statements, then you should write a TACCLASS statement for every TAC class used. In this case, openUTM assigns the minimum value for TASKS and TASKS-FREE to those TAC classes for which no TACCLASS statement is issued. You must always issue TACCLASS statements for TAC classes with PGWT=YES!
If you do not use TAC classes, i.e. the TACCLASS= operand is not specified in any TAC statement and there are no TACCLASS or TAC-PRIORITIES statements, then the following applies:
Dialog TACs are processed without restriction.
Asynchronous TACs are restricted by the number of processes specified in the ASYNTASKS start parameter. This value can be modified by the administration.
You will find a detailed description of the TAC classes and priority control in section "Job control - priorities and process limitations" |
|
|
tacclass | Number of the TAC class for which the number of processes is to be specified. You may specify the following TAC classes:
You assign a transaction code to this TAC class by specifying TACCLASS=tacclass in the corresponding TAC statement. You may only specify an asynchronous TAC class if you have generated a non-zero value in MAX ...,ASYNTASKS. Asynchronous transaction codes that are not assigned a TAC class are automatically assigned TAC class 16. The TAC class numbers are not priorities, rather only a designation for the TAC class. Only the number number1 of permitted processes can determine the extent to which processing of a TAC class is restricted so that the TACs of other classes can be processed quicker. This is possible only if number1 is less than the number of active processes of the application. | |||||||||||||||||||
TASKS= | number1 Maximum number of application processes that can be executed simultaneously for the TACs of this class. The values permitted here depend on the value of the PGWT operand and the values defined for the TASKS, TASKS-IN-PGWT, and ASYNTASKS operands of the MAX statement.
*) As specified in the MAX statement This is a mandatory operand if TASKS-FREE= is not specified. If you enter TASKS=0 for a dialog TAC class, openUTM automatically resets this value to 1. The total number of tasks entered in the TASKS= operand of the individual TACCLASS statements can be greater than the maximum number of processes permitted by the application (MAX ...,TASKS=). | |||||||||||||||||||
TASKS-FREE= | number2 TASKS-FREE specifies for
Compared to the TASKS parameter, TASKS-FREE offers the advantage of dynamically adapting the number of processes permitted for a TAC class if the total number of application processes is changed. The values permitted for TASKS-FREE=number2 depends on the values defined for the TASKS and ASYNTASKS operands of the MAX statement. The value ranges permitted for TASKS-FREE= are given in the table below:
This is a mandatory operand if TASKS= is not specified. If you enter TASKS-FREE=0, openUTM automatically resets this value to 1. | |||||||||||||||||||
PGWT= | (program wait) This specifies whether or not program units containing blocking calls (e.g. KDCS call PGWT) can be executed in this TAC class. (Further information on PGWT can be found in the openUTM manual „Programming Applications with KDCS” and in the openUTM manual | |||||||||||||||||||
YES | Blocking calls are permitted in this TAC class.
| |||||||||||||||||||
NO | Program units that contain blocking calls are not permitted in this TAC class. Default: NO Blocking calls for asynchronous TACs are not processed until all jobs in the messages queues of dialog TAC classes have been executed. |
Example
The table below shows how the value defined for TASKS-FREE affects that defined for the TAC class under certain marginal conditions.
The CURRENT TASKS column contains the maximum number of processes currently available to the UTM application. CURRENT ASYNTASKS contains the maximum number of processes available for performing asynchronous services. The global maximum values for CURRENT TASKS and CURRENT ASYNTASKS are defined in the TASKS and ASYNTASKS operands of the MAX statement. During runtime, the current values can be modified dynamically within this upper limit using the TASKS and MAXASYN operands of the KDCAPPL command.
The DIALOG column contains the maximum number of processes available for a particular DIALOG-TAC class if TASKS-FREE=nn is specified for this TAC class.
The ASYNCH column contains the maximum number of processes available for a particular asynchronous TAC class if TASKS-FREE=number2 is specified for this TAC class.
CURRENT TASKS | CURRENT ASYNTASKS | TASKS-FREE | DIALOG | ASYNCH |
10 | 9 | 2 | 8 | 7 |
6 | 6 | 2 | 4 | 4 |
3 | 3 | 2 | 1 | 1 |
2 | 2 | 2 | 1 | 0 |
1 | 1 | 2 | 1 | 0 |
10 | 5 | 3 | 7 | 2 |
6 | 5 | 3 | 3 | 2 |