Previous Topic: Recovering the Local VCATNext Topic: Preserving External Logger Data


Volume Contention

The operating system tries to serialize the use of tape volumes during allocation. You can control the way the operating system reacts to volume contention by customizing the VOLUME_ENQ attribute of SYS1.PARMLIB(ALLOCxx). The possible settings are CANCEL, WAIT, and WTOR. CA recommends specifying WAIT or WTOR and does not recommend specifying CANCEL.

Note: For a complete explanation of the VOLUME_ENQ attribute, see IBM's z/OS MVS Initialization and Tuning Reference manual. VOLUME_ENQ behavior can be overridden by the Volume ENQ Installation Exit (IEF_VOLUME_ENQ), as discussed in IBM's z/OS MVS Installation Exits manual.

CA Vtape can be configured to allow CA Disk data sets written to Virtual Volumes to be read by multiple CA Disk jobs. This feature is not supported on a JES3 system. This means a CA Disk Virtual Volume can be mounted for READ on multiple Virtual Devices at the same time.

CA Vtape interacts with the operating system to minimize the amount of time a CA Disk Virtual Volume is unavailable. Most tapes are unavailable until dismounted. A CA Disk Virtual Volume is only unavailable for the time needed to complete the allocation. This means volume contention is less likely to occur except when jobs are submitted at the same time. If message IEF235D does appear, it should only last a few seconds before the jobs proceed on without operator intervention. CA Disk auto-restores (DMSAR) provide their own serialization and message IEF235D will not occur.

Note: For more information, see the section Concurrent Read Access to Virtual Volumes Created by CA Disk.