One of the functions of the CA DB2 for z/OS utility Restart table is the protection against execution of two CA DB2 utilities against the same DB2 Object to avoid data corruption. However in some circumstances, for example with CA Fast Unload Jobs where only SELECT statements are performed, you can find two CA DB2 utilities can be run concurrently with the same UTILID in the Restart table. If the Job fails and it has to be restarted, how does the AUTO-RESTART option in the UTIL member affect CA Fast Unload utility execution?
This operation depends on the value of parameter AUTO-RESTART in the UTIL member of highlvl.CDBAPARM Library. The protection to run more than one CA DB2 utility with the same UTILID is performed with a SYSTEMS wide ENQUEUE.
The ENQUEUE/DEQUEUE name is composed of:
* The DB2 SSID or Group Data Sharing ID
* The UTILID
* CHECKSUM value
The CHECKSUM value is calculated internally, it is based on parameters in SYSIN and it is used to be certain SYSIN parameters are not changed over a possible restart of the job.
If the CA Fast Unload utility has to be restarted the operation depends on value within UTIL member of highlvl.CDBAPARM Library.
The automatic restart allows a job step to automatically restart from the utility statement that failed. The UTILID must be unique and the syntax of the SYSIN cannot be changed as the CHECKSUM value will be different. In this case two CA Fast Unload Jobs with same UTILID cannot be run concurrently, although they run against different table names.
In this case the UTILID does not need to be unique. Two CA Fast Unload Jobs with same UTILID can run concurrently against two different tables as the CHECKSUM will be different, but then if the CA Fast Unload Job fails the automatic restart is not possible.
Bottom line is if you would like to work with the automatic restart of CA Fast Unload Jobs then you have to work with AUTO-RESTART (YES) and the UTILID in the CA Fast Unload Jobs must be unique.