Well, I am no expert on this, so I am willing to be corrected by
somebody if I don't have this right, but here is my understanding.

Yes the deactivate_date will tell you when a given backup object became
inactive, but that won't reliably tell you when it will expire, because
as I said, you don't know what other versions will be coming along. 
Newer versions can cause it to expire sooner.

What if, in my previous example, yoda.txt is in a management class whose
backup copygroup policy is 7 versions for 30 days?  The file gets backed
up on 4/13/2010.  The next day yoda.txt changes, so it gets backed up
again on 4/14/2010.  So at the next 'expire inventory' the 4/13/2010
version of the file becomes inactive, and deactivate_date gets set to
4/13/2010.  If the policy says 30 days, it would be easy to think, yeah,
it is going to really expire on 5/13/2010, 30 days later.  But what if
yoda.txt keeps changing every day? Then yoda.txt from 4/13/2010 is going
to expire when 7 new versions have backed up, on 4/20/1010.  But what if
yoda.txt only changes every other day, or not at all?  

You can do a select to find out all the files that are deactivated, but
the best you could determine is the outside window of how many days they
might still be around, based on the number of days in the policy.  But I
am still not sure why it is useful to run such a report?

Best Regards,

John D. Schneider
The Computer Coaching Community, LLC
Office: (314) 635-5424 / Toll Free: (866) 796-9226
Cell: (314) 750-8721

 
 
-------- Original Message --------
Subject: Re: [ADSM-L] Running a report on what files will expire in the
next sixty days
From: Michael Green <mishagreen AT GMAIL DOT COM>
Date: Tue, April 13, 2010 11:19 am
To: ADSM-L AT VM.MARIST DOT EDU

John,

Please correct me if I'm wrong.
select * from syscat.columns where tabname='BACKUPS'
shows that there is a column called DEACTIVATE_DATE. I guess if you
write a select statement crafted in such a way that it also takes into
account current date, the management class (CLASS_NAME from BACKUPS)
VERE/VERD/RETE/RETO, then you can conclude if the object is candidate
for expiration.

Running such a select on a production machine is a whole other story.
--
Warm regards,
Michael Green



On Tue, Apr 13, 2010 at 6:37 PM, John D. Schneider
<john.schneider AT computercoachingcommunity DOT com> wrote:
> Because of TSM's incremental backup scheme, there is no way to know what
> files will expire, because their is no way to know what new versions of
> files will be taking their place in the future.  For example, say there
> is a file called yoda.txt.  If that yoda.txt file is backed up once and
> is never changed, then the backup for it will never expire because the
> backup of that file remains the "active" version of that file.  If,
> however, yoda.txt is changed from time to time, and a backup runs every
> day, then the older versions of the file become "inactive" versions of
> the file.  Then the inactive versions will expire when they exceed
> either the number of days or versions that you defined in the policy.
>
> So, when I backup yoda.txt today, there is no way to know when this
> version of yoda.txt is going to expire, unless I have some way to know
> how many new versions are going to replace it in the future.
>
> Can you tell us why you think it is necessary to predict what files will
> be expired, or when?  Since new backup data will be coming in
> continuously, is it really important to know?
>
> Best Regards,
>
> John D. Schneider
> The Computer Coaching Community, LLC
> Office: (314) 635-5424 / Toll Free: (866) 796-9226
> Cell: (314) 750-8721
>
>
>
> -------- Original Message --------
> Subject: [ADSM-L] Running a report on what files will expire in the
> next sixty days
> From: yoda woya <yodawoya AT GMAIL DOT COM>
> Date: Tue, April 13, 2010 9:37 am
> To: ADSM-L AT VM.MARIST DOT EDU
>
> Is there a way to find the list of files/amount of data that will expire
> in
> the next 60 days?
>