| Author |
Message
|
| 9A5YY |
 Posted: Fri Dec 10, 2010 4:46 am Post subject: Unable to add and remove queue manager from MQ cluster |
 |
|
Voyager
Joined: 27 Sep 2005
Posts: 99
Location: Croatia
|
I have got 4 z/OS queue managers V6.0 in MQ cluster. They are also repositories. I have got problem to remove Windows queue managers from MQ cluster. Also Windows queue managers in cluster cannot put massages to the shared cluster queues on the z/OS qmgrs. That's the main reason to delete it. The main problem is: It is not possible to update repository. Now the windows queue manager is suspended and deleted but still there are three of them with the same name but different qmid in the cluster and they cannot be removed with the commands:
RESET CLUSTER(clustername) QMNAME(qmname) ACTION(FORCEREMOVE)
and
RESET CLUSTER(clustername) QMID(qmid) ACTION(FORCEREMOVE)
This moment I have got 3 of them with the same name which cannot be removed. They does not exist anymore.
Maybe the following command can help me:
REFRESH CLUSTER(clustername) REPOS(YES)
I didn't use it.
Also there is a message in the log:
CSQX507E: csect-name Channel channel-name is in-doubt,
connection conn-id (queue manager qmgr-name)
Auto-defined channels of deleted qmgr are in-doubt.
Also, command RESOLVE CHANNEL didn't help.
Does anyone have got idea what to do? Last time when I had the same problem the restarting of z/OS qmgrs solved problem and requests for FORCEREMOVE was proccesed. |
|
| Back to top |
|
 |
| Mr Butcher |
| Posted: Fri Dec 10, 2010 5:17 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
| Quote: |
| Also Windows queue managers in cluster cannot put massages to the shared cluster queues on the z/OS qmgrs. That's the main reason to delete it. |
why not? from a windows point of view, its just a cluster queue. its the z/OS mca that puts it into the shared queue. (if you are really talking about a shared queue that resides in the CF).
sometimes it takes some time for the cluster to clean up things. especially when cleaning up.
however, if you already had this situation with a bad cleanup procedure, why dont you follow the recommended procedure in the cluster manual this time and remove those qmgrs before they are unavailable?
what was the output of the resolve channel and reset cluster commands?
cardfully read the comments of the REFRESH CLUSTER REPOS(YES) in the manual. it also reads, that REPOS(YES) can not be used on a full repository, and you said your 4 z/OS are full ones.
but imho ... try to get rid of that indoubt channel, then the remove should work.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| 9A5YY |
| Posted: Fri Dec 10, 2010 6:10 am Post subject: |
|
|
Voyager
Joined: 27 Sep 2005
Posts: 99
Location: Croatia
|
| I resolved again all in-doubt auto-defined channels and it works now. The queue managers are deleted from repository. Probably I didn't do on all of them before. |
|
| Back to top |
|
|
| 9A5YY |
| Posted: Fri Dec 10, 2010 6:42 am Post subject: |
|
|
Voyager
Joined: 27 Sep 2005
Posts: 99
Location: Croatia
|
| We don't use shared queues in CF. We use cluster queues defined on the z/OS qmgrs. I added once again Windows queue manager to the MQ cluster but again it cannot send messages to the cluster queues on the z/OS. The Reason code is 2085. What to do? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Dec 10, 2010 7:34 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Stop trying to send messages to the wrong queue manager.
2085 is an application issue, not a configuration issue. |
|
| Back to top |
|
|
| nathanw |
| Posted: Fri Dec 10, 2010 7:38 am Post subject: |
|
|
Knight
Joined: 14 Jul 2004
Posts: 550
|
2085 0x00000825 MQRC_UNKNOWN_OBJECT_NAME
so the app is trying to connect to something that doesnt exist as jeff says
_________________
Who is General Failure and why is he reading my hard drive?
Artificial Intelligence stands no chance against Natural Stupidity.
Only the User Trace Speaks The Truth  |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Dec 10, 2010 9:04 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| The Reason code is 2085. What to do? |
This is insufficient information.
Exactly what were you doing when you received the 2085? For example, were you issuing s START CHANNEL command?
Were you running an application (like amqsput)?
_________________
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 |
|
|
| Mr Butcher |
| Posted: Sun Dec 12, 2010 11:32 pm Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
"shared queue" is something different on z/OS then a "queue shared inthe cluster". please avoid using "shared queues" unless it is not really a queue that resides in the z/OS CF.
i assume your windows queuemanager never joined the cluster correctly, or your configuration is not correct, or both.
maybe its worth to show us some displays......
"dis clusqmgr(*) all" from both Windows and z/OS
maybe also the clsuter channels and channel status if z/OS Fr does not know about the windows qmgr or vice-versa.
what queue does your application is trying to put too? show us the name used on windows. show us the "dis qcluster" for that queue from the FR
_________________
Regards, Butcher |
|
| Back to top |
|
|
| 9A5YY |
| Posted: Tue Dec 14, 2010 4:07 am Post subject: |
|
|
Voyager
Joined: 27 Sep 2005
Posts: 99
Location: Croatia
|
| I received 2085 when I tried to send messages to the cluster queues on the z/OS qmgrs from Windows qmgr. It was obvious that Windows qmgr wasn't able to communicate with the qmgrs in the MQ cluster. The uninstall and install of the MQ on the windows server didn't helped. Finally, is solved the problem. I replaced the windows server and installed the Windows queue manager with same name on it. Now everything works fine! Thanks for help! |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Tue Dec 14, 2010 4:36 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
this sounds to me like you changed the wheels when the light was not burning. you should have investigated WHY you where not able to communicate with the cluster, not just performing one uninstall / reinstall after the other wihtout searching for the real cause ....... 
however, good luck with this working mehtod ..... 
_________________
Regards, Butcher |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Dec 14, 2010 5:41 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
I strongly recommend reading through the WMQ Queue Manager Clusters manual.
In the clusters manual you will find detailed instructions on how to configure a cluster, and verify that it works. I doubt that uninstalling and reinstalling software fixed the problem you encountered. Rather, I suspect that you did not validate that the new qmgr was, in fact, fully connected to a Full Repository.
_________________
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 |
|
|
|
|
