The update tool KDCUPD creates a runtime log that contains the following important information in addition to the parameters specified:
Specifications on the data that was transferred.
Specifications on the data that could not be transferred (these messages are marked with
*).Brief information on the page pool usage
KDCUPD compares the generation of the old and new KDCFILE.
As a result of these checks, KDCUPD can reject transfer of individual items of user data because they are incompatible with the generation options of the new KDCFILE.
It is also possible for KDCUPD to reject transfer completely because individual generation options of the old and new KDCFILE differ so significantly that it would not be possible to start the application with the new KDCFILE and the transferred data (see also "Changing generation parameters").
The runtime log is output to SYSOUT and SYSLST or to stdout and stderr by default. The output can be controlled using the LIST statement.
The KDCUPD messages are listed in the openUTM manual ”Messages, Debugging and Diagnostics”. The causes of error and the actions to be taken in response to the UTM message are described where necessary.
On Unix, Linux and Windows systems KDCUPD uses the NLS message catalog to output its messages.
Behavior in the event of errors
If an internal error occurs, KDCUPD creates a UTM dump (on Unix, Linux and Windows systems the dump is located in the DUMP subdirectory of the base directory).
This dump can be edited using the KDCDUMP editing tool (see the openUTM manual ”Messages, Debugging and Diagnostics”).
On BS2000 systems the process switch 3 is set if KDCUPD cannot terminate itself normally due to an error. Process switch 3 is also set when not all of the data could be transferred to the new KDCFILE because some generation components have been removed although KDCUPD terminated itself normally.
The process switch 3 is also set if KDCUPD could not run because an error occured during checking the KDCFILEs.
Diagnostic documentation
If an error message is output in relation to the execution of KDCUPD, the following documentation should be supplied or at least saved:
UTM dump, if one was created
In the event of a memory bottleneck, it may be the case that no dump file can be written.For UTM applications on Unix and Linux sYstems the core dump also must be logged.log of KDCUPD
KDCDEF control statements for the old and new KDCFILE
(unless prohibited for data protection reasons)the old KDCFILE
the new KDCFILE in the state before the KDCUPD run
(alternatively KDCDEF control statements)in the case of cluster updates:
the old cluster files and the new cluster files in their state before the KDCUPD run