| Author |
Message
|
| FrodGandalf |
 Posted: Wed Apr 12, 2006 4:51 pm Post subject: How to avoid charset conversion in EBCDIC JMS Bytes Message? |
 |
|
Newbie
Joined: 06 Apr 2006
Posts: 7
|
Hi,
We have the following setup – The MQ Queue manager is on a IBM Z/OS box
Our application is using MQ JMS and is running on AIX box. We have separate request and response queues to communicate with the COBOL application on mainframes. The mainframe application sends and receives data in EBCDIC.
Using MQ JNDI I have created the JMS MQ Queue definitions with – target client as MQ, CCSID = 37, ENCODING = 785
I printed the message that the COBOL application sends from my JMS app. It look slike this -
JMS Message class: jms_bytes
JMSType: null
JMSDeliveryMode: 2
JMSExpiration: 0
JMSPriority: 0
JMSMessageID: ID:c3e2d840d4e3f0f74040404040404040be9ab9fd81474e42
JMSTimestamp: 1144159274240
JMSCorrelationID:null
JMSDestination: null
JMSReplyTo:
JMSRedelivered: false
JMSXDeliveryCount:1
JMS_IBM_MsgType:8
JMSXAppID:hfkjshf
JMS_IBM_Format:
JMS_IBM_Encoding:785
JMS_IBM_PutApplType:2
JMS_IBM_Character_Set:37
JMSXUserID:S75F
JMS_IBM_PutTime:14011424
JMS_IBM_PutDate:20060404
Integer encoding: 1, Floating point encoding 768
40404040404040404040404040f4c8f5f0f8f7f6f3f3f6f0f5c6c1f2f0f0f6f0f3f2f8f0f6f1f2f0
...
; class name= com.ibm.jms.JMSBytesMessage
Since data is in bytes, I have to retrieve the Bytes and construct String using the Character set converters by Java –
String temp = new String(<bytes[]>, “Cp037”)
I have the following queries -
1.> Is there any way that I could avoid doing this? Or is the preferred way to have the Cobol application to send the message with MQFMT_STRING set?
2.> If the message was defined as all Characters(String) and I use jms.TextMessage.getText(), will the MQ JMS layer convert the data and given valid data?
Any help will be appreciated!!
Thanks,
FG |
|
| Back to top |
|
 |
| bd_mq |
| Posted: Wed Apr 12, 2006 5:11 pm Post subject: Conversion in channel? |
|
|
Newbie
Joined: 12 Apr 2006
Posts: 4
|
| The MQ channel can do the conversion. Putting conversion in the code is usually undesirable since it increases coupling. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Apr 12, 2006 7:24 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
If you are trying for the MQ to do the conversion and set up the JNDI accordingly. Nice but completely beside the point: YOU NEED TO USE TextMessage. You cannot use BytesMessage and expect conversion. It is like creating a message with format none and asking for a conversion.!!! 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| FrodGandalf |
| Posted: Thu Apr 13, 2006 10:17 am Post subject: |
|
|
Newbie
Joined: 06 Apr 2006
Posts: 7
|
So I should be
- While creating the file JNDI definitions for Queue and Queue manager not specify the CCSID/Encodings
- While sending messages to Cobol app on mainframe, use jms TextMessage (This will set the MQSTR of the message to the mainframe app and then the mainframe app should use MQGMO_CONVERT option)
- While recieving messages from Cobol app on mainframe use jms TextMessage (Assuming the Cobol app sets MQSTR).
Basically nowhere is the character set Cp037 or EBCDIC specified. The WS JMS MQ will do the necessary conversion to/from the default characterset of the platform where the JMS application is running.
I tried this and it worked great. Thanks a lot and I agree this is better than doing the transaltion in the code
Thanks,
FG |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Apr 13, 2006 12:29 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| FrodGandalf wrote: |
So I should be
- While creating the file JNDI definitions for Queue and Queue manager not specify the CCSID/Encodings
|
It really depends on what you want to do. If the queue is local to AIX there is no point. If the queue is remote and points to the MF it will allow you to translate the messages into the jndi specified CCSID and encoding before they get transmitted to the MF. (hint no need for convert option on the MF). Of course all messages need to be TextMessages.
| FrodGandalf wrote: |
- While sending messages to Cobol app on mainframe, use jms TextMessage (This will set the MQSTR of the message to the mainframe app and then the mainframe app should use MQGMO_CONVERT option)
|
YES. This is best practice. You may want to keep targetClient=1 (MQ) to avoid creating the RFH header.
| FrodGandalf wrote: |
- While recieving messages from Cobol app on mainframe use jms TextMessage (Assuming the Cobol app sets MQSTR).
|
YES. If the cobol APP set MQF_MQSTR you should receive and instance of the TextMessage in absence of an RFH header.
| FrodGandalf wrote: |
Basically nowhere is the character set Cp037 or EBCDIC specified. The WS JMS MQ will do the necessary conversion to/from the default characterset of the platform where the JMS application is running.
|
This is the standard when routing messages.
| FrodGandalf wrote: |
I tried this and it worked great. Thanks a lot and I agree this is better than doing the transaltion in the code
Thanks,
FG |
Glad we could be of help. Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| DryHeatDave |
| Posted: Thu Apr 13, 2006 2:05 pm Post subject: |
|
|
Apprentice
Joined: 21 Mar 2006
Posts: 28
Location: Phoenix, AZ
|
Perhaps someone with more experience can speak up. But -
"The MQ channel can do the conversion. Putting conversion in the code is usually undesirable since it increases coupling.".
I'd heard it was real inefficient to have the channel do the conversion (aside frm the fact it locks in all channel users, to having their data converted).
I nearly lost a body part, when I tried it once - didn't try it again, after that 
_________________
SCJP2
IBM Cert. Solutions Designer for Websphere MQ 5.3
Not a certified mainframer - just been doing it a real long time. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Apr 13, 2006 2:15 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
It really does mess with you when you attempt default routing through a Mainframe qmgr and the message is a text message but not in EBCDIC (routed from a unix platform to the MF back to unix or win).
Make sure if you do default routing to have channels devoid of conversion exits.!!
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| FrodGandalf |
| Posted: Mon Apr 17, 2006 9:39 am Post subject: |
|
|
Newbie
Joined: 06 Apr 2006
Posts: 7
|
Hi,
I'd heard it was real inefficient to have the channel do the conversion (aside frm the fact it locks in all channel users, to having their data converted)."
"It really does mess with you when you attempt default routing through a Mainframe qmgr and the message is a text message but not in EBCDIC (routed from a unix platform to the MF back to unix or win). "
Does this mean that using the default routing mechanism in MQ (MQGMO_CONVERT/MQFMT_STRING) is not efficient and it locks up the channel users as per the comments above?
If this is true then should I be going for conversion at the application end?
Also in my case one set of text messages would be going from AIX to Mainframe and the other set from Mainframe to AIX. The queue manager is on Mainframes.
So text message going from AIX to MF would not be in EBCDIC. Would this mess up the data?
Thanks,
FG |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Apr 17, 2006 9:50 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
It is a performance hit on the channel, and thus the channel runs less efficiently, if the MCA has to issue an MQGMO_CONVERT on every message that passes through it. This is not because the conversion algorithm is inefficient, it's just because the channel is now doing more work so it takes longer to process each message and thus fewer messages go through the channel in a given timeframe.
It's not considered a performance hit to specify MQGMO_CONVERT in an application - because the conversion algorithm is going to be at least as efficient as anything you write and the work needs to be done regardless of WHO does it.
It is also never a good idea to convert data more than ONCE. So if a message is going from point A to point C by way of point B - you do not want any of the channels to do conversion. Because the application could still specify MQGMO_CONVERT and use a different CCSID than the qmgr.
It is best practices not to use Channel Conversion for both of those reasons.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| FrodGandalf |
| Posted: Mon Apr 17, 2006 10:14 am Post subject: |
|
|
Newbie
Joined: 06 Apr 2006
Posts: 7
|
So does this mean that I should NOT be using MQGMO_CONVERT option and instead send/recieve BytesMessage and expect the recieving applications to do the conversion?
or
Should I be using the MQGMO_CONVERT option with no channel conversion exit ?
I am askign these queries as I am now confused about -
If MQFMT_STRING format is set by the sending app and the recieving application uses MQGMO_CONVERT option then I assumed that it is the MQ Java/JMS libraries that do the EBCDIC to/from ASCII conversions. Is this true or is the conversion done at the channel end?
I agree that conversion should be done only once. So using MQGMO_CONVERT with no channel conversions specified should be equivalent to doing a one time conversion at the application end.
Thanks for your patient replies to a newbie. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Apr 17, 2006 10:44 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You can't specify an MQ Get Message Option on the PUT or SEND. MQGMO_CONVERT is not applicable in those cases.
MQGMO_CONVERT should basically always be set by receivers.
The channel should basically never be configured to perform data conversion.
In cases where MQGMO_CONVERT is specified in a receiving appplication, then it is actually the MQ substructure that performs the conversion - not the Java libraries.
In the case of JMS receivers, you don't specify MQGMO options normally. You leave the CCSID alone, and verify that you've been given a TextMessage object and not a BytesMessage object.
In the case where a channel has not converted a message, ever, then the data in the message *on the final queue* is in the original code-page of the sending application. It's only when it's retrieved from that queue via GET that conversion could occur.
If a channel has converted the message, then the data on the final queue is in the receiver's code page already.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Apr 17, 2006 4:21 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| FrodGandalf wrote: |
So does this mean that I should NOT be using MQGMO_CONVERT option and instead send/recieve BytesMessage and expect the recieving applications to do the conversion?
or
Should I be using the MQGMO_CONVERT option with no channel conversion exit ? |
No. You should be using MQFMT_MQSTR on the sending side, no channel exits or conversion and the JMS layer will do a GET with Convert for you so you should see that data in plain text.
| FrodGandalf wrote: |
I am askign these queries as I am now confused about -
If MQFMT_STRING format is set by the sending app and the recieving application uses MQGMO_CONVERT option then I assumed that it is the MQ Java/JMS libraries that do the EBCDIC to/from ASCII conversions. Is this true or is the conversion done at the channel end?
|
No the conversion is not done at the channel end. It is done in the MQLayer that retrieves the message from the queue and serves it up to your application.
| FrodGandalf wrote: |
I agree that conversion should be done only once. So using MQGMO_CONVERT with no channel conversions specified should be equivalent to doing a one time conversion at the application end.
Thanks for your patient replies to a newbie. |
You got it.!
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
