On 5/21/07, Richard Sims <rbs AT bu DOT edu> wrote:

Michael -

I think you mean 05/20/2007 in the above.

yes!

There are two other factors at play as well...
First, the volume location information says offsite.  That suggests
the use of TSM DRM, and in that case, DELete VOLHistory should not be
used for pruning dbbackup volumes; and such offsite volumes need to
be returned onsite (Vault state) before the pruning will work.  The
second factor relates to the Backup Series number, which you
suspected.  You had been performing dbsnapshot type backups for some
time, having gotten up to 164 generations of them, where their series
number is independent of full+incremental backup series numbering,
and now you have the series number back to 1.  TSM is confused, and
refuses to perform the volhistory deletion, based upon its last-
backup preservation rule.  I don't know of circumstances where the
series number would reset like that: Activity Log research may shed
light on it.

I've also noticed that the Backup Series number has jumped from 164 to 1.
The only thing  that could perhaps cause this and I can think of is db
reorganization that I have performed a week ago.

Did a Force work to delete it?

I haven't tried it yet.
I'd prefer to figure out what's the root cause of such a weird (IMO)
behavior before I attempt to delete that volume forcibly (if there is
no other choice).

--
Warm regards,
Michael Green