Our disaster backup process stores a control file on AUTOLOG1 191 when the
backup of that minidisk is taken (a very short while) and it is erased
afterwards.  The PROFILE EXEC of AUTOLOG1 checks for the presence of this
file, if found; it prompts the operator to ask if it is really an IPL after
a disaster; it will not continue until the operator sends an SMSG YES or
NO.  This prompt is required as there is a -small- chance that VM dies while
AUTOLGO1 is being backed up on the disaster tapes.  If the operator replies
YES, AUTOLOG1 and AUTOLGO2 will take very different actions, so that only
VMBACKUP & co will be started as to enable restoring the VMBACKUP tapes.

Testing the CPUID is only good when after a disaster you IPL on another
CPU.  But, what if you have fatal disk problems (or someone whiping out your
resident).

2007/10/3, Brian Nielsen <[EMAIL PROTECTED]>:
>
> We run the same configuration both live and at DR.  The only 2 things don
> e
> different at DR are to manually FORCE off AUTOLOG2 (there is a 1 minute
>
> delay which allows this to be easily done) and to manually XAUTOLOG
> TCPIPDR (which runs in *addition* to the normal TCPIP stack).
>
> AUTOLOG2 brings up all the LINUX guests, which need to be restored first.
>
> If needed, the individual LINUX guests can be forced off.
>
> The TCPIPDR stack masquerades as the various gateways that the LINUX
> guests use and forwards everything to the external router IP used at DR.
>
> The DR I/O configuration leaves out the OSA addresses in use at the home
>
> site and includes a new OSA address for use only by TCPIPDR.  This
> prevents the VSWITCHes from passing traffic directly to an OSA, allowing
>
> the TCPIPDR stack to route all the traffic.  This setup means we don't
>
> have to update IP stacks.
>
> Brian Nielsen
>
>
> On Wed, 3 Oct 2007 09:29:51 -0400, Mary Anne Matyaz
> <[EMAIL PROTECTED]> wrote:
>
> >Hello all. I need a few lines of code for a D/R situation. I need to kno
> w,
> >in VM and Linux, if we are in a real D/R or in a
> >test D/R.
> > My plan is to default to a real D/R situation, then, if it's a test,
> >execute a command from operator
> >that asks if it is a test, and if so, place a variable somewhere, shutdo
> wn
> >the linuxes and tcp/ip, make my necessary
> >changes to point to different startups (primarily for IP addresses), and
>
> >bring them up again.
> >
> >What I need is how to put the variable somewhere that other users can th
> en
> >access it...
> >
> >TIA for any insight/thoughts, etc...
> >
> >Mary Anne
> >
>



-- 
Kris Buelens,
IBM Belgium, VM customer support

Reply via email to