| Author |
Message
|
| tony_f |
 Posted: Mon Nov 19, 2012 3:31 am Post subject: Problem with Polish character set in messages from iSeries |
 |
|
Novice
Joined: 30 Sep 2011
Posts: 19
|
Hi
We have an iSeries application that writes MQ messages that are processed via Message Broker 7 into Siebel. It is now required that it sends data with Polish characters (possible other character sets in future) and they are not being sent through correctly.
The CCSID and encoding of the queue manager on the iSeries is 37 and 273 and on the target broker it's 819 and 273. The channel is set to convert message.
If the channel was set to convert no and the encoding of the output message in the ESQL was changed like this :-
SET OutputRoot.Properties.CodedCharSetId='1208';
SET OutputRoot.Properties.Encoding='546';
Would that allow the Polish characters to be passed through correctly? |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Nov 19, 2012 3:40 am Post subject: Re: Problem with Polish character set in messages from iSeri |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| tony_f wrote: |
| Would that allow the Polish characters to be passed through correctly? |
I don't know. All that would do is have the output from WMB written in code page 1208. If, as the subject line indicates, the messages are coming from iSeries then this would allow Polish characters to pass if:
- code page 37 allows Polish characters
- the consuming application can either consume 1208 or can convert that into an appropriate code page for Polish
As I say above, I don't know the Polish code pages. A Polish poster will be along in a moment. Remember that internally WMB uses double byte Unicode so code page is irrelevant.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Nov 19, 2012 4:37 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Start at the transmission queue.
If the messages produced by the application sitting on the transmission queue contain characters that are not legal CCSID 37 characters then nothing you can do downstream will fix it, unless the message says that the codepage of the message is something other than 37.
Conversion on the channel when sending to Broker is typically unnecessary. but again, if the messages are mislabelled before the channel gets them, then it's all bad text from there. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Nov 19, 2012 4:50 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Don't use conversion on the channel. Create a channel without conversion for the WMB messages. CCSDI 819 may not cover all the characters you need 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Mon Nov 19, 2012 5:15 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Go to the iSeries application developers and find out what CCSID they are using for the messages that contain Polish data. When they give you a blank look, then you can be fairly sure that they are using the QMGR default CCSID.
Get them to change the message CCSID to something that can handle Eastern European characters correctly. you may need to include the Euro Symbol support as well.
CCSID 1208 is the ideal solution but one of the ISO-8859-x series may work just as well. Then the data is written in a way that can be understood by the broker. If not is it a case of GIGO.
As has been said, you will have to remove any channel conversions that may be in place between the queue manager.
If the message is sent incorrectly then there is little that the receiver can do about it.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| tony_f |
| Posted: Mon Nov 19, 2012 5:22 am Post subject: |
|
|
Novice
Joined: 30 Sep 2011
Posts: 19
|
Thanks for the quick responses 
So, if we switch the conversion off on the channel and write the message from the iSeries with a codepage of 870 (I believe that's Polish) then that should do the trick? |
|
| Back to top |
|
|
| kimbert |
| Posted: Mon Nov 19, 2012 5:25 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
I agree with this:
| Quote: |
Get them to change the message CCSID to something that can handle Eastern European characters correctly. you may need to include the Euro Symbol support as well.
CCSID 1208 is the ideal solution but one of the ISO-8859-x series may work just as well. Then the data is written in a way that can be understood by the broker. If not is it a case of GIGO. |
...but I would put it even more strongly. UTF-8 ( 1208 ) is the ideal choice. Don't accept anything else unless they give a very good reason. |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Tue Nov 20, 2012 12:49 am Post subject: Re: Problem with Polish character set in messages from iSeri |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| tony_f wrote: |
| So, if we switch the conversion off on the channel and write the message from the iSeries with a codepage of 870 (I believe that's Polish) then that should do the trick? |
ccsid=870 (EBCDIC-base) and ccsid=912 (ASCII-based) both use the ISO 8859-2 character set, which contains many (but not all) Polish characters.
ISO 8859-16 might be a better choice, but there don't seem to be any supported ccsids for that.
Unicode, (as kimbert strongly suggests), is the best choice.
And again, it's the sender (iSeries) that needs to specify a proper ccsid when writing the message (before MQPUT). The receiver (broker) need not specify a ccsid or conversion upon MQGET. Unless the broker needs to convert the message to some other ccsid upon output, it doesn't need to specify a ccsid at all. |
|
| Back to top |
|
|
|
|
