| Author |
Message
|
| Empeterson |
 Posted: Tue Jan 10, 2006 11:24 am Post subject: SOLVED: QMID's not matching on CLUSSDR and CLUSRCVR... |
 |
|
Centurion
Joined: 14 Apr 2003
Posts: 125
Location: Foxboro, MA
|
We have just set up a new cluster making 2 qmgr's on AIX (UFXCPIAP1 and UFXCPIAP2), the full respositories. We added 12 windows qmgr's to the cluster, each hosting a copy of a clustered queue. 6 of the windows qmgr's had their CLUSSDR defined to UFXCPIAP1, the other 6 were dfined to UFXCPIAP2. After the cluster was built, we realized that the FR's could only see the clustered queue's that were definined on the qmgr's that had CLUSSDR's defined to it. After some digging, I realized the following:
On UFXCPIAP1:
DISPLAY CLUSQMGR(*) ALL shows
for the CLUSSDR (TO.UFXCPIAP2)
QMID(UFXCPIAP2_2004-08-05_18.07.24)
for the CLUSRCVR (TO.UFXCPIAP1)
QMID(UFXCPIAP1_2003-01-29_11.23.31)
DISPLAY QMGR shows
QMID(UFXCPIAP1_2003-01-29_11.23.31)
On UFXCPIAP2:
DISPLAY CLUSQMGR(*) ALL shows
for the CLUSSDR (TO.UFXCPIAP1)
QMID(UFXCPIAP1_2004-08-05_17.44.13)
for the CLUSRCVR (TO.UFXCPIAP2)
QMID(UFXCPIAP2_2003-01-29_11.19.34)
DISPLAY QMGR shows
QMID(UFXCPIAP1_2003-01-29_11.19.34)
As you can see, the QMID on the CLUSSDR on UFXCPIAP1(TO.UFXCPIAP2) and the CLUSRCVR on UFXCPIAP1,(TO.UFXCPIAP2) do not match. The same holds true going the other way. I am assuming that this is the reason why the FR's cant see the clustered queue's that the other FR can see. How did these qmid's get out of synch and how can I fix this so they get back in synch? If I were to issue a RESET CLUSTER(CWSPROD) QMID(UFXCPIAP1_2004-08-05_17.44.13) ACTION(FORCEREMOVE) QUEUES(NO), would the CLUSSDR automatically change to pickup the correct QMID, or would I have to delete and recreate it? (I would then have to do this again for the other CLUSSDR.
Any help would be appreciated. Thank you.
_________________
IBM Certified Specialist: MQSeries
IBM Certified Specalist: Websphere MQ Integrator
Last edited by Empeterson on Tue Jan 10, 2006 12:42 pm; edited 1 time in total |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Tue Jan 10, 2006 11:28 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You do have a manual clussdr and clusrcvr pair connecting each FR, right?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Empeterson |
| Posted: Tue Jan 10, 2006 11:34 am Post subject: |
|
|
Centurion
Joined: 14 Apr 2003
Posts: 125
Location: Foxboro, MA
|
Yes.
_________________
IBM Certified Specialist: MQSeries
IBM Certified Specalist: Websphere MQ Integrator |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Jan 10, 2006 11:51 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
And what is the status of those channels? Sounds like the FRs aren't chit chatting. And the channels are clustered properly?
Are both FRs set to be FRs?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Empeterson |
| Posted: Tue Jan 10, 2006 12:04 pm Post subject: |
|
|
Centurion
Joined: 14 Apr 2003
Posts: 125
Location: Foxboro, MA
|
| Quote: |
| And what is the status of those channels? |
TO.UFXCPIAP2 is running
TO.UFXCPIAP1 is inactive. It was running earlier.
| Quote: |
| And the channels are clustered properly? |
Not sure what you mean by that?
| Quote: |
| Are both FRs set to be FRs? |
Yes
_________________
IBM Certified Specialist: MQSeries
IBM Certified Specalist: Websphere MQ Integrator |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jan 10, 2006 12:15 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I think he was asking if the CLUSTER attribute of both channels was set to the correct thing.
Peter - what if he just deleted and recreated the cluster channels?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Empeterson |
| Posted: Tue Jan 10, 2006 12:39 pm Post subject: |
|
|
Centurion
Joined: 14 Apr 2003
Posts: 125
Location: Foxboro, MA
|
It looks like we got this resolved. This was what was done:
1) Suspended UFXCPIAP1 from the cluster.
2) RESET CLUSTER(CWSPROD) QMID(UFXCPIAP1_2004-08-05_17.44.13) ACTION(FORCEREMOVE) QUEUES(NO)
3) Deleted TO.UFXCPIAP2 CLUSSDR channel and recreated (channel now has proper QMID)
4) RESUMED UFXCPIAP1 to the cluster
Oddly enough, the CLUSSDR channel on UFXCPIAP2 (TO.UFXCPIAP1) appeared resolve itself at that point and now has the proper QMID for UFXCPIAP1, without anyone ever doing any of the above to UFXCPIAP2.
All clustered queue's are now visible on both FR's.
Thank you Jeff and Peter for your assistance.
_________________
IBM Certified Specialist: MQSeries
IBM Certified Specalist: Websphere MQ Integrator |
|
| Back to top |
|
|
| rdubey |
| Posted: Wed Jul 12, 2006 7:13 pm Post subject: |
|
|
Novice
Joined: 11 Jul 2006
Posts: 17
Location: USA
|
guys,
whar are other things(except qmids) which should match in initial handshaking of cluster channels . we are planning for data center move and as part of that new hpux machines( same hostname) will run the same qmgrs but new ip address . everything will be copied from old box to new box using srdf . this qmgr is part of a cluster and full repository is on mainframe.
my question is:
is it recommended to create all the objects from scratch or is not recommended since if i recreate qmgr then it might get new qmid and
the channels might not start because handshaking might fail since mainframe qmgr (FR) will have channels having old qmids.
should a copy like this will work without any change on mq side .
any help is greatly appreciated |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jul 13, 2006 1:54 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
For the copy to work seemlessly I would expect following:
- At no time will you have both qmgr (old and new) accessible through the net
- all the data directories have been moved
- the channel conname information has no ip addresses in it only dns names
- even though the ip address for the new box may be different from the ip address of the old box the dns name moves from old box to new box and does not change.
- Last and not least nothing of this is worth a dime if not confirmed by YOUR testing.
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
