ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum IndexGeneral DiscussionCluster Queue not up to date

Post new topicReply to topic
Cluster Queue not up to date View previous topic :: View next topic
Author Message
OzgurAydin
PostPosted: Tue Oct 24, 2017 1:27 am Post subject: Cluster Queue not up to date Reply with quote

Apprentice

Joined: 08 Sep 2008
Posts: 26

Hi,
We have a MQ Cluster consisting of multiple queue managers residing on both the mainframe side and the open side. Last weekend we changed one queue property of a mainframde queue. We had a maintanence break and we did put inhibited one queue. All the Queue Manager got their cluster queues refreshed and up to date. But one of them did not change the status of the clustered queue.
The one WHO did not change was a partial repository. Did anyone of you had such an issue with MQ Cluster ?
The version of the open side is 7.5
The version of the mainframe MQ is 9

Thanks
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Tue Oct 24, 2017 5:26 am Post subject: Reply with quote

Grand Poobah

Joined: 18 Nov 2003
Posts: 19758
Location: LI,NY

Avenues of research:
Check the communication between full reps. Was the full rep the PR is attaching to correctly updated?

Check the communication between the PR and the full reps. Does it flow as expected?

Check the queue bindings, on the putting app, are they bindings not fixed?
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
bruce2359
PostPosted: Tue Oct 24, 2017 6:40 am Post subject: Re: Cluster Queue not up to date Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8156
Location: US: west coast, almost. Otherwise, enroute.

OzgurAydin wrote:
But one of them did not change the status of the clustered queue.

On the affected qmgr, are the CLUSSDR and CLUSRCVR channels to/from the FR in RUNNING state?

Are the CLUSSDR and CLUSRCVR channels between the two FRs in RUNNING state?
_________________
I would tell you a UDP joke, but you might not get it.
Back to top
View user's profile Send private message
tczielke
PostPosted: Tue Oct 24, 2017 8:58 am Post subject: Reply with quote

Shaman

Joined: 08 Jul 2010
Posts: 738
Location: Illinois, USA

Yes, I have seen quirky behavior like this before with clustering, and the underlying issue is not always a connectivity issue between the partial and full repositories. MQ clustering seems to have quirks, based on my own personal experience.

Please note that IBM recommends that you check all the partial repositories after doing any kind of clustering change like this to confirm that the command did fully take.

https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.0.0/com.ibm.mq.adm.doc/q021225_.htm#q021225_
_________________
MQ administrator since 2010.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Wed Oct 25, 2017 5:04 am Post subject: Reply with quote

Grand Poobah

Joined: 18 Nov 2003
Posts: 19758
Location: LI,NY

tczielke wrote:
Yes, I have seen quirky behavior like this before with clustering, and the underlying issue is not always a connectivity issue between the partial and full repositories. MQ clustering seems to have quirks, based on my own personal experience.

Please note that IBM recommends that you check all the partial repositories after doing any kind of clustering change like this to confirm that the command did fully take.

https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.0.0/com.ibm.mq.adm.doc/q021225_.htm#q021225_


For a check if the operation was successfully communicated to the offending PR, and as it is a queue inhibit, you would need to check that the operation is reflected in each of the FRs, that the PR is subscribed for the queue at at least one of the FRs and that the PR's SCCQ (system.cluster.command.queue) is being processed by the queue manager and is empty...

Even in a small cluster it pays to have the FRs only carry cluster command traffic and no data traffic as it helps isolate any communications problems between command traffic between FR and PR.

If the FRs did not get the queue inhibit information, then clearly you have done something wrong in the handling of communications between the originating PR and the FRs.

Have fun
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexGeneral DiscussionCluster Queue not up to date
Jump to:



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
Protected by Anti-Spam ACP


Theme by Dustin Baccetti
Powered by phpBB 2001, 2002 phpBB Group

Copyright MQSeries.net. All rights reserved.