MQ

This is part of an occasional series of small blog posts where I (Morag) will write about some of the quirks in IBM MQ, in the hope of invoking the response, "Well, I didn't know that!" Read other posts in this series.

The MQPUT API call has a parameter for you to pass in the MQMD structure. In this structure you can describe your message, its format, persistence and so on. In fact the MQMD structure also has some output fields, for example the Message ID and Correlation ID, and the Put Date and Put Time.

In this post we are going to specifically look at the Message ID. Every message has a Message ID. If you do not create one yourself on input to the MQPUT call, the queue manager will generate one for you, and that generated one is guaranteed ^[1] to be unique. It is a very good practice for all the messages in your system to be uniquely identifiable, and therefore it is best practice to let the queue manager generate it for you.

When you use the MQPUT API call to put a message to a queue, the MQMD is filled in on output with the Message ID that was generated and assigned to this message. This can be useful for request/reply patterns so that when the reply comes back, you can correlate it with the original request message. The report option MQRO_COPY_MSG_ID_TO_CORREL_ID (which is the default action) ensures that the Correlation ID of a reply message contains the original Message ID.

When you use the MQPUT API call to publish a message to a topic, zero or more copies of that message are created and sent to the interested subscribers. Each copy is a new message and has a generated Message ID to ensure all the messages are unique. What is returned in the MQMD to the publishing application on output cannot be all of the Message IDs for the copies because there isn't room. Also, sometimes there might be no copies made (if there are no interested subscribers). So, if the application asks for a MQPMO_NEW_MSG_ID, then a unique ID is generated for this output field. This Message ID is however, not the Message ID of any message in the system. Otherwise, the field is all nulls on output.

Example

In a system with three subscribers to the topic "MQuirk/test":-

AMQ8096: WebSphere MQ subscription inquired.
   SUBID(414D51204D5147312020202020202020BE58A85B20FEED2B)
   SUB(SUB1)                               TOPICSTR(MQuirk/test)
   DEST(SUB.Q1)                         
AMQ8096: WebSphere MQ subscription inquired.
   SUBID(414D51204D5147312020202020202020BE58A85B20FEED31)
   SUB(SUB2)                               TOPICSTR(MQuirk/test)
   DEST(SUB.Q2)                         
AMQ8096: WebSphere MQ subscription inquired.
   SUBID(414D51204D5147312020202020202020BE58A85B20FEED38)
   SUB(SUB3)                               TOPICSTR(MQuirk/test)
   DEST(SUB.Q3)                         

I use our API Exerciser to publish a message using MQOPEN of the topic string "MQuirk/test", and then MQPUT. The screen shot below shows that the Message ID returned on completion of the MQPUT in the MQMD structure is 414D51204D5147312020202020202020BE58A85B20FF6E09.

and then I browse the three subscription queues to see what Message ID each of them has received.

  MsgId : X'414D51204D5147312020202020202020BE58A85B20FF6E0A'
  MsgId : X'414D51204D5147312020202020202020BE58A85B20FF6E0B'
  MsgId : X'414D51204D5147312020202020202020BE58A85B20FF6E0C'

As you can see, the Message ID returned to the publisher, is not the same as any of the Message IDs sent to the subscribers.

Why does this matter?

If you're using a request/reply model, or report options, and your application saves away the Message ID so that it can correlate the reply messages or report messages with the original request, then if you convert your application to use topics instead of queues, you no longer have access to the original Message ID.

Request For Enhancement

There is an open RFE on this very subject. If you are interested in shaping the way IBM MQ works, please have a read of that RFE and consider whether you think it is important and cast your vote.

Footnote:

^[1] Its uniqueness is guaranteed so long as your queue managers are uniquely named within the first 12 characters of their name (see footnote on Fields for MQMD > MsgId (MQBYTE24))

#mquirks
#IBMMQ
#gwc
#ChampionsCorner