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 <mishagr...@gmail.com> Date: Tue, April 13, 2010 11:19 am To: ADSM-L@VM.MARIST.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.schnei...@computercoachingcommunity.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 <yodaw...@gmail.com> > Date: Tue, April 13, 2010 9:37 am > To: ADSM-L@VM.MARIST.EDU > > Is there a way to find the list of files/amount of data that will expire > in > the next 60 days? >
