従来、①、②のようなデータセットは、同一ジョブの後続ステップにて再使用することを意図するため、それらを含むテープ・ボリュームは、ステップ終了処理（ステップ・アンアロケーション）でもUNLOADされず、ジョブ・ステップを跨ってマウント状態を維持しようとします。
①DISP処理に従い「PASS」されたデータセット ・・・ DISP=(XXX,PASS)
➁アロケーション時のVOLUMEパラメータで「RETAIN」オプションを指定したデータセット ・・・ VOLUME=(,RETAIN)
また、テープ・データセット①、②が後続ステップにて再使用されない状況が発生すると、最終ステップ終了時点でもボリュームがマウント状態となる可能性があり、その場合はジョブ終了処理（ジョブ・アンアロケーション）にてテープ・ボリュームがUNLOADされます。
※最終ステップの終了処理（ステップ・アンアロケーション）後に、ジョブ終了処理（ジョブ・アンアロケーション）が行われます
※通常、あるテープ・データセットを使用する最後のジョブ・ステップ（DDステートメント）では、①PASS、②RETAINパラメータ指定を行わず、ステップ終了処理（ステップ・アンアロケーション）にてテープ・ボリュームをUNLOADします
【z/OS V2R3までの課題】
■通常のステップ終了処理ではなく、前述のようなジョブ終了処理にてテープ・ボリュームがUNLOADされる場合、z/OS V2R3以前では、そのUNLOAD処理が完了するまで（IEF234Eメッセージ）、次のような事象発生が知られています。
（事象①）同一システム内でテープ・データセットを使用するジョブ・ステップ（別ジョブ）が開始できない（UNLOAD処理中の資源とは無関係）
（事象②）シスプレックス（テープ装置を共用するATS環境）の他メンバーで稼働するジョブ・ステップが対象資源を必要とする場合、IEF474Iメッセージ出力を伴いジョブが失敗する（IEF453I JOB FAILED - JCL ERROR）
IEF474I jobname stepname ddname - UNIT OR VOLUME IN USE BY SYSTEM FUNCTION - CANNOT BE ALLOCATED
IEF272I jobname stepname - STEP WAS NOT EXECUTED.
■特に（事象②）が発生した場合、ジョブの再実行（リラン）を必要とするため、それを回避するための機能改善が要望されていました。
【z/OS V2R4の変更点】
■z/OS V2R4では、スループット向上を目指した機能改善に伴い、ジョブ終了処理におけるテープ・ボリュームのUNLOADと、同一システム内でテープ・データセットを使用するジョブ・ステップ（別ジョブ）の開始がオーバラップ可能になりました。
※先行ジョブでのUNLOAD完了（IEF234Eメッセージ）を待たずとも、テープ・データセットを使用するジョブ・ステップ（別ジョブ）が開始可能
■ジョブ終了処理にてテープ・ボリュームがUNLOAD中に、シスプレックス（テープ装置を共用するATS環境）の他メンバーで稼働するジョブ・ステップが対象資源を必要とする場合、リカバリー・アロケーション（IEF238D WTORメッセージ出力）を通じて、特定ボリュームまたは装置を待機することが可能になりました。
※ジョブの再実行（リラン）が回避可能
【考慮事項】
■z/OS V2R4以降では、先行ジョブの終了処理にてテープ・ボリュームのUNLOAD中に、それと同一のテープ・ボリュームを必要とするジョブ・ステップ（別ジョブ）が開始した場合、リカバリー・アロケーション（IEF238D WTORメッセージ）が発生し、オペレータの応答が求められます。
IEF238D jobname - REPLY 'WAIT' OR 'CANCEL'.
※z/OS V2R3までは、先行ジョブ終了時のUNLOAD処理中、同一システム内でテープ・データセットを使用するジョブ・ステップ（別ジョブ）が開始できないため、同一事象は発生せず
■IEF238D WTORメッセージへの応答遅延は、アロケーション機能の観点では好ましくないため、z/OS V1R10以降、省略時解釈として90秒ごとに高輝度（赤色）のリマインダー・メッセージIEF882E（宛先コード： 1）が出力されます。
IEF882E jobname stepname IS WAITING FOR A REPLY TO IEF238D
※z/OS V1R11以降、PARMLIB(ALLOCxx)メンバーの「SYSTEM REMIND_INTV」ステートメントにて、リマインダー・メッセージの出力頻度をカスタマイズ可能（10秒～999秒、0指定はメッセージ出力せず）
【挙動変化の発生事例】
■z/OS V2R3からV2R5へ移行時、IEF238Dリカバリー・アロケーションの発生例（同一システムで稼働するJOB1/JOB2）
（移行前）※z/OS V2R3
・投入済みの後続ジョブ（JOB2）は、先行ジョブ（JOB1）終了時のUNLOAD処理が完了（IEF234E）するまで、ジョブ・ステップを開始（IEF403I）不可
・JOB2のジョブ・ステップ開始時は、必要とするテープ・ボリューム（VVVVVV）がJOB1にてUNLOAD完了しているため、問題なく処理可能
（移行後）※z/OS V2R5
・先行ジョブ（JOB1）終了時のUNLOAD処理が完了する前に、テープ・データセットを使用する後続ジョブ・ステップ（JOB2）が開始
・UNLOAD最中のテープ・ボリューム（VVVVVV）に含まれるデータセット（DSNAME）をJOB2から要求したため、リカバリー・アロケーション発生（IEF238D）
【対応策】
■z/OS V2R4以降、前述のようなシナリオで新たに発生するリカバリー・アロケーション（IEF238D WTORメッセージ）を回避するには、次のような対応方法が考えられます。
＜方法①＞ 先行ジョブ（JOB1）における不要な①PASS、②RETAINパラメータ指定を削除する
※これらのパラメータは、同一ジョブの後続ステップで対象テープ・データセットが再使用される場合を想定
＜方法②＞ 後続ジョブ（JOB2）の稼働タイミングを遅らせる
※先行ジョブ（JOB1）のジョブ終了処理におけるテープ・ボリュームのUNLOADと重ならなければ、後続ジョブ（JOB2）ではリカバリー・アロケーションを伴わずにテープ・データセットが使用可能
＜方法③＞ PARMLIB(ALLOCxx)メンバーの「SPEC_WAIT」ステートメントを使用して、リカバリー・アロケーションに対するポリシー定義（WAITNOH）を行う
※「SPEC_WAIT」ステートメントでは、アロケーション要求時に特定ボリュームまたは装置を待機する必要がある場合のアクションを指定（省略時値： WTOR）・・・ IEF238D WTORメッセージ出力
（指定例） SPEC_WAIT POLICY(WAITNOH) MAXNWAIT(2) POLICYNW(WTOR)
■＜方法③＞に関する補足情報
※POLICY(WAITNOH) ・・・ IEF238D WTORメッセージに対して「WAIT」、その後のIEF433D WTORメッセージに対して「NOHOLD」を応答したかのように自動的に振る舞う
IEF238D jobname - REPLY 'WAIT' OR 'CANCEL'
IEF433D jobname - WAIT REQUESTED -- REPLY 'HOLD' OR 'NOHOLD'
※IEF238D WTORメッセージの代わりに、IEF289Eメッセージ出力 ・・・ POLICY(WTOR)の場合は、IEF238D WTORメッセージに対して「WAIT」を応答した時点で、IEF289Eメッセージ出力
IEF289E jobname stepname WAITING FOR VOLUME(S) OR UNIT(S)
※MAXNWAIT(2) ・・・ リカバリー・アロケーション発生時、POLICY(WAITNOH)に沿ったアクションを2回まで行う
アロケーション処理の再試行が成功せず、3回目のリカバリー・アロケーションが発生した場合は、POLICYNW(WTOR)オプション指定に従い、IEF238D WTORメッセージ出力
以上