Rao, My apologies. Do you have any monitoring on MQ? QPasa and Candle CC DE XP can be configured to hadle these failover situations. Nastel may also - just can't confirm from experience. The channel may have to be stopped/started to correct the ip issue. Maybe someone with a deeper understanding knows otherwise. I'd like to know for sure. My bet is that if you have a script triggered by a channel retry event, that the script can verify that the machine is available/not available, and can issue pcf commands to cycle a channel - it will work. How will the IP flip be achieved - manually? Initiate the channel cycle script manually after swapping IPs. Some companies will alter qremote definitions to point to different xmitqs to failover, but this can leave messages on the failed chl's xmitq. Hope that this helps, Chris
--- "Adiraju, Rao" <[EMAIL PROTECTED]> wrote: > Chris > > Call me "Rao". > > The spoke is on Windows machine with MQ V5.3 CSD06. > And I can't locate any > "adoptmca" parameter on that platform. There is one > for Z/OS but not for > windows. > > I don't want to DELETE and re-DEFINE channels either > because then channel > sequence numbers will be out of whack. > > Cheers > > Rao > > > -----Original Message----- > From: Christopher Warneke > [mailto:[EMAIL PROTECTED] > Sent: 19 April 2004 10:58 AM > To: [EMAIL PROTECTED] > Subject: Re: Channel Connection name resolution > > Adiraju, > What kind of machine is at the other end of the > channel? Could this be an > adoptmca issue? Why not have a "failover" script > cycle the channel when it > fails? It could interogate the primary ip and > secondary ip when the channel > has a retry event trigger it. Then make a failover > or alert you to a bad > channel. Do you have any monitoring on your system? > Just some thoughts, > Chris > > --- "Adiraju, Rao" <[EMAIL PROTECTED]> wrote: > > Fellows > > > > Last night I was testing our Disaster Recovery > strategy for MQ and > > stuck with a problem and need (as well as > appreciate) some help from > > the forum: > > > > Situation: > > > > I have a MQ hub running on Solaris with MQ version > > 5.3 CSD04. It is talking > > to a spoke using SDR and RQSTR pair of channels. > The connection name > > for these channels are defined with a sudo(alias) > DNS entry to > > facilitate Disaster Recovery switch for the spoke > box (I am not > > talking of DR switch for HUB). > > > > Eg: Spoke-live box tcp-ip address is - > 100.20.20.200 > > spoke disaster box tcp-ip address is - > 100.20.35.350 > > > > Created a DNS entry called "Spoke1.co.nz" > and put this name in > > connection name field for both the above channels. > > > > Initially the DNS entry "Spoke1.co.nz" is directed > to 100.20.20.200. > > > > Every thing was working OK and then we brought > down the first box and > > restarted the second box (with the same Queue > Manager name with disk > > mirroring etc..). Also changed the DNS entry to > > point to 100.20.35.350. > > When I go to Nslookup on Solaris box, it shows > correctly the changed > > the TCP-IP address for this "Spoke1.co.nz". > > > > Initially the channels on the HUB was in > "retrying" > > state which I stopped > > and started again. But somehow, MQ is still trying > to resolve with old > > TCP-IP address, as if something is cashed. I > failed to refresh this > > cashing and couldn't able to redirect my channels > to connect to new > > box. > > > > Being a production system, I have to bring it back > quickly and hence > > temporarily changed the channel definitions to > physical address > > "100.20.35.350" (no more DNS alias) and then > restarted the channels, > > MQ is happy. > > > > Is there something I need to do, to force the > Queue Manager to > > recognise the new TCP-IP address. Restarting the > queue manager is not > > a feasible option - this is being a HUB any > shutdown will effect the > > entire organisation. > > > > Thanks in advance for your help. > > > > Cheers > > > > Rao > > > > > > > > This communication is confidential and may contain > privileged > > material. > > If you are not the intended recipient you must not > use, disclose, copy > > or retain it. > > If you have received it in error please > immediately notify me by > > return email and delete the emails. > > Thank you. > > > > > > > > __________________________________ > Do you Yahoo!? > Yahoo! Photos: High-quality 4x6 digital prints for > 25" > http://photos.yahoo.com/ph/print_splash > > Instructions for managing your mailing list > subscription are provided in the > Listserv General Users Guide available at > http://www.lsoft.com > Archive: http://vm.akh-wien.ac.at/MQSeries.archive > > This communication is confidential and may contain > privileged material. > If you are not the intended recipient you must not > use, disclose, copy or retain it. > If you have received it in error please immediately > notify me by return email > and delete the emails. > Thank you. > > Instructions for managing your mailing list > subscription are provided in > the Listserv General Users Guide available at > http://www.lsoft.com > Archive: http://vm.akh-wien.ac.at/MQSeries.archive __________________________________ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25" http://photos.yahoo.com/ph/print_splash Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
