I have gone through the process you are describing a few months ago and am
now past the "retain last Version" date. Which leaves me quite puzzled. I
did not set my new value to zero though, I used 2. It matches my DB backup
count.
I still have some non API stuff hanging around and am now under the believe
that there are also other things happening. I am under the belief that the
number of versions kept is determined by the lesser of the VERSIONS DATA
EXISTS (nolimit) and RETAIN EXTRA VERSIONS (42) . I am trying to meet the
requirement of saving 42 days worth of backups.
Thanks Again
Matt
-----Original Message-----
From: Nicholas Cassimatis [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 10, 2001 1:12 PM
To: [EMAIL PROTECTED]
Subject: Re: things NOT expiring
For #3, after the db2adutl command tells TSM to delete the file, it is kept
for the "Retain Last Version" number of days, per the management class it's
bound to. 90 days is a common number there (for me, at least), so that
means you're keeping 90 versions more than you need to. You can fix this
by binding the database backups to a management class where this value is
set to 0. On the TSM Server, you'd create the new management class (I
called mine DATABASE to make things easy), and then added the following
line to the include/exclude list on the client (in this case AIX, be
basically the same on NT):
include /NAMEOFDATABASE database
Unfortunately the old backups don't rebind (since they don't have a backup
run against them, they won't), but in "Retain Last Version" days, they'll
all be gone.
Nick Cassimatis
[EMAIL PROTECTED]
Today is the tomorrow of yesterday.
