CLWLWGHT (Cluster Workload Weight)

Primary and backup designs lean on CLWLPRTY; active/active capacity sharing leans on CLWLWGHT (cluster workload weight). When two or more queue managers host ORDERS.IN at the same priority and rank, weights tell IBM MQ what proportion of cluster puts each instance should receive among eligible candidates—think 50 and 50 for even split, or 70 and 30 when one data center has more CPU and memory for consumers. Weight is not a service-level agreement: CLWLUSEQ(LOCAL) on every member prevents remote sharing regardless of weight, and broken cluster channels remove instances from the candidate set entirely. Beginners set CLWLWGHT(50) on one member only or expect weight to override a priority-9 primary—then file defects against the product instead of the configuration. This tutorial explains weight on queues and channels, ratio arithmetic in plain language, combining weight with priority for canary deployments, ALTER and DISPLAY MQSC, measurement methodology with CURDEPTH and message counters, troubleshooting uneven splits, and exercises to run in a three-member lab cluster.

How Weight Participates in Routing

After repository builds the list of instances hosting the cluster queue name, CLWLUSEQ may remove remote candidates or keep only local. CLWLPRTY selects the highest priority band still eligible. CLWLRANK orders ties within that band. Among remaining instances, CLWLWGHT biases distribution so higher weight receives more puts over time. The algorithm is statistical across many messages—one put is not guaranteed to land on the heaviest weight instance, but ten thousand puts should trend toward the configured ratio when all else is equal.

Example weight ratios
Instance A weightInstance B weightIntended ratio
505050% / 50% balanced
703070% / 30% capacity skew
802080% / 20% canary on smaller site
109010% / 90% DR rarely used with low PRTY on 10
050Confirm if zero is allowed on your release—often avoid

50/50 Active/Active Example

shell
1
2
3
4
5
6
7
* QM_EAST DEFINE QLOCAL('WORK.IN') CLUSTER('GRID') REPLACE + CLWLPRTY(5) CLWLRANK(0) CLWLWGHT(50) CLWLUSEQ(ANY) * QM_WEST - mirror attributes DEFINE QLOCAL('WORK.IN') CLUSTER('GRID') REPLACE + CLWLPRTY(5) CLWLRANK(0) CLWLWGHT(50) CLWLUSEQ(ANY) * Load-generate 10000 puts from a third member; compare CURDEPTH

ANY on both sides allows the putting application on a third member to choose either instance. If puts originate only on QM_EAST with CLWLUSEQ(LOCAL) on WORK.IN, weight on QM_WEST never matters because local instance always wins. Match USEQ to your traffic pattern: LOCAL for process-local affinity, ANY for shared workload pool.

Capacity Skew 70/30

Larger site CLWLWGHT(70), smaller site CLWLWGHT(30), same priority and rank. Consumers should exist on both sites if you intend messages to land there—otherwise depth grows on one side while consumers starve on the other. Weight distributes puts, not consumer capacity; scale MQGET workers or application instances to match expected depth growth rate.

Weight on Channels

Parallel network paths between the same queue managers can carry CLWLWGHT on CLUSSDR and CLUSRCVR definitions. When one VPN is saturated, operators sometimes lower weight on that path’s channels so workload prefers the alternate link. Coordinate with network teams—MQ weight cannot fix packet loss caused outside MQ. DISPLAY channel status alongside queue depth when diagnosing skew.

Interaction with Priority

Backup at CLWLPRTY(2) CLWLWGHT(90) still loses to primary at CLWLPRTY(9) CLWLWGHT(10) while primary is eligible. Weight helps among peers, not across priority tiers. Canary releases sometimes add a third instance at priority 6 weight 10 while production pair stays at priority 7—measure whether canary receives roughly ten percent of peer traffic after filters.

Explainer: Slices of Cake

After the party decides which tables may serve guests (USEQ and priority), CLWLWGHT is how big each slice of cake is on each table—half and half, or a bigger slice for the table with more chairs.

Measuring Distribution

  1. Record starting CURDEPTH on each instance.
  2. Generate N persistent or non-persistent puts from a controlled client.
  3. Record ending CURDEPTH; delta is approximate received count.
  4. Compute percentage per instance; compare to weight ratio.
  5. Repeat with channels cycled and with one instance inhibited.

Troubleshooting Uneven Splits

  • CLWLUSEQ LOCAL on putting QMgr—remote weight ignored.
  • Only one instance in repository cache—incomplete sync.
  • Application bind to fixed instance—bypasses cluster workload.
  • Equal weight but unequal rank or priority—check all three attributes.
  • One consumer much slower—depth grows; mistaken for routing bug.

Explain Like I'm Five: CLWLWGHT

If three friends share cookies, CLWLWGHT is how many cookies each friend is allowed to take from the jar when it is their turn—bigger number, more cookies over time.

Practice Exercises

Exercise 1

Configure 60/40 weights on two peers and describe how you would measure actual ratio.

Exercise 2

Why does CLWLWGHT(90) on DR not help if DR CLWLPRTY is 1 and primary is 9?

Exercise 3

All puts stay local with equal weights on two members—list three CLWLUSEQ checks.

Frequently Asked Questions

Frequently Asked Questions

Test Your Knowledge

Test Your Knowledge

1. CLWLWGHT mainly controls:

  • Proportional share among eligible instances
  • Message persistence
  • TLS cipher
  • Topic retain

2. Equal weights 50 and 50 suggest:

  • Balanced share when peers eligible
  • No messages ever remote
  • Queue is DLQ
  • Channel is SDR only

3. Weight 70 versus 30 expresses:

  • Relative capacity ratio
  • TCP port numbers
  • Days to retain
  • COBOL line numbers

4. CLWLWGHT is evaluated after:

  • CLWLPRTY and CLWLRANK among candidates
  • JES initiation
  • FTP transfer
  • Batch job end
Published
Read time15 min
AuthorMainframeMaster
Verified: IBM MQ 9.3 documentation