ADSM-L

DB2/6000 and ADSM again and always...

1996-07-18 11:54:30
Subject: DB2/6000 and ADSM again and always...
From: David Bohm <bohm AT VNET.IBM DOT COM>
Date: Thu, 18 Jul 1996 08:54:30 MST
Hello:

You will need to use a different management class for the files that
are backed up with DB/2, SQL-Backtrack, or any other program using the
API interface that manages its own versioning of files using different
file names and doing the deletes for the files itself.  This only applies
to the files are being sent to ADSM as Backup data instead of Archive
data.

The reason for this is the Backup Copygroup contains VERDELETED and RETONLY
options which govern how long the file will remain in the storage pool
after it has been deleted on the client.  My recommendation is to have a
different management class for these backups and use VERDELETED=0 and
RETONLY=0 in the backup copygroup for that management class.  This way
after the delete is issued from the client the next inventory expiration
will remove these files from the ADSM server storage.

In addition you need to make sure the node has the authorization to delete
backup data.  By default when you register a node it does not have the
authorization to delete backup data.

Hope this helps - David Bohm, ADSM technical support.
<Prev in Thread] Current Thread [Next in Thread>