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 STATUS
SYSW XCOM16 0283 008C8358 EXCLUSIVE OWN
SYSW 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.
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)
1. Prevent transfers with tape requests from being submitted when no tape units are available. (see Resolution below)
2. 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 way XCOM can cancel itself, so there must be an external intervention.
3. You may use a scheduler such as OPS/MVS to automatically cancel XCOM if these messages appear.
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 TEC1751816 Disable Inbound and Outbound Transmissions with CA XCOM Data Transport for z/OS.