It can happens that, during an heavy batch activity where multiple mount requests are issued at the same time by different jobs, CA TLMS issues the following WTOR:
*8939 CAT9090D CA TLMS - QUEUE FULL. REPLY 'U' TO WAIT OR 'N' TO CONTINUE
waiting for the correct reply and the batch jobs involved remain in a waiting status.
How to prevent this situation, avoiding to delay the batch activity?
Z/OS / CA-TLMS
In CA TLMS Message Guide we report the following explanation:
CA TLMS - QUEUE FULL. REPLY 'U' TO WAIT OR 'N' TO CONTINUE.
TLMSQMGR: The CA TLMS queue is full. This may be a temporary condition caused by many
transactions coming in very quickly or it may be permanent, caused by some error conditions.
Check for other messages which may indicate the reason the queue is full. Then reply U or N for the
Below some possible causes of this message:
1). VMF and ALOG are on same pack so, when the VMF is updated a reserve is done on the pack to insure the product has full control. The ALOG update does the same thing. If the pack is locked up, the queue will have to wait for the updates to the VMF and to the ALOG. This can cause the queue to backup waiting for the next cycle.
In this case there are also additional warning messages coming from Health Checker and looking like the following:
HZS0002E CHECK(CA_TLMS,TLMS_VMF_ALOG_SEPARATION): 662
TLMSH0021E The CA TLMS VMF and ALOG files should not be on the same
In this case it is necessary to move the ALOG on a different pack.
2). A TLMS CATVMFB is taking place due this time frame. If the VMF is being backed up during this time could cause some issue. So the VMF Backup should be done in a quite time before/after the batch workload activity planned during the night.
3). TLMSTRS/TLMSTRAN's running at the same time. TLMSTRS creates a transaction file that is passed to TLMSTRAN. TLMSTRAN shoots the transaction to the queue.
In all these cases a REPLY 'U' is correct after a short delay to have the batch activity progressing correctly.