Technical Limitations

The Journaling and Commitment Control facilities have some limitations and unique requirements.  This required the creation of custom programs for Recovery Management.  It also raises some additional processing considerations.

Commitment Control

Commitment processing requires that all files under commitment control are journaled to the same journal.  This means that the creation of multiple journals to improve performance could prevent the use of commitment control.  Commitment control can only handle transactions in which a maximum of 1,024 updates are made.  This makes commitment control an unlikely means of recovery for batch update applications. Commitment control also locks all updated records until the transaction is complete.  One online update could have 1,024 records that would not be accessible to other users, thus creating many record lock situations.

File Reorganization and Journaling

The use of journaling requires that file reorganization steps are monitored closely.  Journaling keeps track of record updates using the relative number of the records in the data base file.  File reorganizations that alter relative record numbers make the journal useless as a recovery tool.  File reorganizations must be controlled so that recovery can still be performed using journal receivers.

Online Rollback

The rollback process is a direct re-application of the before image rather than a net change rollback.  Therefore, it is imperative that all rollback file processing is initiated immediately after system failure.  This ensures that updates made after the failure are not overwritten by the before image of an old transaction applied during recovery processing.  All subsequent updates are identified at the time of online rollback to detect situations in which updates were removed for transactions other than the failed transaction.

Off-line Rollback

Since recovery from a batch failure requires the removal of many more updates than recovery from an online failure, the off-line rollback removes ranges of journaled updates rather than individual updates.  The range of updates is identified by the beginning user journal for the failed application and the last update performed by the application.

This requires that batch update programs are executed sequentially to provide explicit beginning and ending points within the journal receiver (with no overlap).  If it is necessary to run concurrent batch update programs, the online rollback approach will have to be implemented for off-line recovery.  This would increase substantially the time it takes to recover off-line failures.