After upgrading to MQ V7, MQMessage.format inside a base Java V6 application returns incorrect value of "MQSTR" instead of "MQHRF2" when getting JMS messages

Answer

Yes, you can still use the MQMessage.format method in MQ V7 for a base Java application when dealing with a queue in an MQ V7 queue manager.

There are 3 ways to resolve the problem:

a) At the queue level, you need to alter the property PROPCTL from the default COMPAT to FORCE.

In the MQ Explorer, this queue property is listed under the Extended tab, field: "Property control"

This does NOT require any changes to your existing applications.

However, all applications that get messages from the queue will be affected.

b) If you want to keep the queue with the default value of PROPCTL as COMPAT, then another option is to modify your base Java application to include the following Get option: MQGMO_PROPERTIES_FORCE_MQRFH2

An example is shown below:

MQGetMessageOptions gmo = new MQGetMessageOptions();
gmo.options = gmo.options + MQConstants.MQGMO_PROPERTIES_FORCE_MQRFH2;
queue.get(rcvMessage, gmo);

+ Java sample provided

You can browse the attached Java sample: MQSampleGet.java
This sample is a trimmed down version of the following MQ Java sample in V7 (the section for Put has been removed, to concentrate on the Get action):

Windows: C:\Program Files\IBM\WebSphere MQ\tools\wmqjava\samples\MQSample.java
Unix: /opt/mqm/samp/wmqjava/samples/MQSample.java

c) Use the new property called PropctlToFORCE_RFH2 introduced with APAR IZ47686 in 7.0.1.0.

IZ47686: CREATE AND IMPLEMENT NEW PROPERTY PROPCTLTOFORCE_RFH2

Setting the property PropctlToFORCE_RFH2 to the value "yes" ensures that the complete RFH2 header is returned to WebSphere MQ V7 JMS applications when the PROPCTL attribute of the queue being used is set to COMPAT.

The property can be set in one of two ways. Either of these methods will enable the new property and ensure the complete RFH2 header is returned if the queue being monitored by JMS applications has the PROPCTL property set to COMPAT.

- The JVM property
Dcom.ibm.mq.cfg.MessageProperties.PropctlToFORCE_RFH2 can be specified when the JMS application is invoked. An example of how to do this is shown below:
java -Dcom.ibm.mq.cfg.MessageProperties.PropctlToFORCE_RFH2=Yes <application name>

- Alternatively, the property can be set in the client configuration file, mqclient.ini, which can be found in the WMQ installation directory.
To enable the property, create a new stanza 'MessageProperties' and new property 'PropctlToFORCE_RFH2=Yes'. For example:

MessageProperties:
PropctlToFORCE_RFH2=Yes

References

WebSphere MQ 7.5.0 > WebSphere MQ > Migrating and upgrading > Migration tasks > V6.0 to V7.5 migration tasks > Migrating applications from version 6.0 to version 7.5 > Migrating an application that uses the MQRFH2 folder >
Using the PROPCTL channel property to control message properties

In WebSphere MQ Version 6.0, using all defaults, a get MQMessage includes the RFH2 header (if present) and the message payload (for example, Hello World). If, for example, the message was sent from JMS, this RFH2 would be the standard RFH2 that is generated for a JMS Message. It is possible, though, for the RFH2 to have been generated by other means.
In WebSphere MQ Version 7.0, using all defaults, a get MQMessage does not include the RFH2 header (if present) for folders of the RFH2 that are recognized as being from JMS. If a JMS message is got it consists solely of the message payload. The RFH2 is represented in the message properties of the WebSphere MQ classes for Java message.
To preserve the WebSphere MQ Version 6.0 behavior of propagating the RFH2 to the caller, the queue attribute PROPCTL must be changed from COMPAT to FORCE.

WebSphere MQ 7.0.1 > WebSphere MQ > Using Java > WebSphere MQ classes for Java > Introduction for programmers >
What is new in Websphere MQ Version 7.0?

WebSphere MQ V7.0 introduces the general availability of message properties, previously only available in WebSphere MQ classes for JMS. You can add new properties to any message without affecting applications that currently process that message. For more information, see Handling message properties.
Existing applications which rely on the presence of MQRFH2s containing properties must be changed to use the get*Property methods or to specify CMQC.MQGMO_PROPERTIES_FORCE_MQRFH2 to continue receiving properties in the MQRFH2 format. If the application cannot be changed then the queue attribute PropertyControl can be changed to the value MQPROP_FORCE_MQRFH2 so that properties are always returned in MQRFH2 form.


WebSphere MQ 7.5.0 > WebSphere MQ Explorer > Reference > Properties > Message properties >
MQ Get Message Options

MQGMO_PROPERTIES_FORCE_MQRFH2
Properties of the message, except those contained in the message descriptor (or extension) should be represented using MQRFH2 headers. This provides backward compatibility for applications which are expecting to retrieve properties but are unable to be changed to use message handles. If a MsgHandle is provided it is ignored.