Recall needs volume
If recall needs a data set that is on a tape volume being used for ML2 output, then recall causes the output task to relinquish that tape and continue its output using a different tape. This applies to all forms of migration: primary space management, interval migration, secondary space management, command data set migration, and command volume migration. It also applies to recycle output.
- For recycle input, the recycle function ends processing on the input connected set and moves on to the next best connected set.
- For TAPECOPY input, the tape takeaway function is optional. After the first recall attempt there is a time allowance before the function initiates the takeaway. This gives TAPECOPY a chance to complete. All the copying done up to the point of the tape takeaway is discarded if the TAPECOPY task does not complete.
- There is a form of recall versus recall contention, and takeaway within a host. If the maximum number of tape recall tasks are running and taking a long time, a high-priority recall for a different tape may not get started because there are no available tasks. This is possible when many requests exist for each tape and you are using tape mount optimization. For this condition DFSMShsm provides a task takeaway consideration at a specified amount of time after a tape is first mounted for recalls. After the specified amount of time is met, a higher-priority request causes recall processing to end on the current tape, freeing a task for the highest-priority request.
Because a takeaway does not happen instantaneously, the recall task does not wait, but leaves this recall on the queue to be retried at approximately two-minute intervals. This enables recalls that are readily performed to proceed. When migration or recycle processing is complete for the data set being processed, the allocated volume is released and a new volume is selected for migration or recycle processing.
- If ABACKUP is reading an ML2 tape and recall needs that tape,
there are two possibilities:
- If the recall request is a NOWAIT request, recall repeatedly tries to access the tape until it reaches the specified limit for retries. A NOWAIT recall does not take tapes away from ABACKUP.
- If the recall request is a WAIT request, recall repeatedly tries to access the tape. However, it does not flag ABACKUP to give up the tape until ten minutes after the first time recall finds the tape is in use. This ten minute delay gives ABACKUP time to complete its use of the tape. After ABACKUP is notified, recall repeatedly tries to access the tape until (unlikely in this case) it reaches the specified limit for retries.
- If ARECOVER is writing an ML2 tape and recall needs that tape, then recall keeps retrying to access that tape until it reaches the specified limit for retries. Recall does not take tapes away from ARECOVER.
When recall completes its use of a tape taken away from other tasks, the tape is released and is available for continued use by other tasks.
- WAIT
- This reply causes the recall task to reset its count of attempts, and begin another sequence of up to 15 retries at two-minute intervals.
- CANCEL
- This reply causes the recall task to end without even allocating the tape, which causes the recall to fail. If you know that the tape will not become available in a reasonable amount of time, use this choice.
- MOUNT
- This reply causes the recall to go ahead and request that the subject tape be allocated and mounted. Use this choice only when you are certain the tape can be mounted. An example is if DFSMShsm says that the tape is in use by a host that is down and is not running.
Related reading
- For more information about the delay time associated with ABACKUP and how to change the delay time, see z/OS DFSMShsm Implementation and Customization Guide.
- For more information about changing the number of recall retries, see z/OS DFSMShsm Implementation and Customization Guide, under supported patches. If the number of retries is patched to zero, the recall immediately fails.