Tom...SQL-BackTrack should be deleting all old files...it sends delete object
api calls to ADSM when the number of versions option (specificed in SQL-BackT)
is exceeded.  Files will not be deleted based on number of days on ADSM.  On
ADSM, each file is a unique object and hence, will always be an active copy.
The only way it gets deleted is when the delete object api call happens.
ADSM doesn't delete the object right away...we change the object from active
to inactive, and the next time file expiration processing occurs, the
object is "logically deleted"...that is, deleted from the ADSM database.

I'm not sure if SQL-BackTrack also sends delete api calls based on time, but
it does send it when you reach the number of versions....

I dont' know whether you are using compression, that might account for size
differences, or perhaps emtpy space in the database that doesn't get backed
up.

If something is messed up and you do have stranded stuff on ADSM, you can
delete it by deleting the filespace (which means deleting everything) or
by sending a delete object api call from an application (tough to replicate).

You might want to give DataTools a call to determine if you really do
have something stranded on ADSM...this shouldn't happen; so if it has
happened maybe there is a bug??
thanks,
Cyndie Behrens (IBM San Jose)