Error recovery must be capable of performing the following steps in the event of an error in the system:
It must be able to roll back all open transactions. As in the case of an error in the application program, this is done with the aid of before-images.
The results of all completed transactions that are not yet in the database must be committed to the database. This is done with the aid of after-images (after images describe the state of data after it has been updated). To this end, the after-images of each transaction are written to the RLOG file, at the latest by the end of the transaction.
Warm start
Following a DBH crash, the databases involved are inconsistent if they have been updated during the session. If these databases are attached to a configuration, UDS/SQL first performs a warm start for these databases. This involves rolling forward completed transactions and rolling back open transactions. The databases are then flagged as consistent.
If a openUTM application is involved, the statuses of the individual transactions must be synchronized with openUTM, for which purpose a status file is required (see section “Status file”).
If a UDS-D application is involved, it is also necessary to synchronize global transactions. Global transactions are transactions for which DML statements are processed in more than one DBH. The status file is required in order to perform this synchronization, too.
Following a DBH crash, you may not update the databases involved until a warm start is performed. This rule does not apply in the following cases:
The database is destroyed during or after a DBH crash. You must then read in a backup and use the BMEND utility routine to update the database to the time of the crash (UPDATE-DATABASE, DEADLINE = BREAK-POINT statement).
After the crash, only DMS catalog entries for the files involved, but not their contents, are updated (e.g. following file reorganization by the computer center and swapping out and in by HSMS).
In this case, the DBH may reject the warm start. If this happens, you must use the BMEND utility routine to update the crashed database to the time of the crash (statement UPDATE-DATABASE, DEADLINE = BREAK-POINT).
Session restart
UDS/SQL stores information on the current configuration in the SLF (see section “Session log file (SLF)”). If the DBH is started after a crash with the same configuration name, the DBH takes the DBH load parameters from the SLF. The DBH load parameters that you specified when starting the DBH are then ignored.
This procedure is called session restart.
If you do not want a session restart, you must delete the SLF before starting the DBH.