- Limitations of Recovery

Report and screen output is not recoverable and cannot be rolled back. An application procedure that consists of multiple transactions may be partially complete after a process or system failure. Such procedures will need to be either continued or restarted after system recovery. Typically, procedures that commit no writes before completion can be restarted but procedures with committed writes need to be continued.

No processes are automatically recreated after a process or system failure so applications must provide a means for users to restart or continue their incomplete procedures. Ideally, applications would (recoverably) record the initiation and completion of procedures and use this to perform automatic restart or continuation.

It is not feasible to continue procedures with partially complete report output because a new process would be unable to attach the original print job (which is non-recoverable anyway). Procedures that produce report output needs to be restorable.

In order to continue a partially complete update procedure, an application must (recoverably) record its progress as part of each transaction. The application can then use this information to resume processing at the correct point when continuation is required.

After a failure, a screen procedure that commits writes prior to the final user-input must permit navigation to the correct point from which to continue. (See Screen Procedure Design Recommendations, page 160 for more information.)

Comment on this topic

Topic ID: 720131