| Author |
Message
|
| jjanes |
 Posted: Thu Aug 18, 2011 9:54 am Post subject: JMS messages placed in Mainframe queue in unreadable format |
 |
|
Newbie
Joined: 18 Aug 2011
Posts: 3
|
Hi All.
I am a newbie at message queues and JMS.
I have been struggling with an issue where the messages I send to the mainframe queue show up, but part of it is unreadable. It appears to me that it's the message header portion. The actual text message is readable. Is this normal or am I doing something wrong?
I currently have a Java Restful web service application that calls a Linux Based Websphere MQ v7 queue. All works fine for browsing, getting and putting messages, both to local queues and the remote mainframe queue, with the exception that I spoke of above.
Following is the put message code:
| Code: |
@GET
@Path("putMessage")
@Produces(MediaType.TEXT_PLAIN)
public String putMessage(
@QueryParam("pQueueName") String pQueueName,
@QueryParam("pMessage") String pMessage,
@QueryParam("pHost") String pHost,
@QueryParam("pPort") String pPort,
@QueryParam("pChannel") String pChannel,
@QueryParam("pQueueManagerName") String pQueueManagerName
) {
// Local Variables
Connection connection = null;
Session session = null;
Queue destination = null;
MessageProducer producer = null;
Message message = null;
StringBuffer sbResponse = new StringBuffer();
// Set tracing off.
Trace.setOff();
// Determine if queue name was delivered or not.
if(pQueueName != null && pQueueName.trim().length() > 0) {
// Try to browse queue.
try {
// Create a connection factory
JmsFactoryFactory ff = JmsFactoryFactory.getInstance(WMQConstants.WMQ_PROVIDER);
JmsConnectionFactory cf = ff.createConnectionFactory();
// Set the properties
sbResponse.append("Setting the following connection properties.<br/>");
// Determine if connection properties were delivered or not.
if(
(pHost == null || pHost.trim().length() <= 0) ||
(pPort == null || pPort.trim().length() <= 0) ||
(pQueueManagerName == null || pQueueManagerName.trim().length() <= 0)
) {
sbResponse.append("Connection properties were not provided, using defaults.<br/>");
sbResponse.append("Host: "+host+"<br/>");
sbResponse.append("Port: "+port+"<br/>");
sbResponse.append("Channel: "+channel+"<br/>");
sbResponse.append("Queue Manager: "+queueManagerName+"<br/>");
cf.setStringProperty(WMQConstants.WMQ_HOST_NAME, host);
cf.setIntProperty(WMQConstants.WMQ_PORT, port);
cf.setStringProperty(WMQConstants.WMQ_CHANNEL, channel);
cf.setIntProperty(WMQConstants.WMQ_CONNECTION_MODE, WMQConstants.WMQ_CM_CLIENT);
cf.setStringProperty(WMQConstants.WMQ_QUEUE_MANAGER, queueManagerName);
} else {
sbResponse.append("Host: "+pHost+"<br/>");
sbResponse.append("Port: "+pPort+"<br/>");
sbResponse.append("Channel: "+pChannel+"<br/>");
sbResponse.append("Queue Manager: "+pQueueManagerName+"<br/>");
cf.setStringProperty(WMQConstants.WMQ_HOST_NAME, pHost);
cf.setIntProperty(WMQConstants.WMQ_PORT, Integer.parseInt(pPort));
cf.setStringProperty(WMQConstants.WMQ_CHANNEL, pChannel);
cf.setIntProperty(WMQConstants.WMQ_CONNECTION_MODE, WMQConstants.WMQ_CM_CLIENT);
cf.setStringProperty(WMQConstants.WMQ_QUEUE_MANAGER, pQueueManagerName);
}
sbResponse.append("Queue: "+pQueueName+"<br/>");
// Create JMS objects
sbResponse.append("Connecting to queue manager.<br/>");
connection = cf.createConnection();
session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
destination = session.createQueue(pQueueName);
producer = session.createProducer(destination);
// Create message.
sbResponse.append("Creating outbound message.<br/>");
if(pMessage != null) {
message = session.createTextMessage(pMessage);
message.setStringProperty(WMQConstants.JMS_IBM_CHARACTER_SET, "IBM500");
sbResponse.append("Sending message to queue.<br/>");
producer.send(message);
recordSuccess(sbResponse);
} else {
sbResponse.append("Required message parameter was not present.<br/>");
recordFailure(null, sbResponse);
}
} catch (JMSException jmsex) {
recordFailure(jmsex, sbResponse);
} finally {
if (producer != null) {
try {
producer.close();
} catch (JMSException jmsex) {
sbResponse.append("Producer could not be closed.<br/>");
recordFailure(jmsex, sbResponse);
}
}
if (session != null) {
try {
session.close();
} catch (JMSException jmsex) {
sbResponse.append("Session could not be closed.<br/>");
recordFailure(jmsex, sbResponse);
}
}
if (connection != null) {
try {
connection.close();
} catch (JMSException jmsex) {
sbResponse.append("Connection could not be closed.<br/>");
recordFailure(jmsex, sbResponse);
}
}
}
} else {
sbResponse.append("No queue name provided.");
}
// Return response.
return sbResponse.toString();
}
|
The mainframe message looks like the following:
............._....(...._.^......(....._.........._
.................&........................_........
.........._....%......%....._.....This is a test.
Any assistance would be greatly appreciated! |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Thu Aug 18, 2011 9:56 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Switch to MQ v7.
That will remove the MQRFH2 header and set everything as message properties instead. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Aug 18, 2011 10:13 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| Switch to MQ v7. |
| jjanes wrote: |
| I currently have a Java Restful web service application that calls a Linux Based Websphere MQ v7 queue |
Is the problem that you can't read the message header, or that the mainframe application can't read the message header? If you can't read it but the application is safely ignoring it (which it could be coded to do) then you're fine.
If the problem is that the application is doing an MQGet call and getting a mouthful of header it doesn't expect in the message, you need to suppress the JMS headers (which is what's on the front of your message) in your application by means of TARGCLIENT or similar.
There have been a number of discussions on this in here over the years.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Aug 18, 2011 10:15 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| just because LINUX is at Mq V7 doesn't mean the MF is at MQ v7. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Aug 18, 2011 10:24 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| just because LINUX is at Mq V7 doesn't mean the MF is at MQ v7. |
And I was entirely attempting to circumvent the OP coming back with "but I am using v7 - see my original post". 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Aug 18, 2011 10:26 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
And, for clarity I'll pose this question before someone else does:
Can you access message properties set by a v7 Linux application (using JMS or not) with an application using v6 features?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Aug 18, 2011 10:28 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
And, for clarity I'll pose this question before someone else does:
Can you access message properties set by a v7 Linux application (using JMS or not) with an application using v6 features?
|
Yes, they get turned into an MQRFh2. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Aug 18, 2011 10:49 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| Vitor wrote: |
And, for clarity I'll pose this question before someone else does:
Can you access message properties set by a v7 Linux application (using JMS or not) with an application using v6 features?
|
Yes, they get turned into an MQRFh2. |
Like the one on the front of the OP's message?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jjanes |
| Posted: Thu Aug 18, 2011 10:50 am Post subject: |
|
|
Newbie
Joined: 18 Aug 2011
Posts: 3
|
| Vitor wrote: |
| mqjeff wrote: |
| Switch to MQ v7. |
| jjanes wrote: |
| I currently have a Java Restful web service application that calls a Linux Based Websphere MQ v7 queue |
If the problem is that the application is doing an MQGet call and getting a mouthful of header it doesn't expect in the message, you need to suppress the JMS headers (which is what's on the front of your message) in your application by means of TARGCLIENT or similar.
|
Thanks for your quick responses!
Yes the problem is that the mainframe programmer is getting all the garbage as well as the payload.
Suppression of header would not allow for obtaining such things like the correlation id, right?
The use case for this service is to allow multiple ColdFusion applications to request data from the mainframe which in turn places output in receive queue for the applications to pick up. (short explanation).
I am looking into what version the mainframe is at. One person said v7, but I have someone else looking into it just to be sure. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Aug 18, 2011 10:59 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| jjanes wrote: |
| Suppression of header would not allow for obtaining such things like the correlation id, right? |
No.
It would suppress the JMS specific properties, not the MQMD. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Aug 18, 2011 11:00 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jjanes wrote: |
| Yes the problem is that the mainframe programmer is getting all the garbage as well as the payload. |
"Garbage" is a harsh word; one day you may be thankful for it! 
| jjanes wrote: |
| Suppression of header would not allow for obtaining such things like the correlation id, right? |
Wrong. The correlation id is stored in a header but not that header. Your mainframe app will be accessing that separately. A spot of research on the MQMD & MQRFH2 structures in the Application Programming Reference will be illuminating at this point in your life.
| jjanes wrote: |
| I am looking into what version the mainframe is at. One person said v7, but I have someone else looking into it just to be sure. |
If it is also v7, then I fully endorse the comments of my most worthy associate about message properties.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jjanes |
| Posted: Thu Aug 18, 2011 11:27 am Post subject: Thanks guys for all your help! |
|
|
Newbie
Joined: 18 Aug 2011
Posts: 3
|
What I ended up doing was changing the create queue line to:
| Code: |
destination = session.createQueue("queue:///"+pQueueName+"?targetClient=1");
|
The output does show that the JMS message headers were removed.
000001,RFH .......u.......4MQSTR ...........
000002,Second test with targetclient set to 1.
Thanks again! |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Aug 18, 2011 12:23 pm Post subject: Re: Thanks guys for all your help! |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| jjanes wrote: |
What I ended up doing was changing the create queue line to:
| Code: |
destination = session.createQueue("queue:///"+pQueueName+"?targetClient=1");
|
The output does show that the JMS message headers were removed.
000001,RFH .......u.......4MQSTR ...........
000002,Second test with targetclient set to 1.
Thanks again! |
Wrong move! you should have changed the parm of your JMS app to say
pQueueName="queue:///<pqueuename>?targetClient=1" ...
Thus you would have suppressed the RFH2 without changing a line of code...
Have fun anyway.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Aug 18, 2011 10:56 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| Set TargetClient to NonJMS. |
|
| Back to top |
|
|
|
|
