| Author |
Message
|
| lindita27 |
 Posted: Wed Jan 29, 2014 4:40 am Post subject: PR encountered RC 2087 when accessing cluster q |
 |
|
Newbie
Joined: 29 Jan 2014
Posts: 3
|
We encountered a problem yesterday with the PR(QM03) whereby it is unable to access cluster queues (local QA on FR), although it was successfully implemented and operational for over 1 year. The error 2087 is captured by a program attempting to put a message into the clustered queue through QM03.
Situation:
1. Display qcluster (*) at QM03 : return empty results (although expectation is a list of QA from QM01 & QM02 shared into the cluster)
2. Display clusqmgr(*) at QM03 : return a list of FR (QM01 and QM02)
3. QM01 is able to access and put message into a cluster q on QM03
Action done:
1. Checked cluster channels between FR and PR (QM01, QM02,QM03) are active. Even tried restarting the cluster channels successfully
2. Qdepth of System.cluster.command.queue & System.cluster.transmit.queue are empty on FR (QM01, QM02)
3. No errors found in Qmgr logs in all 3 queue managers
4. Checked that all queues are put enabled
5. Refresh cluster command issued in PR (QM03)
4. Verified QMIDs of Qmgrs in the cluster - consistent across FR & PR
Environment:
MQ version : WMQ7
OS : FR (QM01&QM02) - AIX 6
PR (QM03) - z o/s
Any pointers on finding the root cause & resolution is very much appreciated. Thanks. |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Wed Jan 29, 2014 5:12 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
On the MQOPEN or MQPUT1 call, what did the application specify for the ObjectName and ObjectQMgrName parameters?
With that information, then go thru the options here:
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.tro.doc/q041500_.htm
Maybe its as simple as the app coded BaBaBooey for the ObjectQMgrName field on the MQOPEN call, resulting in the 2087.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| lindita27 |
| Posted: Wed Jan 29, 2014 5:40 am Post subject: |
|
|
Newbie
Joined: 29 Jan 2014
Posts: 3
|
Hi. Thanks for the prompt reply to the post.
The program specifies the QA name (shared in cluster) on QM01 (FR). My view is that the issue is not with the app as this is the same app working since day-1 in this environment. Just to add-on, the same version of the program and MQ Cluster setup is working in another test environments (i.e. SIT).
Some additional information:
1. Verified that the QAs on FR QM01 are shared into the correct cluster name. These cluster queues are visible in FR QM02
2. Verified q properties and setup to be similar to another test environment which is "working".
3. No config/property change performed in QM03 prior to the problem.
Somehow, the PR (QM03) seems to be "disconnected" from the cluster since it can't list existing cluster queues although other checks (e.g. chstatus, dis clusqmgr etc) indicates that QM03 is still active in the cluster. Am unsure if this problem is a result of the "periodic internal mq cluster update/cleanup", and if so how to verify and fix it.
Thks. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Jan 29, 2014 6:51 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
Unless you know what the app specified for the ObjectName and ObjectQMgrName parameters on the MQOPEN that got the 2087, you are purely making educated guesses as to what is wrong. It might be a problem at the MQ Infra structure layer, it might be a problem with the app. THat it works in other environments or that it worked before is no guarantee that the app did the right thing for this MQOPEN in this environment.
What I would do next is connect to QM03 with amqsput or amqsputc to open the queue in question. Here you are in control and you know what if anything you are specifiying for the ObjectQMgrName. Just because you open the queue from QM03 using amqsput(c) doesn't mean you have to put a message. THe name resolution is 100% done at MQOPEN time. If the MQOPEN works, just hit enter again and end amqsput(c) without sending a message. Harmless. If it fails, you get a MQRC and you know what you did to get it.
In my opinion every MQ cluster should have a set of test queues used exclusively by the MQ Admin to test connectivity and load balancing between the QMs in the cluster.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Wed Jan 29, 2014 6:57 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1231
Location: Gold Coast of Florida, USA
|
At QM3 when you did the "refresh cluster(bla)", did you also say REPOS(YES)?
Looks like QM3 has not received updates from the cluster FRs in a while. The extra param I mention is a swift kick to QM3 about the cluster. Use amqsput QA but do not actually put a message. This will go out and subscribe to the queue definition once again.
You can do what Peter says first to see if the cluster info at QM3 is stale. |
|
| Back to top |
|
|
| lindita27 |
| Posted: Thu Jan 30, 2014 8:36 pm Post subject: |
|
|
Newbie
Joined: 29 Jan 2014
Posts: 3
|
Thanks for the suggestions.
Will try out using a amqputc program and also reissue the refresh cluster command with repos param. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jan 31, 2014 6:06 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
If there is a problem with cluster configuration or app coding, the refresh cluster will do nothing at best and offer only temporary relief with a false sense of problem solved at worst.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Fri Jan 31, 2014 8:19 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1231
Location: Gold Coast of Florida, USA
|
More to Peters point, I will ask questions intended to determine if the cluster is correctly formed in the first place:
- Does FR QM01 have an explicit cluster sender channel to FR QM02?
- Does FR QM02 have an explicit cluster sender channel to FR QM01?
- Are these the only FRs for this cluster?
Because an FR will only forward cluster updates to Qmgrs to which it has explicitly defined cluster sender channels. All other Qmgrs will only get updates about cluster objects to which they subscribe (and they establish such a subscription by accessing a cluster object). |
|
| Back to top |
|
|
|
|
