Lizette,
I believe that's correct. But, what you have to remember is that if the
D/R takes place at a remote site, the BSDS will contain the tape data set
names and volsers that were used for archiving. If those volumes are not
at the remote site, you have a problem. These can be handled by copying
the archive log tapes to tapes that are sent offsite, and by modifying the
contents of the BSDS to reflect the offsite tapes.
"Anderson, Lizette T.
(RyTull)" To: [EMAIL PROTECTED]
<[EMAIL PROTECTED] cc:
ONTULL.COM> Subject: Re: Disaster testing
Sent by: MQSeries List
<[EMAIL PROTECTED]
T>
04/03/2003 04:51 PM
Please respond to
MQSeries List
One of the steps in the recovery procedure is to define a new BSDS data set
and use REPRO to copy the most recent archived BSDS into it. My archive
logs are on tape.
Am I reading this correctly " If archive logs are on tape, The BSDS is the
first data set of the first archive log volume. The BSDS is not repeated
on
later volmues." Does this mean I should use the CSQ.ARCHLOG1.A0000001
instead of CSQ.ARCHLOG1.B0000001?
The instructions for archive logs on DASD are:
If archive logs are on DASD, the BSDS is allocated on any available DASD.
The BSDS name is like the corresponding archive log data set name; change
only th e first letter of the last qualifier, from A to B, as in the
example
below:
Archive log name
CSQ.ARCHLOG1.A0000001
BSDS copy name
CSQ.ARCHLOG1.B0000001
-----Original Message-----
From: Robert Broderick [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 03, 2003 12:10 PM
To: [EMAIL PROTECTED]
Subject: Re: Disaster testing
I think I pointed this out so if I am repeating myself I very much
apollogize. I am Mainframe born and brought up. I now have my hand
entrenched in distributed side processing. (six years of going back to
school paid off!!). I would have to agree with Bump, I mean Lump, I mean
HILL (tee hee hee). The distributed platforms TEND (and this is not a
gerneralization....OH well...yes it is!!) not to think of DR in the same
terms as the OS390 people do. Most of the times. I was in a shop that was
doing financial transfers. If you designed a system that lost a transfer,
you were looking for a good place to play checkers the next day. This was
OS390. This also included a DR situation. In the past few contract with
distributed platform they were happy to be back up and running!! What do
you
mean, I said in a meeting...you are running a brokerage system with DR
rplication in ASYNC mode. BUT don't you understand..... They said don't
worry about it!! Drove me nuts!!! I couldn't sleep for a couple of nights.
Well I digressed again. My origional point here is that to support true DR
there will certainly be a good amoung of system (software side) to support
the Holy Grail of DR physical recovery. The Designers must be aware of the
limitations of the DR and must design redundency checking and transaction
recovery into the system. DR is not perfect. But with both a physical and
software approach it can become the Nervana you hope it to be.
Please vote for me this coming Nov 11.
bee-oh-dubble-bee-dubble-egh
>From: "Hill, Dave" <[EMAIL PROTECTED]>
>Reply-To: MQSeries List <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: Disaster testing
>Date: Thu, 3 Apr 2003 11:27:46 -0500
>
>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
_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.
http://join.msn.com/?page=features/virus
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
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
