Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

TACCLASS - define the number of processes for a TAC class

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"

 

TACCLASSS

tacclass    
  ,{ TASKS=number1 | TASKS-FREE=number2 }   
[ ,PGWT={ NO | YES } ]
            

tacclass

Number of the TAC class for which the number of processes is to be specified. You may specify the following TAC classes:

  • the dialog TAC classes 1 - 8

  • the asynchronous TAC classes 9 - 16.

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.
The value ranges permitted for TASKS=number1 are given in the table below.


Class 1 - 8
Dialog TACs
Class 9 - 16
Asynchronous TACs

Minimum value

PGWT=NO

PGWT=YES

PGWT=NO

PGWT=YES

1

1

0

0

Maximum value

TASKS *)

TASKS-IN- PGWT *)

ASYNTASKS*)

The lesser of the two values: ASYNTASKS, *) TASKS-IN-PGWT *)

*) 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

  • dialog TAC classes: Minimum number of processes of the UTM application to be kept free for processing TACs of other classes.

  • asynchronous TAC classes: Minimum number of processes permitted for asynchronous jobs (MAX ...,ASYNTASKS=) to be kept free for processing TACs of other classes.

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:


Class 1 - 8
Dialog TACs
Class 9 - 16
Async. TACs

Min. value

1

1

Max. value

TASKS-1 *)

ASYNTASKS *)

*) As specified in the MAX statement

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
“Concepts und Functions”).

    YES

Blocking calls are permitted in this TAC class.
PGWT=YES can only be generated if MAX ...,TASKS-IN-PGWT !=0 is defined. It can be specified for up to one dialog TAC class and one asynchronous TAC class. Program units containing PGWT calls must be assigned to this TAC class.

  • CPI-C program units
    If a CPI-C program unit is to conduct dialog conversations in which send authorization is transferred to the conversation partner using a Set_Send_Type call with send_type=CM_SEND_AND_PREP_TO_RECEIVE or by issuing a Receive call in Send status, the transaction code of this CPI-C program unit must be assigned to a TAC class generated with PGWT=YES, e.g.:
    MAX TASKS=2
    MAX TASKS-IN-PGWT=1
    TACCLASS 1,TASKS=1,PGWT=YES
    TAC CPIC1,PROGRAM=xyz,API=(XOPEN,CPIC),TACCLASS=1
  • XATMI program units
    If an XATMI application contains both requests and conversational services, at least two tasks must be started and a TAC class that permits PGWT calls must be generated. A service is always linked to the task. This is not necessary for applications that only contain
    request/response services.

    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