Cluster Queue Resolves to the Wrong Queue Manager
CLUSTER ORDERS has two full repositories, QM1 and QM2. Both host a cluster queue named Q.ORDERS. QM1 sits on a 4 TB all-flash array; QM2 uses older storage and is meant only for disaster recovery. QM3 is a partial repository and runs the order-putting application. Until last week QM3 was the only producer and all messages went to QM1. After QM2 was added to the cluster, about half of the messages are placed on QM2, and end-to-end latency breaches the 2-second SLA. The application team says it can change the MQOPEN call but not its business logic. The operations team wants a deterministic route to QM1 while keeping QM2 available as a manual failover target. A developer suggests setting CLWLPRTY(9) on QM1's Q.ORDERS and CLWLPRTY(0) on QM2's, then 'it will always choose QM1.' You must explain whether that is sufficient and propose a design that meets both requirements. No application outage is allowed for the change.
1. Why are messages being placed on QM2, and which commands confirm that both queue instances are visible?
Read the worked answer
The split is normal cluster workload balancing, not a defect. QM3's partial repository learns that both QM1 and QM2 host a cluster queue named Q.ORDERS. When the application opens Q.ORDERS without naming a queue manager, the cluster workload manager chooses among available instances, normally round-robin. Adding QM2 therefore sent roughly half the traffic there. Confirm with DIS CLUSQMGR(*) on QM3: both QM1 and QM2 should appear with their cluster channels. On QM1 and QM2, DIS Q(Q.ORDERS) should show CLUSTER(ORDERS) and CLUSNL(' '). Check DIS CHSTATUS for the cluster sender/receiver channels to rule out a channel failure that would also change distribution.
2. Is CLWLPRTY(9) on QM1 and CLWLPRTY(0) on QM2 sufficient to guarantee that QM2 never receives messages?
Read the worked answer
No. CLWLPRTY(9) on QM1 and CLWLPRTY(0) on QM2 makes QM1 preferred, but it is not a guarantee. If QM1's queue is full, its channel is stopped, or QM3 cannot reach QM1, the workload manager can still select QM2. It also does not prevent a new QM4 instance from joining later with the same queue name. Priority is a bias, not a route. For deterministic routing, the application must name QM1 in MQOD.ObjectQMgrName, or the administrator must put a local remote-queue definition in front of the cluster queue. That is why the developer's suggestion only partly meets the requirement.
3. Design a routing change that pins the SLA path to QM1 but still allows a manual failover to QM2.
Read the worked answer
Define a non-cluster route on QM3: a transmission queue to QM1, a sender channel to QM1, and either an alias or remote queue that the application opens. For example, DEFINE QREMOTE(ORDERS.PIN) RNAME(Q.ORDERS) RQMNAME(QM1) XMITQ(QM1.XMIT) plus the QM1 sender channel. A local definition takes precedence over cluster resolution, so all puts go to QM1's xmit queue. If QM1 is unavailable, messages accumulate on QM3 rather than silently going to QM2. For manual failover, operations changes the alias to point at QM2, or the application uses a configurable queue-manager name. Keep QM2's Q.ORDERS in the cluster for other consumers or for the failover alias, but do not rely on CLWLPRTY for the SLA path. Document that the pinned route trades automatic fallback for deterministic latency.