| Author |
Message
|
| awatson72 |
 Posted: Wed Oct 27, 2004 9:22 am Post subject: (resolved) Problem adding a QM to a cluster |
 |
|
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 |
|
 |
| siliconfish |
| Posted: Wed Oct 27, 2004 9:43 am Post subject: |
|
|
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 |
|
|
| awatson72 |
| Posted: Wed Oct 27, 2004 10:10 am Post subject: |
|
|
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 |
|
|
| siliconfish |
| Posted: Wed Oct 27, 2004 11:19 am Post subject: |
|
|
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 |
|
|
| offshore |
| Posted: Wed Oct 27, 2004 11:26 am Post subject: |
|
|
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 |
|
|
| awatson72 |
| Posted: Wed Oct 27, 2004 12:11 pm Post subject: |
|
|
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 |
|
|
| siliconfish |
| Posted: Wed Oct 27, 2004 12:40 pm Post subject: |
|
|
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 |
|
|
| PeterPotkay |
| Posted: Wed Oct 27, 2004 2:16 pm Post subject: |
|
|
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 |
|
|
| siliconfish |
| Posted: Wed Oct 27, 2004 3:26 pm Post subject: |
|
|
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 |
|
|
| PeterPotkay |
| Posted: Wed Oct 27, 2004 5:25 pm Post subject: |
|
|
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 |
|
|
| awatson72 |
| Posted: Tue Nov 16, 2004 10:15 am Post subject: |
|
|
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 |
|
|
| PeterPotkay |
| Posted: Tue Nov 16, 2004 7:31 pm Post subject: |
|
|
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 |
|
|
| awatson72 |
| Posted: Fri Nov 19, 2004 11:39 am Post subject: |
|
|
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 |
|
|
|
|
