| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Encoding - Non ASCII Chars - iSeries to Windows platform |
« View previous topic :: View next topic » |
| Author |
Message
|
| Luke |
 Posted: Thu Sep 17, 2009 1:09 am Post subject: |
 |
|
Centurion
Joined: 10 Nov 2008
Posts: 128
Location: UK
|
Oh, THAT document?  This document contains a lot of good info, but I think in this scenario it needs to be understood in conjunction with an understanding of Message Broker, and the role the Broker is playing here. In particular:
Message Broker does its own conversion, in addition to the facilities provided by MQ.
The document states:
| Quote: |
in the application that is doing the initial MQPUT of the message, you should:
Set MQMD.CodedCharSetId to MQCCSI_Q_MGR. ... |
The Broker isn't doing the initial MQPUT in the described scenario. It's performing transformation and routing the message to another application (as is fairly common). So, given this, I'd suggest that it's rarely appropriate for Message Broker to set the CCSID in that way.
Generally speaking, if I'm developing a flow that's MQ in and MQ out, unless I have a specific requirement to convert the data, I'd write the message out with the same CCSID and Encoding as were input in the MQ headers of the incoming message. If there's a specific requirement to convert, then I'd explicitly code the flow to convert to the required codepage.
If you set the CCSID to MQCCSI_Q_MGR, this may work. i.e. If conversion is required and the Broker's queue manager happens to have the default CCSID that is required, or if no conversion is required and the default CCSID of the QM happens to be the same as the CCSID of the incoming message ... then it will work.
It just doesn't seem a reliable way to code it to me. |
|
| Back to top |
|
 |
| Ramphart |
| Posted: Thu Sep 17, 2009 5:05 am Post subject: Re: Encoding - Non ASCII Chars - iSeries to Windows platform |
|
|
Disciple
Joined: 21 Jul 2004
Posts: 150
Location: South Africa, JHB
|
| rekarm01 wrote: |
| Ramphart wrote: |
| 6. The message in 5. above does parse properly into the client application due to the non ascii chars. I think I need the encoding="Windows-1252" or encoding="ISO-8859-1" |
Should that be "does parse properly", or "doesn't parse properly"? Is the problem just that the XML encoding declaration has the wrong value, or is there another problem with the endpoint parsing non-ASCII data? |
Hi rekarm01,
The xml does NOT parse properly into the client app. In fact, it "breaks" if you open it within a browser like IE or Mozilla. Seems to be because the encoding is wrong <?xml version="1.0" encoding="ibm-437_P100-1995"?>. It works fine if I maunually change the the encoding to <?xml version="1.0" encoding="windows-1252"?>.
The question now is how can I set the encoding the "windows-1252" either within the eQSL code, or on the XML1 layer in the message set (im using the MRM domain if relevant) or is there some other way that the broker needs to be instructed to auto generate this for me depending on some criteria?
Thx for all the assistance.
_________________
Applications Architect |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Sep 17, 2009 8:23 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| What have you put in OutputRoot.Properties.CodedCharSetId? |
|
| Back to top |
|
|
| Ramphart |
| Posted: Thu Sep 17, 2009 10:50 pm Post subject: |
|
|
Disciple
Joined: 21 Jul 2004
Posts: 150
Location: South Africa, JHB
|
| kimbert wrote: |
| What have you put in OutputRoot.Properties.CodedCharSetId? |
| Code: |
SET OutputRoot.Properties.CodedCharSetId = 1252;
SET OutputRoot.MQMD.CodedCharSetId = 1252; |
_________________
Applications Architect |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Fri Sep 18, 2009 11:56 pm Post subject: Re: Encoding - Non ASCII Chars - iSeries to Windows platform |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
Did you follow any of the recommendations given so far? If so, what happened?
| Ramphart wrote: |
| The xml does NOT parse properly into the client app. In fact, it "breaks" if you open it within a browser like IE or Mozilla. |
"breaks" is a bit vague. For future reference, please post any relevant error messages.
| Ramphart wrote: |
| Seems to be because the encoding is wrong <?xml version="1.0" encoding="ibm-437_P100-1995"?>. |
437 is an MS-DOS code page; unless your WMQ applications are running in DOS, ccsid=437 is usually a very poor choice for encoding non-ASCII character data, for a variety of reasons:- It isn't very interoperable with more commonly used character sets, (including Unicode). It contains line-drawing characters that are mostly unused outside of DOS, and to make room for them, it omits some other commonly used characters.
- The first 32 characters are ambiguous; depending on the context, they can either be interpreted as graphic characters, or as control characters. Moreover, different standards, (such as the WMQ/WMB's IBM CDRA, versus most Internet browser's IETF), define the control characters in a slightly different order. So characters such as '§' may not convert as expected.
- The MRM parser maps ccsid=437 to XML Encoding="ibm-437_P100-1995"; while this may be fine for WMB, it is not an IANA official name for this charset, so most browsers aren't likely to recognize it. Even if WMB used an official name, browsers aren't required to support this charset at all, and many don't. Just because it "breaks" in a browser doesn't mean that there's something wrong with the message.
It's a good idea to avoid converting to/from ccsid=437, or even using it at all, without a really good reason.
| Ramphart wrote: |
| It works fine if I manually change the the encoding to <?xml version="1.0" encoding="windows-1252"?>. |
Does "works fine" mean "doesn't throw an exception"? 'M¿BINDI N§' still looks a bit like gibberish. Is that what it's supposed to look like?
| Ramphart wrote: |
| The question now is how can I set the encoding the "windows-1252" |
Asked. Answered.- Disable channel conversion.
- Check the validity of the incoming message; ensure that the input ccsid matches the data
- If necessary, add an ESQL statement to convert the output message ("SET OutputRoot.Properties.CodedCharSetId = output ccsid;")
If the actual output message doesn't match the expected output message, add Trace nodes as needed, and post the results. If an Exception occurs, run a usertrace as needed, and post the relevant error messages. |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
