Previous Topic: Propagating EnqueuesNext Topic: Rejecting Auto-Restore Requests Through Exclusion Tables


Precautions in Changing Immediate to Deferred Requests

Sysparm ARTAPEOK (with a value of D) and user exit ARESPREX (by setting the return code to H'1') both provide the ability to change an immediate restore request into a deferred request; that is, place the Auto-Restore request in the restore queue rather than process it immediately. The sysparm option automatically defers a request only if it is for a TSO user and a tape mount is required. Batch jobs and restores from disk archives are not affected. The user exit is more general, however, and can defer any of the various request types.

You should consider that there is a slight exposure before using either of them. As you can see from the following description, the exposure is extremely low under most circumstances, especially with the sysparm option, but indiscriminate use of the user exit option can cause a problem.

The concern exists only if two jobs , TSO users or both happen to want the exact same archived data set at the same time. CA Disk Auto-Restore processing for the second request detects that another Auto-Restore task (serving the first request) is already processing the same data set. The second job is then placed in a wait state (if it's batch), or informed that the restore is in progress, and to try again later (if it's a TSO user).

If the sysparm option is used and the first request is from TSO and the second one from batch, the batch job will fail because of its assumption that the Auto‑Restore for the TSO user was actually restoring the data set, when in fact it just placed it in the queue.

If the user exit is used to force a request to be queued instead of restoring it immediately, the results for the second job of two simultaneous requests can be as just described, without regard to the TSO or batch status of either requester.

To summarize, the exposure exists only if two jobs/users attempt to access the same archived data set at the same time. This probability is very low. If the sysparm option is used, the probability is further reduced by the fact that the first job must be a TSO request, and the second a batch job.