If I set CONVERT(YES) on a clusrcvr channel to force all clussdr channels for the cluster to convert data on msgs sent to the receiving Qmgr, then will this cause a problem for an app that converts on the mqget? The problem we have is that some apps on the receiving Qmgr convert and others don't. I'm thinking it is safer to define a separate cluster for all queues consumed by apps that don't convert on the mqget. Even if I define a second clusrcvr on the receiving Qmgr with CONVERT(YES), I can't see a way of forcing messages put to a specific queue to be sent by a specific clussdr channel.

The message will get converted only once, assuming the code is using the same CCSID/Encoding settings as the QM it is connected to.  However, if the code uses a different CCSID/Encoding, then it could be converted twice -- once when the QM receives it and again when the code does the MQGET.

In addition to hat Tony said, keep in mind that using channel conversion means you cannot use MQAMS or any other encryption, cannot send binary-encoded messages, etc. 

It's possible to write exits to handle any message types not converted in the channel but as Tony noted the app getting the message might not be the same CCSID as the destination QMgr.  That requires the exit to work first in the channel and then again during the application GET.

Channel conversion is best used in the case of a point-to-point channel with limited, well-known types of messages.  It's a narrow solution to a narrow problem.  To enable it on a cluster is about the polar opposite of its intended use.  Not that it's impossible, just rarely done and requires significant discipline to vet any and all applications to ensure they will not send unconvertible messages and bring entire nodes to a halt, or worse (if the repositories are not on dedicated QMgrs) the whole cluster.  You did put your repositories on dedicated QMgrs, yes?

Thanks a lot Tony and T.Rob. Very useful replies. I'll define a separate cluster with conversion on the channels and control the use of it, or else use p2p channels if I decide to play it really safe.

And yes, our FRs are on separate Qmgrs (and servers)!

Best practice in MQ design is not to use CONVERT(YES) on any channels. I have found this on legacy MQ networks as a Band-Aid fix for applications that consume string format messages from different platforms (= different CCSID) and are too lazy to specify the MQGMO_CONVERT option on MQGET, or are too lazy to deal with character translation issues.

Glenn Baddeley

Coles Supermarkets Australia Pty Ltd