In <1994Apr5.183004.24803 AT draper DOT com>, PAULB AT stlvm4.vnet.ibm DOT com 
(Paul L.
 Bradshaw) writes:
>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
>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.
>
>Hope this helps to answer some of the questions,
>
>Paul Bradshaw

 I am already doing a tape twinning procedure.  It is similar to what
DF/HSM does.  At a minimum, I would like the next release of ADSM to
internalize this simple procedure.

 When migration is going on the message ANR5321I is
issued when a tape is full.  An Automate rule is triggered by the
message to set up time based rules to submit a job to copy the tape
and to update ADSM to make it readonly.  These 2 new rules fire 5
minutes after the ANR5321I message -- the DEVCLASS mountretention
setting is 3 minutes.

 The trick is to associate the orignal tape with its copy.  I used
predefined tapes in the cartridge storage pool, 1000 tapes starting at
nnn000.  The copy set of tapes is the next 1000 tapes, so Automate can
easily generate the jcl to copy to volser + 1000.  The copies are then
sent offsite.

 I would want a simple tape twinning like this in the next server.  I
should be able to predefine the copy output tape as part of the
definition of the primary tape.  When ADSM fills a tape it should
immediately rewind and mount the copy tape and do the copy itself.

 If you want to add a much more sophisticated syncronous dual
bitfiling feature, go ahead!  Some users may really want that,
but a simple process as I have discribed is good enough for me.  My
concerns with the dual bitfiles are increased storage for the database
(would the record for every user file grow?) and increased cpu.  I
doubt if you could syncronously create a 2nd tape faster than IEBGENER
does it after it is full. (If the dcb's on the tape were f-32760-32760
instead of u-32760 I could use the 'fields=copy' feature of ****SORT
which is really fast.)

Bill Colwell
C. S. Draper Lab
Email: BColwell AT draper DOT com
Voice: 617-258-1550