The first thing that I would do is look through your activity log
and see when and why scratch tapes are being defined into your
storage pools.

Collocation is a common reason for swallowing up loads of scratch
tapes. Collocation by filespace will cause it to happen even
faster.

Without further information, we'd only be guessing. But if you
look in the activity log to see what processes/sessions are
requesting/requiring scratch tapes, that should help to guide
your investigations.

 -- Tom

Thomas A. La Porte
DreamWorks Feature Animation
tlaporte AT anim.dreamworks DOT com

On Thu, 13 Jul 2000, Daniel Swan/TM wrote:

>As mentioned previously, I'm an ADSM newbie taking over the ADSM of a
>regional company.
>There have been ongoing problems with our offsite-tape rotation.
>
>Since I've taken over, I've put in 110 tapes, and
>reduced the total ammount of data stored in the tape library by 1.5
>terabytes (deleting filespaces, expiring old sqlbacktrack).
>
>But somehow, I have NO scratch tapes.  In theory, I should have TONS.
>
>It has been suggested to me that many tapes are being marked as read-only.
>I have investigated this, and have
>found that only 4 tapes have been marked read-only (q vol access=reado).
>
>I have managed to get a few back by agressive reclamation processes, but of
>course, this is tying up all available drives,
>so can only be done for a short time during the day.
>
>Does anyone have any ideas of where my tapes could be going?
>
>Any commands I can run to scare up more scratch tapes?
>
>Ps.  We have experts coming in to overhaul the system at the end of the
>month, but we're really
>scraping the bottom already...
>
>Thanks in advance,
>Dan.
>