The following section describes some of the measures you can take to avoid performance bottlenecks or to remedy existing bottlenecks.
Increasing the total number of processes for an application
If extended wait periods arise when processing jobs, particularly in dialog mode, you can increase the number of processes in which the application program runs.
This makes particular sense in the event that the current application load rises above 80 % and at the same time sufficient system resources are still free on the computer (memory space, CPU capacity). This value should fall again after the total number of processes has been increased sufficiently.
The maximum permitted number of processes is defined in MAX TASKS during KDCDEF generation.This maximum number cannot be increased at the administrative level. However, if the number of processes currently set is less than this maximum number, you can start additional processes for the application.
 | KDCINF SYSPARM: |
 | KC_GET_OBJECT with obj_type=KC_TASKS_PAR: |
Reducing the total number of processes for an application
Because of the possibility of load fluctuations, it is generally not sensible to reduce the total number of processes if the application is not loaded to capacity part of the time.
The total number of processes should only be reduced when the computer as a whole encounters a bottleneck which leads to reduced throughput and/or slower response times on the part of the application.
If you reduce the total number of processes, you must note the following points:
If the total number of processes is reduced to such a level that it is less than the currently set maximum number of processes that can be used at the same time for asynchronous processing (hereafter referred to as ASYNTASKS), openUTM resets the value for ASYNTASKS to the specified total number of processes. For subsequent changes to the total number of processes, openUTM adapts the value of ASYNTASKS automatically until the value is reached which was previously set by administration or in the startup parameter for ASYNTASKS.
The same applies to the maximum number of program units with blocking calls (TASKS-IN-PGWT) permitted to run simultaneously. Note that the maximum number of processes must be at least 2 if a transaction code or a TAC class is generated with PGWT=YES or if the application is a UTM cluster application.
If, in a dialog TAC class, the value for TASKS-FREE is greater than the current total number of processes, one process then continues to process the jobs going to this TAC class.
If, in the application, job processing is priority controlled (TAC-PRIORITIES is generated), and the value for FREE-DIAL-TASKS is greater than the current total number of processes, one process then continues to process the jobs going to this TAC class.
To ensure that, after the total number of processes has been reduced, dialog operation is not impaired by long-running asynchronous services or by programs with blocking calls, it is advisable to adapt the value of ASYNTASKS and TASKS-IN-PGWT to reflect the reduction you make in the total number of processes, i.e. you should also reduce this value.
Reducing the number of processes available for asynchronous processing and for the processing of program units with blocking calls
If the dialog mode for an application is delayed by time-consuming asynchronous processing (in other words, if dialog jobs wait because too many processes are handling asynchronous jobs at the same time), you can reduce the maximum number of processes (ASYNTASKS) that can be used at one time for asynchronous processing. This means that there remain more processes free for synchronous processing. The number of processes in ASYNTASKS is restricted by the maximum value generated in MAX ASYNTASKS.
You can occasionally set ASYNTASKS to 0. However, when doing so, you should note that all asynchronous jobs are placed in buffer storage in the page pool. If the page pool is not large enough, this can cause bottlenecks in the page pool.
When you reduce ASYNTASKS and if jobs are controlled through process restrictions for the individual TAC classes in your application (TAC-PRIORITIES is not generated), you must also note the following:
If an asynchronous TAC class exists for which the current value set in TASKS-FREE is greater than or equal to ASYNTASKS, then this TAC class is disabled, i.e. no further jobs are processed for this TAC class. In this instance, TASKS-FREE is the minimum number of processes which should be kept free for processing other jobs going to other asynchronous TAC classes.
To maintain a check, you should request information about the TAC classes after reducing the ASYNTASKS.
The same applies to the maximum number of processes (TASKS-IN-PGWT) in which program units with blocking calls are allowed to run at the same time. In contrast to ASYNSTASKS, however, note that you cannot set the value to 0, if such tasks exist.
 | KDCINF SYSPARM: Display current settings |
 | KC_GET_OBJECT with obj_type=KC_TASKS_PAR: Determine generated maximum number and currently set number of processes |
In applications without TAC-PRIORTIES:
changing the number of processes for individual TAC classes
If your application is generated with TAC classes, you can define a specific maximum number of processes for each TAC class, i.e. the number of processes able to process jobs in one TAC class, and you can change this number if so required.
When creating the transaction code, you indicate the TAC class to which a transaction code is to belong. You can therefore group transaction codes belonging to long-running program units into one TAC class or several TAC classes. The proportion of processes in the application that are authorized to process jobs in this TAC class at the same time can then be set by you at a level which reflects the utilization of that application. In the case of dialog TAC classes, at least one process must be allowed to process jobs in the TAC class. In the case of asynchronous TAC classes, the number can be reduced to 0.
In particular you should group the dialog TACs in program units containing blocking calls (e.g. KDCS call PGWT, or XATMI call tpcall) in one TAC class (with PGWT=YES). After a blocking call, the program unit waits until the data required for continuing the program has been received. For this period of time, the program unit and the related transaction code assigns a process in the application on an exclusive basis. If several similar program units are running concurrently, this can cause other jobs to remain waiting in the queue because no processes are available to process them. The performance of the application is thus severely impaired. The wait time following a blocking call can also be restricted using the timer PGWTTIME (see below).
 | KDCINF TACCLASS: Determine current setting |
 | KC_GET_OBJECT with obj_type=KC_TACCLASS: Determine current setting |
Changing the setting for timers
Timers are defined to prevent processes from remaining assigned for excessive periods of time while waiting for resources to be freed up or for connections and sessions to be established. The timers monitor these wait times and roll back the waiting transaction after the specified time elapses. The timers are defined during KDCDEF generation and can be adapted at runtime.
In openUTM, timers are defined for the following wait times:
Wait time after a blocking call (pgwttime)
The timer monitors the maximum length of time which a program unit waits before returning to the program unit after placing a blocking call.Maximum length of time during a transaction that is spent waiting for an answer from a dialog partner
(termwait...).Maximum period of time over which resources can remain assigned by a transaction and the maximum period of time that a program unit can wait for resources to be freed up (reswait...).
Using the information functions (parameter type STATISTICS/KC_CURR_PAR) you can, for example, determine how frequently program units have had to wait for locked resources (relative figure).
Maximum length of time to wait for a session/association to the partner application to be assigned.
The timers are intended as "emergency brakes" for unforeseen situations.
You should therefore set the timer values in such a way that they do not run when the application is executing normally. Timeouts should only be caused by exceptional situations, for example when a program error occurs or no response is received from a partner application.
If the timers pgwttime or reswait are set for an excessively long period, particularly in bottleneck situations, then individual processes in the application can be assigned by program units which either lock resources for too long at a time (long-running units) or wait too long for required resources to become free. However, if the timers are not set for long enough periods, system performance is impaired by transactions being rolled back frequently.
 | KDCINF SYSPARM or STATISTICS: Determine current timer settings and request information about current wait times |
 | KC_GET_OBJECT with obj_type=KC_TIMER_PAR / KC_CURR_PAR: Determine current timer settings and request information about current wait times |
Restricting the number of users/clients signed on
At runtime you can influence the number of users/clients that can connect to the application and request services from the application at the same time. For this purpose, you are offered the following options:
You can restrict the total number of users/clients able to sign on to an application at the same time.
You can restrict the number of clients able to connect via individual LTERM pools at the same time. To do this, you disable some of the LTERM partners in the pool.
You can disable individual clients/LTERM partners/users.
You can disable LTERM pools completely. At this point, it is no longer possible for users/clients to sign on to the application via a disabled LTERM pool.
Only on BS2000 systems: You allow only a small number of parallel sessions access to a multiplex connection.
 | KDCAPPL MAX-CONN-USERS: total number of users/clients |
 | KC_MODIFY_OBJECT |
Disabling services
It is, for example, possible to disable long-running services for a certain period by disabling the relevant transaction code (State OFF). As of this point, jobs are no longer accepted for disabled transaction codes. In the case of disabled asynchronous TACs, no further jobs are written to the message queue either.
You can disable a transaction code either exclusively as a service TAC or as both a service TAC and a follow-up TAC (complete lock: State STOP).
You can also lock asynchronous services using the KEEP status, which means that jobs for the asynchronous TAC are accepted, but not processed immediately. They can subsequently be processed when the application is less busy, e.g. at night.
 | KDCTAC |
| KC_MODIFY_OBJECT obj_type=KC_TAC |
Preventing or remedying bottlenecks for connections to partner applications
If bottlenecks occur during communication with LU6.1 or OSI TP partner applications, you can perform the following actions:
Establish other transport connections to an LU6.1 partner application. Before you can communicate with a partner application, you must first have created or generated several parallel connections, but not all the connections created or generated should yet have been established.
Increase the number of parallel logical connections to an OSI TP partner application. The maximum possible number of parallel connections is defined during generation in the OSI-LPAP statement.
Adapt the timer (access wait) for the wait time following a request for a remote service within which a session or association with a partner application is to become available or be established. You can set this timer individually for each LTAC. If the timer is set to 0 for an asynchronous LTAC, asynchronous jobs for this LTAC are also not arranged in the local message queue of the partner application.
Adapt the timer (reply wait) which monitors the wait time for an answer from the partner application. This timer is also set individually for each LTAC.
Adapt the setting of the idle timer. This timer indicates the length of time that a session or association can remain unused before openUTM terminates the connection to the partner application. If the timer setting is too long, an inordinate number of resources will be reserved by unnecessary connections.
If the timer setting is too short, too may resources will be used up to allow the connection to be set up again. The timer is set individually for each partner.
 | KDCLPAP / KDCLSES: establish connections, adjust idle time |
 | KC_CREATE_OBJECT obj_type=KC_CON/KC_LSES: create connections and sessions |
 | KC_MODIFY_OBJECT |
Note on Unix, Linux and Windows systems:
If a large amount of connections in your application are handled by the same BCAMAPPL name or access point in your application, this can give rise to bottlenecks since processes can come up against system limitations (e.g. the maximum number of file descriptors). During the next KDCDEF generation, you should then generate more BCAMAPPL names and access points.
Enabling or disabling data compression
If GSSBs, LSSBs, ULS, TLS, or KB program areas are frequently read or written in a length which is greater than one UTM page, you should check whether enabling data compression will enhance the performance of the UTM application.
You can check whether data compression is worthwhile while it is enabled as follows:
 | KDCINF STAT, AVG COMPRESS PAGES SAVED field |
| KC_GET_OBJECT with obj_type=KC_CURR_PAR, avg_saved_pgs_by_compr field |
