I had to do a RESET CLUSTER(XYZ) QMNAME(QM1) QUEUES(YES) command on a cluster full repository, and I was surprised to see that the qalias queue cluster resources for QM1 were still visible after the command was successfully run. I did see the queue manager drop from the full repository with the DIS CLUSQMGR command. I also did see local queues owned by the QM1 drop from full repository with the DIS QC command. However, the DIS QC command is still displaying qalias references for QM1.

I asked AI (or Ultron as I like to call it :-) ), and it said that this could be an expected behavior of qalias queue cluster resources still being visible in the full repository after a RESET CLUSTER QUEUE(YES) command is run. Does anyone know if that is correct or not? I did not see anything stating this behavior in the IBM MQ manual.

Hi Tim
I would check MQ error logs as well as channel status on both QM1 as well as full repository QMs (do you use 1 or 2 ?)
If there are channels in retrying status, then that can hold back cleanup of the repository.

Do you use multiple MQ clusters ?

If a QM is not reflecting with 'dis clusqmgr' on a repository, then there should be no queues visible with 'dis qc' on the repository for that QM.

I had to do a RESET CLUSTER(XYZ) QMNAME(QM1) QUEUES(YES) command on a cluster full repository, and I was surprised to see that the qalias queue cluster resources for QM1 were still visible after the command was successfully run. I did see the queue manager drop from the full repository with the DIS CLUSQMGR command. I also did see local queues owned by the QM1 drop from full repository with the DIS QC command. However, the DIS QC command is still displaying qalias references for QM1.

I asked AI (or Ultron as I like to call it :-) ), and it said that this could be an expected behavior of qalias queue cluster resources still being visible in the full repository after a RESET CLUSTER QUEUE(YES) command is run. Does anyone know if that is correct or not? I did not see anything stating this behavior in the IBM MQ manual.

Hi Erik,

There are not any channel issues going on between the FRs and the new QM1. For QM1, I had to do a dltmqm on the old QM1 (it was in a broken state) and rebuild with a new QM1 with crtmqm. This is why I had to run the RESET CLUSTER FORCEREMOVE QUEUE(YES) on the FR on the old QM1. Only the new QM1 appears in the full repository with a DIS CLUSQMGR. However, I can see DIS QC QALIAS resources for both the old and new QM1 on the full repository. These QALIAS resource do exist in multiple clusters on QM1.

Thanks,

Tim

Hi Tim
I would check MQ error logs as well as channel status on both QM1 as well as full repository QMs (do you use 1 or 2 ?)
If there are channels in retrying status, then that can hold back cleanup of the repository.

Do you use multiple MQ clusters ?

If a QM is not reflecting with 'dis clusqmgr' on a repository, then there should be no queues visible with 'dis qc' on the repository for that QM.

I had to do a RESET CLUSTER(XYZ) QMNAME(QM1) QUEUES(YES) command on a cluster full repository, and I was surprised to see that the qalias queue cluster resources for QM1 were still visible after the command was successfully run. I did see the queue manager drop from the full repository with the DIS CLUSQMGR command. I also did see local queues owned by the QM1 drop from full repository with the DIS QC command. However, the DIS QC command is still displaying qalias references for QM1.

I asked AI (or Ultron as I like to call it :-) ), and it said that this could be an expected behavior of qalias queue cluster resources still being visible in the full repository after a RESET CLUSTER QUEUE(YES) command is run. Does anyone know if that is correct or not? I did not see anything stating this behavior in the IBM MQ manual.

Hi Tim

The reset command can be executed with QMID option (with the qmid of the deleted QM).

As queues exist in multiple MQ clusters (that is different MQ cluster names) then a reset need to be made for each MQ cluster name.

As the QM was broken then a reset had to be done, otherwise I recommend to first remove MQ cluster specification on queues and topics and confirm the removal on the objects in the FRs before removing the MQ cluster specification on the cluster receiver channel and cluster sender channel, only one of each per MQ cluster specification, on the QM that should no longer participate in the MQ cluster. To avoid channels going into retry it is best to keep the channels for some time (without MQ cluster specification) and wait for the channels to become inactive before deleting them.

Just out of curiosity, is it the same result on both FRs ?

Regards, Erik Houlberg

Hi Erik,

There are not any channel issues going on between the FRs and the new QM1. For QM1, I had to do a dltmqm on the old QM1 (it was in a broken state) and rebuild with a new QM1 with crtmqm. This is why I had to run the RESET CLUSTER FORCEREMOVE QUEUE(YES) on the FR on the old QM1. Only the new QM1 appears in the full repository with a DIS CLUSQMGR. However, I can see DIS QC QALIAS resources for both the old and new QM1 on the full repository. These QALIAS resource do exist in multiple clusters on QM1.

Thanks,

Tim

Hi Tim
I would check MQ error logs as well as channel status on both QM1 as well as full repository QMs (do you use 1 or 2 ?)
If there are channels in retrying status, then that can hold back cleanup of the repository.

Do you use multiple MQ clusters ?

If a QM is not reflecting with 'dis clusqmgr' on a repository, then there should be no queues visible with 'dis qc' on the repository for that QM.

I had to do a RESET CLUSTER(XYZ) QMNAME(QM1) QUEUES(YES) command on a cluster full repository, and I was surprised to see that the qalias queue cluster resources for QM1 were still visible after the command was successfully run. I did see the queue manager drop from the full repository with the DIS CLUSQMGR command. I also did see local queues owned by the QM1 drop from full repository with the DIS QC command. However, the DIS QC command is still displaying qalias references for QM1.

I asked AI (or Ultron as I like to call it :-) ), and it said that this could be an expected behavior of qalias queue cluster resources still being visible in the full repository after a RESET CLUSTER QUEUE(YES) command is run. Does anyone know if that is correct or not? I did not see anything stating this behavior in the IBM MQ manual.

Yes, both FRs are displaying the same result.

Hi Tim

The reset command can be executed with QMID option (with the qmid of the deleted QM).

As queues exist in multiple MQ clusters (that is different MQ cluster names) then a reset need to be made for each MQ cluster name.

As the QM was broken then a reset had to be done, otherwise I recommend to first remove MQ cluster specification on queues and topics and confirm the removal on the objects in the FRs before removing the MQ cluster specification on the cluster receiver channel and cluster sender channel, only one of each per MQ cluster specification, on the QM that should no longer participate in the MQ cluster. To avoid channels going into retry it is best to keep the channels for some time (without MQ cluster specification) and wait for the channels to become inactive before deleting them.

Just out of curiosity, is it the same result on both FRs ?

Regards, Erik Houlberg

Hi Erik,

There are not any channel issues going on between the FRs and the new QM1. For QM1, I had to do a dltmqm on the old QM1 (it was in a broken state) and rebuild with a new QM1 with crtmqm. This is why I had to run the RESET CLUSTER FORCEREMOVE QUEUE(YES) on the FR on the old QM1. Only the new QM1 appears in the full repository with a DIS CLUSQMGR. However, I can see DIS QC QALIAS resources for both the old and new QM1 on the full repository. These QALIAS resource do exist in multiple clusters on QM1.

Thanks,

Tim

Hi Tim
I would check MQ error logs as well as channel status on both QM1 as well as full repository QMs (do you use 1 or 2 ?)
If there are channels in retrying status, then that can hold back cleanup of the repository.

Do you use multiple MQ clusters ?

If a QM is not reflecting with 'dis clusqmgr' on a repository, then there should be no queues visible with 'dis qc' on the repository for that QM.

I had to do a RESET CLUSTER(XYZ) QMNAME(QM1) QUEUES(YES) command on a cluster full repository, and I was surprised to see that the qalias queue cluster resources for QM1 were still visible after the command was successfully run. I did see the queue manager drop from the full repository with the DIS CLUSQMGR command. I also did see local queues owned by the QM1 drop from full repository with the DIS QC command. However, the DIS QC command is still displaying qalias references for QM1.

I asked AI (or Ultron as I like to call it :-) ), and it said that this could be an expected behavior of qalias queue cluster resources still being visible in the full repository after a RESET CLUSTER QUEUE(YES) command is run. Does anyone know if that is correct or not? I did not see anything stating this behavior in the IBM MQ manual.

Just a note for others who might encounter a similar situation. The RESET CLUSTER(XYZ) QMNAME(QM1) QUEUES(YES) command would never fully work on the cluster full repositories in removing the queues of the forcibly removed queue manager. However, after 90 days from the removal of the queue manager, all the cluster full and partial repositories finally discarded the queue  references themselves. I had to develop extra monitoring to make sure all the AMQ9456 and CSQX456E messages that were being reported daily were only for this forcibly removed queue manager. A bit of a pain, but it eventually worked itself out.

------------------------------
Tim Zielke

Original Message:
Sent: Mon June 16, 2025 09:55 AM
From: Tim Zielke
Subject: QALIAS Queue Cluster Resources Still Visible After RESET CLUSTER QUEUE(YES)

Yes, both FRs are displaying the same result.

------------------------------
Tim Zielke

Original Message:
Sent: Mon June 16, 2025 09:43 AM
From: Erik Houlberg
Subject: QALIAS Queue Cluster Resources Still Visible After RESET CLUSTER QUEUE(YES)

Hi Tim

The reset command can be executed with QMID option (with the qmid of the deleted QM).

As queues exist in multiple MQ clusters (that is different MQ cluster names) then a reset need to be made for each MQ cluster name.

As the QM was broken then a reset had to be done, otherwise I recommend to first remove MQ cluster specification on queues and topics and confirm the removal on the objects in the FRs before removing the MQ cluster specification on the cluster receiver channel and cluster sender channel, only one of each per MQ cluster specification, on the QM that should no longer participate in the MQ cluster. To avoid channels going into retry it is best to keep the channels for some time (without MQ cluster specification) and wait for the channels to become inactive before deleting them.

Just out of curiosity, is it the same result on both FRs ?

Regards, Erik Houlberg

------------------------------
Erik Houlberg

Original Message:
Sent: Mon June 16, 2025 09:08 AM
From: Tim Zielke
Subject: QALIAS Queue Cluster Resources Still Visible After RESET CLUSTER QUEUE(YES)

Hi Erik,

There are not any channel issues going on between the FRs and the new QM1. For QM1, I had to do a dltmqm on the old QM1 (it was in a broken state) and rebuild with a new QM1 with crtmqm. This is why I had to run the RESET CLUSTER FORCEREMOVE QUEUE(YES) on the FR on the old QM1. Only the new QM1 appears in the full repository with a DIS CLUSQMGR. However, I can see DIS QC QALIAS resources for both the old and new QM1 on the full repository. These QALIAS resource do exist in multiple clusters on QM1.

Thanks,

Tim

------------------------------
Tim Zielke

Original Message:
Sent: Mon June 16, 2025 03:38 AM
From: Erik Houlberg
Subject: QALIAS Queue Cluster Resources Still Visible After RESET CLUSTER QUEUE(YES)

Hi Tim
I would check MQ error logs as well as channel status on both QM1 as well as full repository QMs (do you use 1 or 2 ?)
If there are channels in retrying status, then that can hold back cleanup of the repository.

Do you use multiple MQ clusters ?

If a QM is not reflecting with 'dis clusqmgr' on a repository, then there should be no queues visible with 'dis qc' on the repository for that QM.

------------------------------
Erik Houlberg

Original Message:
Sent: Fri June 13, 2025 11:19 AM
From: Tim Zielke
Subject: QALIAS Queue Cluster Resources Still Visible After RESET CLUSTER QUEUE(YES)

I had to do a RESET CLUSTER(XYZ) QMNAME(QM1) QUEUES(YES) command on a cluster full repository, and I was surprised to see that the qalias queue cluster resources for QM1 were still visible after the command was successfully run. I did see the queue manager drop from the full repository with the DIS CLUSQMGR command. I also did see local queues owned by the QM1 drop from full repository with the DIS QC command. However, the DIS QC command is still displaying qalias references for QM1.

I asked AI (or Ultron as I like to call it :-) ), and it said that this could be an expected behavior of qalias queue cluster resources still being visible in the full repository after a RESET CLUSTER QUEUE(YES) command is run. Does anyone know if that is correct or not? I did not see anything stating this behavior in the IBM MQ manual.

------------------------------
Tim Zielke
------------------------------

Tim,

Could it be because you omitted the keywords ACTION(FORCEREMOVE) in your command ? And you have to run it on the full repository...

I used RESET CLUSTER(XYZ) ACTION(FORCEREMOVE) QMNAME(QM1) QUEUES(YES) and it did the trick for me...

if it is a problem between old and new qmgr, use QMID instead of QMNAME as both old and new qmgrs will probably not have the same QMID.

------------------------------
Francois Brandelik

Original Message:
Sent: Tue September 16, 2025 10:06 AM
From: Tim Zielke
Subject: QALIAS Queue Cluster Resources Still Visible After RESET CLUSTER QUEUE(YES)

Just a note for others who might encounter a similar situation. The RESET CLUSTER(XYZ) QMNAME(QM1) QUEUES(YES) command would never fully work on the cluster full repositories in removing the queues of the forcibly removed queue manager. However, after 90 days from the removal of the queue manager, all the cluster full and partial repositories finally discarded the queue  references themselves. I had to develop extra monitoring to make sure all the AMQ9456 and CSQX456E messages that were being reported daily were only for this forcibly removed queue manager. A bit of a pain, but it eventually worked itself out.

------------------------------
Tim Zielke

Original Message:
Sent: Mon June 16, 2025 09:55 AM
From: Tim Zielke
Subject: QALIAS Queue Cluster Resources Still Visible After RESET CLUSTER QUEUE(YES)

Yes, both FRs are displaying the same result.

------------------------------
Tim Zielke

Original Message:
Sent: Mon June 16, 2025 09:43 AM
From: Erik Houlberg
Subject: QALIAS Queue Cluster Resources Still Visible After RESET CLUSTER QUEUE(YES)

Hi Tim

The reset command can be executed with QMID option (with the qmid of the deleted QM).

As queues exist in multiple MQ clusters (that is different MQ cluster names) then a reset need to be made for each MQ cluster name.

As the QM was broken then a reset had to be done, otherwise I recommend to first remove MQ cluster specification on queues and topics and confirm the removal on the objects in the FRs before removing the MQ cluster specification on the cluster receiver channel and cluster sender channel, only one of each per MQ cluster specification, on the QM that should no longer participate in the MQ cluster. To avoid channels going into retry it is best to keep the channels for some time (without MQ cluster specification) and wait for the channels to become inactive before deleting them.

Just out of curiosity, is it the same result on both FRs ?

Regards, Erik Houlberg

------------------------------
Erik Houlberg

Original Message:
Sent: Mon June 16, 2025 09:08 AM
From: Tim Zielke
Subject: QALIAS Queue Cluster Resources Still Visible After RESET CLUSTER QUEUE(YES)

Hi Erik,

There are not any channel issues going on between the FRs and the new QM1. For QM1, I had to do a dltmqm on the old QM1 (it was in a broken state) and rebuild with a new QM1 with crtmqm. This is why I had to run the RESET CLUSTER FORCEREMOVE QUEUE(YES) on the FR on the old QM1. Only the new QM1 appears in the full repository with a DIS CLUSQMGR. However, I can see DIS QC QALIAS resources for both the old and new QM1 on the full repository. These QALIAS resource do exist in multiple clusters on QM1.

Thanks,

Tim

------------------------------
Tim Zielke

Original Message:
Sent: Mon June 16, 2025 03:38 AM
From: Erik Houlberg
Subject: QALIAS Queue Cluster Resources Still Visible After RESET CLUSTER QUEUE(YES)

Hi Tim
I would check MQ error logs as well as channel status on both QM1 as well as full repository QMs (do you use 1 or 2 ?)
If there are channels in retrying status, then that can hold back cleanup of the repository.

Do you use multiple MQ clusters ?

If a QM is not reflecting with 'dis clusqmgr' on a repository, then there should be no queues visible with 'dis qc' on the repository for that QM.

------------------------------
Erik Houlberg

Original Message:
Sent: Fri June 13, 2025 11:19 AM
From: Tim Zielke
Subject: QALIAS Queue Cluster Resources Still Visible After RESET CLUSTER QUEUE(YES)

I had to do a RESET CLUSTER(XYZ) QMNAME(QM1) QUEUES(YES) command on a cluster full repository, and I was surprised to see that the qalias queue cluster resources for QM1 were still visible after the command was successfully run. I did see the queue manager drop from the full repository with the DIS CLUSQMGR command. I also did see local queues owned by the QM1 drop from full repository with the DIS QC command. However, the DIS QC command is still displaying qalias references for QM1.

I asked AI (or Ultron as I like to call it :-) ), and it said that this could be an expected behavior of qalias queue cluster resources still being visible in the full repository after a RESET CLUSTER QUEUE(YES) command is run. Does anyone know if that is correct or not? I did not see anything stating this behavior in the IBM MQ manual.

------------------------------
Tim Zielke
------------------------------

Hi Francois,

I did have the command syntax correct, and also tried running the command with the QMID. I have also seen the command work correctly on my MQ sandbox queue manager, so it looked like I was hitting some type of uncommon scenario that was causing the issue. For the cluster full repository that was having the issue, the queues are in multiple clusters. So perhaps the issue had to do with something like that.

Thanks,

Tim

------------------------------
Tim Zielke

Original Message:
Sent: Wed September 17, 2025 03:31 AM
From: Francois Brandelik
Subject: QALIAS Queue Cluster Resources Still Visible After RESET CLUSTER QUEUE(YES)

Tim,

Could it be because you omitted the keywords ACTION(FORCEREMOVE) in your command ? And you have to run it on the full repository...

I used RESET CLUSTER(XYZ) ACTION(FORCEREMOVE) QMNAME(QM1) QUEUES(YES) and it did the trick for me...

if it is a problem between old and new qmgr, use QMID instead of QMNAME as both old and new qmgrs will probably not have the same QMID.

------------------------------
Francois Brandelik

Original Message:
Sent: Tue September 16, 2025 10:06 AM
From: Tim Zielke
Subject: QALIAS Queue Cluster Resources Still Visible After RESET CLUSTER QUEUE(YES)

Just a note for others who might encounter a similar situation. The RESET CLUSTER(XYZ) QMNAME(QM1) QUEUES(YES) command would never fully work on the cluster full repositories in removing the queues of the forcibly removed queue manager. However, after 90 days from the removal of the queue manager, all the cluster full and partial repositories finally discarded the queue  references themselves. I had to develop extra monitoring to make sure all the AMQ9456 and CSQX456E messages that were being reported daily were only for this forcibly removed queue manager. A bit of a pain, but it eventually worked itself out.

------------------------------
Tim Zielke

Original Message:
Sent: Mon June 16, 2025 09:55 AM
From: Tim Zielke
Subject: QALIAS Queue Cluster Resources Still Visible After RESET CLUSTER QUEUE(YES)

Yes, both FRs are displaying the same result.

------------------------------
Tim Zielke

Original Message:
Sent: Mon June 16, 2025 09:43 AM
From: Erik Houlberg
Subject: QALIAS Queue Cluster Resources Still Visible After RESET CLUSTER QUEUE(YES)

Hi Tim

The reset command can be executed with QMID option (with the qmid of the deleted QM).

As queues exist in multiple MQ clusters (that is different MQ cluster names) then a reset need to be made for each MQ cluster name.

As the QM was broken then a reset had to be done, otherwise I recommend to first remove MQ cluster specification on queues and topics and confirm the removal on the objects in the FRs before removing the MQ cluster specification on the cluster receiver channel and cluster sender channel, only one of each per MQ cluster specification, on the QM that should no longer participate in the MQ cluster. To avoid channels going into retry it is best to keep the channels for some time (without MQ cluster specification) and wait for the channels to become inactive before deleting them.

Just out of curiosity, is it the same result on both FRs ?

Regards, Erik Houlberg

------------------------------
Erik Houlberg

Original Message:
Sent: Mon June 16, 2025 09:08 AM
From: Tim Zielke
Subject: QALIAS Queue Cluster Resources Still Visible After RESET CLUSTER QUEUE(YES)

Hi Erik,

There are not any channel issues going on between the FRs and the new QM1. For QM1, I had to do a dltmqm on the old QM1 (it was in a broken state) and rebuild with a new QM1 with crtmqm. This is why I had to run the RESET CLUSTER FORCEREMOVE QUEUE(YES) on the FR on the old QM1. Only the new QM1 appears in the full repository with a DIS CLUSQMGR. However, I can see DIS QC QALIAS resources for both the old and new QM1 on the full repository. These QALIAS resource do exist in multiple clusters on QM1.

Thanks,

Tim

------------------------------
Tim Zielke

Original Message:
Sent: Mon June 16, 2025 03:38 AM
From: Erik Houlberg
Subject: QALIAS Queue Cluster Resources Still Visible After RESET CLUSTER QUEUE(YES)

Hi Tim
I would check MQ error logs as well as channel status on both QM1 as well as full repository QMs (do you use 1 or 2 ?)
If there are channels in retrying status, then that can hold back cleanup of the repository.

Do you use multiple MQ clusters ?

If a QM is not reflecting with 'dis clusqmgr' on a repository, then there should be no queues visible with 'dis qc' on the repository for that QM.

------------------------------
Erik Houlberg

Original Message:
Sent: Fri June 13, 2025 11:19 AM
From: Tim Zielke
Subject: QALIAS Queue Cluster Resources Still Visible After RESET CLUSTER QUEUE(YES)

I had to do a RESET CLUSTER(XYZ) QMNAME(QM1) QUEUES(YES) command on a cluster full repository, and I was surprised to see that the qalias queue cluster resources for QM1 were still visible after the command was successfully run. I did see the queue manager drop from the full repository with the DIS CLUSQMGR command. I also did see local queues owned by the QM1 drop from full repository with the DIS QC command. However, the DIS QC command is still displaying qalias references for QM1.

I asked AI (or Ultron as I like to call it :-) ), and it said that this could be an expected behavior of qalias queue cluster resources still being visible in the full repository after a RESET CLUSTER QUEUE(YES) command is run. Does anyone know if that is correct or not? I did not see anything stating this behavior in the IBM MQ manual.

------------------------------
Tim Zielke
------------------------------

Did you run the command using QMID for each of the clusters the queue manager participated in? 

Each and every time on one of the corresponding full repository for the cluster the command was run against?

------------------------------
Francois Brandelik

Original Message:
Sent: Wed September 17, 2025 08:53 AM
From: Tim Zielke
Subject: QALIAS Queue Cluster Resources Still Visible After RESET CLUSTER QUEUE(YES)

Hi Francois,

I did have the command syntax correct, and also tried running the command with the QMID. I have also seen the command work correctly on my MQ sandbox queue manager, so it looked like I was hitting some type of uncommon scenario that was causing the issue. For the cluster full repository that was having the issue, the queues are in multiple clusters. So perhaps the issue had to do with something like that.

Thanks,

Tim

------------------------------
Tim Zielke

Original Message:
Sent: Wed September 17, 2025 03:31 AM
From: Francois Brandelik
Subject: QALIAS Queue Cluster Resources Still Visible After RESET CLUSTER QUEUE(YES)

Tim,

Could it be because you omitted the keywords ACTION(FORCEREMOVE) in your command ? And you have to run it on the full repository...

I used RESET CLUSTER(XYZ) ACTION(FORCEREMOVE) QMNAME(QM1) QUEUES(YES) and it did the trick for me...

if it is a problem between old and new qmgr, use QMID instead of QMNAME as both old and new qmgrs will probably not have the same QMID.

------------------------------
Francois Brandelik

Original Message:
Sent: Tue September 16, 2025 10:06 AM
From: Tim Zielke
Subject: QALIAS Queue Cluster Resources Still Visible After RESET CLUSTER QUEUE(YES)

Just a note for others who might encounter a similar situation. The RESET CLUSTER(XYZ) QMNAME(QM1) QUEUES(YES) command would never fully work on the cluster full repositories in removing the queues of the forcibly removed queue manager. However, after 90 days from the removal of the queue manager, all the cluster full and partial repositories finally discarded the queue  references themselves. I had to develop extra monitoring to make sure all the AMQ9456 and CSQX456E messages that were being reported daily were only for this forcibly removed queue manager. A bit of a pain, but it eventually worked itself out.

------------------------------
Tim Zielke

Original Message:
Sent: Mon June 16, 2025 09:55 AM
From: Tim Zielke
Subject: QALIAS Queue Cluster Resources Still Visible After RESET CLUSTER QUEUE(YES)

Yes, both FRs are displaying the same result.

------------------------------
Tim Zielke

Original Message:
Sent: Mon June 16, 2025 09:43 AM
From: Erik Houlberg
Subject: QALIAS Queue Cluster Resources Still Visible After RESET CLUSTER QUEUE(YES)

Hi Tim

The reset command can be executed with QMID option (with the qmid of the deleted QM).

As queues exist in multiple MQ clusters (that is different MQ cluster names) then a reset need to be made for each MQ cluster name.

As the QM was broken then a reset had to be done, otherwise I recommend to first remove MQ cluster specification on queues and topics and confirm the removal on the objects in the FRs before removing the MQ cluster specification on the cluster receiver channel and cluster sender channel, only one of each per MQ cluster specification, on the QM that should no longer participate in the MQ cluster. To avoid channels going into retry it is best to keep the channels for some time (without MQ cluster specification) and wait for the channels to become inactive before deleting them.

Just out of curiosity, is it the same result on both FRs ?

Regards, Erik Houlberg

------------------------------
Erik Houlberg

Original Message:
Sent: Mon June 16, 2025 09:08 AM
From: Tim Zielke
Subject: QALIAS Queue Cluster Resources Still Visible After RESET CLUSTER QUEUE(YES)

Hi Erik,

There are not any channel issues going on between the FRs and the new QM1. For QM1, I had to do a dltmqm on the old QM1 (it was in a broken state) and rebuild with a new QM1 with crtmqm. This is why I had to run the RESET CLUSTER FORCEREMOVE QUEUE(YES) on the FR on the old QM1. Only the new QM1 appears in the full repository with a DIS CLUSQMGR. However, I can see DIS QC QALIAS resources for both the old and new QM1 on the full repository. These QALIAS resource do exist in multiple clusters on QM1.

Thanks,

Tim

------------------------------
Tim Zielke

Original Message:
Sent: Mon June 16, 2025 03:38 AM
From: Erik Houlberg
Subject: QALIAS Queue Cluster Resources Still Visible After RESET CLUSTER QUEUE(YES)

Hi Tim
I would check MQ error logs as well as channel status on both QM1 as well as full repository QMs (do you use 1 or 2 ?)
If there are channels in retrying status, then that can hold back cleanup of the repository.

Do you use multiple MQ clusters ?

If a QM is not reflecting with 'dis clusqmgr' on a repository, then there should be no queues visible with 'dis qc' on the repository for that QM.

------------------------------
Erik Houlberg

Original Message:
Sent: Fri June 13, 2025 11:19 AM
From: Tim Zielke
Subject: QALIAS Queue Cluster Resources Still Visible After RESET CLUSTER QUEUE(YES)

I had to do a RESET CLUSTER(XYZ) QMNAME(QM1) QUEUES(YES) command on a cluster full repository, and I was surprised to see that the qalias queue cluster resources for QM1 were still visible after the command was successfully run. I did see the queue manager drop from the full repository with the DIS CLUSQMGR command. I also did see local queues owned by the QM1 drop from full repository with the DIS QC command. However, the DIS QC command is still displaying qalias references for QM1.

I asked AI (or Ultron as I like to call it :-) ), and it said that this could be an expected behavior of qalias queue cluster resources still being visible in the full repository after a RESET CLUSTER QUEUE(YES) command is run. Does anyone know if that is correct or not? I did not see anything stating this behavior in the IBM MQ manual.

------------------------------
Tim Zielke
------------------------------

Yes, but I believe I used QMNAME instead of QMID when I originally did that. However, there was only one queue manager with that name when the commands were run. It resulted in the queue manager being removed from all the clusters with the DIS CLUSQMGR command. However, the DIS QC command would still show queues for the removed queue manager.

Did you run the command using QMID for each of the clusters the queue manager participated in? 

Each and every time on one of the corresponding full repository for the cluster the command was run against?

------------------------------
Francois Brandelik

Original Message:
Sent: Wed September 17, 2025 08:53 AM
From: Tim Zielke
Subject: QALIAS Queue Cluster Resources Still Visible After RESET CLUSTER QUEUE(YES)

Hi Francois,

I did have the command syntax correct, and also tried running the command with the QMID. I have also seen the command work correctly on my MQ sandbox queue manager, so it looked like I was hitting some type of uncommon scenario that was causing the issue. For the cluster full repository that was having the issue, the queues are in multiple clusters. So perhaps the issue had to do with something like that.

Thanks,

Tim

------------------------------
Tim Zielke

Original Message:
Sent: Wed September 17, 2025 03:31 AM
From: Francois Brandelik
Subject: QALIAS Queue Cluster Resources Still Visible After RESET CLUSTER QUEUE(YES)

Tim,

Could it be because you omitted the keywords ACTION(FORCEREMOVE) in your command ? And you have to run it on the full repository...

I used RESET CLUSTER(XYZ) ACTION(FORCEREMOVE) QMNAME(QM1) QUEUES(YES) and it did the trick for me...

if it is a problem between old and new qmgr, use QMID instead of QMNAME as both old and new qmgrs will probably not have the same QMID.

------------------------------
Francois Brandelik

Original Message:
Sent: Tue September 16, 2025 10:06 AM
From: Tim Zielke
Subject: QALIAS Queue Cluster Resources Still Visible After RESET CLUSTER QUEUE(YES)

Just a note for others who might encounter a similar situation. The RESET CLUSTER(XYZ) QMNAME(QM1) QUEUES(YES) command would never fully work on the cluster full repositories in removing the queues of the forcibly removed queue manager. However, after 90 days from the removal of the queue manager, all the cluster full and partial repositories finally discarded the queue  references themselves. I had to develop extra monitoring to make sure all the AMQ9456 and CSQX456E messages that were being reported daily were only for this forcibly removed queue manager. A bit of a pain, but it eventually worked itself out.

------------------------------
Tim Zielke

Original Message:
Sent: Mon June 16, 2025 09:55 AM
From: Tim Zielke
Subject: QALIAS Queue Cluster Resources Still Visible After RESET CLUSTER QUEUE(YES)

Yes, both FRs are displaying the same result.

------------------------------
Tim Zielke

Original Message:
Sent: Mon June 16, 2025 09:43 AM
From: Erik Houlberg
Subject: QALIAS Queue Cluster Resources Still Visible After RESET CLUSTER QUEUE(YES)

Hi Tim

The reset command can be executed with QMID option (with the qmid of the deleted QM).

As queues exist in multiple MQ clusters (that is different MQ cluster names) then a reset need to be made for each MQ cluster name.

As the QM was broken then a reset had to be done, otherwise I recommend to first remove MQ cluster specification on queues and topics and confirm the removal on the objects in the FRs before removing the MQ cluster specification on the cluster receiver channel and cluster sender channel, only one of each per MQ cluster specification, on the QM that should no longer participate in the MQ cluster. To avoid channels going into retry it is best to keep the channels for some time (without MQ cluster specification) and wait for the channels to become inactive before deleting them.

Just out of curiosity, is it the same result on both FRs ?

Regards, Erik Houlberg

------------------------------
Erik Houlberg

Original Message:
Sent: Mon June 16, 2025 09:08 AM
From: Tim Zielke
Subject: QALIAS Queue Cluster Resources Still Visible After RESET CLUSTER QUEUE(YES)

Hi Erik,

There are not any channel issues going on between the FRs and the new QM1. For QM1, I had to do a dltmqm on the old QM1 (it was in a broken state) and rebuild with a new QM1 with crtmqm. This is why I had to run the RESET CLUSTER FORCEREMOVE QUEUE(YES) on the FR on the old QM1. Only the new QM1 appears in the full repository with a DIS CLUSQMGR. However, I can see DIS QC QALIAS resources for both the old and new QM1 on the full repository. These QALIAS resource do exist in multiple clusters on QM1.

Thanks,

Tim

------------------------------
Tim Zielke

Original Message:
Sent: Mon June 16, 2025 03:38 AM
From: Erik Houlberg
Subject: QALIAS Queue Cluster Resources Still Visible After RESET CLUSTER QUEUE(YES)

Hi Tim
I would check MQ error logs as well as channel status on both QM1 as well as full repository QMs (do you use 1 or 2 ?)
If there are channels in retrying status, then that can hold back cleanup of the repository.

Do you use multiple MQ clusters ?

If a QM is not reflecting with 'dis clusqmgr' on a repository, then there should be no queues visible with 'dis qc' on the repository for that QM.

------------------------------
Erik Houlberg

Original Message:
Sent: Fri June 13, 2025 11:19 AM
From: Tim Zielke
Subject: QALIAS Queue Cluster Resources Still Visible After RESET CLUSTER QUEUE(YES)

I had to do a RESET CLUSTER(XYZ) QMNAME(QM1) QUEUES(YES) command on a cluster full repository, and I was surprised to see that the qalias queue cluster resources for QM1 were still visible after the command was successfully run. I did see the queue manager drop from the full repository with the DIS CLUSQMGR command. I also did see local queues owned by the QM1 drop from full repository with the DIS QC command. However, the DIS QC command is still displaying qalias references for QM1.

I asked AI (or Ultron as I like to call it :-) ), and it said that this could be an expected behavior of qalias queue cluster resources still being visible in the full repository after a RESET CLUSTER QUEUE(YES) command is run. Does anyone know if that is correct or not? I did not see anything stating this behavior in the IBM MQ manual.

------------------------------
Tim Zielke
------------------------------