Reserving locations in the KDCFILE object tables

The configuration data of a UTM application is stored in the object tables of the KDCFILE, which is created in the KDCDEF generation of the application. These object tables can only be expanded dynamically insofar as free table locations are available. For this reason, free table locations for objects you do not want to incorporate into the application configuration until the application is running, must still be reserved when generating with the KDCDEF statement RESERVE. You can reserve table locations for the following UTM objects:

UTM object	Object type
User IDs	USER
TS applications, UPIC clients, terminals and printers	PTERM
LTERM partners	LTERM
Program units and VORGANG exits	PROGRAM
Transaction codes and TAC queues	TAC
Transport connections to LU6.1 partner applications	CON
LU6.1 session names	LSES
Key sets	KSET
Local service names for remote applications	LTAC

With the RESERVE statement in section "RESERVE - reserve table locations for UTM objects", you define the number of empty table locations to be created for an object type; this corresponds to the number of individual objects of the respective object type that can be configured dynamically.

The number of table locations that can be created for each object type is limited by the number of names that can be generated. See also the table in section "Number of names".

The empty table locations in the object tables are reserved for specific object types, i.e. a table location you reserved for an LTERM partner for example, cannot be occupied by a transaction code, etc.

During the application run, the number of objects of a particular type that can be configured dynamically corresponds to the number of empty table locations you reserved with
KDCDEF. Deleting another object of the same type does not immediately release a table location for a new object.

User IDs are one exception to this. You can delete user IDs in one of two ways, "delayed" or "immediately". If a user ID is deleted with "delayed", then the table locations remain reserved (as for the other types of objects). If the user ID is removed "immediately" from the configuration, the table location for this user ID is released and can be used immediately for a new user ID.

Please note the following when reserving table locations with RESERVE: openUTM internally creates a user ID for each UPIC client and each TS application entered dynamically in the configuration. Therefore, in UTM applications generated with user IDs (the KDCDEF generation contains at least one USER statement), an additional table location for user IDs must be reserved for each client of type APPLI, SOCKET, UPIC-R or UPIC-L to be entered dynamically. These table locations are not released when the clients are deleted (corresponds to a “delayed“ delete). In applications without user IDs, these table locations are reserved internally by openUTM.

Examples

RESERVE OBJECT=LTERM, NUMBER=100

This means that up to 100 LTERM partners can be entered dynamically in the configuration.

RESERVE OBJECT=LTERM, PERCENT=200

In this case, the number of reserved table locations was defined relative to the number of statically generated LTERM partners. Twice as many (200%) LTERM partners can be created dynamically as were entered statically in the KDCDEF generation. If 50 LTERM partners were entered in the KDCDEF generation, another 100 LTERM partners can be entered dynamically.

RESERVE OBJECT=ALL, NUMBER=100

This means that 100 objects can be entered dynamically for each object type, i.e. 100 user IDs, 100 LTERM partners, etc.

RESERVE OBJECT=USER, NUMBER=0

This statement means that the number of objects of the specified type (here USER) can be increased dynamically up to the maximum value that can be generated.

Due to the large amount of space required by the tables, it is advisable to specify a value != 0 for NUMBER in order to reduce the space requirement of the application.