Wanda,

We used to use a Reuse=0 on our main libraries also, but that got just a
little bit scary during reclamations.  Now we run with Reuse=2 on main
libraries and Reuse=5 on Copypool (tapes go to vault semi-weekly).

The issue we were concerned with was that once a tape was emptied via
reclamation, it immediately became a candidate for reuse.  Very soon
(minutes in some cases) new data would get written to the newly-emptied
tape.  But the *SM database had not yet been saved so there was no record
of the data's new location.  Should the server crash in such fashion as to
require a DB restore, the data locations saved in the DB would NOT match
the physical locations on tape and that data effectively was lost in the
main pools.

When we've run out of scratch tapes in our main libraries, we'd do an
incremental DB backup followed by a Backup Volhist.  Then set Reuse=0 until
the pending tapes toggle to scratch - usually only takes a few minutes.
Once those tapes are scratch, we set Reuse back to "2".

That way, should we suffer a crash requiring a DB restore, when the DB
restore was finished, the DB and physical locations of the data would be in
sync.

Tab Trepagnier
TSM Administrator
Laitram Corporation









"Prather, Wanda" <Wanda.Prather AT JHUAPL DOT EDU>@VM.MARIST.EDU> on 08/16/2001
01:13:49 PM

Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>

Sent by:  "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>


To:   ADSM-L AT VM.MARIST DOT EDU
cc:
Subject:  Re: TAPEPOOL Pending Volumes


FWIW, I keep REUSEDELAY set to 8 on my copy pool, but set to 0 for the pool
in the library, which avoids your problem.  I figure if anything disastrous
happens, it's the copy pool tapes I'll need, anyway.

That may not necessarily work for everybody; but here, COPY POOL tapes are
made daily and sent to the vault, so the pools are (almost) always in sync.