| Author |
Message
|
| smeunier |
 Posted: Wed Jan 02, 2019 1:21 pm Post subject: Partial Repository without any current FR's |
 |
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
In a classic cart before the horse scenario...............
Two servers (AIX V7.5) were scheduled for decommissioning. These servers held the FR's for a cluster. Two z/os servers(V8.0) were PR's in this cluster.
The servers with the FR's were decommissioned without due diligence being performed to remove the two PR from the cluster beforehand. Now that the FR's are gone, I'm finding it increasingly difficult to clean/remove the PR's from the cluster (that really does not exist any longer). I have performed all the normal action for removing a QMGR from a cluster on the PR's. The actions are taken and by all appearance it seems that the PR QMGRS were out of the cluster. However, I'm now getting messages that the CLUSTER SDR channels to the FR are failing to start (of course, the servers are gone and the channels deleted!), even though the manually defined channels have been deleted. It appears that the cluster went ahead an created auto cluster SDR channels to complete communications back to the FR, which again are no longer in service.
How can I clean up this mess and remove these PR's from the cluster(that really no longer exists in nature, but MQ seems to think it still does)?!
If I did a REFRESH CLUSTER with REPOS(YES), this will clear the local cluster cache(PR) specifically the channels AUTO/MANUAL defined? It won't be able to communicate with the FR to rebuild, as it does not exist, so I'm not sure what the state would be. I have an opportunity to perform this action in the next week or so when one of the PR's will be offline.
The desired state, is for the PR's to no longer be a part of or know about the cluster as if it never belonged to it. With the FR's gone, it is becoming difficult to get this clean up.
Thoughts? |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Jan 02, 2019 1:27 pm Post subject: Re: Partial Repository without any current FR's |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| smeunier wrote: |
| Thoughts? |
You're 
Find the genius who took out the FRs and take him out before they get you. It won't help but you'll feel better.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jan 02, 2019 1:29 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
If it was me (and it isn't), I'd make sure all the PRs had their CLUSTER attribute blanked out, endure 90 days of error messages and hope that it all came right when the repository data automatically expired.
Hosed up clusters are the worst to fix.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jan 02, 2019 1:33 pm Post subject: Re: Partial Repository without any current FR's |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| smeunier wrote: |
| (of course, the servers are gone and the channels deleted!) |
Could you put a temporary server on the IP address / hostname of the missing FRs, do a refresh and then decommission the cluster correctly?
You might still get problems because the FRs don't have the QMIDs of the originals but it's an alternative.......
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Jan 02, 2019 2:03 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Jan 02, 2019 3:12 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Vitor wrote: |
If it was me (and it isn't), I'd make sure all the PRs had their CLUSTER attribute blanked out, endure 90 days of error messages and hope that it all came right when the repository data automatically expired.
Hosed up clusters are the worst to fix. |
IMHO, most hosed up clusters are self-inflicted wounds. This one certainly qualifies.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| hughson |
| Posted: Thu Jan 03, 2019 1:14 am Post subject: Re: Partial Repository without any current FR's |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| smeunier wrote: |
| If I did a REFRESH CLUSTER with REPOS(YES), this will clear the local cluster cache(PR) specifically the channels AUTO/MANUAL defined? It won't be able to communicate with the FR to rebuild, as it does not exist, so I'm not sure what the state would be. |
A REFRESH CLUSTER on a PR removes all the information it has received from FRs, so therefore the next time it needs to know where Q-blah lives it asks the FRs again. Adding REPOS(YES) to the command means it ALSO deletes the details about the FRs and has to start again as if it had never been in the cluster before.
To put another way, REFRESH CLUSTER REPOS(YES) means you have to start again from scratch with manual channel defs. If you have deleted said manual channel defs then there is nothing to start again from and so the PR will not be repopulated.
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| smeunier |
| Posted: Thu Jan 03, 2019 7:28 am Post subject: |
|
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
| Quote: |
| If it was me (and it isn't), I'd make sure all the PRs had their CLUSTER attribute blanked out, endure 90 days of error messages and hope that it all came right when the repository data automatically expired. |
The cluster attribute points to another cluster. The two z/os qmgrs were partial repositories for 2 other clusters. They are also FR for another cluster. So QMGRA and QMGRB are PR for CLUSTER1 and CLUSTER2. The are FR to CLUSTER3
QMGRA/B were successfully removed from CLUSTER1. CLUSTER2, which had its FR's blown away, still has residual CLUSTER2 artifacts on QMGRSA/B. CLUSTER3 is to remain intact and is just fine. QMGRA/B are the FR's for this cluster. |
|
| Back to top |
|
|
| smeunier |
| Posted: Thu Jan 03, 2019 7:46 am Post subject: |
|
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
Morag,
| Quote: |
| To put another way, REFRESH CLUSTER REPOS(YES) means you have to start again from scratch |
As I mentioned in previous reply, these z/os QMGRS are PR's for this cluster(CLUSTER2), but they are also FR's for another cluster(CLUSTER3).
I need to insure that if I issue: REFRESH CLUSTER(CLUSTER2) REPOS(YES) that CLUSTER3 information/configuration is not disturbed. I assume that only CLUSTER2 information will be touched. I also need to insure that any of the cluster queues it thinks it has are not deleted. The cluster attributes to those queues were altered last week to '', but the CLUSTER2 repository still believes it owns them(or cluster to it). The goal is to rid CLUSTER2 from the PR's and leave CLUSTER3 untouched. We have a window of opportunity where these z/os QMGRS will be offline (2 day rotating interval). If refresh to CLUSTER2 is the magic key for final clean up, then that is when it will get done.
I originally had this step(REFRESH) as part of my script to clean this up, but after post clean up everything looked good. So I nix'ed it. Looks like it should have been done. |
|
| Back to top |
|
|
| smeunier |
| Posted: Thu Jan 03, 2019 8:05 am Post subject: |
|
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
| Quote: |
| IMHO, most hosed up clusters are self-inflicted wounds. This one certainly qualifies. |
And nothing worse then having to be the medic for someone else's self-inflicted wound  |
|
| Back to top |
|
|
| hughson |
| Posted: Thu Jan 03, 2019 7:37 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| smeunier wrote: |
Morag,
| Quote: |
| To put another way, REFRESH CLUSTER REPOS(YES) means you have to start again from scratch |
As I mentioned in previous reply, these z/os QMGRS are PR's for this cluster(CLUSTER2), but they are also FR's for another cluster(CLUSTER3).
I need to insure that if I issue: REFRESH CLUSTER(CLUSTER2) REPOS(YES) that CLUSTER3 information/configuration is not disturbed. I assume that only CLUSTER2 information will be touched. I also need to insure that any of the cluster queues it thinks it has are not deleted. The cluster attributes to those queues were altered last week to '', but the CLUSTER2 repository still believes it owns them(or cluster to it). The goal is to rid CLUSTER2 from the PR's and leave CLUSTER3 untouched. We have a window of opportunity where these z/os QMGRS will be offline (2 day rotating interval). If refresh to CLUSTER2 is the magic key for final clean up, then that is when it will get done.
I originally had this step(REFRESH) as part of my script to clean this up, but after post clean up everything looked good. So I nix'ed it. Looks like it should have been done. |
REFRESH CLUSTER(CLUSTER2) REPOS(YES) should only touch resources in the PR that are for CLUSTER2.
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jan 04, 2019 10:18 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
I believe for your PRs at this point it's no longer a refresh cluster that you need as the cluster no longer exists but a RESET CLUSTER command with the QMGR and or the QMID...
Have fun  
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| hughson |
| Posted: Sun Jan 06, 2019 3:07 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| fjb_saper wrote: |
I believe for your PRs at this point it's no longer a refresh cluster that you need as the cluster no longer exists but a RESET CLUSTER command with the QMGR and or the QMID...
Have fun |
RESET CLUSTER will not empty the data from the PR. That's what REFRESH CLUSTER does.
Please expand on what you think RESET CLUSTER will achieve on a disconnected PR.
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
|
|
