I'll re-post my prior message:
Don't set ADSM reclamation to 10% -  It'll spin tapes forever and not reclaim
much space.

It turns out that ADSM reclamation makes poor choices regarding which tapes to
reclaim.
If you have reclamation set to 60%, then tapes which are 40% full or less are
candidates, right?

So consider:
if ADSM picks a tape which is 40% full, it'll take maybe 30 minutes to reclaim,
and you'll only free up 60% of a tape.
If ADSM picks a tape which is 1% full, it'll reclaim it in 3 minutes, and
you'll regain 99% of a tape.

Clearly, ADSM should start with tapes which are 1% full, and work its way up
toward the tapes which are 40% full.  It would reclaim a lot more space a lot
faster if it worked this way.

But it doesn't do this.  Instead, it works off a list which is roughly ordered
by total capacity of the tape and completely ignores the utilization.

Two ways to get around this:
1. Use admin schedules to set reclamation to 95% at 6AM, 90% at 6:30, 85% at
7:00, etc.  Tacky, but....
2. Write a script which does a "Query Volume", sorts the output, then does
"Move Data"s on the easiest one first.
I did the latter - it's very effective.

ADSM support understands this problem and has told me they will try to fix the
behavior in some future release.



ADSM-L AT VM.MARIST DOT EDU on 04/10/98 09:39:02 AM
Please respond to ADSM-L AT VM.MARIST DOT EDU
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: scratch volumes in STK 9710


Hi all,

We have reached the maximum capacity of our STK 9710 library.  Currently
all our tape storage pools have the reclaimation threshold set to 10 and,
since we perform full ADSM database backup daily, the REUSEDELAY has been
set to 0.  But these changes are not producing as much SCRATCH tapes as
expected.

Any other suggestion on how to further free up more slots in the library?

We are running ADSM V2.1.0.13 on an AIX machine.

Thanks,
Naveed.