We just wiped out an ADSM tape volume full of client data; did it very
efficiently too.

We run a program which recycles ADSM tapes when they become empty
(through expiration or reclamation) and are deleted by ADSM. It's a
program we wrote. This program:

    1. Does an ADSM QUERY VOLUME to get a list of all tape volumes that
       ADSM thinks it is using. ADSM did this correctly.
    2. Does a VMTAPE LIST (OWNEDBY ADSM to get a list of all volumes our
       tape management system thinks are allocated to ADSM. The tape
       management system did this correctly.
    3. Matches the lists, and any tapes which VMTAPE says belong to ADSM,
       but ADSM does not know about, are erased and returned to the
       scratch pool.

The problem is that there is a time window between steps 1 and 2. The
larger your ADSM database, the longer the Q VOLUME will take, and the
wider the time window becomes. If ADSM requests that a new scratch tape
be allocated for writing during that time window, that new scratch tape
will not be on list 1, but it will be on list 2, and so it will get
recycled and erased immediately after it is written.

The total solution is to simply swap the order of steps 1 and 2.

If you run a similar tape recycling scheme (on any ADSM server platform)
you should pay close attention to the ORDER in which you obtain the
information to determine which tapes are eligible for recycling, or you
can erase valuable client data, as we just did.

Roger Deschner      University of Illinois at Chicago     rogerd AT uic DOT edu
Aliases:                  u52983 AT uicvm.uic DOT edu        R.Deschner AT uic 
DOT edu
================== Entropy isn't what it used to be. ===================