Diagnosing a gap on the delayed issue queue

You may find a situation where there is a gap in the branch entry messages on the delayed issue queue. This gap occurs when the system was unable to find space to queue branch entry messages for delayed issue. When this happens, the system issues two messages with the following information:

At the time the error occurs, the system queues a delayed issue message indicating that some messages might be lost.
When the situation is normal again, the system issues another delayed issue message that gives the following information:
- The number of messages that could not be queued for delayed issue, and therefore were not logged.
- How many of those messages were action/WTORs.
- How many of those messages would have been displayed on the delayed issue, and therefore were never displayed.
- How many of those messages were action/WTORs.
Both messages appear in the hardcopy log only.

Note: Because the delayed message buffer can be expanded dynamically, the system will rarely run out of space to queue messages for delayed issue. But when the system does run out of space, the following conditions could cause it:

Callers have issued branch-entry WTO/R/DOM repeatedly, and they have been in a condition which prevents expansion of the buffer (cannot do branch-entry GETMAIN). Additionally, COMMTASK has not been dispatched to issue and free the messages from the buffer.
Callers have issued branch-entry WTO/R/DOM repeatedly, and COMMTASK has not been dispatched. The buffer has been expanded to the limits of the extended system queue area (ESQA).
Callers have issued branch-entry WTO/R/DOM repeatedly, and the delayed message task (a subtask of COMMTASK) has become permanently inactive as a result of recursive abends. The buffer has been expanded to the limits of ESQA.