Cluster workload management is how IBM MQ chooses where a message lands when the same cluster queue name exists on more than one queue manager. ORDERS.IN might run on QM_LON, QM_PAR, and QM_NYC for capacity; without workload rules, you might expect round-robin but see everything stay on the local member—or always favor one site—because CLWLUSEQ, CLWLPRTY, CLWLRANK, and CLWLWGHT tell a different story. Application OPEN and PUT options (bind to cluster, local queue manager only, etc.) also participate. This tutorial explains the selection problem, each CLWL attribute with comparisons, DEFBIND interaction at overview level, active versus available instances, monitoring with DISPLAY CLUSQ and route commands on your release, tuning for active/active versus primary/backup, and mistakes beginners make when duplicating queue names without setting workload attributes consistently.
Application issues put to cluster queue PAYMENT.IN. Repository cache lists three hosting members with network paths. Workload algorithm filters available instances (channels running, queue not inhibited), applies CLWLUSEQ rules, compares CLWLPRTY and CLWLRANK, may apply CLWLWGHT for weighted distribution, selects target, routes over cluster channel. Consumer on that member MQGETs. Wrong expectations—“why did Paris get London’s messages?”—start with DISPLAY which instances exist and their CLWL attributes.
| Attribute | Purpose | Beginner tip |
|---|---|---|
| CLWLPRTY | Priority—higher often preferred among candidates | Set backup lower than primary |
| CLWLRANK | Rank within priority band | Use with PRTY for tie-break |
| CLWLWGHT | Weight for proportional distribution | Active/active capacity share |
| CLWLUSEQ | Local vs any vs QM sequence rules | LOCAL keeps traffic on home QM |
| DEFBIND | Default bind for queue opens | Align app OPEN with intent |
LOCAL affinity sends work to an instance on the putting queue manager if one exists—common when each site processes its own orders but shares disaster recovery copy. ANY allows remote instances when local absent or per algorithm. Queue-manager sequence options order preferred targets for advanced topologies—read IBM attribute value table for ALLOWED, LOCAL, QMGR, and ANY semantics on your version; do not guess numeric codes. Dedicated CLWLUSEQ tutorial expands scenarios.
1234567* Primary site QM_LON DEFINE QLOCAL('PAYMENT.IN') CLUSTER('PAY') CLWLPRTY(9) CLWLRANK(0) + CLWLUSEQ(LOCAL) * Backup site QM_DR - lower priority DEFINE QLOCAL('PAYMENT.IN') CLUSTER('PAY') CLWLPRTY(1) CLWLRANK(0) + CLWLUSEQ(ANY) * Traffic prefers LON when up; DR receives when LON instance unavailable
Two healthy instances with CLWLWGHT(50) and CLWLWGHT(50) encourage balanced distribution when USEQ allows any—verify behavior in lab with message counters. Unequal weights shift proportion—70/30 split for capacity mismatch. Weights interact with priority—document combined matrix before production.
MQOO_BIND_AS_Q_DEF, MQOO_BIND_ON_GROUP, and MQPMO routing options change whether put respects cluster-wide workload or binds to a specific instance. Misaligned COBOL or Java open options override queue defaults you tuned in MQSC. Developers and operators must share bind strategy in integration specs.
Workload management is the traffic cop when three driveways share one street address. Priority signs (CLWLPRTY), lane weights (CLWLWGHT), and “stay in your neighborhood first” rules (CLWLUSEQ) decide which driveway each car takes.
Three shops all named Toy Store get mail addressed to Toy Store. The post office has rules about which shop gets the next package when more than one can accept it.
Design primary CLWLPRTY 9 and backup CLWLPRTY 1 for PAYMENT.IN.
When should CLWLUSEQ LOCAL be used?
All puts stay local despite remote instance—list four checks.
1. Workload management picks:
2. CLWLPRTY is:
3. CLWLUSEQ controls:
4. All traffic to one host—check: