The KDCFILE of a standalone application consists of one or more files and contains the data required to run a UTM application. It is created using the KDCDEF generation tool (see "Defining the configuration"). When operating a UTM application, the KDCFILE is shared by all processes within the application.
The KDCFILE is logically divided into the following three areas:
administrative data
the page pool
the restart area
For data protection, the KDCFILE can be mirrored on different disk drives.
To avoid disk bottlenecks and improve access times, the page pool and the restart area can be distributed across several files.
| A detailed description of the KDCFILE can be found in the openUTM manual “Generating Applications”. |
Administrative data
The administrative data area contains information on the configuration, e.g. parameters of the UTM application, lists of the contents of all objects that can be addressed by name, administrative information on the page pool and the restart area, as well as tables of services, user IDs, clients, transaction codes, lock codes, and function keys.
When a UTM application is started, the administrative data used by the application processes, and about which they communicate, is provided in a shared memory area. Any changes to the administrative data are written back to the KDCFILE while the application is running and after the application is terminated. This ensures that the data is retained for the next application run, and allows for an automatic restart if the UTM application is terminated abnormally.
Page pool
The page pool contains all user data that arises during a UTM application run. Examples include:
various secondary storage areas
information for a screen restart
communication areas
queues containing output jobs (including time-driven output jobs) and background jobs
messages of service-controlled queues
buffered records from the user log file
The active UTM application can access the page pool via the UTM cache. The size of the page pool (number of UTM pages) is defined during generation.
Restart area
The UTM calls in a program unit result in changes to the administrative data and user data. openUTM collects information on all modifications that occur within a transaction.
In the case of a UTM-S application (see "Restart with UTM-S"), openUTM uses this information to generate a data record containing restart information at the end of the transaction. It then writes this data record in the restart area of the KDCFILE. The data record describes the changes that must be made to the administrative data as a result of the transaction. The size of the restart area determines how often modifications to the administrative data should be transferred to the administrative data area of the KDCFILE. You can use an administration command to find out what this interval is.
In the case of a UTM-F application (see "Restart with UTM-F"), restart data records are written only for transactions in which passwords were changed or administrative data was modified by means of dynamic configuration.