Example 1. Selecting channels when ConnectionAffinity is set to PREFERRED

This example illustrates how an IBM MQ MQI client selects a channel from a CCDT, where the ConnectionAffinity is set to PREFERRED.

CHANNEL(A) QMNAME(DEV) CONNAME(devqm.it.company.example)
CHANNEL(B) QMNAME(CORE) CONNAME(core1.ops.company.example) CLNTWGHT(5) +
AFFINITY(PREFERRED)
CHANNEL(C) QMNAME(CORE) CONNAME(core2.ops.company.example) CLNTWGHT(3) +
AFFINITY(PREFERRED)
CHANNEL(D) QMNAME(CORE) CONNAME(core3.ops.company.example) CLNTWGHT(2) +
AFFINITY(PREFERRED)

Channel A is not a candidate for this connection, because the QMNAME attribute does not match. Channels B, C and D are identified as candidates, and are placed in an order of preference based on their weighting. In this example the order might be C, B, D. The client attempts to connect to the queue manager at core2.ops.company.example. The name of the queue manager at that address is not checked, because the MQCONN call included an asterisk in the queue manager name.

It is important to note that, with AFFINITY(PREFERRED), each time this particular client machine connects it will place the channels in the same initial order of preference. This applies even when the connections are from different processes or at different times.

In this example, the queue manager at core.2.ops.company.example cannot be reached. The client attempts to connect to core1.ops.company.example because channel B is next in the order of preference. In addition, channel C is demoted to become the least preferred.

A second MQCONN(*CORE) call is issued by the same application. Channel C was demoted by the previous connection, so the most preferred channel is now B. This connection is made to core1.ops.company.example.

A second machine sharing the same Client Channel Definition Table migh place the channels in a different initial order of preference. For example, D, B, C. Under normal circumstances, with all channels working, applications on this machine are connected to core3.ops.company.example while those on the first machine are connected to core2.ops.company.example. This allows workload balancing of large numbers of clients across multiple queue managers while allowing each individual client to connect to the same queue manager if it is available.