| Author |
Message
|
| zbyszanna |
 Posted: Mon Dec 29, 2014 4:37 am Post subject: Windows 437 -> AIX 912 conversion |
 |
|
Novice
Joined: 03 Feb 2012
Posts: 23
|
*******There was an answear provided by me later in this thread which was invalid. Read the whole thread before jumping to any conclusions.********
Hello.
Hello!
I have a qmgr on Windows (let's call it WQ) and an application (WA) connected to this qmgr sending messages with CCSID 437. This qmgr connects to another qmgr on AIX (AQ) and there is another application (AA) connected to AQ which receives messages with MQGMO_CONVERT option set (the receiver makes it good approach). The error I receive is 2119 (MQRC_NOT_CONVERTED) and AQ logs show:
"AMQ6047: Conversion not supported.
EXPLANATION:
WebSphere MQ is unable to convert string data tagged in CCSID 437 to data in
CCSID 912."
Changing WA is not an option here.
The solutions I can think of are:
1. MQCONVERT(YES) on sending channel (which is considered not a best practice, although this channel is a dedicated one for this applications).
2. Install some conversion tables on the AIX machine (and then on Windows I believe as the AA will send messages to WA also).
My questions are:
1. Is this conversion at all possible? How to find it out?
2. iconv -l | grep 912 does not return any results (iconv -l | grep IBM-437 is ok), does it mean there is no code page for this CCSID installed? Or does the MQ use the ISO8859-2 code page for this CCSID?
I didn't find the answer through the forum's search facility.
Best regards
Z.
Last edited by zbyszanna on Wed Feb 18, 2015 3:32 am; edited 3 times in total |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Mon Dec 29, 2014 7:07 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
|
| Back to top |
|
|
| zbyszanna |
| Posted: Mon Dec 29, 2014 7:23 am Post subject: |
|
|
Novice
Joined: 03 Feb 2012
Posts: 23
|
Thank you Peter for your response, I'm reading those links at the moment.
We send SWIFT messages and they don't have anything other than standard ASCII characters, so it shouldn't be a problem. Also this is an of the shelf product and we have no option of changing it whatsoever. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Dec 29, 2014 7:30 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
So this is an idea best vetted out by someone who knows what they are talking about, but if all you are sending is plain ASCII, the standard set of characters that is the same in all ASCII code pages (A-Z, 0-9, a-z, things like that), then you may have to just avoid converting at all to get around not being able to change that 437.
Send the messages with MQMD Format set to none, and the receiving app will not ask MQ to convert (and fail) even if they still code an MQGMO Convert option on their MQGET.
MQ is not going to allow 437 to 912 since it knows there are many characters that just don't work in that conversion. It can't know you are only dealing with the "safe" ones. So if you are, and you can't change the CCSIDs, then skip the conversion altogether since its not needed. But 2 years from now when someone sends Cześć and you are long gone and the thing blows up, you are right back where you started - you can't use 437 for those languages.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| zbyszanna |
| Posted: Mon Dec 29, 2014 7:47 am Post subject: |
|
|
Novice
Joined: 03 Feb 2012
Posts: 23
|
I've seen the first link before and I wonder, how they solved the issue, because they somehow managed to start the channel 437<->912 (maybe they just did disable CONVERT on the channel and didn't convert on the application side).
As for the conversion, I've read a white paper about conversion title "Data Conversion Under WebSphere MQ" and they wrote this:
"Conversion tables supplied by WebSphere MQ tend provide round-trip integrity, i.e. when a pieceof data is converted from one CCSID to another and back again, the original data is recovered. Round-trip tables assign a different mapping to every character. If a character only exists in the from CCSIDand not in the to CCSID, an arbitrary but unique mapping is assigned to ensure that the conversionprocess can round trip."
So it suggest that such conversion table (albeit not complete by any means) could exist.
Best regards
Z. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Dec 29, 2014 8:07 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| zbyszanna wrote: |
| So it suggest that such conversion table (albeit not complete by any means) could exist. |
Many code page conversion tables are supplied with the product. Some (many) are not.
Refer to the MQ Application Programming Reference (or equivalent) for "code page conversion" for the list (table) of code-pages (CCSIDs), and to which other CCSIDS translations are possible and supported.
In your case, there is no table for 437 -> 912.
_________________
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 |
|
|
| PeterPotkay |
| Posted: Mon Dec 29, 2014 8:24 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| zbyszanna wrote: |
As for the conversion, I've read a white paper about conversion title "Data Conversion Under WebSphere MQ" and they wrote this:
"Conversion tables supplied by WebSphere MQ tend provide round-trip integrity, i.e. when a pieceof data is converted from one CCSID to another and back again, the original data is recovered. Round-trip tables assign a different mapping to every character. If a character only exists in the from CCSIDand not in the to CCSID, an arbitrary but unique mapping is assigned to ensure that the conversionprocess can round trip."
|
From here:
http://www-01.ibm.com/support/docview.wss?uid=swg27005729&aid=1
All that means is is if you convert from known to unknown to known in MQ, you end up with the same starting value. It does not mean the unknown value will make any sense to the intermediate app. It will likely be interpreted as garbage, a nonsensical character. But a special piece of garbage to MQ so that when MQ converts it back again to the source CCSID, you end up with the original character.
If you continue reading on in that doc, it leads you to believe you will have to code your own special table or conversion routine to identify this nonsensical characters that mean nothing if described as 437 but mean something to you because you know 437 is wrong.
If you stay in the basic ASCII character codes from 32-127 (A-Z, 0-9, you know, the standard basic ones), then it will likely work no mater what happens going between any ASCII systems. Its just that it will choke as soon as you start sending characters outside of that range and try to describe them with a CCSID value that does not cover that character (like 437 doesn't cover the special characters in the Easter European languages)
You will either have to avoid the issue altogether (temporarily?) and stick with the basic ASCII characters so you can avoid conversion attempts, or code your own conversion routine / table, or change the CCSID on one of the systems to a value that works with the other.
Or use CCSID 1208 which is Uni-Code which covers all the characters you need and should be able to convert between either of your 2 CCSIDs. Can the sending and / or receiving app deal with Uni Code?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| zbyszanna |
| Posted: Fri Jan 02, 2015 4:31 am Post subject: |
|
|
Novice
Joined: 03 Feb 2012
Posts: 23
|
Thank you once again for your answers.
It looks like we found a working solution. What we did was two things:
1. We set CONVERT(YES) on the dedicated channels and it seems to work and now we receive 912 instead of 437 (we already had IBM-437 code page installed - iconv -l | grep IBM-437).
2. We installed additional converters for iconv for AIX:
bok.iconv.el_GR
bok.iconv.iso2
and it seems the 437 are now successfully converted to 912 by the AIX we connect to with the client.
Of course one is enough, and probably the el_GR is not needed. We are still testing this. If anything happens, I will update the thread. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jan 02, 2015 7:14 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jan 02, 2015 7:20 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| PeterPotkay wrote: |
| I don't understand how it could work and give you expected results. |
I concur. Not receiving the "AMQ6047: Conversion not supported." error does NOT mean that your data was converted successfully and correctly.
_________________
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 |
|
|
| zbyszanna |
| Posted: Wed Feb 18, 2015 3:30 am Post subject: |
|
|
Novice
Joined: 03 Feb 2012
Posts: 23
|
Well it doesn't work after all. It turns out the testing environment was unstable and all the previous tests (that showed that approach with conversion on the channel works) that client performed with their external vendor were run on the environment that was completely different from what it should have been (there was an alternative application sending 1208 instead) and so all the test results we can throw out of the window. After recreating the environment on my local machine it turns out it just doesn't work (which is consistent with the results we received at the very beginning).
Sending message in 437 with CONVERT(YES) shuts down the channel with 2119 (MQRC_NOT_CONVERTED) and not converting and converting on the final receiving application gives 2119 during MQGET (installing additional iconv conversion tables does nothing).
Final decision is to disable conversion (both on the channel and in receiving application) and take care of 437 directly.
Thank you for your help. |
|
| Back to top |
|
|
| zbyszanna |
| Posted: Wed Feb 18, 2015 3:43 am Post subject: |
|
|
Novice
Joined: 03 Feb 2012
Posts: 23
|
| bruce2359 wrote: |
| PeterPotkay wrote: |
| I don't understand how it could work and give you expected results. |
I concur. Not receiving the "AMQ6047: Conversion not supported." error does NOT mean that your data was converted successfully and correctly. |
Yes, I know that. We fully understand the risks. In this particular case there should be no problem though. The very format of sent messages excludes possibility of sending anything else than ASCII characters. |
|
| Back to top |
|
|
|
|
