Flashes of insight into the MQ SMF data

To misquote Raymond Smullyan’s quote in What Is the Name of This Book?

  • If Professor A says it is obvious then a child of 10 can instantly see it
  • If Professor B says it is obvious then if you spend 10 minutes on it you will see it
  • If Professor C says it is obvious then you might spend the rest of your life and not see it
  • If Professor D says it is obvious – then it is false

I hope the “one liners” below are obvious if you spend 10 minutes on it

I was sent a report of key fields (Opened queue name, number of Mopens, MQgets, MQPUTS etc) and a list of questions

Why do I have records for queues which are not on my queue manager?

If the application put a message to a reply to queue then typically the MQOPEN uses the the remote queue name and remote queue manager name.  This maps to another queue, such as the SYSTEM.CLUSTER.XMIT.QUEUE, or a remote queue name.

The name in the OPENNAME in the SMF record will be the remote queue name.  If you look at the BASENAME as well, you will see the real queue it uses.  So the queue in the OPENNAME may not exist on the system – but the BASENAME will exist.

I have puts but no gets for a queue

  1. This could be caused by using a shared queue.  Messages were put on one queue manager and got from another queue manager in the QSG.   The SMF data from the other QMGR should have the gets.
  2. The IMS bridge got the messages and sent them to IMS over the OTMA interface.  This code does not record any SMF data.

This applies to gets but no puts.

I have 1 SMF record for this queue, but 1000 records for that queue

  • If you have a long running task then the SMF data is produced at a regular time – typically half an hour.  This will produce one record.  If you break out the data into a set of queue records you will have few records (typically more than 1 – one for the putting task (channel), and one for the getting server task
  • If you have short lived transactions such as CICS, or IMS MPP transactions then you will get an SMF record when the transaction ends.  If you break out the data into a set of queue records you will have many records one for each transaction, and  one for each the putting/getting task (channel)