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 Index » Clustering » (resolved) Problem adding a QM to a cluster

Post new topic  Reply to topic
 (resolved) Problem adding a QM to a cluster « View previous topic :: View next topic » 
Author Message
awatson72
PostPosted: Wed Oct 27, 2004 9:22 am    Post subject: (resolved) Problem adding a QM to a cluster Reply with quote

Acolyte

Joined: 14 Apr 2004
Posts: 69
Location: Freeport, Maine

Here we have a very simple clustering scenario which is presenting difficulty.
I have created a cluster between two distributed QMs, each a full repository. Each has a receiver channel and a sender channel to the other QM. This works exactly as it supposed to.
Now I want to add a third QM, (a Z/OS QM) to the cluster, and following the steps from the cluster manual (Task 2a - page 27), I create a cluster receiver and a cluster sender to one of the full repository QMs. A cluster sender to the other repos QM seems to be automatically created for me.
So far, so good - but when I create a cluster queue on one of the original distributed QMs, if fails to show up on the MF QM. When I attempt to put a message to the queue, I get an error 2085 (object doesn't exist). The channels seem to be working properly, I can't think of what else could be wrong...any thoughts appreciated!
_________________
Andrew Watson
L.L. Bean, Inc.
Back to top
View user's profile Send private message
siliconfish
PostPosted: Wed Oct 27, 2004 9:43 am    Post subject: Reply with quote

Master

Joined: 12 Aug 2002
Posts: 203
Location: USA

Your Z/OS QMGR may notbe updated with the latest cluster info. Check if the cluster queue is visible on Z/OS QMGR by using DIS QCLUSTER(queue_name). If that is not visible, first alter the description of the cluster queue on the distributed queue manager and then check if the cluster queue is visible on Z/OS QMGR and then do a put, if you still have the same issue try REFRESH CLUSTER on the Z/OS QMGR.
_________________
siliconfish
Back to top
View user's profile Send private message
awatson72
PostPosted: Wed Oct 27, 2004 10:10 am    Post subject: Reply with quote

Acolyte

Joined: 14 Apr 2004
Posts: 69
Location: Freeport, Maine

Siliconfish,
I tried the what you suggested but I still can't see the cluster queue on the MF QM when I run display qcluster(<qname>)
Other thoughts?
_________________
Andrew Watson
L.L. Bean, Inc.
Back to top
View user's profile Send private message
siliconfish
PostPosted: Wed Oct 27, 2004 11:19 am    Post subject: Reply with quote

Master

Joined: 12 Aug 2002
Posts: 203
Location: USA

Are you able to see the queue from another repository? and also check if the repsoitory process amqrrfma(don't know what it is on Z/OS) is running on distributed queue managers. Check your SYSTEM.CLUSTER.TRANSMIT.QUEUE on all the repos for any messages related to the repository info.
_________________
siliconfish
Back to top
View user's profile Send private message
offshore
PostPosted: Wed Oct 27, 2004 11:26 am    Post subject: Reply with quote

Master

Joined: 20 Jun 2002
Posts: 222

awatson,

What happens when you issue the the DISPLAY CLUSQMGR(*) command?

The 2 repositories should see all the queue managers in the cluster, including the z/Series machine.
The z/Series machine should show the 2 repository machines along and itself.

I have the opposite setup with 2 z/Series qmgrs as the repositories and the distributed (Windows) as partial repos.

Offshore
Back to top
View user's profile Send private message Send e-mail
awatson72
PostPosted: Wed Oct 27, 2004 12:11 pm    Post subject: Reply with quote

Acolyte

Joined: 14 Apr 2004
Posts: 69
Location: Freeport, Maine

The cluster queues can be seen from the other distributed QM and vica versa.
The display clusterqmgr(*) command shows all the cluster QMs on all three of the QMs.
The SYSTEM.CLUSTER.TRANSMIT.QUEUE shows no messages, but the SYSTEM.CLUSTER.REPOSITORY.QUEUE shows a handful of messages. I get the impression that what goes on in that queue is somewhat mysterious and is OK to stay that way...
The /amqrrmfa processes are running on the dist QMs - not sure how to check on the Z/Series.
_________________
Andrew Watson
L.L. Bean, Inc.
Back to top
View user's profile Send private message
siliconfish
PostPosted: Wed Oct 27, 2004 12:40 pm    Post subject: Reply with quote

Master

Joined: 12 Aug 2002
Posts: 203
Location: USA

Would you be able to do a REFRESH CLUSTER from the repository?
BTW repository process on Z/OS runs as MQ MASTER.
_________________
siliconfish
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Wed Oct 27, 2004 2:16 pm    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7722

FR = Full Repository, your distributed.
PR = Partial Repository, your z/OS.

If you create Q1 on FR, PR will not see it right away. this is MQ clustering as designed. But the other FR will see it right away. All FRs know about all queues.

When an app on the PR tries to put to Q1 that does not exist locally, the PR makes a subscription request to the FR to get info about Q1. Now, for the next 90 days, PR will know about Q1.

If the app on PR's QM tries to put to Q1, and specifies PR's QM on the MQOPEN, it will fail, because the app is saying I only want to put to Q1 if it lives on PR's QM. Make sure the putting app does not specify any QM on the MQOPEN.


REFRESH cannot be run on the FRs. It has to be run on a PR. It would not help here anyway. REFRESH pushes info from a PR out to the FRs, it does not suck info into a PR.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
siliconfish
PostPosted: Wed Oct 27, 2004 3:26 pm    Post subject: Reply with quote

Master

Joined: 12 Aug 2002
Posts: 203
Location: USA

Quote:
REFRESH cannot be run on the FRs.

I donot agree with the above statement, u can issue REFRESH CLUSTER REPOS(NO) which is a deafault option from a FR.

Quote:
It has to be run on a PR. It would not help here anyway. REFRESH pushes info from a PR out to the FRs, it does not suck info into a PR.

I would also not agree with the above statement.
As per my understanding from the mq cluster manual

Quote:
Using REFRESH CLUSTER(clustername) REPOS(NO) provides the default
behavior. The queue manager will retain knowledge of all cluster queue manager
and cluster queues marked as locally defined and all cluster queue managers that
are marked as full repositories.
I infer that it will rebuild all the information related to the cluster queue which are not locally defined.
_________________
siliconfish
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Wed Oct 27, 2004 5:25 pm    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7722

You are right about the REPOS(NO) option allowing you to run it on a FR. I always run it with REPOS(YES), and so have gotten used to the fact that you can't run it on a FR (if you use REPOS(YES)). Sorry for the misleading info.

Now, if you issue REFRESH on a PR, it will most definitly not pull in info from all other QMs in the cluster. It starts fresh in the cluster, as if you just introduced it, meaning it only knows about its local queues, and will only learn about new queues as it needs them.

Try it and see.

FR1 has a local clustered queue called PETER.FR1.LOCALQ
FR2 has a local clustered queue called PETER.FR2.LOCALQ

PR1 has never put to either of these queues.

No matter how many times you issue REFRESH on PR1, it will not know about PETER.FR1.LOCALQ or PETER.FR2.LOCALQ.

Now use amqsput, connect to PR1, and do a put to PETER.FR1.LOCALQ. PR1 will now show PETER.FR1.LOCALQ. But do a REFRESH on PR1, and that queue is gone as far as PR1 is concerned, until you try and use it again.

REFRESH tells the QM to wipe clean its knowledge of the whole cluster, start from scratch, which for a PR means knowledge of only its local queues and channels. If you issue REFRESH on a FR, it will again start fresh, but since a FR is supposed to know about every queue, a FR will have info about all clustered queues on all cluster QMs after a REFRSH with REPOS(NO).

I stand behind my statement that a REFRESH command will not help awatson72 if run on his PR, since that will not suck in info from the FRs, or any other PR for that matter.
But I think there is no problem. The PR will not know about his queues on the FRs until he tries to put to them from PR without specifying PR in the MQOPEN call.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
awatson72
PostPosted: Tue Nov 16, 2004 10:15 am    Post subject: Reply with quote

Acolyte

Joined: 14 Apr 2004
Posts: 69
Location: Freeport, Maine

Thanks for the discussion about this problem, and apologies for not updating the post until now.

The bottom line seemed to be that I would need to attempt to put a message on the cluster queue from the mainframe (PR) QM WITHOUT specifying the QM name in the MQOPEN call. The job that tries to put messages to this queue has no QM defined which means it goes to the default QM, which this PR is. (Also the only QM...)

The return code 2085 still indicates the the queue was not found.

Interestingly, the queue now shows up as a clustered queue where it didn't after I created the queue on one of the FR QMs. The only event that I can attibute this to is the QM restarting which happened at some point recently.

So I am still plagued with this problem. When I had the Z/OS QM defined as a FR, this was not an issue, but I don't want three repositories, (heard bad things), so I'd rather it not be a FR.
_________________
Andrew Watson
L.L. Bean, Inc.
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Tue Nov 16, 2004 7:31 pm    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7722

awatson72 wrote:

The bottom line seemed to be that I would need to attempt to put a message on the cluster queue from the mainframe (PR) QM WITHOUT specifying the QM name in the MQOPEN call. The job that tries to put messages to this queue has no QM defined which means it goes to the default QM, which this PR is. (Also the only QM...)


That fact that the QM is the default QM only comes into play when you issue an MQCONN call with a blank QM name. In that case, you MQCONN to the default QM.

Whether a QM is a default or not has zero implications at MQOPEN time, or any other time besides the MQCONN call with a blank QM name. When you issue an MQOPEN with just a queue name and no QM name, name resolution takes place. If the local QM can't find a queue locally (either a local Q or a locally defined remote queue def) by the name specified in your program, then it quieries the Full Repositories for info if it is a clustered QM.

If you get a 2085 at this point, it is one of 2 things (assuming you really are specifying a blank QM name on the MQOPEN call):
A. The queue name is a typo - remember they are case sensitive.
B. Your PR does not have 100% connectivity with the FRs.


If it works when you make this QM a FR, I assume its because when you make it a FR, you define a pair of manual CLUSSNDRs between the 2 QMs in question. So I would bet that this means the CLUSRCVRs on one of your QMs is not 100% right when it is acting as a PR, and this is preventing the Auto Definition of the cluster sender channel to be made, and that is holding up the subscrition request and/or reply for this queue. If the PR can't get the q info from the FR, then it doesn't know about the queue, and you get your 2085.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
awatson72
PostPosted: Fri Nov 19, 2004 11:39 am    Post subject: Reply with quote

Acolyte

Joined: 14 Apr 2004
Posts: 69
Location: Freeport, Maine

Peter,

I'm embarassed to report that the problem is solved, but I didn't do anything.
The connectivity between the PR and FR has been fine all along because other non-cluster channels exist between these QMs and haven't had issues so that can't be it. No typos in queue names either.
I resubmitted the job which puts a test message to the CLUSQ on the Z/OS PR, and it did just what it was supposed to.
Wish I knew what was up before. I'll let folks know if I find out.

Andrew
_________________
Andrew Watson
L.L. Bean, Inc.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » Clustering » (resolved) Problem adding a QM to a cluster
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.