By having both the new and the old QM in the cluster you might have seen other QMs in the cluster trying to send to the old QM that no longer existed in your eyes. You might have seen channels retrying in an attempt to get to a QM that no longer really existed. Although if the new QM had the same IP and port this might not be an issue.
If you issued cluster commands from other QMs and you referenced this QM by name only you could not be sure which QM the cluster would attempt to apply the command to, the new one or the old one (this is why the RESET CLUSTER command has you use the QMID)
So if you plan on deleting QM1 and then recreating QM1, make sure you uncluster QM1 first before rebuilding it and reclustering it.
If you don't do that and find yourself with 2 QMs with the same friendly name then the course of action you took was correct (RESET CLUSTER command issued from one of the FRs). _________________ Peter Potkay
Keep Calm and MQ On
Thanks. I didn't uncluster it first, I just stopped it in quiesce mode because I didn't plan on deleting, but on applying the latest patch on v6. I was hoping it would start normally after migration, but it did not. The same thing happened on that host, with that qmgr when it was migrated from v5.3 to 6.0. I have reported strange overflowed reason code:
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum