| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| cluster 2189 error |
« View previous topic :: View next topic » |
| Author |
Message
|
| dcrgolfer |
 Posted: Thu May 14, 2009 9:41 am Post subject: cluster 2189 error |
 |
|
Novice
Joined: 29 Aug 2002
Posts: 16
Location: Columbus, Ohio
|
Cluster problems, when making cluster changes, required to refresh to propagate the cluster change. Immediate problem...can display qcluster as follows:
dis qcluster(REQUEST.1) CLUSTER CLUSQMGR QMID PUT
2 : dis qcluster(REQUEST.1) CLUSTER CLUSQMGR QMID PUT
AMQ8409: Display Queue details.
QUEUE(REQUEST.1)
TYPE(QCLUSTER) CLUSTER(EDAS_CLUSTER)
CLUSQMGR(QMGR2) PUT(ENABLED)
QMID(QMGR2_2009-05-14_09.24.16)
END
3 : END
2 MQSC commands read.
No commands have a syntax error.
All valid MQSC commands were processed.
And when we attempt to amqsput to that queue we receive the 2189 error
as seen below:
/opt/mqm/samp/bin/amqsput REQUEST.1 QMGR1
Sample AMQSPUT0 start
target queue is REQUEST.1
1
MQPUT ended with reason code 2189
Any advice as to how to corrcet this situation? 
_________________
> 28 years experience on z/os (MVS), AIX/Solaris/Linux/Unix and WIN. IBM senior systems programmer for 15+ years on MVS/CICS/VTAM 3rd party software CONNECT:Direct CA products, TPX, etc. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu May 14, 2009 9:54 am Post subject: Re: cluster 2189 error |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| dcrgolfer wrote: |
| Any advice as to how to corrcet this situation? |
You shouldn't need to use refresh just to make a change and propogate it through the cluster. If you do, it indicates a problem someplace.
First point with all cluster problems in to ensure all the cluster sender/reciever channels are running, and as indicated here.
Second point is to confirm the cluster topology is correct; 2 FRs, both pointing at each other, each PR pointing at an FR and all channels running.
Third point is to check the software levels. If you've got v5.3 and v6 in the same cluster, be certain that the FRs are v6 (or v7). Also ensure that the v5.3 are on the latest maintenance level.
Fourth point is to ensure the repository processes are running.
There are undoubtably other points, and other views on the order of these.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| dcrgolfer |
| Posted: Thu May 14, 2009 10:02 am Post subject: |
|
|
Novice
Joined: 29 Aug 2002
Posts: 16
Location: Columbus, Ohio
|
basic cluster topology:
1 mainframe FR(v6.), 1 solaris FR (v5.3.12), 2 solaris FR (v6.0.2.5) and a multitud of PR's running (v5.2.8, v5.3.12, v6.0.2.x).
mainframe FR and solaris v5.3.12 FR are also FR's for 4 clusters. Some PR's are members of all 4 cluster, some PR's are not members of all 4 clusters.
We have defined CLUSSDR's between each the FR's.
_________________
> 28 years experience on z/os (MVS), AIX/Solaris/Linux/Unix and WIN. IBM senior systems programmer for 15+ years on MVS/CICS/VTAM 3rd party software CONNECT:Direct CA products, TPX, etc. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu May 14, 2009 10:12 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
You have 4 FRs in there. If you have more than or less than 2 FRs in a given cluster you're flirting with exactly the resolution problem you're describing.
Fix this, carefully, following the demotion procedure in the manual. If each cluster only has 2 FRs (with some machines doing duty in 2 clusters), follow my checklist above. Also check how the clusters are overlaping and/or bridged.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
