The monitor process can watch only for predefined events. The events it looks for, in themselves, generally shouldn’t be damaging to the system. When an event occurs, an alert should be generated, so some action can be taken. That action can range from further monitoring to actively making changes to the system.
The alert must be sufficiently timely and directed to the proper resource so the appropriate response can be made before the initiating event results in damage to the system. Checking the depth of a queue every 10 minutes isn’t satisfactory when a process can fill the queue to its maximum-defined depth in less than a minute. In addition, the monitor itself should be reliable, possibly self-checking or redundant, or a monitor for the monitor may be necessary.
What Objects Are at Risk?
The WMQ objects at risk are the Master and Channel Initiator address spaces, queues, channels, pagesets, logs, and buffer pools. Each has its own failure scenario. For Queue Managers and Channel Initiators:
- The jobs could fail to start or start in the wrong order.
- The TCP/IP listener could fail.
- Object definitions could be incorrect, leading to define command failures.
- The CICS and IMS adapters and the Open Transaction Manager Access (OTMA) connector, a client/server protocol used to connect WMQ as an IMS client, could fail to start or connect to the Queue Manager.
- Local queues could reach maximum defined message depth and overflow to the dead-letter queue, which itself could reach maximum depth and cause channels to stop.
- Messages could accumulate on transmit queues due to channel stoppage.