Hi Rebecca, the saveqmgr program does not store the permissions set with the setmqaut command. You need another supportpac (I guess MS0I), to save the authorities too.
Nevertheless, saveqmgr stores only the qmgr configuration, not the qmgr itself. This means, you will be able, to create a qmgr with the same objects. This qmgr may have the same name, but another qmgr ID. This may cause problems when you use MQ clustering (see my mail before). Regards Hubert -----Ursprungliche Nachricht----- Von: Bullock, Rebecca (CSC) [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 26. September 2003 02:21 An: [EMAIL PROTECTED] Betreff: Re: Disaster Recovery scenario for Unix box? Bill, if the only reason you're dong the backups nightly is to be sure you have the required object definitions, then why don't you just plan to create a new qmgr with the correct name and reload the objects/security stuff from the definitions? You can back those up using the saveqmgr SupportPac and the amqoamd command (OK, I may have that last one wrong since I did it from memory and I'm too tired/lazy to go look it up -- but it's at least close). Depending on the particular qmgr and application in question and how critical it is, we may use any one of the following: Veritas clustering Two qmgrs with client channel tables Simply create a new qmgr on another box and reload the definitions It all depends.... (Don't you hate it when people respond with that?) Rebecca Bullock Computer Sciences Corporation MFCoE Princeton, NJ 08541 email: [EMAIL PROTECTED] / [EMAIL PROTECTED] -----Original Message----- From: Beinert, William [mailto:[EMAIL PROTECTED] Sent: Thursday, September 25, 2003 2:50 PM To: [EMAIL PROTECTED] Subject: Re: Disaster Recovery scenario for Unix box? Good thing YOU have the headache, not me! Actually we have hardware clustering already established - the HP High Availability stuff, and we test it every month. The test server(cluster) is in a different location. I initially installed MQ with clustering, but took it out when I had a problem that required a PTF that was only a month old. Too "bleeding edge" for my taste. And it turned out that our development situation got a bit crazy, and on an almost daily basis I was rewiring my channels so the MF test system was sending message to the Unix test server, then production to training, then test to training....you get the picture.... I couldn't have done it with clustering. And we do not store any data on the queues for more than 30 seconds....The only reason for a regular copy is to pick up any changes I make to MQ objects. Bill -----Original Message----- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Thursday, September 25, 2003 2:21 PM To: [EMAIL PROTECTED] Subject: Re: Disaster Recovery scenario for Unix box? Speaking of which.....Why wouldn't you consider CLUSTERING. It would make things simple for you. You would have automatic failover. Another secenario would be to use some sort of Hardware/Software clustering. I have been in installations whee Veratas was used. It worked well and you can (maybe) forget about the clustering. Unfortunatly you have to invest in the technology on a hardwar, software and education level. But it can be used for other critical application other than MQ. You did not mention how people are connecting to the QMGR in question. If it is client you have a channle table failover option and can have the queue manager runing on the other box to accept the work. Not much change necessary there. You mentioned that you would copy the environment over at night. WHY???? Are applications in your group using the QMGR as a storage device or is it a business req. If you think about it. In any good MQ environment the messages should only stay on the queues long enough to get them out the door. Otherwise you have an issue. Restoring a QMGR from an image from a couple of hours (?) ago would imply the QMGR is stale or out of sync. You may have to consider the re-processng of old messages. This could be as devastating as loosing messages. As you can see this discussion can get very complicated. There I go...I went and gave myself a headache!!!!! my two cents bobbee >From: Rick Tsujimoto <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Disaster Recovery scenario for Unix box? >Date: Thu, 25 Sep 2003 11:59:54 -0400 > >Bill, > >One approach is to define the qmgr with the same name and leave it dormant >until needed. When a disaster hits, have the DNS updated to point to the >backup server. Once that's done, you can connect from the m/f (although, >the channels will have to be resynch'd). > >If you don't use DNS on the m/f, just update IP address in your sdr >channel. > > > > > "Beinert, > William" To: >[EMAIL PROTECTED] > <[EMAIL PROTECTED] cc: > COM> Subject: Disaster Recovery >scenario for Unix box? > Sent by: > MQSeries List > <[EMAIL PROTECTED] > en.AC.AT> > > > 09/25/2003 11:39 > AM > Please respond > to MQSeries List > > > > > >Our initial scenario for DR is the loss of the HP box that hosts both the >queue manager and the application. We have another server that provides >test and training systems. > >One approach would be to copy /var/mqm/qmgrs/ProdQM on the active server >over to /var/mqm/qmgrs/ProdQM on the standby server on a nightly basis. >Moving to the standby server would then require on-the-fly changes to >mqs.ini, as well as a recycling of the channels on the mainframe (the >virtual IP of the standby system would stay the same as the primary). >I'm a little leary of this approach. It seems too much "under the hood" and >requires some expertise to execute. > >An alternative is to create a real queue manager in the normal way on the >standby box, configure him the same as the production QM, and start him up >and make him the default when needed. Just alter a few queue definitions on >the MF, and we are in business. >A question is what to name the standby QM. I have a recollection from >discussions here that multiple QMs with the same name can cause strange >problems - or is that only with clustering? > >The collective wisdom of this list is truly appreciated. > > >Bill Beinert >Systems Programming >Con Edison > >When they took the fourth amendment, > I was quiet because I didn't deal drugs! >When they took the sixth amendment, > I was quiet because, I was innocent. >When they took the second amendment, > I was quiet because I didn't own a gun! >Now they've taken the first amendment, > and I can say (or do) nothing about it. >The Second Amendment is in place in case they ignore the others. >MODWN DAbE > >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 > >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 _________________________________________________________________ Instant message in style with MSN Messenger 6.0. Download it now FREE! http://msnmessenger-download.com 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 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 e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. 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 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
