--> This list of tapes is used by the operators to go and fetch the tapes to
be brought onsite.

I cannot figure it out! For what a reason you prefer to add more risk to
your offsite copies by bringing them onsite? Before new copies reach the
vault you are having *no* offsite copies (or your copies are less than
designed).
I can accept Richard's suggestion assuming he is doing delete and
subsequent stgpool backup *before* to retrieve the volumes onsite. But in
that scenario tracking what to be retrieved might be error prone process.
Yes, TSM is having rather complicated handling of offsite copies, but this
is done so intentionally!!

Zlatko Krastev
IT Consultant






Richard Sims <rbs AT BU DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
16.10.2003 18:34
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: SQL to determine what offsite volumes are needed 
for move data


...
>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