Page pool

The page pool stores user data created during the application run. This includes:

• LSSBs, GSSBs, TLS blocks, and ULS blocks

• message queues, i.e. asynchronous messages (including time-driven messages) for clients, asynchronous services and service-controlled queues, and the dead letter queue, among other items

• buffered user log records (USLOG)

• service data (KB program area, last dialog message, etc.)

• dialog messages buffered after input as a result of TAC class or priority control

• output messages to clients

A number of specific characteristics apply to UTM cluster applications on Unix, Linux or Windows systems, see "Notes on generating a UTM cluster application".

The active UTM application accesses the page pool via the UTM cache, see KDCDEF generation, MAX statement, CACHESIZE operand in section "MAX - define UTM application parameters".

You can define the size of the page pool (number of UTM pages) during KDCDEF generation using the MAX statement:

MAX...,PGPOOL=( number, warnlevel1, warnlevel2 )

number	Size of the page pool in UTM pages
warnlevel1	The first warning is output when the percentage utilization of the page pool reaches the value specified here
warnlevel2	The second warning is output when the percentage utilization of the page pool reaches the value specified here

The current utilization of the page pool can be queried by the administration, e.g. using the KDCINF PAGEPOOL command (see openUTM manual “Administering Applications”) or by means of WinAdmin or WebAdmin.

The utility program KDCUPD provides another way of obtaining more detailed information about the type of the data stored in the page pool. It is possible to display the number of pages used for each application object, e.g. for each user. You will find more information on this subject in section "The tool KDCUPD - updating the KDCFILE".

Estimating the necessary size of the page pool

Once the page pool size has been defined, it cannot be modified while the application is running. When designing a UTM application, it is therefore necessary that you estimate the page pool size which will be required during runtime. The page pool size cannot be modified until after the application has been terminated. This involves regenerating the KDCFILE using the KDCDEF generation tool, whereby the existing user data is copied then from the old KDCFILE to the new KDCFILE using the KDCUPD tool. Further information can be found in section "The tool KDCUPD - updating the KDCFILE".

When estimating the required page pool size, you must examine the behavior of the program units, identify which data areas are stored in the page pool, and determine their size. The following must also be noted:

• The page pool is divided into UTM pages:
  a UTM page is either 2KB, 4KB or 8KB in length, depending on the value of the BLKSIZE= parameter in the MAX statement.

• The following applies for the data areas GSSB, LSSB, TLS, and ULS:each of these data areas begins on a new UTM page. Of each UTM page, 1994 bytes (in the case of a 2KB UTM page), 4042 bytes (in the case of a 4KB UTM page) or 8138 bytes (in the case of a 8KB UTM page) are available for user data. The remaining space is reserved by openUTM.

  openUTM offers the option of compressing the user data of these areas, see the DATA-COMPRESSION parameter of the MAX statement. This can reduce the number of UTM pages required.

• The following applies to asynchronous messages:
  Each message begins on a new UTM page. Of the first UTM page of a message, at least 1914 bytes (in the case of a 2KB UTM page), 3962 bytes (in the case of a 4KB UTM page) or 8058 bytes (in the case of a 8KB UTM page) are available for user data. Of each follow-up page occupied by the message, at least 2030 bytes (in the case of a 2KB UTM page), 4078 bytes (in the case of a 4KB UTM page) or 8174 bytes (in the case of a 8KB UTM page) are available for user data.

  In future versions of openUTM, it is possible that less space will be provided for user data on each UTM page. When programming, therefore, you should ensure that all the available space is not exhausted.

• If an existing area is modified, openUTM stores the new area up to the end of the transaction at another location in the page pool. The area is thus temporarily duplicated.

  

  Figure 4: Dual-file operation of changed areas in the page pool

You must also allow for the volume of FPUT and LPUT messages. Make sure that the page pool is not too small.

Page pool overflow warning

While the application is running, it is vital that the page pool does not become full as it is also required to back up the dialog messages. For this purpose, openUTM provides the following protective measures:

• There are two warning levels (percentages), which can be set during generation. If utilization of the page pool exceeds or falls short of these values, openUTM outputs UTM message K040 or K041, so that the user can respond with a MSGTAC routine.

• Local asynchronous messages and LPUT calls to write records to the USLOG file are rejected if utilization of the page pool has reached warning level 2.

• Asynchronous messages from a partner application via LU6.1 or OSI TP are rejected if utilization of the page pool has reached warning level 2. The connection is cleared. When communicating via OSI TP, the message K119 OSI-TP error information with the insert DIA3=21 is output in both applications. The queued message is resent to the partner application at regular intervals determined by the value in MAX CONRTIME.

• An asynchronous job issued by a terminal or TS application is reject with UTM message K101 if utilization of the page pool has reached warning level 2.