The inverse KDCDEF function provided by openUTM is used to ensure that changes made to the configuration dynamically during runtime are not lost when your application is regenerated. It creates control statements for the KDCDEF generation tool from the configuration data in the current KDCFILE.
Inverse KDCDEF generates control statements for object types that can be entered and deleted dynamically:
USER statements
For all user IDs currently defined in the application. Inverse KDCDEF does not create USER statements for user IDs defined internally by UTM for the LTERM partners of clients of type UPIC-R, APPLI and SOCKET.
LTERM statements
For all LTERM partners of the application which do not belong to an LTERM pool or to a multiplex connection (BS2000 systems).
PTERM statements
For all clients and printers entered in the configuration. No PTERM statements are created for clients that connect via an LTERM pool to the application or that belong to a multiplex connection.
PROGRAM statements
For all program units and conversation exits currently defined in the application configuration.
TAC statements
For all transaction codes and TAC queues of the application.
KSET statements
For all key sets of the application.
CON statements
For all LU6.1 connections of the application.
LSES statements
For all LU6.1 session names of the application.
LTAC statements
For all local transaction codes for VTV partner applications.
Control statements are also generated for objects of the types listed above, which were created statically in a previous KDCDEF generation. All modifications entered dynamically for these objects during runtime are taken into consideration.
Inverse KDCDEF does not create control statements for object types other than those listed above. Nor does it generate control statements for other components of the application or for application parameters.
It does not create control statements for objects that were dynamically deleted from the application configuration. After regeneration, these objects are thus permanently removed from the configuration. They do not occupy a table location and their object names are no longer reserved.
After regeneration with KDCDEF, the update tool KDCUPD does not transfer any application data from the old KDCFILE to the new KDCFILE, which relates to objects deleted dynamically. This applies even if the new KDCDEF generation includes an object with the same name and type as a deleted object. In particular, KDCUPD does not transfer any asynchronous jobs created by LTERM partners or user IDs that have since been deleted.
The USER statements created by inverse KDCDEF do not include any passwords. For user IDs generated with a password, inverse KDCDEF creates USER statements with the following format:
USER username, PASS=*RANDOM,....
Once the KDCDEF run is complete and the new KDCFILE has been created, you must transfer the passwords of the user IDs to the new KDCFILE using the KDCUPD tool. This is also possible in a UTM-F application. For further information, see "The tool KDCUPD - updating the KDCFILE".
It is not generally necessary to transfer the passwords with KDCUPD with UTM cluster applications. In UTM cluster applications, the current passwords are stored in the cluster user file and not in the KDCFILE.
You only need to transfer the passwords with KDCUPD if a new cluster user file has been generated and you wish to retain the passwords from the last application run.