| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| using request message Encoding. |
« View previous topic :: View next topic » |
| Author |
Message
|
| soanewbee |
 Posted: Tue Aug 07, 2012 8:21 pm Post subject: using request message Encoding. |
 |
|
Newbie
Joined: 07 Aug 2012
Posts: 2
|
Hi Techies,
I am very new to Websphere MQ Series API platform. Assume we are having the requirement for response message should be encoded in the encoding type of request message . Existing application sends the request message in to the request queue, the message is picked by the consuming application and create the response with
. Again the reponse is posted in response queue by consumed application. My Problem here is, if we try to use the request encoding as response encoding means , we have the BYTE Order problem in message. Could you please share your thought.? if you give you valuable thought ,its really appreciated. 
Scenario :
Request message encoding value 546 ,MQ Manager is encoding value 273. My code Logic is using the MQ Manager Native Encoding.(to avoid BYTE Order problem).so response MQMD message encoding is 273. But i need to obtain the encoding value as request MQMD message.
| Code: |
| this._encoding = newMessage.encoding; |
Assume
as MQMessageWrapper , which contains the already native encoding value of MQ Manager. Now we try to assign the request message encoding value to MQMessageWrapper encoding. This will creates the BYTE Order issue. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Tue Aug 07, 2012 9:35 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
First problem: Understanding of MQ terms:
- MQ Encoding Defines the byte order for numerical values
- MQ CCSID (Character Code Set ID) defines the code page to use for text
My guess is that you are talking about text.
Recognize also the different use of API commands:
WriteUTF can only be used in combination with ReadUTF.
Now when writing a message that contains only text:
Set message format to MQFMT_STRING (MQ constant value)
Set message CCSID to the value you need before using the first write statement.
On the receiving app, set the CCSID of the connection factory or MQMD before receiving the message and if using base make sure you use the MQGMO option Convert.
Make sure there exists a conversion table (usually at OS level) between the CCSID of the source and the CCSID requested by the target...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| soanewbee |
| Posted: Tue Aug 07, 2012 10:27 pm Post subject: using request message Encoding. |
|
|
Newbie
Joined: 07 Aug 2012
Posts: 2
|
Hi Mate,
The first thing is "My guess is that you are talking about text" , i am not talking about text. It is purly Numeric values. The second one is , i have to use the same encoding type of request which one sent for process, will be return back to same encoding type of response, The problem is if i am using the MQMessageWrapper, where we can possible to set the request encoding type. but if we set that we are getting BYTE ORDER Problem. Please share your ideas.  |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Tue Aug 07, 2012 11:29 pm Post subject: Re: using request message Encoding. |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| soanewbee wrote: |
| My Problem here is, if we try to use the request encoding as response encoding means , we have the BYTE Order problem in message. |
What byte order problem is that? All of the MQMessage numeric read/write methods convert the data as needed, using the given message encoding.
It might be useful to describe the problem more clearly: post some of the relevant code that reads/writes the message, describe the expected results, actual results, and how they differ. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Aug 08, 2012 5:14 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
It's a little-endian, big-endian thing. Intel hardware stores numbers backwards (byte order reversed).
Thus, on Intel, if you create a request message, encoding-native, that asks for 123 of something, Intel stores (encodes) the number as 321. If the message arrives on a non-Intel platform, AND you DON'T request conversion, you replying app will see 321.
This is well-documented in the APG and APR, and equivalent InfoCenter.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Wed Aug 08, 2012 11:51 pm Post subject: Re: using request message Encoding. |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
All of the Java (and .NET) MQMessage numeric read/write methods convert the data as needed, using the given message encoding, with or without MQ conversion. So there shouldn't be a byte order problem.
This is well-documented in 'Using Java' (and 'Using .NET'), and equivalent InfoCenter. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Thu Aug 09, 2012 3:39 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
A suggestion to avoid this cross-platform binary representation issue is to store numeric values in MQ messages as decimal text strings. Then people can easily read the data too. 
_________________
Glenn |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
