...
>Our tape copy pools are kept offsite.  Reclamation for these pools is
>handled by leaving the TSM reclamation threshhold at 100% so that he never
>does reclaims on his own.  On a regular basis, we run a job that queries
>the server for copy pool tapes with a reclamation threshhold greater than
>'n' percent.  This list of tapes is used by the operators to go and fetch
>the tapes to be brought onsite.  They then run a job that updates those
>tapes to access=readwrite, and issues a 'move data' command for each tape.
>
>Now the problem.  Some of these 'move data' processes treat the volume
>that is being emptied as 'offsite', even though the volume has been loaded
>into the library and its access updated to readwrite.  I'm pretty sure the
>reason for this is that the volumes in question have files at the
>beginning and/or end that span to other copy pool volumes which are
>themselves still offsite.
...

Bill - I gather that you are not using DRM.  I started out doing much the
       same as you, in our non-DRM offsite work.  Then I realized that I
was making it much more complicated that it need be...

You can greatly simplify the task and eliminate the problems you are
experiencing with the inevitable spanning issue by just doing
     DELete Volume ... DISCARDdata=Yes
The next Backup Stgpool will automatically regenerate an offsite volume
with that data, and pack it much fuller than Move Data can.  It's a win
all around.

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