How does the client connect table work? 2

[pajamas]

Can someone please explain, in detail, how the client connect table (amqclchl.tab) works? A client connect table was created for each of 7 MQ servers (NT 4.0) deployed to various offices. The MQ client is installed on each user PC. The client connect table for each office lives on a local drive in that office's network and all users in an office use the same client connect table. For failover purposes, the primary connection is to the 'home' server and the secondary connection is to another MQ server in a different location.
I am not sure how/when/why the failover takes place..I only know that it does. But I would like to understand how it works.
Thanks.

 

[GFC]

The AMQCLCHL.TAB file is created/amended when properties of a CLNTCONN are defined/altered. This file is required for the client to connect to the QMgr. The SVRCONN entries are held on the corresponding (target) QMgr.

When the client application issues MQCONN, the QMgrName in the connect request is compared with the QMgrName property in each CLNTCONN definition in AMQCLCHL.TAB until a match is found.

If no match is found MQRC_QMGR_NOT_AVAILABLE (2059) is
returned.

If a match is found a connection attempt is made. If the
QMgr is not available, the search of AMQCLCHL.TAB resumes.

During the connection attempt MQ checks that the executing
QMgrName matches the QMgrname requested. If not,
MQRC_QMGR_NOT_AVAILABLE (2059) is returned.

This check by MQ can be avoided by prefixing the QMgrname
in the MQCONN with an asterisk ('*'). This enables the
application to connect to the first available of multiple
QMgrs.

Example:

AMQCLCHL.TAB has two CLNTCONN entries, one executing
on QMGR1, the second on QMGR2...

MAIN.CLIENT.CONN QMGRNAME(QMGR1)
CONNAME('100.200.300.400')

BACKUP.CLIENT.CONN QMGRNAME(QMGR1)
CONNAME('100.200.300.401')

Application executes MQCONN to QMGR1 - this can only
connect to the QMgr @ 100.200.300.400 using
MAIN.CLIENT.CONN . An attemnpt to connect to
100.200.300.401 may be made but will fail since the
QMgr executing on 100.200.300.401 is QMGR2.

Application executes MQCONN to *QMGR1 - this will
connect to QMGR1 using MAIN.CLIENT.CONN, if available,
otherwise will proceed to try BACKUP.CLIENT.CONN which
is on 100.200.300.401 (QMGR2) because it has the
QMgrName property QMGR1.


An application can be coded to re-issue MQCONN where an MQRC_QMGR_NOT_AVAILABLE is returned, making the connectivity transparent to the user.

I hope this helps,

Garry.