sijo0703
sijo0703

Reputation: 577

Using default CCSID for WebSphere MQ in Linux connected to client Application in Windows

I have two Applications A & B. Application A puts message in QMA which is a Linux queue manager with default CCSID 1208. The QMA sends message to QMB which is a Windows queue manager with default CCSID 437. Application B consumes messages from QMB. Everything is fine. Then I migrated the Windows queue manager QMB to a Linux platform and changed the CCSID as default 1208. The App B started getting issues related to data. Then I altered the QMB in Linux platform use CCSID as 437 and the App B did not see any issues with data after that.

I am an MQ admin and do not have much understanding of how CCSID defined in a MQ server really matter for a client application when there are no Data Conversion attributes enabled in the MQ server.

My understanding was the queue manager CCSID should be the default based on the platform used and never required to be altered.Help me to understand better?

Upvotes: 1

Views: 1377

Answers (1)

Morag Hughson
Morag Hughson

Reputation: 7609

You are correct that the CCSID defined on the MQ Server shouldn't really matter for an application (whether client or otherwise). This is because what an application should do is request its messages on the MQGET using MQGMO_CONVERT.

It sounds rather like the applications in your setup were relying upon the codepage of the message being correct and what they needed from the putter, and that they weren't using MQGMO_CONVERT.

MQGMO_CONVERT should always be used for applications even if - initially - it is not needed because the putter and getter use the same codepage. This is because, eventually that application will spread, or move, and then when you do need it you have to go back and change the application. There is no down-side to using MQGMO_CONVERT when it is not needed, it is just a no-op. But there is a downside to not using it when you do need it.

Upvotes: 3

Related Questions