As bee oh double beee double eeee says:
It is a multi-platform muti-people environment. I have found that a service level 
agreement ( SLA ) to be an option so that upon failure to recover you can produce your 
SLA and show that it has been satisfied. Now that you have seen the BS side of DR lets 
go on.   
You need to recover all platforms and here in lays the problem. I have recovered all 
platforms in testing but have yet to get all platform in sync. This is a major goal 
but I feel it is the holly grail I seek. I am "lucky" to be "in charge" of all MQ 
platforms and am the DRC too. I still have trouble getting the admin of NT/AIX/WIN2000 
machines to agree on a single backup strategy. I still believe that MQSeries can be 
taken up a notch in this area.
As for having a plan? I suggest test and test and fail and fail until someone takes 
note. I find that non-Mainframe people do not understand what true recovery is. You 
have to show them and hold their hands and cuddle and whisper ( getting uneasy yet? ) 
until they see the light.
The bottom line is this. How do you define a point in time that can be recovered and 
is acceptable to your business and or business units.
DR Its not just a job its an adventure ;-) 
   

-----Original Message-----
From: mqm mqm [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 03, 2003 10:01 AM
To: [EMAIL PROTECTED]
Subject: Re: Disaster testing


This is the first real discussion I've seen on this
list about DR. My favourite topic ...ha! ha! Everytime
you mention DR and MQ to IBM you get pointed to the
manual/redbook about restart/recovery. But as Bobbee
points out DR is potentially much more than this.
Which of Bobbee's three options are people adopting ?
Or are you doing something else ? Like just hoping you
never have a disaster ?

mqm

--- "Anderson, Lizette T. (RyTull)"
<[EMAIL PROTECTED]> wrote:
> Thanks for your response.  There goes Vegas.  I was
> thinking it may be
> easier to just start from scratch with new pagesets
> and logs.  I am not even
> sure we can bring MQ down to get a decent backup.
>
> -----Original Message-----
> From: Robert Broderick
> [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, April 01, 2003 2:09 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Disaster testing
>
>
> I am not an expert on this but here is my
> 2.314567489364532 cents.
>
> Well there are different levels/approaches to what
> people call DR. Some
> believe it is an image restore of the queue manager
> at the point of failure.
> Others see it as COB (Continuance of Business). The
> two views are radically
> different from a hardware (and yes! Software) stand
> point.
>
> If you are viewing it as recoverable from a point in
> time then all
> participants must agree on a point in time. Usually
> this is a climb up the
> staircase of the tower of babble. If you can get all
> the platform people to
> sit in a room and agree on a coordination to achieve
> this. I will take you
> to Vegas for the weekend!!! As you see, I'm not
> worried about loosing my
> shirt at the tables because to achieve this is
> almost impossible.
>
> The lowest point of view is the COB one. Do you want
> to put in place a
> framework where you can, with a bit of effort, bring
> the business back up to
> operating speed to move forward and your business
> and IT people will hammer
> out what was going on at the time of the disaster
> and fix it with their
> magic wands, special programs to sync up the servers
> and catch isolated
> transaction from replaying and lots of bubblegum.
> This is usually the
> easiest and looks to be what you are talking about.
> Remember in a situation
> like this the servers aren't in sync so there may be
> duplicates. If it's a
> financial system you are going to need LOTS of
> bubblegum!!
>
> A third possibility that I failed to mention is a
> hardware solution. This
> being where you have your OS390 fiber connected to a
> redundant site, your
> UNIX servers Veritas clustered AND replicated in
> SYNC and the NT boxes with
> a similar redundancy. I'm not talking about just
> mirrored disk arrays here.
> IF you run a DR then the boxes failover to their
> mirrored replicated
> partners and the day moves ahead with minimal
> outage. This is EXPENSIVE from
> a hardware and support staff point of view. (Someone
> has to know how to set
> up and monitor this stuff).
>
> AS I said prior, Hardware, Software or platform
> coordination. Pick your
> poison, it is all downhill from here with a big
> bottle of aspirins waiting
> for you at the bottom.
>
>                                       bobbee
>
>
>
>
>
>
> >From: "Anderson, Lizette T. (RyTull)"
> <[EMAIL PROTECTED]>
> >Reply-To: MQSeries List <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >Subject: Disaster testing
> >Date: Tue, 1 Apr 2003 13:15:03 -0600
> >
> >We are in the process of creating a disaster plan
> for MQSeries v 5.2
> >running
> >on OS/390, Windows 2000 and AS/400.  I wanted to
> get some ideas.  The plan
> >is to run a backup of MQSeries on the mainframe
> while MQSeries is up.  This
> >backup would be used to restore MQSeries once we
> get to the DR site.  The
> >server side is handled by another group which means
> their backup may have
> >been taken at a different time. Maybe even a
> different day.  This is also
> >true of the AS/400.
> >
> >How are you handling DR testing at your shop?
> >
> >
> >--- Legal Disclaimer: The information contained in
> this communication may
> >be
> >confidential, is intended only for the use of the
> recipient named above,
> >and
> >may be legally privileged.  If the reader of this
> message is not the
> >intended recipient, you are hereby notified that
> any dissemination,
> >distribution, or copying of this communication, or
> any of its contents, is
> >strictly prohibited.  If you have received this
> communication in error,
> >please re-send this communication to the sender and
> delete the original
> >message and any copy of it from your computer
> system. 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
>
>
>
_________________________________________________________________
> The new MSN 8: advanced junk mail protection and 2
> months FREE*
> http://join.msn.com/?page=features/junkmail
>
> 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
>
>
> --- Legal Disclaimer: The information contained in
> this communication may be
> confidential, is intended only for the use of the
> recipient named above, and
> may be legally privileged.  If the reader of this
> message is not the
> intended recipient, you are hereby notified that any
> dissemination,
> distribution, or copying of this communication, or
> any of its contents, is
> strictly prohibited.  If you have received this
> communication in error,
> please re-send this communication to the sender and
> delete the original
> message and any copy of it from your computer
> system. 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! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.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

Reply via email to