I believe you're over thinking this a bit.  Why not just drop the threshold
to 60% and let the right thing happen?  It will mostly.  You might choose to
let them get a little emptier before you start, say 70%.

The thing to remember about offsite tapes is they go offsite ready to be
reclaimed in many cases.  This since you rarely fill all the tapes going
offsite.  If you have more than one per day going off, the first is full
while the second is partially empty and an immediate potential reclamation
candidate.

What most folks do is have an admin schedule drop the thresholds on the
various pools at certain times during the week.  They then raise the
thresholds back to 100 sometime later.  This threshold raising doesn't stop
the reclamation but the reclamation will stop once the current volume has
created its reclamation (you could also write a script to run that would
determine if any reclamation processes are running and manually stop them.
A little harder but it guarantees the processes will stop when you want them
to).  Offsite tape reclamation is done a bit differently than onsite
reclamation.  For offsite, *SM will reclaim all the tapes meeting the
criteria simultaneously.  This cuts down on tape mounts.  So when a
reclamation starts, you might see message in the actlog like "beginning
reclamation on tapes 5, 43, and 87."  This might cause tapes 6, 19, 25, 45,
and 83 to be mounted.  Once this reclamation process completes, 5, 43 and 87
will be empty and offsite.

Onsite tape reclamation works like a move data: the volume to be reclaimed
is mounted and valid data on that volume is moved to a filling volume.

Advanced Technique:

Another technique I've employed from time to time is to delete the offsite
volumes I want to reclaim and then run a backup stg operation.  This moves
the data to the copy storage pools that was on the volumes you deleted.  You
could script this with a number of select statements to find the volumes
meeting your original criteria, deleting the volumes you find and starting
the backup stg.  The danger to this approach is now you are perhaps
vulnerable to a disaster.  You need to think out when your db backup is
being done and worry a bit about reusedelay.  The other downside is if you
have damaged data on the primary pool volume and you find that out while
doing the backup stg, you're stuck.  That data is now gone.  If you hadn't
deleted the copy storage pool volume you could have recovered this data.
Bottom line on this technique is proceed warily and make darn sure you know
what you are doing.  I would rate this as an advanced technique not to be
undertaken by everyone.  I've only used it under strictly controlled
circumstances where I knew all the possible outcomes before I started.

Kelly J. Lipp
Storage Solutions Specialists, Inc.
PO Box 51313
Colorado Springs CO 80919
(719)531-5926
Fax: (719)260-5991
www.storsol.com
lipp AT storsol DOT com