| Author |
Message
|
| vinothkhannas |
 Posted: Wed Aug 10, 2011 7:58 am Post subject: |
 |
|
Novice
Joined: 09 Aug 2011
Posts: 13
|
Hi Jeff,
Let me tel the senders to use CCSID 1200 or 1208 and i'll check on that. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Aug 10, 2011 7:59 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Note also mainframe can support DBCS (double byte character set) and may be doing so if these are fullwidth Kanja.
As my most worthy associate points out, this is another case where Unicode is worth considering!
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| vinothkhannas |
| Posted: Wed Aug 10, 2011 8:00 am Post subject: |
|
|
Novice
Joined: 09 Aug 2011
Posts: 13
|
Vitor,
Yes, the hex values at my end match that of mainframe japanese values at the queue.
But i convert this into CCSID 500 using .NET to read the string and in these the english characters are displayed properly other than japanese values.
And after conversion am getting below values
<KanaLastNm>¸ÇÊ¡</KanaLastNm>
Below is the MQMD header received from queue
****Message descriptor****
StrucId : 'MD ' Version : 2
Report : 0 MsgType : 1
Expiry : 17709 Feedback : 0
Encoding : 785 CodedCharSetId : 500
Format : 'MQSTR '
Priority : 0 Persistence : 0
MsgId : X'C3E2D840D4D8D4F14040404040404040C8335A9FA72AFB82'
CorrelId : X'404040404040404040404040404040404040404040404040'
BackoutCount : 0
ReplyToQ : 'GETMULTISOURCEEXTERNALDATA.GNA.REPLY.IMSR '
ReplyToQMgr : 'MQM1 '
** Identity Context
UserIdentifier : 'nb5205a '
AccountingToken :
X'18E6D5C1C4E5404040C9D4E2D94040404000000C270000000200000000000000'
ApplIdentityData : ' '
** Origin Context
PutApplType : '3'
PutApplName : 'IMSR WNADV '
PutDate : '20110810' PutTime : '11570879'
ApplOriginData : ' '
GroupId : X'000000000000000000000000000000000000000000000000'
MsgSeqNumber : '1'
Offset : '0'
MsgFlags : '0'
OriginalLength : '-1'
**** Message **** |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Aug 10, 2011 8:02 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
Post here the complete MQMD of one of the messages.
_________________
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 |
|
|
| Vitor |
| Posted: Wed Aug 10, 2011 8:21 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| contact admin wrote: |
| But i convert this into CCSID 500 using .NET to read the string and in these the english characters are displayed properly other than japanese values. |
Accepting I don't know .NET as well as I should, but I don't get why you're converting to CCSID 500 (US Latin EBCDIC) using a Windows based platform that uses Unicode natively. The reason is.....?
I also don't see how the unconverted message can have a CCSID of 500 and correctly hold Japanese characters. How do you (or the mainframe developers) explain that/
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Aug 10, 2011 9:59 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| Vitor wrote: |
| contact admin wrote: |
| But i convert this into CCSID 500 using .NET to read the string and in these the english characters are displayed properly other than japanese values. |
Accepting I don't know .NET as well as I should, but I don't get why you're converting to CCSID 500 (US Latin EBCDIC) using a Windows based platform that uses Unicode natively. The reason is.....?
I also don't see how the unconverted message can have a CCSID of 500 and correctly hold Japanese characters. How do you (or the mainframe developers) explain that/ |
The MQMD shows CCSID 500.
There is more than one flavor of Japanese language ccsid.
[edit]
This is from the WMQ Application Programming Reference, which identifies WMQ-supported ccsids, AND to which other ccsids thay be converted by WMQ:
Japanese Latin SBCS ccsid 1027 (converts to 500)
Japanese Katakana SBCS ccsid 290 (converts to 500)
Japanese Kanji/ Latin Mixed ccsids 1399, 5035 (do not convert to 500)
Japanese Kanji/ Katakana Mixed ccsids 1390, 5026 (do not convert to 500)
[/edit]
Which one did the developer use? Which did the developer intend?
_________________
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 |
|
|
| Vitor |
| Posted: Wed Aug 10, 2011 10:10 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
This demonstrates how much direct experience I have of Japanese... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Aug 10, 2011 10:53 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| Vitor wrote: |
| This demonstrates how much direct experience I have of Japanese... |
The OP isn't so much about Japanese, as it is about a developer loading the application data payload with (I suspect) DBCS data, and setting CCSID 500, a single-byte coding scheme.
_________________
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: Thu Aug 11, 2011 7:21 am Post subject: |
|
|
Novice
Joined: 09 Aug 2011
Posts: 13
|
Hi Jeff & Victor,
I was not able to convince the senders to use any other encoding since mainframes uses 500 by default.
I was trying to do some analysis and below is what i've found.
1) String str = "ﾄｳｷｮｳﾄ";
If i convert the above string to 500 am getting 6F 6F...6F(six times) and so i get "???..." while decoding back in 500.
And if i encode and decode in 932 am getting the string back.
But the problem here is, the string is going to be encoded in 500 and even though i get as 6F 6F... i need to do something and get the original characters.
I tried jus decoding as 932, but i get "ooo...".
Am breaking my head in this for a week so Please suggesst a solution in .NET which can make this happen.
Thanks a lot. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Aug 11, 2011 7:26 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| contact admin wrote: |
| I was not able to convince the senders to use any other encoding since mainframes uses 500 by default. |
a) It's a default setting not a mandatory one
b) It's a default because the majority of mainframe work is in US Latin.
If the senders are sending non-default characters, why not use a non-default character set? Oh well.
| contact admin wrote: |
| Please suggesst a solution in .NET which can make this happen. |
You're looking for a solution where a string of (preumably) different hex representations in 932 have been forced into 500, resulting in them arriving in the queue as a sequence of X'6F' in CCSID 500, and you're looking for a solution where you can derive the original hex values in 932 from this sequence of identical values so they can be further converted into an equivalent Windows CCSID?
You're going to need someone better with CCSID & .NET than me I'm afraid..... 
_________________
Honesty is the best policy.
Insanity is the best defence.
Last edited by Vitor on Thu Aug 11, 2011 7:27 am; edited 1 time in total |
|
| Back to top |
|
|
| vinothkhannas |
| Posted: Thu Aug 11, 2011 7:26 am Post subject: |
|
|
Novice
Joined: 09 Aug 2011
Posts: 13
|
| bruce2359 wrote: |
| Vitor wrote: |
| contact admin wrote: |
| But i convert this into CCSID 500 using .NET to read the string and in these the english characters are displayed properly other than japanese values. |
Accepting I don't know .NET as well as I should, but I don't get why you're converting to CCSID 500 (US Latin EBCDIC) using a Windows based platform that uses Unicode natively. The reason is.....?
I also don't see how the unconverted message can have a CCSID of 500 and correctly hold Japanese characters. How do you (or the mainframe developers) explain that/ |
The MQMD shows CCSID 500.
There is more than one flavor of Japanese language ccsid.
[edit]
This is from the WMQ Application Programming Reference, which identifies WMQ-supported ccsids, AND to which other ccsids thay be converted by WMQ:
Japanese Latin SBCS ccsid 1027 (converts to 500)
Japanese Katakana SBCS ccsid 290 (converts to 500)
Japanese Kanji/ Latin Mixed ccsids 1399, 5035 (do not convert to 500)
Japanese Kanji/ Katakana Mixed ccsids 1390, 5026 (do not convert to 500)
[/edit]
Which one did the developer use? Which did the developer intend? |
Hi,
Am not sure on which one the sender is using. This is something which is done internally in mainframes. But am decoding with 500 and am able to get the XML properly but not the japanese data inside the tags. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Aug 11, 2011 7:30 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| contact admin wrote: |
| Am not sure on which one the sender is using. This is something which is done internally in mainframes. But am decoding with 500 and am able to get the XML properly but not the japanese data inside the tags. |
Yes, because I'm fairly certain all the US Latin characters are in the same places on all the EBCDIC code sets in the same way they are in all the ASCII ones. So English (like XML) works if you encode it in 500, 932 or any of the others.
Same principle as if you select Greek or Russian on Windows. Latin characters still come out correctly.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Aug 11, 2011 7:31 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| contact admin wrote: |
Hi Jeff & Victor,
I was not able to convince the senders to use any other encoding since mainframes uses 500 by default. |
No. No. No.
The application decides what kind of data AND what character set to put into the application payload of a message. The application must insert the correct ccsid - the one that matches the actual app payload - into the MQMD.
By default, the qmgr inserts its ccsid into the MQMD - which may or may not accurately reflect what is in the application payload.
| contact admin wrote: |
I was trying to do some analysis and below is what i've found.
1) String str = "ﾄｳｷｮｳﾄ";
If i convert the above string to 500 am getting 6F 6F...6F(six times) and so i get "???..." while decoding back in 500.
And if i encode and decode in 932 am getting the string back.
But the problem here is, the string is going to be encoded in 500 and even though i get as 6F 6F... i need to do something and get the original characters.
I tried jus decoding as 932, but i get "ooo...".
Am breaking my head in this for a week so Please suggesst a solution in .NET which can make this happen.
Thanks a lot. |
You will need to use a utility that displays the message in HEX as well as character. Post here the HEX. Posting little boxes doesn't help us help you.
_________________
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 |
|
|
| bruce2359 |
| Posted: Thu Aug 11, 2011 7:42 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
This is not a mainframe problem This same issue would occur on UNIX and Windows. It is an application issue.
The app that created the message (with Kanji, or Spanish, or whatever) failed to set the ccsid in the MQMD to the ccsid of the application data BEFORE the mqput.
_________________
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: Thu Aug 11, 2011 7:55 am Post subject: |
|
|
Novice
Joined: 09 Aug 2011
Posts: 13
|
You will need to use a utility that displays the message in HEX as well as character. Post here the HEX. Posting little boxes doesn't help us help you.[/quote]
ﾄｳｷｮｳﾄ
8B 6367 5663 8B
Above are the byte values which is present in the queue and at mainframes end.
Now am trying to convert these into 500 and here it becomes junk.
And i can see that in the MQMD header the CCSID value is set as 500. |
|
| Back to top |
|
|
|
|
