Mark Stapleton wrote, in part, a week or two ago:

You've got half of the problem solved. You should be running two commands
per storage pool to be reclaimed:

        upd stgpool <stgpool_name> reclaim=60

when you want reclamation to start, followed by

        upd stgpool <stgpool_name> reclaim=100

when you want it to stop. (It will stop sooner than the scheduled time if it
finishes first.)

A few remarks ...

1. The low value that you use (60% in the above example) is completely
up to you. Lower values tend to decrease restore times, wear out
read/write heads, and potentially to decrease the number of tapes
required.  Higher values tend to leave more tape drive time to do other
*SM actions.  My hardware and rate of data change cause my low
reclamation value to be more like 75-85 for my collated and copy pools.

2. The current tape's reclamation won't stop when you set recl=100, but
will complete (unless you cancel the process). A tape reclamation might
be quick, but might be fairly long depending on several data and
hardware variables. My reclamations can run over an hour, but are
generally somewhat less slow.

3. Although it may have changed in current *SM versions (mine is V3),
reclamations of offsite volumes (in a copypool) are selected somewhat
differently than others.  Tivoli ADSM determines the volumes eligible
for reclamation of copypools (just offsite tapes?) when you lower the
reclamation value. The reclamation process will continue until all of
those volumes are reclaimed ... even if you change to recl=100.

4. Reclamation (in tandem with some other operations such as backups) is
one of the activities that can cause your recovery log to become pinned
(I don't use roll forward).  So, it might pay to keep an eye on the max
utilization of your recovery log ... well, it probably will pay to keep
an eye on it anyway ;-)

Hope this helps, wayne

Wayne T. Smith -- ADSM AT Maine DOT edu -- University of Maine System -- UNET