| Author |
Message
|
| vinothkhannas |
 Posted: Tue Aug 09, 2011 8:05 am Post subject: Reading japanese character through MQ |
 |
|
Novice
Joined: 09 Aug 2011
Posts: 13
|
Hi All,
Iam trying to read japanese characters through .NET amqmdnet.dll. Input is from a mainframe system and when am reading, the japanese characters are displayed as junk values, like "áïáÍá]ágçbáèáìágçbâ1â-â6â0".
Am using the below values
mqMsg.CharacterSet = MQC.MQCCSI_Q_MGR;
mqMsg.Encoding = MQC.MQENC_NATIVE;
Please let me know is there a way of retrieving japanese characters through MQ.
Thanks. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Tue Aug 09, 2011 8:18 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Are you GETTING or PUTTING a message?
Are you using a tool to *display* the message that KNOWS japanese characters?
The CCSID indicates what code page the message is *actually in*. You should not set it when you are GETTING a message.
You should set it to the *correct* value when you are PUTTING a message, and that correct value should, again, DESCRIBE THE CONTENTS OF THE MESSAGE.
Don't set CharacterSet or Encoding if you are Getting a message. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Aug 09, 2011 8:22 am Post subject: Re: Reading japanese character through MQ |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| contact admin wrote: |
| Please let me know is there a way of retrieving japanese characters through MQ. |
Same way you'd read Latin EBCDIC characters through a .NET application - make sure there's a conversion table loaded on the Windows side, the message is eligible for conversion and that you're requested that WMQ perform the conversion.
All this is described in the documentation, and has been the subject of multiple discussions on this forum. I'll leave other, more experienced posters to comment on the best code pages to use.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| vinothkhannas |
| Posted: Tue Aug 09, 2011 8:25 am Post subject: |
|
|
Novice
Joined: 09 Aug 2011
Posts: 13
|
Hi Jeff,
Am trying to do MQGET. The CCSID and Encoding are the values which another team is setting and putting the message. So am trying to use the same value and trying to read, but its displaying as junk.
And am viewing the content in notepad. Not sure whether its a notepad problem, because if its displaying problem i thought it'll display as boxes and not junk values.
Correct me if am wrong on any of the above points.
Thanks. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Aug 09, 2011 8:29 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
If they are writing Japanese characters to the message, and the qmgr is running on windows, then they are setting the CCSID to 437 almost certainly, which will not match the Japanese characters they have put into the message.
Make them demonstrate to you how they can successfully get and display the message they have written. It's almost certainly corrupt. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Aug 09, 2011 8:32 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| contact admin wrote: |
| Correct me if am wrong on any of the above points. |
Do not rely on how notepad handles non-native code pages.
You cannot possibly succeed using those values for CCSID & Encoding. Those are constants for the CCSID of the local queue manager & the local encoding so when the message is put on the mainframe they will have mainframe values. Unless you have your .NET running inside a mainframe emulator (!) you need the message to be presented in a non-mainframe format.
As my most worth associate also correctly points out, you can't change those values simply by specifying them on a get. And you wouldn't want to as they describe the message, not how it's displayed.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| vinothkhannas |
| Posted: Tue Aug 09, 2011 8:48 am Post subject: |
|
|
Novice
Joined: 09 Aug 2011
Posts: 13
|
Hi Jeff & Victor,
Thanks for your replies. But after the request is put, we checked the hex values in Queue and it corresponds to japanese values. But when i read the values at my end, the hex value and the content changes totally.
So should i do some conversion after i read the message at my end?
Thanks Much. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Aug 09, 2011 8:52 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| contact admin wrote: |
| we checked the hex values in Queue and it corresponds to japanese values. |
Japanese values in what code page? The mainframe one? The Windows one? Unicode?
| contact admin wrote: |
| So should i do some conversion after i read the message at my end? |
If the putting application is using the values quoted then the values in your queue should match Japanese on a mainframe unless WMQ has been configured to convert everything coming from the mainframe. In which case it could be converting them into a code page your application doesn't expect or assuming the message contains Latin characters and converting incorrectly on that basis.
You should get WMQ to do the conversion when you get the message if the message is still in mainframe on the queue. Or you can convert in via .NET.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| vinothkhannas |
| Posted: Tue Aug 09, 2011 9:12 am Post subject: |
|
|
Novice
Joined: 09 Aug 2011
Posts: 13
|
Hex values corresponds to japanese values at mainframe end.
The mainframe team puts the message in a particular queue and it routes to my queue. I read from my queue. We checked the hex values at mainframe queue. Both the queue properties are similar and so i never doubted the queue. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Aug 09, 2011 9:17 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| use amqsbcg to confirm that the hex values in your queue are correct. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Aug 09, 2011 9:17 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| contact admin wrote: |
| Hex values corresponds to japanese values at mainframe end. |
So you get junk characters because mainframe japanese values don't correspond to Windows japanese values.
So you need to:
a) get WMQ to convert them for you
b) perform the conversion within your application
Option a) I discussed further up this thread. Option b) I'll leave to better .NET people than me.
(Shouldn't junk characters be Chinese..... ? Or do the Japanese use a similar style of boat?  )
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Aug 09, 2011 11:55 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Browse the messages in the queue. Look at the MQMD. What is the value of the CCSID? What is the value of the Format?
_________________
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 |
|
|
| vinothkhannas |
| Posted: Wed Aug 10, 2011 7:47 am Post subject: |
|
|
Novice
Joined: 09 Aug 2011
Posts: 13
|
Hi Jeff,
I checked with amqsbcg and the hex values in my queue are correct. And i used CCSID of 500 (input is done with CCSID 500) and tried converting the values but after conversion the content changes and guess its junk again..Is there any other way in which we can acheive in .NET ? I cannot rely on Queue Conversion so i hav to handle it in code.
Let me know your suggessions.
Thanks. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Aug 10, 2011 7:51 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Okay, so if it comes in at your qmgr with valid byte values, then the message data itself hasn't (yet) been corrupted.
If the message on your qmgr is marked as being in CCSID 500, however, then that's almost certainly wrong. I don't believe that CCSID 500 supports Japanese characters, as I believe that it's the US EBCDIC codepage.
You should convince the senders to use CCSID 1200 or 1208, and then you shouldn't have any issues receiving this on your side, since that's the .NET native codepage. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Aug 10, 2011 7:52 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| contact admin wrote: |
| I checked with amqsbcg and the hex values in my queue are correct. |
By which you mean they match the mainframe Japanese values?
| contact admin wrote: |
| And i used CCSID of 500 (input is done with CCSID 500) |
Input of what? The message should have been output on the mainframe with something else - 500 is US Latin EBCDIC & if that supports Japanese it's news to me. Mr Google says the correct code page is 930 (but what does he know?).
| contact admin wrote: |
| tried converting the values |
With what? WMQ? .NET?
| contact admin wrote: |
| but after conversion the content changes and guess its junk again.. |
Don't guess - know. Are they junk or not? What does amqsbcg show? Post examples of before and after (desensitived)
| contact admin wrote: |
| I cannot rely on Queue Conversion |
Why not? What happens? Did you check the MQMD fields as suggested? What did they show?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
