| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Queue Manager missing SYSTEM.CLUSTER.* queues... |
« View previous topic :: View next topic » |
| Author |
Message
|
| Allan Mackay |
 Posted: Thu Sep 02, 2010 7:07 am Post subject: |
 |
|
Apprentice
Joined: 08 Jul 2010
Posts: 29
|
Yes, the queues being missing is a mystery. The INP2 concats have been commented out. Had they been left in, the queues would have been redefined at startup...
We have the same issue with another production QM too. I took over the admin of MQ some 10 years ago from someone that had their 'own ideas'. This is the first time we've tried clustering though so we didn't spot this before. It's likely the production QMs have been missing their queues for at least that 10 years!
Thanks everyone for your help on this. We will be restarting the QM next Tuesday (7th September) morning (0600 UK time) and going forward with the clustering again. Look out for more woes or (hopefully) a success  |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Thu Sep 02, 2010 8:10 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| fjb_saper wrote: |
You need also the cluster repository process to run and check for the input count on the SYSTEM.CLUSTER queues.
My guess is talk with your system admin. Make sure all is set up correctly to enable cluster operations and then bounce the qmgr.
Now you need to look at translating that to zOS terminology...  |
Thanks to Mr Butcher for putting this in zOS terminology:
| Quote: |
the repository manager process, that reads the system.cluster.command.queue runs in the CHIN address space.
If the CHIN was started without the cluster queues being present, the repository manager ends with that 2085 message.
Code:
CSQX410I xxxx CSQXREPO Repository manager started
CSQX036E xxxx CSQXREPO Unable to open SYSTEM.CLUSTER.COMMAND.QUEUE,
MQCC=2 MQRC=2085
CSQX411I xxxx CSQXREPO Repository manager stopped
I do not know any other way to restart thje repository manager then restarting the CHIN. Maybe you can do that and leave the MSTR up..... |
It is great that on zOS, this does not require a restart of the qmgr.
However I have been told that on Distributed, if the repository manager is not running, you have to restart the qmgr. As you also mentioned zLinux, I thought I'd add this info.
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Sep 02, 2010 12:59 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| fjb_saper wrote: |
| ...I have been told that on Distributed, if the repository manager is not running, you have to restart the qmgr... |
There are ways of restarting the repos manager, but it's not guaranteed, and depending on why the process failed in the first place, there's no guarantee a restart will do it either.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Fri Sep 03, 2010 1:41 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
| Quote: |
| Yes, the queues being missing is a mystery. The INP2 concats have been commented out. Had they been left in, the queues would have been redefined at startup... |
Maybe they have never been defined?!? there are multiple input members on z/OS, one is for distributed queueing, one is for clustering, one is for whatever. If the guy that set up the queuemanager thought he will not use clustering, then maybe it was commented out before the first start so the queues have never been created?!?
I have queuemanagers like this. In addition, when creating new queuemanagers, i only define the SYSTEM.CLUSTER objects when i know i will use clustering. If not, i leave them out. I do not want to have a repository manager running wthout need (although it will not be very expensive).
If i want to use clustering, i still can define these objects ......
Just my guess why the objects where missing.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| Allan Mackay |
| Posted: Wed Sep 08, 2010 2:41 am Post subject: |
|
|
Apprentice
Joined: 08 Jul 2010
Posts: 29
|
Ok, ongoing saga...
We bounced the QM, the repository manager is now running and everything looks to be ok on that front. Our attempt to actually re-implement the cluster failed. Still trying to get my head around what actually happened so I won't trouble you guys with that particular woe. I've put it down to tiredness for now... If I do get stuck, I will be back!
Cheer |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Sep 08, 2010 6:10 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9471
Location: US: west coast, almost. Otherwise, enroute.
|
You might want to recreate the qmgr startup proc (copy the IBM-supplied version it from the installation library). Copy the BSDS and pageset DDs from the old proc to the newly recreated one. Then restart the qmgr.
_________________
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 |
|
|
|
|
|
|
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
|
|
|
|
