Client channel definition tables, or CCDTs for short, are convenient ways for the client to read channel definitions. A CCDT file contains all CLNTCONN channel definitions of a particular queue manager.
So, how does a client using a CCDT know which channel to use ?
The answer lies in the way the CCDT itself is written by the queue manager. The queue manager writes channel definitions on to the CCDT file in alphabetical order. So, the client picks up the first channel whose QMNAME parameter matches with the queue manager name parameter of the
MQCONNX) call. In the event there are more than one channel definitions that have matching QMNAME parameters, simply the first one encountered is used. This serves as an extremely useful mechanism to initiate fail-over.
Click here to understand how a queue manager interprets a CCDT
Arriving to the focus of this post - how does one deliberately make use of a channel that is lower down in the alphabetical list of channel names ?
Wildcards - are the answer. The queue manager name passed to MQCONN(X) can have the wildcard character *, in which case, any channel with a matching QMNAME parameter is picked up.
The twist in the story, however, lies in the fact that neither the name of the queue manager passed to MQCONN(X) nor the QMNAME parameter need to have the actual name of the queue manager ! If your head is reeling at this moment, take time to peruse through this example.
Our queue manager, say
QM1 has 2 CLNTCONN channels viz.
BETA.CLNTCONN. The idea is to make use of
BETA.CLNTCONN to a dummy queue manager name, say,
ALTER CHL(BETA.CLNTCONN) CHLTYPE(CLNTCONN) QMNAME(NOQM)
Allow the client to do an MQCONN(X) in the fashion MQCONN("NO*", . . . )
and voila !
BETA.SVRCONN is being used.