UTM storage areas

openUTM offers program units for reading and writing user data in various storage areas. These storage areas provide a clear distinction between program and data areas, as well as guaranteeing the reentrant capability of programs. They also allow for high-performance, transaction-oriented communication between programs, and ensure effective memory utilization. Some storage areas are designed specifically for statistical or logging purposes.

In this sense, service-controlled queues can also be considered as UTM storage areas. Since service-controlled queues are designed specifically for message queuing, they are described separately in the chapter "Message queuing" especially in subchapter "Service-controlled queues" .

Primary storage areas

These are storage areas which are available to the program units in the main memory:

• Communication area (KB)

  openUTM creates the communication area when a new service is started. The contents of the communication area are transferred to the program unit currently being executed. In the communication area, openUTM provides the program units with up-to-date information. This area is also used for communication between the program units of a service. Its size can be adapted to the data to be transferred. The communication area is subject to transaction security and continues to exist until the service is terminated.

• Standard primary working area (SPAB)

  By default, openUTM assigns a standard primary working area to each program unit. This area is then available to the program unit from the start of the program to the end of the program (PEND call). The data in this area therefore cannot be stored or forwarded once the program unit run is terminated. The SPAB can be used for the parameter area in which the program unit supplies the parameters for KDCS calls. It can also be used to buffer messages, for example. Since the standard primary working area is reserved for a specific program unit, it is not integrated in transaction management. One advantage the SPAB has over other forms of program memory (e.g. stacks) is that the SPAB is output in the UTM dump.

• Other areas

  A program unit can use other areas for storing data. These areas are defined during generation using the KDCDEF statement AREA and must be managed by the users themselves, they are not subject to transaction management. Their structure is not prescribed by openUTM and can be defined freely.

Secondary storage areas

These storage areas are implemented by openUTM in background memory that is subject to transaction management. They are read and written to using special KDCS calls:

• Local secondary storage area (LSSB)

  The local secondary storage area is a service-specific background storage area used to transfer data between program units within a particular service. While the communication area is automatically provided and logged for each program unit, the local secondary storage area is accessed only when required. It is therefore particularly suitable for read-only data, or for cases where several program units which do not require the respective data are to be executed between the write operation and the read operation. The local secondary storage area continues to exist until it is explicitly released or the service is terminated.

• Global secondary storage area (GSSB)

  The GSSB is a background storage area that allows for any data to be transferred between the services in a UTM application. Unless it is explicitly released, it continues to exist even after the application is terminated.

  In UTM cluster applications, GSSBs can be used cluster-wide; all node applications have the same view of the data of a GSSB.

• Terminal-specific long-term storage area (TLS)

  The TLS is assigned an access point (LTERM, LPAP or OSI-LPAP partner) and is used to store information that must be available irrespective of the duration of a service or the runtime of the application. For instance, it can be used to produce statistics for an LTERM partner.

  In UTM cluster applications, TLSs are only supported locally in the node.

• User-specific long-term storage area (ULS)

  A ULS can be assigned to each user ID during configuration. It is used to store information that must be available irrespective of the lifetime of the services or the runtime of the application. For instance, it can be used to produce statistics for each user ID.

  A ULS is also assigned a session (LU6.1) and an association (OSI TP).

  In UTM cluster applications, ULSs can be used cluster-wide; all node applications have the same view of the data of a ULS.

User log file (USLOG)

The user log file is a log file managed by openUTM in which user-specific information can be written using the KDCS call LPUT. It is implemented in the form of a file generation group (see the openUTM manual “Generating Applications”). The user log file can be used to record attempts to violate the data access control mechanisms, for example.

Each node application has its own user log file in UTM cluster applications.

The user log file is subject to transaction management and is therefore not suitable for use as a general log function. This is because the LPUT information is discarded when a transaction is rolled back. 

Overview: UTM storage areas

Abbreviation	Type of Area	Life Cycle	Function	Transactional Backup
KB	Communication area	From the start of the service until the end of the service	Access to up-to-date information provided by openUTM; communication between the program units of a service	Yes
SPAB	Standard primary working area	From the start of the program unit until the end of the program unit	Transfer of parameters for KDCS calls; message buffer	No
AREA	Other storage area defined during generation	For the duration of the application	Store global application data, preferably for read-only purposes; In UTM cluster applications, AREAs only apply locally to the node.	No
LSSB	Local secondary storage area	From the first write call until explicit release or until the end of the service	Data exchange between the program units of a service	Yes
GSSB	Global secondary storage area	From the first write call until explicit release or until deletion of the application information	Distributed data exchange	Yes
ULS	User-specific long-term storage area	From generation until the generation is modified	For example, statistics for particular user IDs, sessions or associations	Yes
TLS	Terminal-specific long-term storage area	From generation until the generation is modified	Statistics for particular access points (LTERMs, LPAPs, OSI-LPAPs)	Yes
USLOG	User log file	Defined individually	Logging	Yes