During the operation of a UTM application, it may become necessary to regenerate the application.
For UTM cluster applications on Unix, Linux or Windows systems, there are changes that can be made with a new generation of the KDCFILE with a running UTM cluster application and changes that can only be made when the UTM cluster application has been completely terminated.
 | A list of changes that require the UTM cluster application to be completely terminated before the application is started with the new KDCFILE can be found in the openUTM manual “Using UTM Applications on Unix, Linux and Windows Systems” |
Possible reasons for initiating a new KDCDEF run are listed below:
to adjust the maximum values defined during generation
to create new objects for distributed processing based on LU6.1 or OSI TP, because the server group is to be expanded during distributed processing A KDCDEF run is only needed for distributed processing based on LU6.1 if it is necessary to insert LPAP objects. Objects of the types CON, LSES and LTAC, on the other hand, can be created with dynamic administration (provided that sufficient table entries were reserved with the RESERVE statement).
to enter new load modules (BS2000 systems), shared objects (Unix and Linux systems) or DLLs (Windows systems) in the application program
in cases where table locations reserved for the dynamic entry of objects in the configuration are occupied, to extend the table or to remove objects marked for deletion in order to release the table locations and object names for further use
The application downtime associated with regeneration can be reduced by observing the following recommendations:
When generating your application for the first time, split the KDCDEF control statements between various files depending on whether the objects involved can only be generated statically or can be entered dynamically. These files can then be provided to KDCDEF as input files using the OPTION DATA= statement.
The control statements USER, LTERM, PTERM, PROGRAM TAC, CON, KSET, LSES and LTAC should be entered separately in files in accordance with the various object groups. When regenerating the application, you can simply replace these files with those created by inverse KDCDEF (DEVICE, PROGRAM, and USER, CON, KSET, LSES and LTAC). Further information can be found in section "CREATE-CONTROL-STATEMENTS - Create KDCDEF control statements".
Before regenerating the application or initiating the inverse KDCDEF run, it is
recommended that you dynamically delete all objects that are to be excluded from the new configuration (KC_DELETE_OBJECT call). Further information can be found in the openUTM manual “Administering Applications”.
Compared to the manual deletion of control statements from the input file for the KDCDEF run, dynamic deletion offers the following advantages:
If an object is manually deleted from the input file during regeneration, and another object is defined with the same name and type but with different properties in the same generation run, the KDCUPD tool does not recognize these as two different objects, and transfers the data of the deleted object to the KDCFILE. This can be avoided by dynamically deleting the object beforehand, and then creating an object with the same name and type during regeneration. In this case, KDCUPD will recognize these as two different objects, and will not transfer the data of the old object into the new KDCFILE.
The manual deletion of KDCDEF statements from the KDCDEF input file is both tedious and prone to errors. During deletion, you must look out for dependencies between objects and thus between the KDCDEF statements. If dependencies are inadvertently overlooked, the KDCDEF run will have to be repeated thus increasing downtimes.
The processes performed during regeneration can be automated. Within a single procedure, you can call inverse KDCDEF, transfer the generated files directly to KDCDEF, and call the KDCUPD update tool. This fully automatic procedure minimizes downtimes during regeneration.
To prevent undesirable repercussions from dynamic deletion, make sure for instance that there are no jobs pending for objects deleted or loaded dynamically during runtime.