Matt,

The way I handled this, on an AIX DB2 system, was simply to add a
management class (which I called DATABASE) with the following copy group
settings - 1,0,0,0.  On the client, I added a statement to the inclexcl.txt
file (include/exclude list) as below:

include databasefilesystem    DATABASE

The "databasefilesystem" in the line above is the filesystem that the DB2
API creates on the node in TSM.  It's usually the name of the database, in
capital letters, as a filesystem name - ex: /LOTSOFDATA

This will cause the backups from now on to bind to the new management
class, so when the DB2 DBA's run db2adutl to delete backups, they will go
inactive and be deleted on the next Expire Inventory.  The old ones don't
bind to the new management class, so the inactive ones will take however
long the old management class told them to expire, so you're stuck with
them for a while.  Unless...

If the backups are the only thing on a volume ("q content VOLSER" only
lists the DB2 backup), you can just do a "delete volume VOLSER discard=yes"
and that will rid you of the backup.  Since DB2 already has deleted all
references to that backup, they can't restore it anyway.  Just be very
careful that the only thing on the volume is an expired DB2 backup.  (You
can tell if it's an expired/inactive backup by running "show versions
/LOTSOFDATA" and looking for that individual backup.  Of, if you know
they're keeping 10 days of backups, look for the date part of the backup
name that says it's over 10 days old).

Nick Cassimatis
nickpc AT us.ibm DOT com