| Author |
Message
|
| MQEnthu |
 Posted: Mon Feb 10, 2014 10:53 pm Post subject: CCSID of QMGR and message |
 |
|
Partisan
Joined: 06 Oct 2008
Posts: 329
Location: India
|
Hi All,
There is a CCSID property set at queue manager level. I wanted some clarification around this.
If application puts a message with non-zero CCSID then the message will not get the Queue manager CCSID. Only if the
If an application puts a message with "0" or "MQCCSI_Q_MGR", message gets assigned/converted to the queue manager CCSID. So QMGR CCSID, comes into picture only if the application chooses to use QMGR CCSID. Is my understanding correct? Please confirm.
Application puts message by setting CCSID= 0/MQCCSI_Q_MGR into a queue (remote queue definition) on queue manager whose CCSID is set to 939, message gets assigned/converted to 939 CCSID. Remote queue definition is pointing to a queue on queue manager whose CCSID is set to 819. When message reaches the destination queue, message does not get converted to 819. AFAIK, only reading application can set the desired CCSID and convert it with convert options in this case.
Wanted to know if there is any property at queue manager that can convert the message when it arrives at destination queue to 819.
Thank you in anticipation
_________________
-----------------------------------------------
It is good to remember the past,
but don't let past capture your future |
|
| Back to top |
|
 |
| zpat |
| Posted: Mon Feb 10, 2014 11:10 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
MQ does not convert messages unless you ask it to.
It is the job of the recipient application to request conversion on the MQGET with MQGMO_CONVERT.
It is a bad practice to force conversion on a sender channel by setting the convert option to yes, but you can also do this.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| MQEnthu |
| Posted: Tue Feb 11, 2014 12:36 am Post subject: |
|
|
Partisan
Joined: 06 Oct 2008
Posts: 329
Location: India
|
Thank you.
So application can put any Character set message (by setting proper CCSID in MQMD/RFH2 header) to queue on queue manager. Or the character set should be supported by queue manager?
_________________
-----------------------------------------------
It is good to remember the past,
but don't let past capture your future |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Feb 11, 2014 12:57 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
First of all MQ does not generate message data for you, it just takes what you supply and it does not change it (on the MQPUT).
You need to set the CCSID to match the actual data in your message since MQPUT will not convert it.
In order for MQGET with MQGMO_CONVERT to work, the codepage must match the actual data (i.e. be correctly described) and the conversion must be possible - this means the two codepages (original and target) must be supported for the conversion between them.
The supported conversions are documented in the infocenter. The same applies to conversion by the sender channel (if the option is set).
If you want to handle the conversion in your own code, then it's up to your code to support the codepages required.
Keep an eye on Dead Letter Queues if doing the conversion on channels since messages that can't be converted will end up on there.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| MQEnthu |
| Posted: Tue Feb 11, 2014 1:02 am Post subject: |
|
|
Partisan
Joined: 06 Oct 2008
Posts: 329
Location: India
|
Thank you for explanation.
| Quote: |
First of all MQ does not generate message data for you, it just takes what you supply and it does not change it (on the MQPUT).
You need to set the CCSID to match the actual data in your message since MQPUT will not convert it. |
So if applications choose to put message with CCSID=0 or MQCCSI_Q_MGR, then the application should make sure that the data in the message message matches the queue manager CCSID. So that the message gets assigned the correct CCSID.
_________________
-----------------------------------------------
It is good to remember the past,
but don't let past capture your future |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Feb 11, 2014 1:18 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
Correct.
Websphere Message Broker MQOutput node is a different case, because the broker product will prepare the message in the desired codepage before the MQPUT happens.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| MQEnthu |
| Posted: Tue Feb 11, 2014 1:27 am Post subject: |
|
|
Partisan
Joined: 06 Oct 2008
Posts: 329
Location: India
|
Thanks a lot:) 
| Quote: |
| Websphere Message Broker MQOutput node is a different case, because the broker product will prepare the message in the desired codepage before the MQPUT happens. |
 Yes, I have seen this. We can set the CCSID in code before MQ OUTPUT node. May be we can say it as application (WMB) converts before the MQPUT call.
_________________
-----------------------------------------------
It is good to remember the past,
but don't let past capture your future |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Feb 11, 2014 5:23 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
| MQEnthu wrote: |
Thank you for explanation.
| Quote: |
First of all MQ does not generate message data for you, it just takes what you supply and it does not change it (on the MQPUT).
You need to set the CCSID to match the actual data in your message since MQPUT will not convert it. |
So if applications choose to put message with CCSID=0 or MQCCSI_Q_MGR, then the application should make sure that the data in the message message matches the queue manager CCSID. So that the message gets assigned the correct CCSID. |
But don't forget that for MQ Clients, the MQCCSI_Q_MGR value means the CCSID of the platform the MQ Client is executing on, NOT the CCSID of the Queue Manager on the other server.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Feb 11, 2014 5:44 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| MQEnthu wrote: |
| May be we can say it as application (WMB) converts before the MQPUT call. |
Yes. In the same way any application assembles data for a put, WMB does the same. As a party piece it can assemble the data into a dynamically set CCSID from it's native code page (UTF-16).
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Feb 11, 2014 8:46 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20697
Location: LI,NY
|
| zpat wrote: |
First of all MQ does not generate message data for you, it just takes what you supply and it does not change it (on the MQPUT).
|
Generally true, but for some obscure exception in JMS when you specify a different CCSID for the JMSDestination. The put then translates the text message to the CCSID specified on the JNDI Setup for the destination(Queue). 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Feb 11, 2014 1:37 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
JMS is a law unto itself. I try to keep well away from JNDI 
Even worse with Spring, as you have to untangle what Spring is doing to JMS, then what JMS is doing to MQ.
Then you have to allow for IBM changing their mind about how JMS/MQ works in different versions and even down to fixpack level (and sometimes changing it back to how it was before!).
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
|
|
