MQ

MQ

Join this online group to communicate across IBM product users and experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only

CLUSQT(0) Cluster Issue

By Tim Zielke posted 07/24/26 10:44 AM

  

I ran across an issue when doing some cluster administration, and I wanted to pass it on in case it can help anyone else who encounters it. For the queue managers that were involved in this issue, they were primarily at recent versions of IBM MQ 9.4.

I had a cluster set up like the following for moving messages from QM1 -> QM3 through a pass through QM2 queue manager.

QM1

  • participates in cluster CLUS1
  • applications connect locally to QM1 and MQOPEN Q1 with a blank queue manager name and then MQPUT to Q1
  • Q1 does not exist on QM1 and there is a QCLUSTER resource in QM1 for a QUEUE(Q1) CLUSQT(QALIAS) CLUSTER(CLUS1)  CLWLRANK(3) CLUSQMGR(QM2)

QM2 

  • participates in cluster CLUS1 and CLUS2
  • there is a QALIAS definition in QM2 for a QUEUE(Q1) TYPE(QALIAS) TARGET(Q1) CLUSTER(CLUS1)  CLWLRANK(3)
  • there is a QCLUSTER resource in QM2 for a QUEUE(Q1) CLUSQT(QLOCAL) CLUSTER(CLUS2)  CLWLRANK(5) CLUSQMGR(QM3)

QM3

  • participates in cluster CLUS2
  • there is a QLOCAL definition on QM3 for a QLOCAL(Q1) CLUSTER(CLUS2) CLWLRANK(5)

This setup allows applications on QM1 to MQOPEN Q1 with a blank queue manager name and MQPUT to Q1. Next, the message flows to QM2 and then it is redirected to QM3 where the message lands on Q1 and is processed. I understand this is not the recommended way to do this and it would be better to have a queue manager alias set up where applications on QM1 are using a queue manager alias on the MQOPEN, however this is a legacy application design that we are currently in need to support.

I ran across an issue when the full repository for CLUS1 had some QCLUSTER references for Q1 with a CLUSQT(0). This is an invalid CLUSQT type. I have no idea how these bad records got into my full repository, but when I did a REFRESH CLUSTER(CLUS1) on QM1, it brought in these bad records and then the following happened.

The applications on QM1 that were putting to Q1 had the message land on QM2 and then go to the Dead Letter Queue with a 2001 (MQRC_ALIAS_BASE_Q_TYPE_ERROR) error.

The fix was to change the DESCR on the Q1 QALIAS definition on QM2 which caused the full repository to republish this definition to QM1, and then the bad CLUSQT(0) records went away in both the full repository and QM1.

I don't know if MQ Admins do much monitoring for the information inside the CLUSQMGR and QC resources, but checking for invalid CLUSQT values might be something to consider for cluster health.

2 comments
19 views

Permalink

https://community.ibm.com/community/user/blogs/tim-zielke1/2026/07/24/clusqt0

Comments

Tim Zielke
07/26/26 01:14 PM

I am not aware of any APAR fix for this issue. Also, I don't have a way of passing doc on the issue to IBM, as the ALTER QA DESCR commands cleared up the corruption in the full repository.

Morag Hughson
07/25/26 09:03 AM

Is there an APAR fix coming for this?