To ensure that regeneration does not cause you to lose the changes you made to your configuration while the application was running, openUTM provides you with the inverse KDCDEF. You can use this inverse KDCDEF to generate control statements for the UTM tool KDCDEF from current configuration data in the KDCFILE.
KDCDEF control statements generated by the inverse KDCDEF
The inverse KDCDEF generates control statements for the object types for which dynamic entry and deletion is possible. The inverse KDCDEF does not generate control statements for other objects and components in the application or for application parameters. However, you can use the inverse KDCDEF to generate the following KDCDEF control statements:
USER statements
For all user IDs that currently exist in the application. The inverse KDCDEF does not create any USER statements for the user IDs created internally by openUTM.
In applications without user IDs, the inverse KDCDEF does not generate any USER statements.
LTERM statements
For all LTERM partners in the application which do not belong to an LTERM pool or a multiplex connection.
PTERM statements
For all clients and printers entered in the configuration. For clients belonging to an LTERM pool or a multiplex connection, no PTERM statements are generated.
PROGRAM statements
For all program units and exits currently contained in the configuration of that application.
TAC statements
For all transaction codes and TAC queues in the application.
KSET statements
For all the application’s key sets.
CON statements
For all the application’s LU6.1 connections.
LSES statements
For all the application’s LU6.1 sessions.
LTAC statements
For all the transaction codes for partner applications.
The inverse KDCDEF generates control statements for all objects in the application belonging to one of these object types, regardless of whether the objects were entered in the configuration dynamically or were generated statically during a previous KDCDEF generation process. All modifications which you performed for this object during the application run are taken into account.
The inverse KDCDEF does not generate any control statements for objects which were deleted dynamically from the configuration of this application. After the next regeneration, these objects are therefore deleted completely from the configuration. They then cease to occupy any space in the table and the names of these objects can reused during regeneration.
Over and above this, after regeneration with KDCDEF, the UTM tool KDCUPD does not transmit any application data relating to the dynamically deleted objects from the old KDCFILE to the new KDCFILE, even if there is an object with the same name and object type as a deleted object in the new KDCDEF generation process. In particular, no asynchronous jobs generated by LTERM partners or user IDs which have subsequently been deleted are passed from KDCUPD.
The USER statements generated by the inverse KDCDEF do not contain any passwords. For user IDs generated with a password, the inverse KDCDEF generates USER control statements in this form:
USER name, PASS=*RANDOM,....
After a new KDCFILE has been generated, i.e. after the following KDCDEF run, you must pass the passwords for user IDs to the new KDCFILE using the UTM tool KDCUPD (see the openUTM manual “Generating Applications”). This is also possible in a UTM-F application.
In the case of UTM cluster applications, the passwords are present in the cluster user file and do no have to be transferred to a new KDCFILE using KDCUPD.