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.

I learned something new the other day, and thought I would share it with you in case any of you weren't aware of it either. It certainly comes into the category of small MQ features that you may not have noticed!

MQ has a command DISPLAY CONN which allows you to see information about an application connection, including various fields about the Unit of Work that connection may have created. One of the reasons this command was created was to enable an administrator of a queue manager to discover which application(s) has a long running Unit of Work.

So what command should I issue to discover the applications that might be responsible for long-running Units of Work? You might imagine, as I did, that one of the following might do it.

DISPLAY CONN(*) ALL WHERE(UOWSTATE EQ ACTIVE)

DISPLAY CONN(*) ALL WHERE(UOWSTDA NE ' ')

DISPLAY CONN(*) ALL WHERE(UOWSTTI NE ' ')

DISPLAY CONN(*) ALL WHERE(QMURID NE ' ')

These however will also show up applications (on the distributed platform queue managers) that have made an MQGET call that may result in a Unit of Work being started, even if it didn't actually start a Unit of Work. For example, an MQGET call that used the MQGMO_SYNCPOINT option (or even the MQGMO_SYNCPOINT_IF_PERSISTENT option) but didn't receive any message and completed with a return code of MQRC_NO_MSG_AVAILABLE, will still show up in the above commands. It may have made that call minutes, hours or days ago, but it doesn't have a long-running Unit of Work open.

Instead, what you need to look for are those applications that have written to the log. One of the following commands will work.

DISPLAY CONN(*) ALL WHERE(UOWLOGDA NE ' ')

DISPLAY CONN(*) ALL WHERE(UOWLOGTI NE ' ')

Here's an example connection which made an MQGET call using MQGMO_SYNCPOINT at 14.20.10 but didn't actually process a message in that Unit of Work until 14.22.39.

AMQ8276: Display Connection details.
   CONN(80C95B5820039E01)                
   EXTCONN(414D51434D5147312020202020202020)
   TYPE(*)                               
   PID(8632)                            TID(1) 
   APPLDESC( )                          APPLTAG(D:\nttools\mqmonntp.exe)
   APPLTYPE(USER)                       ASTATE(NONE)
   CHANNEL( )                           CLIENTID( )
   CONNAME( )                           CONNOPTS(MQCNO_SHARED_BINDING)
   USERID(morag)                        UOWLOG(S0000000.LOG)
   UOWSTDA(2017-01-19)                  UOWSTTI(14.20.10)  
   UOWLOGDA(2017-01-19)                 UOWLOGTI(14.22.39) 
   URTYPE(QMGR)                         
   EXTURID(XA_FORMATID[] XA_GTRID[] XA_BQUAL[])
   QMURID(0.8194)                       UOWSTATE(ACTIVE)
   OBJNAME(Q1)                          OBJTYPE(QUEUE)
   ASTATE(NONE)                         HSTATE(INACTIVE)
   OPENOPTS(MQOO_INPUT_SHARED,MQOO_OUTPUT)
   READA(NO)                            

What I've written applies to the distributed platform queue managers, but not to z/OS. Perhaps that's why I never realised until now. On z/OS, UOWSTTI and UOWLOGTI appear to always be the same. There is no UOWSTATE(ACTIVE) until the log has been involved.

So, make sure you're not finding false positives when looking for long-running Units of Work. While the first set of commands above will work on z/OS, the second set of commands will work on all platforms.