Page pool of a standalone application

User data generated during the application run is stored in the page pool of a standalone application. In addition to UTM memory areas and service data, this includes:

• the message queues of the asynchronous TACs, LTERM, LPAP and OSI-LPAP partners and the user, TAC and temporary queues (i.e. jobs to local services and communication partners and print jobs to the printers of the application) that are not being processed

• dialog jobs or asynchronous jobs buffered for transaction codes of TAC classes, which are interrupted as a result of TAC class control

The page pool size is defined during KDCDEF generation and cannot be modified at runtime.

While an application is running, it is necessary to ensure that the page pool is assigned completely. To this end, two warning levels are defined for KDCDEF generation (page pool assignment in %). If page pool assignment reaches one of these warning levels, openUTM generates message K041. If the destination MSGTAC is defined for this message, you can respond to this event in an MSGTAC routine. If the second warning level (default setting 95%) is reached, no more asynchronous jobs are written to the message queues and no more user log records (LPUT jobs) are written to the user log file. Asynchronous jobs and LPUT calls then are rejected.

For this reason, when the first warning level is reached, measures must be taken to release memory space in the page pool. While the application is running, you can obtain information about the current assignment of the page pool.

	KDCINF STATISTICS KDCINF PAGEPOOL
	KC_GET_OBJECT with obj_type=KC_CURR_PAR KC_GET_OBJECT with obj_type=KC_PAGEPOOL

However, if page pool bottlenecks occur frequently, the page pool is simply not large enough. In this case, you should regenerate the application and increase the size of the page pool.

The following section describes how to terminate message queues and dialog jobs in buffer storage in order to clear space, i.e. relieve congestion, in the page pool.

Reducing the size of message queues

You can implement the following measures to reduce the size of message queues:

• Reduce printer queues by establishing connections to all printers for which print jobs are waiting. These print jobs will then be processed immediately even if a control value (plev) has been generated for a printer and this has not yet been reached.

• Request connections to TS applications and partner applications for which asynchronous jobs are in buffer store in the page pool. If the communication partners are disabled, they must first be re-enabled.

• Increase the number of processes that can be used concurrently for asynchronous processing purposes.

• Increase the number of processes that can be used concurrently for processing jobs of a specific TAC class (in applications without priority control).

• Unlock (status ON) or lock with status OFF any asynchronous transaction codes and TAC queues that are locked with the KEEP status or blocked. The KEEP status means that jobs for the transaction code or queue in question are accepted, but are not processed immediately, whereas the status OFF means that no further jobs are accepted, but any waiting jobs will be processed.

• Delete the asynchronous jobs in the message queues of dynamically deleted LTERM partners and asynchronous TACs.

• Delete older messages from service-controlled queues if they are no longer expected to be read.

• Assign messages from the dead letter queue to a new destination again in order to allow them to be edited.

KDCINF STATISTICS: total number of all messages in the buffer store in the page pool KDCINF LTERM / LPAP / OSI-LPAP / TAC: query the assignment of message queues for individual objects KDCINF PAGEPOOL: query the page pool page utilization subdivided according to types KDCAPPL SPOOLOUT: reduce size of printer queues KDCLTERM or KDCLPAP: establish connection to communication partners KDCAPPL ASYNTASKS: change the number of processes KDCTAC STATUS: change the status of a transaction code KDCTCL: change the number of processes in a TAC class

KC_GET_OBJECT with obj_type=KC_CURR_PAR: query the total number of messages in buffer store in the page pool with obj_type=KC_LTERM / KC_LPAP / KC_OSI-LPAP / KC_TAC: assignment of message queues of individual objects with obj_type=KC_PAGEPOOL: query the page pool page utilization subdivided according to types KC_SPOOLOUT: reduce the size of printer queues KC_MODIFY_OBJECT with obj_type=KC_LTERM/ KC_LPAP/KC_OSI_LPAP: establish connections with obj_type=KC_TASKS_PAR: change number of ASYNTASKS processes with obj_type=KC_TAC: change the status of a transaction code or a TAC queue with obj_type=KC_TACCLASS: change the number of processes in a TAC class DADM (KDCS call): delete jobs and move messages from the dead letter queue

In applications without TAC-PRIORITIES:
reducing the size of job queues in TAC classes

The information functions enable you to determine the number of jobs in buffer storage in the page pool in any given TAC class. The information which openUTM issues on a TAC class includes the number of messages stored in buffer storage in the page pool.

In order to reduce the size of these queues you can increase the maximum number of processes able to process jobs in this TAC class at the same time.

	KDCINF TACCLASS query number of dialog jobs in buffer storage KDCTCL: change number of processes
	KC_GET_OBJECT with obj_type=KC_TACCLASS: query number of dialog jobs in buffer storage KC_MODIFY_OBJECT with obj_type=KC_TACCLASS: change number of processes

Enabling or disabling data compression

When a large number of page pool pages are utilized for GSSBs, LSSBs, TLS, or ULS (KDCINF PAGEPOOL or KC_GET_OBJECT with obj_type=KC_PAGEPOOL), you should check whether enabling data compression might possibly reduce the number of utilized pages.

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