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.
The recall function also causes tapes to be taken away from other
tasks, such as recycle input, TAPECOPY input, and from recall itself.
- 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.
The recall function can also contend with ABACKUP and ARECOVER.
- 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.
If a tape needed by recall does not become available to the recall
task after 15 retries, DFSMShsm sends message ARC0380A to the operator.
The operator can give one of the following answers:
- 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.