| Author |
Message
|
| Jeff.VT |
 Posted: Wed Dec 09, 2020 7:48 am Post subject: CCSID.tbl Default Conversion - Can it break things? |
 |
|
Acolyte
Joined: 02 Mar 2017
Posts: 71
|
I have a queue manager that connects to ~30 different third parties in various countries.
I'm trying to connect to a new 3rd party and I'm getting this error:
IBM MQ is unable to convert string data tagged in CCSID 437 to data in CCSID 862.
CCSID 862 is Hebrew and I'm connecting to an Israeli connection, so that makes sense.
I've encountered this one other time, connecting to a Test China connection. For silly reasons, I had to connect to that via a more-or-less stand-alone queue manager where the Chinese connection was the only connection other than to internal queue managers.
The fix I found was the enable the Default Conversion lines in the CCSID.tbl file. That seemed to work just fine.
---------------
But now, the situation is different. I obviously don't want to disrupt the 50 connections into and out of this Queue Manager by making changes to this conversion table that I don't fully understand.
I would just enable the default conversion immediately, but then I'm forced to ask - why is it disabled out of the box? What is this going to do to my other connections? if it did impact my other connections, what would that impact look like? Would there be errors? or just general instability?
Or am I just being paranoid as usual? |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Wed Dec 09, 2020 8:24 am Post subject: Re: CCSID.tbl Default Conversion - Can it break things? |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Jeff.VT wrote: |
I would just enable the default conversion immediately, but then I'm forced to ask - why is it disabled out of the box? What is this going to do to my other connections? if it did impact my other connections, what would that impact look like? Would there be errors? or just general instability?
Or am I just being paranoid as usual? |
I'm not a trained therapist, so I can't comment on paranoia.
Conversion of the data component of your messages is an option. You can specify on the sender channel CONVERT(YES) to convert at the Sender end before the message is pressed onto the network, OR you can specify in the consumer app at the Receiver end of the channel with MQGMO_CONVERT.
Both presume compatible CCSID tables at both ends of the channel.
_________________
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 |
|
|
| Jeff.VT |
| Posted: Wed Dec 09, 2020 8:29 am Post subject: |
|
|
Acolyte
Joined: 02 Mar 2017
Posts: 71
|
| Quote: |
| Both presume compatible CCSID tables at both ends of the channel. |
I wouldn't assume that. I'd guess that's precisely our issue here is that we don't have compatible CCSID tables.
This is long before the content of messages are being passed. The channel fails to connect at all. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Dec 09, 2020 8:36 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
What command did you issue? PING CHL or START CHL?
What did PING CHL on a non-started Sender channel tell 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 |
|
|
| Jeff.VT |
| Posted: Wed Dec 09, 2020 8:42 am Post subject: |
|
|
Acolyte
Joined: 02 Mar 2017
Posts: 71
|
Ping Channel got the same error:
Conversion not supported.
IBM MQ is unable to convert string data tagged in CCSID 437 to data in CCSID 862.
Check the IBM MQ Application Programming Reference Appendix and the appropriate National Language Support publications to see if the CCSIDs are supported by your system. |
|
| Back to top |
|
|
| Jeff.VT |
| Posted: Wed Dec 09, 2020 8:49 am Post subject: |
|
|
Acolyte
Joined: 02 Mar 2017
Posts: 71
|
Reading through the ccsid.tbl, I was considering making this change:
| Code: |
# CCSID Base CodePage CodePage Type Enc ACRI Codeset
# CCSID DBCS SBCS name
# ----- ----- -------- -------- ---- ---- ----- -------
...
# Hebrew
916 916 0 916 1 3 0 ISO8859-8
1255 1255 0 1255 1 2 0 IBM-1255
5351 5351 0 5351 1 2 0 IBM-5351
# 862 862 0 862 1 2 0 IBM-860
862 862 0 850 1 2 0 IBM-860
867 867 0 867 1 2 0 IBM-867
424 424 0 424 1 1 0 IBM-424
4520 424 0 424 1 1 0 IBM-424
12712 12712 0 12712 1 1 0 IBM-12712
...
#default 0 500 1 1 0
#default 0 850 1 2 0
|
So taking 862, and instead of using codePage 862 for it, using 850... Because from what I'm reading here, that's pretty much would un-remarking the default line would do...
It "works" on two local queue managers on my laptop, when one is set to CCSID 862. But the 862 queue manager isn't running on a server with only the Hebrew language pack on it. So I don't know precisely what it would do.
Also, the two queue managers are technically sharing a CCSID.tbl file.
But I think if pressed, I'd rather just un-remark the default lines. If it works the way the file says:
| Quote: |
# DEFAULT DATA CONVERSION
#
# You can define default conversion CCSIDs which will be used to convert
# between ASCII or similar and EBCDIC CCSIDs if no conversion is supported
# between two CCSIDs. If enabled, the default conversion is used for
# transmission and message headers and can also be enabled in user data
# conversion. For more information see the System Administration book. |
*IF no conversion is supported* - then I would be fine with that. Presuming it wouldn't cause a problem with my other channels.
I really hate things like this. It would absolutely affect all my channels, and there's no way to know how it would affect them until I do it. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Dec 09, 2020 11:54 am Post subject: Re: CCSID.tbl Default Conversion - Can it break things? |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Jeff.VT wrote: |
I'm trying to connect to a new 3rd party and I'm getting this error:
IBM MQ is unable to convert string data tagged in CCSID 437 to data in CCSID 862. |
Please post the complete error message from the mq logs - including the error message numbers.
Does the affected channel go into RUNNING state? Or does it fail completely?
_________________
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 |
|
|
| Jeff.VT |
| Posted: Wed Dec 09, 2020 2:02 pm Post subject: |
|
|
Acolyte
Joined: 02 Mar 2017
Posts: 71
|
It does not go into Running state.
------------
12/8/2020 15:43:41 - Process(16004.1) User(_____) Program(runmqchl.exe)
Host(_____) Installation(_____)
VRMF(9.0.5.0) QMgr(_____)
Time(2020-12-08T15:43:41.078Z)
ArithInsert1(437) ArithInsert2(862)
AMQ6047E: Conversion not supported.
EXPLANATION:
IBM MQ is unable to convert string data tagged in CCSID 437 to data in CCSID
862.
ACTION:
Check the IBM MQ Application Programming Reference Appendix and the appropriate
National Language Support publications to see if the CCSIDs are supported by
your system. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Wed Dec 09, 2020 2:33 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
437 is a really old code page for IBM PC ASCII that includes extended codes for various graphical and special characters that were used in PC-DOS and PC graphics cards. It was not designed for international use.
If your apps don't use any of these extended codes, you should consider changing to an ASCII based code page that is more widely supported for conversion to other code pages, particularly ISO European. eg. 850, 858.
1208 UTF-8 is fairly popular for Windows MQ qmgrs.
Ref. https://en.wikipedia.org/wiki/Code_page
_________________
Glenn |
|
| Back to top |
|
|
| Jeff.VT |
| Posted: Wed Dec 09, 2020 2:40 pm Post subject: |
|
|
Acolyte
Joined: 02 Mar 2017
Posts: 71
|
| Quote: |
| 437 is a really old code page for IBM PC ASCII that includes extended codes for various graphical and special characters that were used in PC-DOS and PC graphics cards. It was not designed for international use. |
Interesting. I just used whatever default IBM gave me when I created the Queue Manager. Never had a problem until recently. We connect to a lot of governments and other companies and always been good.
I'm certainly open to a more ubiquitous code page. |
|
| Back to top |
|
|
| Jeff.VT |
| Posted: Tue Dec 15, 2020 12:19 pm Post subject: |
|
|
Acolyte
Joined: 02 Mar 2017
Posts: 71
|
Quick after-note since I hate when people don't post their answers. Unfortunately there's no real answer here.
The guys in Israel decided to change their CCSID to a more generic one to avoid this problem in the future - their queue manager is brand new and has no existing connections, so that works out better for me.
No answer to the IBM ticket I put in, though it was a very low priority.
Intuitively I'd guess making this change would be just fine. A bit anti-climatic. But as I said below, I get paid not to end up on the news, and there's a lot of 'end up on the news' kinda stuff going through this queue manager I'd rather not mess with if possible. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Tue Dec 15, 2020 2:35 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
When a MQ queue manager is created, it will choose the qmgr ccsid based on the OS language. This may or may not be appropriate. It should be reviewed and possibly changed before the qmgr is used for app messaging.
eg. z/OS qmgrs may be 500, but this can cause issues with z/OS apps that use 37 internally. A few special characters are different, which can play havoc if MQ does message data conversion.
_________________
Glenn |
|
| Back to top |
|
|
|
|
