Refer to Using the client channel definition table with the WebSphere MQ classes for Java in the Infocenter. I contacted the V7.0 Infocenter since you mentioned that the version you are using, but it works in later versions.
Before multi-instance QMgr and the corresponding CONNAME attributes from multiple instances were used in the channel definitions, the client channel or CCDT definition table was specified, as it is more widely known. CCDT contains CLNTCONN definitions for any number of channels for one or more QMgr. When multiple entries have the same value in the QMName field, they are treated as a group. (Note that the QMName in CCDT does not match not to match the actual QMgr name. This will force you to use unidentified QMgr names, which is not good practice. It is just an index in CCDT to identify channel groups.)
To better understand CCDT, read the sections on Connecting WebSphere MQ client applications to queue managers in the Infocenter and, in particular, examples Role of the client channel definition table and MQCONN call examples. (Get access to them from the Table of Contents on the left. In the upper right corner of the frame there is a button that will smooth the table of contents of any page you are on if you are lost.)
One of the “received” with CCDT is that each channel name inside it must be unique. This is different from the Multi-Instance CONNAME, which searches for the same channel on different IP addresses. This is because the CCDT file is supported using the MQSC commands on QMgr. In namespaces managed by the queue manager, all object names must be unique. When defining channels in QMgr, each channel must have a unique name. In the case of CCDT, entries are determined using the CLNTCONN channels. Although they point to SVRCONN channels defined on other QMgr, since all CLNTCONN channels are defined in the same namespace, they must be unique.
To illustrate this, consider creating an application called PAYROLL. You can create channel names based on the application name in combination with the name QMgr. This leads to a channel that describes a from → to a relation reading from left to right. For example, to determine the CCDT for three QMgrs, you would have:
* On any QMgr DEF CHL(PAYROLL.QMGR1) CHLTYPE(CLNTCONN) QMNAME(PAY) CONNAME("qm1host(1414)") DEF CHL(PAYROLL.QMGR2) CHLTYPE(CLNTCONN) QMNAME(PAY) CONNAME("qm2host(2414)") DEF CHL(PAYROLL.QMGR3) CHLTYPE(CLNTCONN) QMNAME(PAY) CONNAME("qm3host(3414)") *On QMgr1 DEF CHL(PAYROLL.QMGR1) CHLTYPE(SVRCONN) *On QMgr2 DEF CHL(PAYROLL.QMGR2) CHLTYPE(SVRCONN) *On QMgr3 DEF CHL(PAYROLL.QMGR3) CHLTYPE(SVRCONN)
The application then defines the name QMgr as *PAY , and the WMQ client code selects among the three entries. Additional options are available for weighting records and the order of repetitions that you will see in the documents.
Note: the above examples are reduced to the main elements illustrating the concept. SVRCONN entries for implementing production will include MCAUSER and / or channel output, possibly SSL packets and, on V7.1 or later, some CHLAUTH rules.