Processing priority of recalls and deletions

You may receive complaints from end users that an inordinate amount of time was required to service a long series of NOWAIT requests for recalls or deletions. The delay occurs only if DFSMShsm is heavily loaded with recall and deletion requests in relation to the number of tasks that are permitted to process them. The delay is caused by the priority scheme that DFSMShsm uses to prevent one user from monopolizing the system and from tape mount optimization processing.

The same queue of management work elements (MWEs) processes all recall and deletion requests that are submitted to one DFSMShsm host. This queue is called the recall queue. DFSMShsm gives all WAIT requests a higher priority (position) on the queue than NOWAIT requests. The NOWAIT requests are interleaved according to the user ID of the submitter. All users start one NOWAIT request before any user starts a second NOWAIT request. Processing of the requests is generally from the oldest to the newest requests.

An exception to the order of processing is when doing recalls from tape, where DFSMShsm reduces the number of mounts by doing several recalls from a given tape while the tape is continuously mounted. If a recall task has just completed a recall from a tape, it processes the highest-priority request that is currently on the queue for that same tape, no matter where the request is positioned on the queue. DFSMShsm continues to process only recalls from this single tape for a duration of time that is specified by the TAPERECALLLIMITS parameter. After the time specified by the TAPERECALLLIMITS parameter is reached, DFSMShsm determines whether a higher-priority recall request that needs this tape exists on another DFSMShsm host. If so, it ends the recall processing on the tape by the current DFSMShsm host, freeing the tape for use by other hosts. If no higher-priority request exists, DFSMShsm continues to process any recalls requested from the tape. DFSMShsm checks after every recall for a higher-priority recall request from other hosts.

When performing recalls from tape, DFSMShsm also determines if there is a higher-priority tape recall request from the same host, for a different tape, that cannot be performed because DFSMShsm is already processing at the maximum permitted tape recall task limit. If so, it ends recall processing on the tape that has met the specified TAPERECALLLIMITS processing time, enabling the higher-priority recall request from DASD or a different tape to take place.

Programming interface information

Programming interface information You can use the return-priority installation exit ARCRPEXT to change the priorities of these requests as the requests are put on the queue. ARCRPEXT allows you to assign a relative queuing priority such that WAIT requests can be prioritized relative to other WAIT requests and NOWAIT requests prioritized relative to other NOWAIT requests. You can, for example, give recalls a higher priority than deletes, or give interactive requests a higher priority than requests from batch processing. You can even negate the interleaving scheme described earlier in this topic for interactive NOWAIT requests. (In the case of a NOWAIT request that is initiated from a volume recover request, the queuing priority is initialized with the value that is propagated from the volume recover request passed earlier to the exit.) For more details on ARCRPEXT, see z/OS DFSMS Installation Exits.

Note: With regard to the common recall queue, ARCRPEXT is invoked by the host that the request originated on.

End of programming interface information

You can also affect the order in which data sets are recalled from a single tape by specifying the SETSYS command with TAPEDATASETORDER. For more information about the TAPEDATASETORDER keyword, see Specifying the order in which data sets from a single tape are processed.