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.
As users of IBM MQ get going with JMS programs or with Publish/Subscribe, we see questions on the various fora asking about MQRFH2 headers. When messages are annotated with meta-data using Message Properties, any application that doesn't ask for the message properties in a message handle, is instead given that meta-data in an MQRFH2 header. This can cause many applications to stop working because they don't know how to handle an MQRFH2 header.
IBM MQ comes with controls to remove these properties for applications that can't cope with either message properties/message handles or MQRFH2 headers.
Controls on a queue
For applications reading messages from a queue, you can control whether those applications receive message property data or not using the PROPCTL attribute.
ALTER QLOCAL(MY.WORK.QUEUE) PROPCTL(NONE)
Making this change to your queue means that applications which do not explicitly request message properties are not going to see an MQRFH2. Applications that can handle message properties and are using a message handle will still be given the meta-data and applications that explicitly request MQGMO_PROPERTIES_FORCE_MQRFH2 will still be given all the meta-data in an MQRFH2 header.
Compare this control to the JMS setting targetClient=MQ. This setting also strips the meta-data properties off the message, but the removal takes place before the message is even put on the queue, so there is no way for an application that can cope with them to get hold of that meta-data because it was never on the queue.
Controls on a subscription
In a very similar way to the above control on a queue which can remove the meta-data in message properties or an MQRFH2 being given to an application that cannot handle them, there is also a control when you create a subscription to indicate that the meta-data added to the message by the queue manager's publish engine should not be added to messages for this subscription. There are several properties that are added at publish time, such as MQTopicString and MQIsRetained (the full list is in Knowledge Center) and these can trip up an application that isn't expecting them. This is especially a concern when the subscription has been made administratively to allow a non-Pub/Sub aware application to consume messages that have been published. You can control the appearance of these message properties by using the PSPROP attribute on the subscription.
DEFINE SUB(MY.WORK.SUB) DEST(MY.WORK.QUEUE) TOPICIBJ(WORK.ITEMS) PSPROP(NONE)
Unlike the above control on the queue, this control removes the meta-data before it is placed on the subscription queue and so, like targetClient=MQ, you cannot choose to read it later. Generally, a subscription queue and a subscription are a 1-1 pairing, so this shouldn't be a problem, but if it is, you should use the queue attribute instead.
Controls on a channel
The other IBM MQ configuration that can affect how meta-data is consumed by applications is on channel objects. This is more likely to be used are as migration control. For example, if you have a back-level queue manager, and you simply don't want any properties coming across from a newer level queue manager that has started making more use of them.
ALTER CHANNEL(TO.QM1) CHLTYPE(SDR) PROPCTL(NONE)
Other values for these attributes
In the above sections you've seen an example of each control using the value NONE. There are in fact other values for these attributes as well which are shown below.
||No properties unless explicitly asked for by application
||No properties are added to the message
||No properties are sent to the remote queue manager
||All properties given to application
||All properties are sent to the remote queue manager
||Only JMS properties unless explicitly asked for by application
||All properties are returned to the application in an MQRFH1 header
||Only JMS properties are sent to the remote queue manager
||Avoid the queue manager making an changes to an MQRFH2 that you have deliberately constructed.
||Properties as MQRFH2 header unless message handle explicitly used by application
||All properties are returned to the application in an MQRFH2 header
||All properties are returned
The default settings attempt to ensure that if you have JMS properties in your messages, they continue to be available to other JMS applications, and to any non-JMS application who must have been coping with them in earlier releases anyway. Any properties that don't appear to be a JMS property are not returned to applications when using the COMPAT setting.
So remember, if you see some MQRFH2 header that you're not expecting, one of the above attributes will be of use to you.
Morag Hughson is an MQ expert. She spent 18 years in the MQ Devt organisation before taking on her current job writing MQ Technical education courses with MQGem
. She also blogs for MQGem
. You can connect with her here on IMWUC or on Twitter