MQ

 View Only

IBM MQ Little Gem #15: PROPCTL

By Morag Hughson posted Sun August 21, 2016 11:23 PM

  
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.

Message MetadataAs 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.

  Queue PROPCTL Subscription PSPROP Channel PROPCTL
NONE 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 All properties given to application   All properties are sent to the remote queue manager
COMPAT 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
V6COMPACT Avoid the queue manager making an changes to an MQRFH2 that you have deliberately constructed.    
FORCE Properties as MQRFH2 header unless message handle explicitly used by application    
RFH2   All properties are returned to the application in an MQRFH2 header  
MSGPROP   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 and LinkedIn.

#Little-Gem
#IBMMQ
#ChampionsCorner
7 comments
63 views

Permalink

Comments

Fri February 09, 2024 04:47 PM

Hi Morag, 

I am facing an issue with reading the RFH2 header in the message.  Message is posted correctly on the MQ with RFH2 header and folder details. The first 4 characters in retrieved message, should be equal to "RFH"(MQRFH_STRUC_ID) but I am getting a different string. The same solution works fine in a different environment. Is there a property for RFH2 to be set while installing/configuring MQs. 

Fri July 20, 2018 07:00 PM

Thank you, Morag.

Thu July 19, 2018 09:17 AM

I don't know of a way to get MQ to add an RFH2 header if no content (message properties) exist to convert into one. You could of course use an API exit, but that's just doing the same job as the message flow you've already got.

Thu July 19, 2018 07:58 AM

Morag,
What if the sending app is not setting and properties? 
The sender is non JMS, doesn't care about Properties or RFH headers.
The Receiver is JMS, and says they must have an RFH header.
Neither are will to accommodate the other.

Today we route thru IBM Integration Bus to add the header one way, strip it on the way back.

I want to see if MQ settings can replace that detour thru the IIB Message Flow. I understand how to strip the header with the info in the blog post. Now I am wondering if there is a way to add a header with MQ settings. A legitimate question would be what values could/should/would be added into this RFH header if its possible.

Peter

Thu July 19, 2018 07:58 AM

Morag,
What if the sending app is not setting and properties? 
The sender is non JMS, doesn't care about Properties or RFH headers.
The Receiver is JMS, and says they must have an RFH header.
Neither are will to accommodate the other.

Today we route thru IBM Integration Bus to add the header one way, strip it on the way back.

I want to see if MQ settings can replace that detour thru the IIB Message Flow. I understand how to strip the header with the info in the blog post. Now I am wondering if there is a way to add a header with MQ settings. A legitimate question would be what values could/should/would be added into this RFH header if its possible.

Peter

Wed July 18, 2018 06:05 AM

Hi Peter,

If the message has message properties in it, you can force them to be flattened into an RFH2 by the use of PROPCTL(FORCE) on the queue.

Cheers,
Morag

Tue July 17, 2018 01:30 PM

Morag,
If the sending application is non-JMS, and the receiving application is JMS and expects an RFH header, is there a similar trick to make MQ create one?

-Peter