On May 21, 2007, at 6:29 AM, Michael Green wrote:

Richard, you are right, however in this specific case I'm not trying
to remove the last and only DBS that is left.

There are 2 (two) database snapshots, one from 05/06/2007 and the
other one from 20/06/2007. I expect that running 'del volh t=dbs
tod=today' would remove the older db snapshot leaving the one from
20/06/2007 and that doesn't work.

Michael -

I think you mean 05/20/2007 in the above.
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.  Did a Force work to delete it?

   Richard Sims