On Fri, 2002-12-27 at 12:03, bbullock wrote:
>         Ahh, this is an old problem that you can find in the archives. But
> to save you the trouble, here is the fix.
> The simple answer is a "audit vol fix=yes" but for a copypool tape, you need
> a couple extra steps:
>
> update vol $1 access=readw
> audit vol $1 fix=yes
> update vol $1 access=offsite
>
> (note, you do NOT need to insert the tape, it will never ask for it).
>
> It will now be empty and should be returned by your normal DR processes.

When it comes to copypool tapes, there is a *far* easier way to convert
those suckers to scratch. Run
        delete volume <volume_name> discarddata=yes
The next time there is a backup from primary pool to offsite pool, TSM
will write those deleted files to another tape. The window of
vulnerability can be minimized by running the volume deletes immediately
prior to the stgpool backup.

This is *much* quicker than bothering with updates and audits,
particularly if the tape volume is densely populated, or the tape media
is a slow-mounting and -seeking type like DLT.

--
Mark Stapleton (stapleton AT berbee DOT com)