Author |
Message
|
mqhuang |
Posted: Tue Jul 13, 2004 11:32 am Post subject: Coded Character Set Issue |
|
|
Newbie
Joined: 08 Jul 2004 Posts: 9
|
I am doing a pilot to send a request from iSeries to a MQ Client and then get a response from the Client throught a separate Queue. The problem I am facing is that the response in the message queue is 158 bytes with the coded character set of 1200. The length of the message becomes 356 after I issue a MQGET. It appears it is adding a null (hex 00) to the end of each byte in the message. Has anyone run into the same situation? How can I fix this problem?
I am running WebSphere MQ 5.3. |
|
Back to top |
|
 |
jefflowrey |
Posted: Tue Jul 13, 2004 11:36 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
That's Unicode.
Unicode is a two-byte character system. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
mqhuang |
Posted: Tue Jul 13, 2004 11:46 am Post subject: |
|
|
Newbie
Joined: 08 Jul 2004 Posts: 9
|
I know it is Unicode. But what do I do to get the message in its original format without the null after each byte? |
|
Back to top |
|
 |
jefflowrey |
Posted: Tue Jul 13, 2004 11:51 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
mqhuang wrote: |
what do I do to get the message in its original format without the null after each byte? |
It seems like Unicode is your original format.
Quote: |
response in the message queue is 158 bytes with the coded character set of 1200 |
1200 is Unicode.
So you either need to process the buffer you get as Unicode, or specify that you want to CONVERT the data when you issue the MQGet.
Or, and this is a less recommended practice, change the client app to not send Unicode. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
mqhuang |
Posted: Tue Jul 13, 2004 11:51 am Post subject: |
|
|
Newbie
Joined: 08 Jul 2004 Posts: 9
|
I forgot to mention the client is running on Windows platform in .NET code. |
|
Back to top |
|
 |
mqhuang |
Posted: Tue Jul 13, 2004 11:58 am Post subject: |
|
|
Newbie
Joined: 08 Jul 2004 Posts: 9
|
I did try to convert the unicode by adding GMCONV to GMOPT but it did not work either.
I don't think I want to process the input as Unicode, I was hoping MQ can handle it for me. Besides the message looks perfectly fine when I went into the Queue on iSeries. It clearly states the corrent length of 158 bytes. Why did it get doubled after MQGET? |
|
Back to top |
|
 |
jefflowrey |
Posted: Tue Jul 13, 2004 12:02 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
mqhuang wrote: |
I did try to convert the unicode by adding GMCONV to GMOPT but it did not work either. |
Then the client application isn't setting the MQ Format to MQFMT_STRING.
mqhuang wrote: |
I don't think I want to process the input as Unicode, I was hoping MQ can handle it for me. Besides the message looks perfectly fine when I went into the Queue on iSeries. It clearly states the corrent length of 158 bytes. Why did it get doubled after MQGET? |
Because the iSeries tool you are using to view the queue knows how to handle Unicode, and your application doesn't, most likely.
You should search around here for ways to change the client application so that it doesn't actually put the data using Unicode. I think it's a matter of which write method you use in .NET, but I don't remember the details.
Unicode is the default character format for .NET String objects. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
mqhuang |
Posted: Tue Jul 13, 2004 12:08 pm Post subject: |
|
|
Newbie
Joined: 08 Jul 2004 Posts: 9
|
Thanks for your suggestion. I will ask the .NET person to look in that direction. |
|
Back to top |
|
 |
JasonE |
Posted: Wed Jul 14, 2004 1:47 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003 Posts: 1220 Location: Hursley
|
Basically, if you set the codedcharset before calling the writestring method, then .net will convert it from uniicode into the ccsid specified at the time. In this way, you can prepare your message in the ccsid you want at the destination. |
|
Back to top |
|
 |
mqhuang |
Posted: Wed Jul 14, 2004 4:12 am Post subject: |
|
|
Newbie
Joined: 08 Jul 2004 Posts: 9
|
JasonE - Do you have any code examples that you can share with me? Or, do you know what ccsid should be set to before the .NET client puts the message to the response queue on the iSeries? |
|
Back to top |
|
 |
mqhuang |
Posted: Wed Jul 14, 2004 5:27 am Post subject: |
|
|
Newbie
Joined: 08 Jul 2004 Posts: 9
|
I asked our .NET person to put in the code to set ccsid to 850 before he does the wirte using the sample code you suggested in other thread
mqMsg = new MQMessage();
mqMsg.CharacterSet = 850; <** added
mqMsg.WriteString( message );
Instead of sending the original 158 byte, it is now sending 356 byte to iSeries with ccsid of 850. I tried to get the message both with and without GMCOVN, but with no success.
F100F000 F000F100 F5004000 E200A800 <1.0.0.1.5. .S.y.>
9300A500 81009500 4000E600 8100A800 <l.v.a.n. .W.a.y.>
Any one with any idea how I can fix this? |
|
Back to top |
|
 |
mqhuang |
Posted: Wed Jul 14, 2004 5:41 am Post subject: |
|
|
Newbie
Joined: 08 Jul 2004 Posts: 9
|
It would only be logical if the .NET program is sending unicode and set ccsid to 1200. The program on iSeries would then get the message by adding GMCONV to GMOPT. MQ should be doing the conversion automatically. But this is not happening for me. IBM should document this problem and not let new MQ users scraching their head without knowing what to do. |
|
Back to top |
|
 |
JasonE |
Posted: Wed Jul 14, 2004 5:43 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003 Posts: 1220 Location: Hursley
|
I think you are not using the fixpack 5/6/7 amqmdnet.dll - Try unregistering amqmdnet.dll, and reregistering it. Ensure you are building with the 1.0.0.3 version.
Chaning nmqsput the same way shows amqsbcg output of:
Encoding : 546 CodedCharSetId : 850
00000000: 4845 4C4C 4F20 574F 524C 44 'HELLO WORLD ' |
|
Back to top |
|
 |
|