On Tue, 5 Apr 1994 10:37:23 PDT, "Paul L. Bradshaw" <PAULB AT STLVM4.VNET.IBM 
DOT COM>
wrote:

>This is a hot topic both inside ADSM and outside.  Suffice it to say that
>this is a top requirement that we are actively working on.  As to the exact

Glad to hear it.

>method of implementation a variety of alternatives are being researched to
>see which provides the highest performance, most function, and the lowest
>cost to the customer.  We don't have the final model decided on yet so any
>questions on how it works cannot be answered.  Instead, a concise list of
>just what you expect out of a tape twinning (multiple bitfile) function would
>help us in making the correct decisions.

What we need twinning for is testing our disaster recovery plans.  What
we need to be able to do is to take a set of tapes and a copy of DSM's
database to a remote site and have a fully functional DSM server.  The
easiest way of doing that as I see it is to simply pass a parameter to
the tape mount exit routine to specify that two tapes should be mounted
and then have the server write to them both simultaneously.  It would
be nice if the two copies didn't have to be of the same density.  Eg.
our silos are EXF, while our drives downstairs are 38K.  I'd like to have
the option to send one copy to the silo, and the other downstairs.

During a DRP (Disaster Recovery Planning) test, only one set of tapes
will be available.  Both servers (home and DRP) must be able to handle
that.  As well, when the tapes come back from the test, we have to be
able to resynch the two copies.  I don't think we need any more
functionality than that.  So for us a simple "enable tape twinning" flag
in the OPT file would do the job.

Have fun,
Carl Forde                            phonenet: 604-389-3234
VM Systems Software Group             bitnet  : CFORDE at BCSC02
British Columbia Systems Corporation  internet: cforde AT bcsc02.gov.bc DOT ca