> Thanks, thats what I did wrong.  Question, I created the new mgmt class and
> last nights incremental is bound to that class, but the other inactive
backups
> are still bound to the old mgmt class.  Is there a way to rebind them to the
> new mgmt class, or do they have to age off according to the retain only
> parameter of the old mgmt class?

I only know of one way to rebind the inactive backups, and it would probably
be a lot of work. At a previous job I ran into the same sort of problem with
SQL-BackTrack, and needed to clean up the inactive backups in preparation for
changing our approach to disaster recovery. I obtained a complete list of file
names for SQL backups from the output of 'query content' commands. I then
removed the file names that still appeared in the control files maintained by
SQL-BackTrack to obtain a list of files to be deleted. I made a copy of the
sample code for the ADSM API and modified the copy to pretend to be
SQL-BackTrack, read the list of files to be deleted, and send a one byte dummy
version of each file to the ADSM server. This caused the server to rebind the
files to the new management class, which called for retaining only one version
of a file that still existed on the client. When the next expiration process
ran the one byte dummy files were kept and the corresponding real backup files
were deleted.

There are some more or less dirty ways of getting rid of files outside of
normal expiration processing. If you are lucky enough to have the inactive
backups on tape volumes that do not contain other types of backup files, you
could simply delete the volumes with the 'discarddata=yes' option. Earlier
postings to this list have described an undocumented procedure for deleting
individual backup files from the ADSM database. I personally would be too
nervous about database corruption to do this on a production server.