Comparison of some of the properties of the two methods

You can only use one of the two methods for job control in your UTM application. Which of the two possibilities you should select for your application also depends on the sometimes different properties of the two methods.

Program units with blocking calls

• Priority control

  Transaction codes from program units that execute blocking calls may be assigned any TAC class as long as a value > 0 is generated in the TASKS-IN-PGWT operand of the MAX statement. You must specify the operand PGWT=YES in the TAC statement for transaction codes with blocking calls.

  TAC ..., TACCLASS=number,PGWT=YES

  This also allows you to process corresponding jobs with different priorities.

• Process limitation

  All transaction codes from program units that execute blocking calls must be assigned the same dialog or asynchronous TAC class. You must generate these dialog or asynchronous TAC class as follows:

  TACCLASS ...,PGWT=YES

  The corresponding dialog or asynchronous jobs are thus handled in the same way.

Temporarily stopping the execution of certain asynchronous jobs

Both methods for job control provide a mechanism with which you can temporarily prevent the processing of certain asynchronous jobs. These jobs are then received and accepted by openUTM and written in the message queue of the corresponding transaction code. The processing of these jobs is only initiated after the “processing lock“ is removed by the UTM administration.

To temporarily prevent the execution of jobs, set the status of the transaction code to KEEP. You can do this during live operation via the UTM administration or do this during the generation of the transaction codes by specifying the following:

TAC ...,STATUS=KEEP

openUTM processes the buffered jobs first when you set the status of the transaction code to ON.

See the openUTM manual “Administering Applications”; KDCADMI operation code KC_MODIFY_OBJECT with object type KC_TAC or the administration command KDCTAC

When using the process limitation method, the execution of jobs can also be prevented for all transaction codes of an asynchronous TAC class. In this case you must set the maximum number of processes that are available for jobs of this TAC class to 0.

TACCLASS ...,TASKS=0

openUTM only processes the jobs if you increase the maximum number of processes again.

See the openUTM manual “Administering Applications”; KDCADMI operation code KC_MODIFY_OBJECT with object type KC_TACCLASS or the administration command KDCTCL

You can use both mechanisms, for example, to collect jobs that are to be executed at a later point in time when the load on the application is lower (e.g. at night).

In both cases you should limit the message queue of the transaction code(s) to prevent overloading the page pool with too many buffered jobs. This is done for each TAC by:

TAC ...,QLEV=

Change of process when processing jobs

• Priority control

  If a service consists of several program units (follow-up TAC after a PEND PA/PR), then a change of process can always occur when processing the service, regardless of whether the current TAC and follow-up TAC belong to the same TAC class or not.

• Process limitation

  For job control via process limitation, openUTM guarantees that no change of process will occur after a PEND PA/PR and SP when the service TAC and follow-up TAC are assigned the same TAC class.

  If the current TAC and follow-up TAC belong to different TAC classes, then a change of process can also occur when using this method.

Change of process for asynchronous services

When a change of process occurs, an asynchronous service is inactive at first and does not reserve a UTM process although it remains open.

You can limit the maximum number of simultaneously open asynchronous services. You must specify the following in the MAX statement to do this:

MAX ...,ASYNTASKS=(...,service_number).

If service_number of open asynchronous services exist, then no new asynchronous job that is ready is started. An interrupted open asynchronous service is selected from the next process that becomes free, and this service is resumed.