Advanced Topics › Tape Device Allocation and Allocation Recovery Considerations › z/OS Device Allocation Recovery

z/OS Device Allocation Recovery

Allocation recovery is the part of allocation that a job enters when it cannot allocate a suitable online device. During allocation recovery, z/OS tries again to select a device that meets the device requirements of the job. However, z/OS considers the suitability of both currently allocated and offline devices during this part of the allocation process.

z/OS creates two types of lists from the EDL during allocation recovery:

• A list of offline or inaccessible devices. This list is known as the offline device list.
• A list of currently allocated devices for which the job can wait. These devices are called wait-eligible devices.

After creating these lists, z/OS issues messages that tell you the name of the job in allocation recovery and what options you have in getting this job out of allocation recovery. z/OS also may issue additional messages, depending on whether there are any offline devices on the offline device list and on your response to the z/OS IEF238D allocation recovery message.

Remember that z/OS serializes allocation through a locking structure for device groups. While an allocation recovery message is outstanding, z/OS allows no other jobs to select devices from the device groups on the EDL of the current job. z/OS also suspends SWAP processing while a job is in allocation recovery.

While the job is in allocation recovery, no other jobs wanting any of the same devices can proceed in allocation. When GTAF is serializing devices among systems, no jobs wanting the same devices can proceed in allocation on external systems. Therefore, a prompt response to any z/OS allocation recovery message is essential to avoid delays in allocation locally and on external systems.

The following steps provide an overview of the z/OS allocation recovery process:

1. z/OS allocation creates the offline device list and a list of wait-eligible devices for this job, based on the devices in the EDL.
2. z/OS passes the allocation recovery information to any recovery exits loaded at the IEF_SPEC_WAIT or IEF_ALLC_OFFLN exit points.

   If there are no exits, then z/OS issues message IEF238D, which tells you the name of the job in allocation recovery and what options you must choose from to get this job out of allocation recovery. If there are devices on the offline device list, then z/OS issues message IEF877E before issuing the IEF238D message to show you the available offline devices. z/OS waits for you to reply to message IEF238D. z/OS suspends all SWAP processing and all jobs in allocation that need to use the device groups on the EDL of the current job. The job holds the device group locks.

   If exits are loaded, then z/OS takes whatever recovery action is specified by the exits. These actions can include replying automatically to the IEF238D/IEF4433D messages, issuing the IEF238D/IEF433D WTORs, or other actions.

3. z/OS processes your response (or the response of the exit) to the IEF238D message in one of these ways:
   • If you replied CANCEL, then z/OS cancels the job.
   • If you replied with the name of an offline device, then z/OS brings this device online, if possible, and sends the current job back through the allocation process.
   • If you replied WAIT, then z/OS makes the job wait for a wait-eligible device to become available. z/OS also issues message IEF433D, described in Step 4.
   • If you replied CANCEL or entered the name of an offline device, then z/OS allocation and SWAP processing resumes and Step 4 is omitted. The job releases the device group locks.
4. z/OS issues message IEF433D whenever you reply WAIT to the z/OS IEF238D message. The IEF433D message tells you that z/OS needs additional information on what to do about other resources this job is holding.

   z/OS processes your reply to the IEF433D message as follows:

   • If you reply HOLD, then z/OS keeps the device group locks this job is holding. As a result, other jobs that need these device groups must wait until the current job allocates a device.
   • If you reply NOHOLD, then z/OS releases the device group locks this job is holding. This lets other jobs use the device groups while the current job is waiting for a device.