Under openUTM, program units can use various storage areas for the reading and writing of user data. These storage areas ensure a clear distinction possible between program and data areas and ensure that programs are reentrant. Additionally, these areas also enable the transaction-logged, high-performance exchange of information between programs and guarantee the efficient usage of working memory. Some memory areas are specially designed for statistical purposes and for logging.
In addition to the storage areas shown here, openUTM also offers you the chance to use service-controlled queues for communication between program units (see section "Messages to service-controlled queues").
The following storage areas are available:
standard primary working area (SPAB)
communication area (KB))
local secondary storage area (LSSB)
global secondary storage area (GSSB)
terminal-specific long-term storage (TLS)
user-specific long-term storage (ULS)
user log file (for writing only)
areas (AREA)
The number of GSSBs, LSSBs, TLS blocks and ULS blocks available in a UTM application is specified during generation; names are also assigned for the TLS and ULS blocks at this time; the names of the GSSBs and LSSBs are specified when programming the application.
Storage location for user data
In the case of standalone applications, the user data in the KB, GSSBs, LSSBs, TLS and ULS blocks is stored in the KDCFILE.
Unix, Linux and Windows systems
In a UTM cluster application, each node application possesses a separate KDCFILE. The fact that some data is valid at local node level whereas other data is valid globally throughout the cluster results in a number of peculiarities compared to standalone applications:
- Data that is local to the node is stored only in the KDCFILE file of the relevant node application. Data that is local to the node includes, for example,TLS, asynchronous messages, background jobs and data relating to other node-bound services. The KDCFILEs of the individual node applications are not identical at runtime.
Data that applies globally in the cluster is stored in UTM cluster files such as the cluster page pool or the cluster user file, see the openUTM manual “Concepts and Functions”. This includes user data such as GSSB, ULS, the service data of users and passwords.
Storage concept
The storage concept supports the following functions:
reentrant capability of program units (SPAB)
application data can be accessed by two or more services running in parallel (GSSB, TLS, AREA)
protection of user-specific data against access by foreign login names (ULS)
transaction-oriented storage of logging data (user log file)
independence of program units running in parallel (KB, LSSB).
openUTM provides two types of storage area:
working memory areas (KB, SPAB)
These are storage areas which are available for the program units in the working memory. You can address them directly.secondary storage areas (GSSB, LSSB, TLS, ULS, log files)
openUTM sets up these storage areas in background storage areas and uses special KDCS calls to write to and read from them.
Depending on their function these areas are assigned to:
a program unit (SPAB)
a service (KB and LSSB)
an LTERM, LPAP or OSI-LPAP partner (TLS)
a user ID (USER), Session (LSES) or Association (OSI-LPAP ASSOCIATION NAMES)
the application (log file, AREAs, GSSB).
If a service is processed in two or more processing steps or in two or more program units, the data has to be stored and passed on. For this you use:
the communication area (KB) and the
local secondary storage area (LSSB).
You should use the KB for data required in each processing step.
LSSBs are to be used either when the data is not required in each program unit run of a service or when there is more than 32 Kbytes of data, which means that it will not fit in the KB.
Function and lifetime of the storage areas
The following table provides a summary of the lifetimes and functions of the KDCS storage areas. The diagram on the next page also shows the KDCS calls you can use for storage processing and illustrates the assignment of the individual storage areas.
Abbreviation | Area type | Lifetime | Function |
|---|---|---|---|
KB | Communication area | Start of service to end of service | Accesses current information provided by openUTM; exchanges data between program units of a service |
SPAB | Standard primary working area | Start of program unit to end of program unit | Transfers parameters for KDCS calls; message buffers |
AREA | Additional storage area, declared for each generation | Duration of application | Accepts global data of an application; preferably used for read access only. Unix, Linux and Windows systems |
LSSB | Local secondary storage area | From first write call to explicit release or deletion of user ID | Exchanges data between the program units of a service |
GSSB | Global secondary | From first write call to explicit release or end of service | Exchanges data across services |
ULS | User-specific long-term storage | Generation until generation modification | E.g. statistics which are specific to particular users (USER), LU6.1 Sessions (LSES) or OSI-TP Associations (OSI-LPAP ASSOCIATION-NAMES) |
TLS | Terminal-specific long-term storage | Generation until generation modification | Statistics which are specific to particular connection points (LTERMs, LPAPs, OSI LPAPs) |
USLOG | User log file | Individually defined | Logging |
Figure: Assignment of the KDCS storage areas and KCDS calls for storage processing