IEF289E CA XCOM WAITING FOR VOLUME(S) OR UNIT(S) & All Transfers Hanging in Active State
Article ID: 39003
Updated On:
Products
Issue/Introduction
All XCOM transfers were hung in Active state. XCOM processed and scheduled new transfers, but none of them completed.
System logs showed these errors:
IEF289E XCOM41 XCOM41 WAITING FOR VOLUME(S) OR UNIT(S)............=SYSTEM SYSZTIOT c >SYSNAME JOBNAME ASID TCBADDR EXC/SHR STATUSSYSW XCOM16 0283 008C8358 EXCLUSIVE OWNSYSW XCOM16 0283 008C81A8 SHARE WAIT
A dump showed:
Contention on SYSZTIOT. The TCB holding the enqueue is processing dynamic allocation (SVC99).
Cancelling and restarting XCOM resolved the problem, but the problem recurred.
Environment
Release: CA XCOM Data Transport for z/OS
Component: XCMVS
VTS
Cause
Tape devices had been taken offline for maintenance. No tape units were available at all. A transfers requesting access to a tape dataset requested dynamic allocation of new tape files when no tape units were available. This resulted in a hang when XCOM called for a z/OS OPEN for a virtual tape dataset.
This processing is not affected by the MAXMOUNTWAIT setting which limits the elapsed time of OPEN requests (which is where volume mount is performed)
Resolution
To prevent users submitting transfers when tape devices are being taken offline for maintenance, use the parameter TRANSFERS_ALLOWED to stop dispatching of new transfers PRIOR to taking devices offline. Please refer to Disable Inbound and Outbound Transmissions with CA XCOM Data Transport for z/OS.
Additional Information
Possible Workarounds:
- Prevent transfers with tape requests from being submitted when no tape units are available. (see Resolution below)
- To restore function, IBM recommended CANCELing the task trying to do the OPEN – or as a worst case, the XCOM address space. There is no wayXCOM can cancelitself, so there must be an external intervention.
- You may use a scheduler such as OPS/MVS to automatically cancel XCOM if these messages appear.
Feedback
