A more draconian method (not recommended) is to perform a Delete Volume for the 
copy storage pool volumes you would reclaim, where their former content would 
be freshly written to tape in the next Backup Stgpool.  That leaves you with 
one less copy of the data, of course, so not the best approach.

The reclamation of offsite copy pool tapes can put a drag on your TSM server, 
as the processing involves inventorying the files on the offsite tape to be 
reclaimed, then identifying the onsite tapes containing the files, and compile 
that into a list ordered so as to minimize mounts and repositioning.  That can 
be a lot of database work, which can be observable as reclamation processing 
seems to pause for a time.

Where realistic, I like to bring a batch of offsite tapes back onsite, check 
them all in at once, then start reclaiming, where the span-from and span-to 
companion volumes are thus likely to be mountable, preventing the process from 
having to revert to primary pool tapes for the duration of the volume reclaim 
because of the spanning.  (It continues using the surrogate primary pool 
volume(s) even after having gotten past a span into the volume being reclaimed, 
where such processing can result in a bunch of primary pool tape mounts and 
think time between each, resulting in a reclaim which can run about 8x slower 
than a straight reclaim.)  You can spot check for spanning by performing Query 
Content <Volser> F=D Count=1 for a span-into condition, and Query Content 
<Volser> F=D Count=-1 for span-out-of.

To assess process progress, I employ a macro called 'processes', whose contents 
are:

SELECT Char(PROCESS_NUM,6) as "Number", PROCESS as "      Process      ", -
 Left(Char(START_TIME),19) as "    Start Time     ", -
 FILES_PROCESSED as "  Files  ", Char(BYTES_PROCESSED,14) as "  Bytes  ", -
 STATUS as "                  Status                  "  FROM PROCESSES

This is more useful than Query PRocess in that you can directly see how much 
data has been checkpoint committed, not just how much has been physically 
operated upon thus far.

    Richard Sims   http://people.bu.edu/rbs/ADSM.QuickFacts