com.ibm.mq.MQQueue vs. com.ibm.mq.jms.MQQueue?

Question

I am trying to put a raw MQSTR message on a WebSphere MQ queue. According to this , I can do:

((com.ibm.mq.jms.MQQueue) queue).setTargetClient(JMSC.MQJMS_CLIENT_NONJMS_MQ);

to indicate that it is a non-JMS queue. (I'm aware JMSC.MQJMS_CLIENT_NONJMS_MQ is deprecated -- that's not relevant to this question.) However, I had been using com.ibm.mq.MQQueue instead of com.ibm.mq.jms.MQQueue . Casting from the former to the latter doesn't work. Additionally, only com.ibm.mq.jms.MQQueue has the setTargetClient method.

Why are there two MQQueue classes and which one should I be using? I want to connect to az/OS queue externally in a Java program using hostname, channel name, and queue manager name (not JNDI).

Answer 1

Humm. I don't want to give the "RTM" answer but that is really the answer. There are 2 JAVA MQ APIs: 1 for "MQ classes for Java" and 1 for "MQ classes for JMS".

Note: "MQ classes for JMS" will put the JMS header (aka MQRFH2) on the message where as "MQ classes for Java" does NOT.

Therefore, if you are writing a regular Java/MQ application then do NOT use the "MQ classes for JMS" just use the "MQ classes for Java" and you will be good to go.

Answer 2

Using

((com.ibm.mq.jms.MQQueue) queue).setTargetClient(JMSC.MQJMS_CLIENT_NONJMS_MQ);

will tell the JMS client that the RFH2 will NOT be used so sending a JMSTextMessage will ensure that a plain MQSTR format message arrives on the queue. ie that the target client is NOT JMS therefore doesn't required the RFH2.

Stick to using the JMS API with the com.ibm.mq.jms.MQQueue with the setting above. The reason for deprecation is to use an alternative set of constants. The function this provides IS NOT deprecated.

This technote http://www-01.ibm.com/support/docview.wss?uid=swg21423244 explains what constants to use.