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.

When writing a transactional IBM MQ application many of you will be familiar with the use of the MQPMO_SYNCPOINT option on MQPUT or MQPUT1 and the MQGMO_SYNCPOINT and MQGMO_SYNCPOINT_IF_PERSISTENT options on MQGET. These options indicate to the queue manager that you want this message dealt with transactionally and then the use of the MQCMIT or MQBACK verbs later in the application tell the queue manager to commit or rollback the transaction and thus those messages.

What I want to write about today is how to create portable IBM MQ applications. What you may not realise is that if you omit to use any of the MQ*SYNCPOINT* options, there is a default decision taken on your behalf by the queue manager your application connected to. This means that the behaviour of the application could change just simply by pointing it at a different queue manager.

The default decision that a queue manager on a Distributed platform will choose if you omit to use any SYNCPOINT option is MQ*_NO_SYNCPOINT.

The default decision that a queue manager on the z/OS platform will choose if you omit to use any SYNCPOINT option is MQ*_SYNCPOINT.

The problem that arises from these differences is that when taking an application that doesn't require syncpoint and so did not specify any of the SYNCPOINT options and connecting it to a z/OS queue manager is that the messages involved in the application will be held in an open transaction until the application ends. This can make it look like the application has hung, and certainly is not operating correctly. The problem can be diagnosed with the use of the UNCOM status attribute that I wrote about in a previous post.

It's easy to forget to do, and unfortunately even some of the supplied samples that come with the IBM MQ product forget about it, for example CSQ4BCK1, CSQ4BCM1 and CSQ4BCS2 on the IBM MQ for z/OS product. The last of which is particularly heinous since it reads input from STDIN and thus can be run interactively and left sitting with an open transaction until the user chooses to close it. I've raised an RFE to get it fixed but please be aware of these if you use them as a base to copy from to get going with your own applications.

This problem can be very easily resolved. Even if you believe your application will never connect to a z/OS queue manager, code your application to always use one of these options on an MQPUT or MQPUT1 call.

• MQPMO_SYNCPOINT
• MQPMO_NO_SYNCPOINT

And one of these options on an MQGET call.

• MQGMO_SYNCPOINT
• MQGMO_SYNCPOINT_IF_PERSISTENT
• MQGMO_NO_SYNCPOINT

That way you won't give a future user of your application that sinking feeling.