Safely on tape?  One is even more likely to lose data on tape than on DASD.  To
solve the problem, it must be solved on all levels of the backup storage
hierarchy.  In the past, when we've lost "backup" type of data (HSM backup tapes
for instance), we've attempted to identify those data sets whose backups have
been lost and force new backups.  Althought, this is easy on the MVS mainframe,
I have no idea how to approach the problem with ADSM.

Regardless, it doesn't address the issue of what to do for those data sets which
backups can not be taken (deleted data sets). Short of tape copies, which are
prohibatively expensive for us, we've learned to live with it as an acceptable
risk.

Dean Smith
_______________________________________________________________________________
From: ARCO.ADSML on Mon, Oct 11, 1993 15:27
Subject: Qiet Ipsos....
To:   ADSM-L (ARCO.ADSML); Smith, Dean

I have thought of a simple solution that others may find is good enough.

Use a 0% low threshold.  This is more palatable with ADSM than it was with
WDSF because now ADSM caches the info.  All your data is now safely on tape.

To be sure I'm planning a timer-pop command late at night to change the
hi to 1 and low with low at 0 it should flush everything onto tape.

I'm planning on using this with a prop routine that watches ADSM and
copies the tape to a duplicate when it is 'closed full' and maybe once
a night after I flush the disk stages to tape.

In the end I think there's an ADSM command like WDSF that tells it that
there is some lost data and then , I assume, it causes someone's next
incremental backup to really be a 'new' full backup.  Right?

Of course this all assumes that sometime in the day/or/night theres a
'quiet' period that you can count on.

cheers ..joe.f.