The KDCFILE contains all data required to run a UTM application. It is shared by all application processes during runtime. In its most basic form, the KDCFILE consists of a single file (a PAM file on BS2000 systems). The KDCFILE can also be distributed over several files. For security reasons, it can be duplicated.
The KDCFILE is logically divided into three areas:
Administrative data, see "Administrative data"
Page pool, see "Page pool"
Restart area, see "Restart area"
KDCDEF generation
The KDCFILE is generated during the KDCDEF run by specifying
|
in the KDCDEF statement.
The following characteristics of the KDCFILE must be specified at the KDCDEF generation:
Data block size
Each area within the KDCFILE is organized in units of either 2K, 4K or 8K. These units are known as UTM pages. You can define the block size of a UTM page using the following control statement:MAX...,BLKSIZE={ 2K | 4K | 8K }Whether a block size of 2K, 4K or 8K is to be favored depends on the sizes of the data areas (GSSB, LSSB, etc.) and the lengths of the messages that your program uses. See also "Page pool" for more information.
Base name of the KDCFILE
You specify the base name (called the filebase in the following) and single or dual-file operation of the KDCFILE with:MAX..., KDCFILE={ filebase [, SINGLE | DOUBLE ] }In the case of dual-file operation, the contents of both KDCFILE files are always identical. If one of the files is corrupted, it can be restored by simply copying the other file.
The name specified in filebase is also the base name of additional files and file generations of the application (for example, the system and user log file). filebase is therefore the base name of the application.
The significance of the base name filebase is different for each of the various platforms:
BS2000 systems:
The full names of the files derived from filebase have the following format:
The total length of the file name must not exceed 54 characters. The base name filebase can be up to 42 characters in length, including userid and catid. If no catid or userid is specified when defining the base name (filebase=prefix), the lengths of these fields must still be taken into consideration when determining the total length of the file name.
If file generation groups (i.e. USLOG files, SYSLOG generation group) are not used in the application, prefix can be up to 33 characters in length. Otherwise, prefix must not exceed 26 characters.
The KDCDEF generation tool then creates the following files:
filebase.KDCA in the case of single-file operation (SINGLE)
filebase.KDCA and filebase.KDCB in the case of dual-file operation (DOUBLE)
When splitting the KDCFILE, additional files are created, see "Splitting the KDCFILE".
Unix, Linux and Windows systems:
filebase specifies the name of the base directory in which the KDCFILE is stored.
The KDCFILE is created by KDCDEF under the filebase directory, where filebase is the fully qualified name of a directory which must be created before the KDCDEF run.
The KDCDEF generation tool creates the following files in the filebase file directory:
KDCA in the case of single-file operation (SINGLE)
KDCA and KDCB in the case of dual-file operation (DOUBLE)
Size of the page pool
You can define the size of the page pool using the following control statement:MAX...,PGPOOL=( number, warnlevel1, warnlevel2 )Further information can be found in section "Page pool".
Size of the restart area
You can define the size of the buffer and the restart area using the following control statement:MAX ...,RECBUF=( number,length )Further information can be found in section "Restart area".
During generation, the page pool and the restart area can be distributed over several files. Further information can be found in section "Splitting the KDCFILE".
Data security - dual-file operation of the KDCFILE
For security reasons, it may make sense to duplicate the KDCFILE (dual-file operation). If one of the files is destroyed, then you can continue working with the other KDCFILE without losing data.
Dual-file operation of the KDCFILE does not have any significant effect on I/O times (these are certainly not doubled), and therefore does not reduce performance.
With dual operation of the KDCFILE, it makes sense to store the two files on different volumes (disks). If one of the volumes is physically damaged, this ensures that a viable copy is still available.
BS2000 systems:
You can create the files on the desired volumes by issuing appropriate /CREATE-FILE commands before the KDCDEF run or by copying the files after the KDCDEF run. When generating the application, you can also use the CATID parameter of the MAX statement to assign different CATIDs to the two files.
A copy of the KDCFILE is maintained when you specify MAX KDCFILE=(....,DOUBLE)
in the KDCDEF generation.
Unix and Linux systems:
On Unix and Linux systems you can store the two KDCFILEs on different disks. This is generally only possible with the help of symbolic links (ln -s) to raw devices or across different file systems across different file systems. In this manner, you have a copy of the file even if one of the two disks is physically destroyed.
A copy of the KDCFILE is maintained when you specify MAX KDCFILE=(....,DOUBLE)
in the KDCDEF generation.
Windows systems:
On Windows systems you can additional increase data security with the operating resources already available. For example, you can use single-file operation for the KDCFILE (MAX KDCFILE=(....,SINGLE)) and create a mirrored image of the disk on which the KDCFILE is stored on another disk. During operation, all changes to the KDCFILE are also made on the mirror disk. Even if one of the disks is physical destroyed, you can still continue working with the other hard disk without losing data.