| Author |
Message
|
| kals |
 Posted: Mon Feb 25, 2008 5:13 am Post subject: Setting up the CCSID value |
 |
|
Newbie
Joined: 22 Jan 2008
Posts: 4
|
Hi all,
Messages will be posted to Websphere MQ (Windows machine) by AS400 application and I have C# application to read the messages. CCSID value is 37 and Encoding value is 273 if the message posted by AS400 application. I tried to set the CCSID value as 1208 before getting the message in my C# application. But it is not setting up the new CCSID value (i.e. 1208), it is taking the original value(i.e. 37).
Other case: It is taking new CCSID value(i.e.1208) if I post the messages manually (this time CCSID value is 850 and Encoding is 546) instead of AS400 application.
Finally why I am setting the CCSID value as 1208 is: to avoid the Swedish characters conversion to some characters.
My questions are:
1. Why CCSID value is not getting set (if the messages posted through AS400 appln) in my C# application eventhough it is set if the messages posted manually?
2. Is there any other ways to avoid the Swedish characters conversion instead of setting up the CCSID value as 1208?
3. How to change the CCSID and Encoding values in Websphere MQ?
Thanks in adv
Rgds
Kals |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Mon Feb 25, 2008 6:27 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
This is not an MQ Everyplace question. 
This is a general MQ API question.
Did you MQGMO_CONVERT?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Feb 25, 2008 3:09 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
so moved
@kals
As to your plight:
assuming that your format is MQFMT_STRING
- If you set the CCSID to the "as qmgr value" (default) on the message (MQMD), the CCSID will be changed to 37 before the message is put to the queue.
- Did you check that there is no message / channel exit that would convert the CCSID of the message?
- Did you check that the channel does not have the convert option set?
- Do you set 1208 as CCSID on the MQMD of the getting application before the get?
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Feb 25, 2008 4:19 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
CCSID of a message is set in the Message Descriptor by the qmgr OR application program that mqputs the message. The default (and recommended) behavior is to let the qmgr set CCSID to its CCSID.
The recommended behavior of the getting application is to specify MQGMO_CONVERT, and drive application data conversion as part of the mqget. An alternative would be to specify CONVERT(YES) on the sender channel. Conversion would take place when the message is sent across the network.
| Quote: |
| I tried to set the CCSID value as 1208 before getting the message in my C# application. |
How? Did you change the qmgr CCSID attribute on the receiving qmgr. This does not change the CCSID of the inbound message.
_________________
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 |
|
|
| fjb_saper |
| Posted: Mon Feb 25, 2008 9:55 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| bruce2359 wrote: |
| CCSID of a message is set in the Message Descriptor by the qmgr OR application program that mqputs the message. The default (and recommended) behavior is to let the qmgr set CCSID to its CCSID. |
This may have adverse effects especially when it would imply a conversion from a multibyte char set to a single byte char set where not all chars are represented. Hence the possibility to specify the charset id on the message so that it does not get converted to the qmgr's ccsid.
| bruce2359 wrote: |
The recommended behavior of the getting application is to specify MQGMO_CONVERT, and drive application data conversion as part of the mqget. An alternative would be to specify CONVERT(YES) on the sender channel. Conversion would take place when the message is sent across the network.
| Quote: |
| I tried to set the CCSID value as 1208 before getting the message in my C# application. |
How? Did you change the qmgr CCSID attribute on the receiving qmgr. This does not change the CCSID of the inbound message. |
Nothing really changes the ccsid of the message. For the afore mentioned reason a channel conversion is often a nightmare to recover from and you do not want it. Worst case scenario: special characters get simply transformed into some unreadable graphical nonsense that you cannot recover from...
Now if you do not want the message in the receiving qmgr's ccsid (default on a get with convert) you need to specify the requested ccsid on the message descriptor before doing the get. Same caveats apply for multi-byte to single byte conversion and vice versa.
In JMS you specify the ccsid on the qcf/tcf... although I believe that by default it will not convert to the qmgr's ccsid, if it can avoid a conversion, JMS will take the message in UTF-8 or Unicode without needing a conversion to the qmgr's ccsid...
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Feb 26, 2008 4:50 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| fjb_saper wrote: |
| bruce2359 wrote: |
| CCSID of a message is set in the Message Descriptor by the qmgr OR application program that mqputs the message. The default (and recommended) behavior is to let the qmgr set CCSID to its CCSID. |
This may have adverse effects especially when it would imply a conversion from a multibyte char set to a single byte char set where not all chars are represented. Hence the possibility to specify the charset id on the message so that it does not get converted to the qmgr's ccsid.
|
There is no conversion on a MQPUT to be clear. If your code spits out a message in code page 437 and the QM is 500 and you ask for the default then all you have is a 437 message labeled as 500. At this point your app data is still fine sitting as 437. But the next app will try to convert it to its code page (whatever that is) as if it was 500 and then it all falls apart since those bytes only make sense as 437.
When you ask for the QM Default CCSID you are saying that my app code is running in the same CCSID as the QM is so lets label it as such, presuambly becasue both are running on the same server. IBM was smart enough to make MQ Clients smart enough to not get tripped up by this. If a 437 MQ Client connects to a 500 QM and ask for the default "QM" CCSID it will not get the message incorrectly lableled as 500. MQ Clients get their messages tagged with the local CCSID, not the QMs, when they ask for the default QM CCSID to be applied.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Feb 26, 2008 6:57 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Some fundamentals:
A message consists of the Message Descriptor and your application data. The programmer builds both of these to MQPUT to a queue. The programmer gets both of these at MQGET.
The Message Descriptor describes the application data - such things as persistence, priority, CCSID. Setting CCSID to some arbitrary code-page number does not magically convert your application data to that CCSID.
For application portability (and other best practices), the putting application should set (or let the qmgr set) the MD fields about the application data on the platform where the message is being created.
Thus, let the CCSID default to that of the qmgr the putting application is connected to. Then, let the getting application drive the conversion of application data if necessary on the getting platform.
Another choice - a non-best practice - would be for the programmer putting the message to manually convert each character in the application data to the CCSID of the getting application qmgrs CCSID, set the CCSID to that code-page, then mqput the message. The thought here would be to save the getting application the trouble of asking (GMO_CONVERT) for application data conversion. Is this what you are trying to accomplish?
There is a SupportPac white-paper on application data conversion. Please read this, along with whats in the MQ Application Programmers Guide and MQ Application Programmers Reference.
_________________
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 |
|
|
| fjb_saper |
| Posted: Tue Feb 26, 2008 9:07 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
OK to be clear lets look at following scenarios:
sending qmgr ccsid = 819
receiving qmgr ccsid = 500
message format = MQFMT_STRING
Message content from sending app is UTF-8 with special chars (multibyte)
Now in a normal manner the putting app (running on unix) sets the cssid as qmgr (819) which means translation of the data to 819 either by the app or the agent (java/JMS).
The data being translated to ccsid 819 has already lost the special chars... as you cannot map them from ccsid 1208 to ccsid 819....
If you set the ccsid 1208 on the message, the putting app is correctly identifying the content of the message, and the qmgr now has the correct information on the message.
The retrieving app (mainframe)will be able to do a get with convert with default values and gets the message returned in EBCDIC (ccsid 500)
If you need however to process the message as XML and Unicode (ccsid 1200) you can ask for the message with a ccsid 1200 in the MQMD. The message content will then be converted to ccsid 1200 before being served to the app.
I hope I understood all the information from the manuals and the link (hursley on MQ) correctly.
JMS is a little bit more complex as it allows you to specify a ccsid on the destination object.
The qmgr will translate the text message to that specified ccsid during the put operation.
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Feb 26, 2008 5:31 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| fjb_saper wrote: |
OK to be clear lets look at following scenarios:
sending qmgr ccsid = 819
receiving qmgr ccsid = 500
message format = MQFMT_STRING
Message content from sending app is UTF-8 with special chars (multibyte)
Now in a normal manner the putting app (running on unix) sets the cssid as qmgr (819) which means translation of the data to 819 either by the app or the agent (java/JMS).
|
What is going to translate the data to 819? MQ won't. Does JMS have some built in stuff to do this?
Bruce, when you replied you were agreeing with me right? My response wasn't as clear as yours and adding the MQ Client twist made it more complicated.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Feb 26, 2008 7:23 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Bruce, when you replied you were agreeing with me right? |
Of course. I thought some basics about the MD, the application data, and the relationship between them, needed to be covered.
_________________
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 |
|
|
| fjb_saper |
| Posted: Tue Feb 26, 2008 8:46 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| PeterPotkay wrote: |
| fjb_saper wrote: |
OK to be clear lets look at following scenarios:
sending qmgr ccsid = 819
receiving qmgr ccsid = 500
message format = MQFMT_STRING
Message content from sending app is UTF-8 with special chars (multibyte)
Now in a normal manner the putting app (running on unix) sets the cssid as qmgr (819) which means translation of the data to 819 either by the app or the agent (java/JMS).
|
What is going to translate the data to 819? MQ won't. Does JMS have some built in stuff to do this?
Bruce, when you replied you were agreeing with me right? My response wasn't as clear as yours and adding the MQ Client twist made it more complicated. |
If you want a consistent content that is readable at the other end the data needs to be in the CCSID of the message. So if the app does not translate it, you will have "1208" data in a message labeled "819". This is still tame.
Now imagine having "1208" data in a text message labeled "500" and doing a get with convert on a windows platform (nightmare).
And yes as stated with setting the CCSID on the destination JMS does some strange things with conversion...
My point is: the default is great but is not always the recommended path.
Especially when the message content is in a multi byte char set and the qmgr is in a single byte char set and the conversion between the 2 is not complete....(mangled graphic chars etc...) and when the application does not handle data in the platform's native char set....but uses a different char set like UTF-8 ...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
