This is part of a series of small blog posts which will cover some of the smaller, perhaps less likely to be noticed, features of IBM MQ. Read other posts in this series.

This is the original post that gave me the idea for the series. It was hosted in the AIM Support Blog, which is on the developerWorks Connections platform, which is sunset as of 31st December 2019, so to ensure I don't lose it, I have recreated it here, with the series it inspired.

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

   CHSTATUS(MQ23.TO.MQ24)  XMITQ(TO.MQ24)
   CONNAME(127.0.0.1)      CURRENT
   CHLTYPE(SDR)            STATUS(RUNNING)
   SUBSTATE(MQGET)         RQMNAME(MQ24)

Receiver Channel Status

   CHSTATUS(MQ23.TO.MQ24) 
   CONNAME(127.0.0.1)      CURRENT
   CHLTYPE(RCVR)           STATUS(RUNNING)
   SUBSTATE(RECEIVE)       RQMNAME(MQ23)

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.

Slow channels

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.

Hung channels

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:

• Connecting to the network
  When there are problems reaching the host, perhaps because the IP address is not longer in service, this can take a very noticeable number of seconds to timeout and return an error. Until it does, the channel will show SUBSTATE(NETCONNECT).
• Making a DNS request
  If the local DNS doesn't know how to resolve your CONNAME, it may be able to ask other related DNS (if your system is configured this way). This can all take considerable time. While this is happening, the channel will show SUBSTATE(NAMESERVER).
• SSL/TLS Handshake
  When using SSL or TLS, by specifying a cipher spec on a channel definition in the SSLCIPH field, this means that the channel must complete an SSL handshake before any other data can flow across the channel. While this is happening, the channel will show SUBSTATE(SSLHANDSHAKE).
• In an exit
  There are various different exits than can be used on a channel. While the exit is processing, the channel will show a sub state reflecting which exit it is in, for example, SUBSTATE(SENDEXIT). If the exit is taking a long time then you may see this for more than a fleeting moment.

A summary of all the sub states and when they can be seen can be found in IBM MQ Knowledge Center Channel status section.