MQ

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.

As I've written about before, a common question that is raised on MQ fora is about applications complaining that they are not able to get messages from a queue. I wrote about one tool in your toolbox to help with this problem in a previous post.

Questions of that nature usually get the same reminders, has the application cleared out the MessageId between MQGET calls; are the messages committed; have they expired and so on. One piece of advice that is less regularly provided, but can sometimes be the problem is, "has the application actually done the MQGET?"

It probably isn't often offered as advice because it's the equivalent of asking "is it switched on" when someone says, "my computer isn't working". However, it can sometimes be the problem, and without trace from the application itself, it can be hard to determine. Application Activity Trace could be used here for example.

There is however, one tool in your IBM MQ Administration toolbox that you can use to check this more easily than capturing and analysing application trace.

Below are two example outputs from the command, DISPLAY QSTATUS(Q1) TYPE(HANDLE). There are two applications making use of the queue. One of them has the queue open for input (the sample amqsget) and the other has the queue open for output (the sample amqsput).

AMQ8450: Display queue status details.
   QUEUE(Q1)                               TYPE(HANDLE)
   APPLTAG(amqsget)                        BROWSE(NO)
   HSTATE(ACTIVE)                          INPUT(SHARED) 
   INQUIRE(NO)                             OUTPUT(NO)
   SET(NO)                              
AMQ8450: Display queue status details.
   QUEUE(Q1)                               TYPE(HANDLE)
   APPLTAG(amqsput)                        BROWSE(NO)
   HSTATE(INACTIVE)                        INPUT(NO)
   INQUIRE(NO)                             OUTPUT(YES) 
   SET(NO)                              

Looking more closely at the example of the getting application, there is an attribute called HSTATE which is ACTIVE in the case of the getting example. This attribute shows whether the handle is active in the queue manager, in other words is the application currently sitting in an MQGET with wait.

AMQ8450: Display queue status details.
   QUEUE(Q1)                               TYPE(HANDLE)
   APPLTAG(amqsget)                        BROWSE(NO)
   HSTATE(ACTIVE)                          INPUT(SHARED) 
   INQUIRE(NO)                             OUTPUT(NO)
   SET(NO)                              

IBM Knowledge Center has the following to say about this attribute.

HSTATE

Whether an API call is in progress.

Possible values are:

ACTIVE

An API call from a connection is currently in progress for this object. For a queue, this condition can arise when an MQGET WAIT call is in progress.

If there is an MQGET SIGNAL outstanding, then this value does not mean, by itself, that the handle is active.

INACTIVE

No API call from a connection is currently in progress for this object. For a queue, this condition can arise when no MQGET WAIT call is in progress.

It only applies to MQGET with wait because other API calls would be so quick that you would never be able to see them before they were complete.

So, if your application says it is sitting in an MQGET with wait and no messages are being delivered to it, you can now double check that it truly is in an MQGET with wait, before delving into other more time consuming diagnosis.