David, the way that SQL-BackTrack sends data to ADSM is that it uses
unique object names for every backup.  So ADSM never has more than one
version on an object, and therefore it is always an active version and
never expires UNLESS, SQL-BackTrack issues a delete-api call to delete the
object.  There is a parameter in backtrack that says how many versions you
want to keep...if you say 30 versions, then when the 31st version is
created, backtrack sends a delete-api to adsm for the oldest version.  ADSM
changes the object to inactive in the ADSM database, and the next time
expiration processing occurs it gets deleted from ADSM.

The only way to delete from ADSM is the delete filespace, but backtrack
will still think ADSM has the data, so this isn't a great way to deal with
your problem.  We need to get backtrack to issue the delete api calls....
you need to change the number of versions settings on backtrack...let me
know if this is still a problem...my email is cbehrens AT vnet.ibm DOT com,
thanks, Cyndie Behrens (IBM San Jose)