When operating a UTM application, it may prove unavoidable to regenerate the application, i.e. to perform another KDCDEF run. Possible reasons can include:
The maximum values defined during generation must be adapted.
New objects may have to be generated for distributed processing via LU6.1 or OSI TP because the server network has to be extended for distributed processing.
A KDCDEF run is only required for distributed processing via LU6.1 when new LPAP objects have to be inserted. Objects of the type CON, LSES and LTAC, on the other hand, can also be created by means of dynamic administration (provided enough table spaces have been kept free by means of the RESERVE statement).
New load modules, shared objects or DLLs must be inserted in the application program.
The table spaces reserved for dynamic entry of objects in the configuration are occupied. The tables must be extended or objects marked for deletion must be deleted now to create spare table spaces.
You can minimize the application downtime resulting from this type of regeneration. To do this, please note the following recommendations:
When first generating your application, you should distribute the control statements for KDCDEF across several files before making them available to KDCDEF with OPTION DATA=. In particular, you should write the control statements USER, LTERM, PTERM, PROGRAM, TAC, CON, KSET, LSES and LTAC and TAC to separate files. When doing so, ensure that all statements relating to one specific group (see "Starting the inverse KDCDEF") are written to one file. In this way, you can replace these files with files generated by an inverse KDCDEF if you regenerate the application at a later time.
Before regenerating the application and before starting the inverse KDCDEF run, you should dynamically delete all objects no longer intended for the new configuration (KC_DELETE_OBJECT). Compared with manual deletion, dynamic deletion of related control statements from the input file has the following advantages for KDCDEF:
Manual deletion of KDCDEF statements from the KDCDEF input file is messy and prone to errors. Due account must be taken of relationships between the objects and, hence, between the KDCDEF statements during the manual deletion process. If any such relationships are overlooked, you must repeat the KDCDEF run. This only adds to the downtime.
You can automate the procedures involved in regeneration by calling the offline inverse KDCDEF followed by KDCUPD, see openUTM manual “Generating Applications”.
Over and above this, please note that under certain circumstances, when objects are being deleted manually, data stored in the KDCFILE and relating to the deleted objects can be passed to the new KDCFILE by KDCUPD, which is executed in conjunction with the following regeneration operation:
You wish to prevent KDCUPD from transferring the data from the old KDCFILE for a given file (e.g. because the "new" object has the same name and type but different properties). However, with KDCUPD you can only exclude the transfer of data for all objects of a given type, but not for a given object. You should therefore delete the object from the configuration dynamically. The object should be included again in the new generation.
In this case, KDCUPD does not transfer the data belonging to this object, as KDCUPD does not transfer the data of deleted objects.
 | For information on update generations in a UTM cluster application, see the corresponding subsection in the openUTM manual “Using UTM Applications on Unix, Linux and Windows systems”. |
Example
The new configuration should contain a transaction code with the name of an asynchronous transaction code which existed in the “old” configuration. However, the new transaction code calls a different service (i.e. it is assigned to a different program unit). A distinction must be made between the following cases:
The properties of the "old" transaction code have been changed:
In this case, if you enter TRANSFER ASYNTACS=YES, KDCUPD transfers the message queue of the “old” transaction code to the new KDCFILE together with the asynchronous jobs in the queue and assigns them to the “new” transaction code. Entering KDCUPD with TRANSFER ASYNTACS=NO ensures that none of the message queues for asynchronous transaction codes are transferred from the old KDCFILE to the new one.The old transaction code was dynamically deleted from the configuration. In the new configuration, it is included again:
In this case, even if you enter TRANSFER ASYNTACS=YES, KDCUPD does not transfer the message queue for the old transaction code to the new KDCFILE because KDCUPD does not transfer any data from deleted objects.
The same applies to message queues for LTERM partners and USER queues of users.