Channel Sub Status
Morag Hughson 110000EQPN Comments (2) Visits (10134)
My favorite part of channel status is a field showing the sub status for a channel - SUBSTATE. It is just one little field and yet it can convey so much information about what the channel is doing. It was originally introduced in WebSphere MQ V6 to address the ever present question, "My channel is stuck in BINDING state - what is it doing?", however it is useful for other problems too.
Well behaved channels
When a queue manager to queue manager channel is running, but not currently moving any messages, the SUBSTATE fields can show you what I call the "resting state" of a channel. The resting state of a sender (SDR) channel is to be sitting in a MQGET with wait, on the transmission queue. The resting state of a receiver (RCVR) channel is to be sitting in a network receive awaiting data (either message data or a heartbeat flow) from the sender channel.
Sender Channel Status
Receiver Channel Status
So, if you see the channel in this state, it does not believe it has any messages to send. As an aside, this can be a useful check to make at the same time as checking for uncommitted messages on the transmission queue when a user suggests that the channel is not moving the messages he just MQPUT.
It is worth noting at this point that the resting state of a server-connection channel is similar to a receiver channel as it spends its time sitting in a network receive waiting for the client to send it an API call to issue.
The sub status of channels is also useful when other evidence suggests that your channel is running really slowly. Having described above the resting state of channels, if you see the sender, rather than the receiver channel, is sitting in a network receive, this can indicate that the line turn arounds on the network are slow, since the sender channel is waiting on the receiver to process all the messages that have been sent in the batch and then respond to the End of Batch (EoB in the diagram below) notification to say the batch has been successfully completed.
This state will happen at the end of every batch, but it will usually be so fleeting, that you'd be unlikely to see it. If you see it for a prolonged period of time it can be indicative of major network issues, such as router problems, retransmission of dropped packets, or other issues that cause the network to run slow; or alternatively something else that causes the receiving end to slow down, such as message retry or issues in a exit. At this point looking at how the receiver channel is doing is the next step.
Of course, the original reason that sub status was added - hung channels - is also a very useful time to look at the field. When a channel is hung, either stuck in BINDING state for a long time, or even hung in RUNNING state where fields such as Number of Bytes Sent (NUMBYTES) is not increasing, then sub status can help.
When a channel, whether a queue manager channel or a server-connection channel, is starting up there are a number of different operations that it has to do before it can be considered to be RUNNING. All these different operations happen while the channel is in BINDING state. To help break that down into a more granular view of what the channel is doing, there are sub status values for all these major operations, some of the more common ones you'll see are listed below:
A summary of all the sub states and when they can be seen can be found in the WebSphere MQ information center Channel status section.