IBM Mq Message Header - ibm-mq

Question

I am sending messages to a remote queue, to which I have no control.
I send a xml file as message but when the application reads the message it gets a message header like
<mcd><Msd>jms_text</Msd></mcd> \0\0\0l<jms><Dst>queue:///TEST</Dst><Tms>1281475843707</Tms><Cid></Cid><Dlv>1</Dlv></jms>
i don't want this message header to be present and my code for sending this message is as follows:
Properties props = new Properties();
props.setProperty("java.naming.factory.initial",this.initialFactory);
props.setProperty("java.naming.provider.url", url);
Context context = new InitialContext(props);
QueueConnectionFactory qcf = (QueueConnectionFactory) context.lookup(this.context);
qConn = qcf.createQueueConnection();
queue = (Queue)context.lookup(name);
qSession = qConn.createQueueSession(false, QueueSession.AUTO_ACKNOWLEDGE);
qConn.start();
QueueSender send = qSession.createSender(queue);
String text = "My xml file";
TextMessage tm = qSession.createTextMessage(text);
send.send(tm);
send.close();
How do I avoid this ?

Answer 1

It appears that you are sending a jms message to a non jms destination. How is the message being consumed on the destination? Is it expecting a native MQ message? The receiver is not understanding the MQRFH2 header that stores the JMS header properties.
You should either configure the destination to understand jms or your can do something like the following to tell the mq jms that your receiver is a non-jms client.
((com.ibm.mq.jms.MQQueue) queue).setTargetClient(JMSC.MQJMS_CLIENT_NONJMS_MQ);

Answer 2

Have a look at the properties for JMS objects as listed in the docs. On the administered object there is a property called TARGCLIENT which should be set to 'MQ'. Although you may have no control over the administered object, it is the responsibility of the person who administers the managed objects to set this property correctly. If the destination does not understand the RFH2 headers (which WMQ v6 uses to hold JMS properties) then any WMQ JMS applications which send messages to that destination must have that property set.
Incidentally, the fact that you are having this problem tends to indicate that the application consuming messages is still at v6. Please be aware that v6.0 of WMQ is end-of-life as of Sept 2011. If you switch to v7 now at both the QMgr and the client side, you can manage this with simple settings on the queue itself. The legacy app will understand the messages regardless of whether they have an RFH2 attached and the client app will see the responses as JMS messages regardless of whether the legacy app adds RFH2 headers. Move to v7 now, save your self a whole lot of trouble developing this app and also avoid having to migrate to v7 next year.
WMQ v7 client downloads are available here
Update: End-of-life for WMQ V6 was pushed back to September 2012.