Question 5: If a data set becomes unusable, should all applications be terminated while recovery is performed? If degraded service to any application must be preserved while recovery of the data set takes place, you will need to include procedures to do this.

Question 6: Which of the files to be updated are to be regarded as vital? Identify any files that are so vital to the business that they must always be recoverable.

Question 7: How important is data integrity, compared to availability? Consider how long the business can afford to wait for a record that is locked, and weigh this against the risks to data integrity if the normal resynchronization process is overridden.

The acceptable waiting time will vary depending on the value of the data, and the number of users whom you expect to be affected. If the data is very valuable or infrequently accessed, the acceptable waiting time will be longer than if the data is of low value or accessed by many business-critical processes.

Question 8: How long can the business tolerate being unable to use the application in the event of a failure? Indicate (approximately) the maximum time that the business can allow the system to be out of service after a failure. Is it minutes or hours? The time allowed may have to be negotiated according to the types of failure and the ways in which the business can continue without the online application.

Question 9: How is the user to continue or restart entering data after a failure? This is an important part of a recovery requirements statement because it can affect the amount of programming required. The terminal user’s restart procedure will depend largely on what is feasible—for example:

vMust the user be able to continue business by other means—for example, manually?

vDoes the user still have source material (papers, documents) that allow the continued entry (or reentry) of data? If the source material is transitory (received over the telephone, for example), more complex procedures may be required.

vEven if the user still has the source material, does the quantity of data preclude its reentry?

Such factors define the point where the user restarts work. This could be at a point that is as close as possible to the point reached before the system failure. The best point could be determined with the aid of a progress transaction, or it could be at some point earlier in the application—even at the start of the transaction. Note: a progress transaction here means one that enables users to determine the last actions performed by the application on their behalf.

These considerations should be in the external design statement.

Question 10: During what periods of the day do users expect online applications to be available? This is an important consideration when applications (online and batch) require so much of the available computer time that difficulties can arise in scheduling precautionary work for recovery (taking backup copies, for example). See “The RLS quiesce and unquiesce functions” on page 168.

Validate the recovery requirements statement

After considering the above questions, produce a formal statement of application and recovery requirements.

102CICS TS for z/OS 4.1: Recovery and Restart Guide

Page 114
Image 114
IBM SC34-7012-01 manual Validate the recovery requirements statement