“I do not understand these get counts on z/OS”

I had a question from someone who was trying to use the MQ SMF statistics to understand their queue manager usage. This came from a post from Lynn Elkins who was talking about “Data ManagerGets”. I started writing a short answer… but the answer got longer, so I thought I would post on this topic.

The z/OS queue manager has different components, for example the logging component which manages recovery data, the buffer manager which manages pages in the buffer pool, the message manager which handles the API side of MQ requests, and the data manager which manages who messages are mapped to pages in a page set.

There is an SMF statistic QMSTGET which is the number of application MQGET requests, and QISTMGET, the number of requests to data manager to start getting a messages.

I’ll give some examples and explain why there could be a big difference in the numbers.

Shared queue

Simple MQGET of shared queue

An application issues an MQGET, there is a message on the queue but this is a shared queue, so data manager is not involved

QMSTGET is now +1, QISTMGET is unchanged

Local queue

Simple MQGET of local queue

An application issues an MQGET, there is a message on the queue the messsage is returned.

QMSTGET is now +1, QISTMGET is +1GET.

Get with wait when there was no message on the queue

The application issues an MQGET, so increment QMSTGET. The queue is empty, so do not change QISTMGET. Control is returned to the adapter and the application waits. A message arrives, the application is woken up, and reissues the MQGET. The message is returned.

Increment QMSTGET again, increment QISTMGET.
QMSTGET is now +2, QISTMGET is +1

The getting application polls the queue

Rather than use MQGET with wait, the application issues MQGET with no wait. There is a code

Loop forever:
MQGET; if message available then leave loop
else wait for 1 second
end

After 1 hour the statistics could be

QMSTGET is now + 3600, QISTMGET is unchanged.

Multiple applications waiting on a queue

• 100 applications issue MQGET with wait on a queue.
  • QMSTGET is now +100, and all applications are waiting in the adapter.
• A message arrives one application wakes up and gets the message
  • QMSTMGET is now +101, QISTGET is now +1
• The woken application reissues the MQGET
  • QMSTGET is now +102, QISTGET is now +1, and all applications are waiting in the adapter.

An application gets a message by message-id or correl-id

If the queue has not been indexed there is internal logic which searches along the queue for a message with matching message-id or correl-did. For example if there were 1000 messages on the queue, and the message was not found:

QMSTGET is now + 1, QISTMGET is now +1000.

An application gets a message by filter or message property

For example get the next message where the property color=”red”. This is like the previous case. The queue has to be searched looking for the specified property in the message header.

For example if there were 1000 messages on the queue, and the message was not found:

QMSTGET is now + 1, QISTMGET is now +1000.

Should you compare QMSTGET and QISTMGET?

If you gave me the two values, it would be very hard to draw any conclusions from it. Where it might be useful is comparing the difference over time. It delta or ratio changes, then it is likely that something has changed in your system, and could be a hint to go sniffing around.

Of course the delta or difference is likely to change with time of day, and day of week, so make sure you compare a similar time period.