MQ

This is part of a series of small blog posts which will cover some of the smaller, perhaps less likely to be noticed, features of IBM MQ. Read other posts in this series.

The Client Channel Definition Table (CCDT) is a binary file used by IBM MQ clients to obtain client-connection channel details. This file can have one or many channel definitions in the file. The definitions in the file nominate a queue manager name and this can be a real queue manager name or a logical queue manager name. The client application, when it runs, attempts to connect to a queue manager name, whatever name it uses on the MQCONN call is what is searched for in the CCDT.

When there are multiple entries for the same queue manager name in a CCDT (a very valid use case) the choice the client makes can go one of two ways:-

• The alphabetically first channel name
• A random choice from the set of entries

The default behaviour is the alphabetical choice, because historically that was the only choice. However, if you are creating a CCDT with multiple entries for a single (logical) queue manager name, you don't want all clients using the same channel name (and thus all going to the same queue manager). This behaviour has, in the past, led to MQ users creating multiple different CCDTs in order to spread the load of client connections across multiple queue managers. Of course, this is a lot of extra effort, which happily is no longer necessary.

In WebSphere MQ V7, a new attribute on a client-connection channel was introduced called Client Weight (CLNTWGHT) which, when set to a non-zero value, stops the client using an alphabetical choice, and instead causes the client to randomise across the set of entries in the CCDT. This means that you can put all the choices into the same CCDT, have all client machines use the same CCDT and all the client-connections will be spread across all the queue managers. Much less effort for the MQ administrator!

If the Client Weight value is the same for all the entries in the CCDT, the client-connections will be equally spread across the entries (and thus the target queue managers), but if you want to send more work to some queue managers than others, you can skew the spread by skewing the Client Weight accordingly.

A good way to look at the weightings is as a percentage, for example:-

DEFINE CHANNEL(MQG1.SVRCONN) CHLTYPE(CLNTCONN) CONNAME('mqgem.com(1701)') CLNTWGHT(40) QMNAME(MQGEM)

DEFINE CHANNEL(MQG2.SVRCONN) CHLTYPE(CLNTCONN) CONNAME('mqgem.com(1702)') CLNTWGHT(40) QMNAME(MQGEM)

DEFINE CHANNEL(MQG3.SVRCONN) CHLTYPE(CLNTCONN) CONNAME('mqgem.com(1703)') CLNTWGHT(20) QMNAME(MQGEM)

A CCDT containing the above three definitions will send 40% of the work to queue manager MQG1 (the first entry), 40% to MQG2 (the second entry) and 20% to MQG3 (the third entry). Of course, the Client Weight numbers do not have to total up to 100, as MQ will do the maths for you, but it does help to illustrate the spread.

If any of you are still battling with multiple CCDTs, take a look at the Client Weight feature. Unless you're using out of support client libraries, you have this feature available to use now.