| Author |
Message
|
| jmeier |
 Posted: Thu Sep 04, 2003 5:11 am Post subject: [SOLVED] Encountering 2189 MQRC_CLUSTER_RESOLUTION_ERROR |
 |
|
Apprentice
Joined: 30 Aug 2002
Posts: 46
Location: Minneapolis
|
I am suddenly encountering the MQRC_CLUSTER_RESOLUTION_ERROR in one of our testing environments. This environment worked in the past, yet this week this error is occuring. I noticed that many of you have had seen this error, but I haven't seen any resolutions posted, and it is new to our environment. What are some of the ways to get around this error?
Our environment is NT, the application that this error is happening on is written in VB. We have recently upgraded to MQ 5.3. We have 2 other development/test environments running on the same server and they both run cleanly. Any help is appreciated since our release is in jeapardy of being delayed due to this error.
_________________
Joe Meier
Last edited by jmeier on Tue Sep 16, 2003 9:35 am; edited 2 times in total |
|
| Back to top |
|
 |
| mqonnet |
| Posted: Thu Sep 04, 2003 7:21 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
When you try to access a clustered queue that is not yet Publicized you would get this error. Generally you would get this when you have defined a cluster queue on a full repos qm and you have an application that tries to access this queue connecting itself to a partial-repos qm. In this case what happens is the queue was not yet publicized and hence not known to the repos cache that is held by the partial repos qm. The first time you try to acces such a queue, a request message is sent to the full repos and the full repos replies to that request. It is then the local repos(partial) knows about this queue. This is how queue resolution works.
Now for some reason if your full repos fails to respond within a timeframe, the request is cancelled by the partial repos and it reissues the request. But since it did not get a response(positive), it returns 2189 to the application. The application can then try to issue the same Mq api call again. And the next time this call should be succeeded. Hence this is usually not termed as an error. But just a warning.
Hope this helps.
Cheers
Kumar |
|
| Back to top |
|
|
| jmeier |
| Posted: Thu Sep 04, 2003 7:41 am Post subject: |
|
|
Apprentice
Joined: 30 Aug 2002
Posts: 46
Location: Minneapolis
|
Thanks Kumar. The queue that I am trying to access happens to be the exexmlinputq. I can access the other queue that I need to.
_________________
Joe Meier |
|
| Back to top |
|
|
| mqonnet |
| Posted: Thu Sep 04, 2003 8:00 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Could you please elaborate as to what "exexmlinputq" is....
Also if you can explain your setup of your cluster alongwith what app connecting to which qm... What api call failing where etc...
Cheers
Kumar |
|
| Back to top |
|
|
| jmeier |
| Posted: Thu Sep 04, 2003 8:06 am Post subject: |
|
|
Apprentice
Joined: 30 Aug 2002
Posts: 46
Location: Minneapolis
|
I have a VB application that reads successfully from queue "A". It does some processing and sends a return code back to the EXEXMLINPUTQ, which is basically your input back to MQ Workflow. It is on writing to this queue that the VB app seems to be having difficulty. To add to the confusion, we have 3 different queue managers running on the same server. I am able to successfully put to this queue in the other queue managers, with the same code, however, in this 1 environment, I can't seem to write to the queue. It seems to be specific to the 1 environment, however, everything looks like it is running correctly on the MQ side.
_________________
Joe Meier |
|
| Back to top |
|
|
| mqonnet |
| Posted: Thu Sep 04, 2003 8:15 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Well, firstly you gave the business logic of the problem. I wished you could post the actual cluster definitions.
Any ways, from what you posted, it looks like the queue EXEXMLINPUTQ is not publicised as i mentioned earlier to the other queue managers. That is the reason you are able to put to this queue connecting to one of the other queue managers, presumably this is the one that hosts this queue. Hence i come back again to the same queuestion as to how is your setup. May be you can answer these question.
1) Where is EXEXMLINPUTQ defined. Is this a clusterq.
2) How many qmgrs are involved in the cluster and how many are full/partial repos qms.
3) Is queue "A" a cluster queue.
4) Whom is your vb app connecting to. Is that qm a full or a partial repos qm.
5) If you have clustered queues, are they visible from all the queeu managers.
Cheers
Kumar |
|
| Back to top |
|
|
| vennela |
| Posted: Thu Sep 04, 2003 9:01 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
I think EXEXMLINPUTQ is not a clustered Queue.
Since MQWorkflow config utility creates this queue, I don't think it will be different in your case.
| Code: |
dis QUEUE(EXEXMLINPUTQ) all
AMQ8409: Display Queue details.
DESCR(Local queue for Execution Server XML input)
PROCESS( ) BOQNAME( )
INITQ( ) TRIGDATA( )
CLUSTER( ) CLUSNL( )
QUEUE(EXEXMLINPUTQ) CRDATE(2003-05-01)
CRTIME(13.28.42) ALTDATE(2003-05-01)
ALTTIME(13.28.42) GET(ENABLED)
PUT(ENABLED) DEFPRTY(0)
DEFPSIST(YES) MAXDEPTH(10000)
MAXMSGL(4194304) BOTHRESH(0)
SHARE DEFSOPT(SHARED)
HARDENBO MSGDLVSQ(FIFO)
RETINTVL(999999999) USAGE(NORMAL)
NOTRIGGER TRIGTYPE(FIRST)
TRIGDPTH(1) TRIGMPRI(0)
QDEPTHHI(80) QDEPTHLO(20)
QDPMAXEV(ENABLED) QDPHIEV(DISABLED)
QDPLOEV(DISABLED) QSVCINT(999999999)
QSVCIEV(NONE) DISTL(NO)
DEFTYPE(PREDEFINED) TYPE(QLOCAL)
SCOPE(QMGR) DEFBIND(OPEN)
IPPROCS(0) OPPROCS(0)
CURDEPTH(0)
|
If you can also post your OpenOptions, that will be helpful. |
|
| Back to top |
|
|
| jmeier |
| Posted: Thu Sep 04, 2003 9:22 am Post subject: |
|
|
Apprentice
Joined: 30 Aug 2002
Posts: 46
Location: Minneapolis
|
Kumar -
One thing to note about this setup is that this configuration has been working since this spring with out this error. These are not new queues that have been setup. That said, here are the answers to the questions...
1) Where is EXEXMLINPUTQ defined. Is this a clusterq.
On another server, it is a clustered queue.
2) How many qmgrs are involved in the cluster and how many are full/partial repos qms.
5 qmgrs. 2 of which are full repos.
3) Is queue "A" a cluster queue.
Yes.
4) Whom is your vb app connecting to. Is that qm a full or a partial repos qm.
It could be either. We have two EXEXMLINPUTQs, one is on a full the other is on a partial.
5) If you have clustered queues, are they visible from all the queeu managers.
Yes.
Hope this gives some insight into what we are encountering. Thanks everybody for the quick responses.
_________________
Joe Meier |
|
| Back to top |
|
|
| mqonnet |
| Posted: Thu Sep 04, 2003 9:56 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
I think you should verify this statement.
--- If you have clustered queues, are they visible from all the queeu managers.
Yes.
---
From all the 5 queue managers, when you issue a dis qcluster(*) do you see Queue "A", 2 queue EXEXMLINPUTQ, one each from the full repos and the partial repos.
The other very obvious question is, are your clussdr and clusrcvr channels up and runnin on all the qmgrs.
Also when you issue a dis clusqmgr(*) do you see the "SAME" output on all the 5 qmgrs, none with "temp" in it.
Cheers
Kumar |
|
| Back to top |
|
|
| vennela |
| Posted: Thu Sep 04, 2003 9:58 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
Can you post the definitions of the EXEXMLINPUTQ from both the QMGRs where it is hosted.
I have one question though. Did you manually cluster this queue or did MQWF config utility do this? What version of Workflow?
If all you are trying to do is to PUT to EXEXMLINPUTQ from different QMGRs created by workflow then you could very well use this queue
FMC.FMCGRP.EXE.XML assuming your GROUP is FMCGRP.
Replcae FMCGRP with whatever your group name is. This queue is clustered and it is an alias pointed to EXEXMLINPUTQ.
-------
Venny |
|
| Back to top |
|
|
| TonyD |
| Posted: Thu Sep 11, 2003 8:02 pm Post subject: |
|
|
Knight
Joined: 15 May 2001
Posts: 540
Location: New Zealand
|
| I would be inclined to use amqrfdm to examine the state of your cluster. It may be that a rogue definition is causing the problem. In particular check that additional cluster channels have not been created |
|
| Back to top |
|
|
| jmeier |
| Posted: Tue Sep 16, 2003 9:33 am Post subject: |
|
|
Apprentice
Joined: 30 Aug 2002
Posts: 46
Location: Minneapolis
|
After involving IBM (which didn't end up solving the issue), we discovered that changes to the OS/390 full repository caused some repository corruption on our end that was very difficult to diagnose. We had to refresh our repository (AIX).
_________________
Joe Meier |
|
| Back to top |
|
|
|
|
