Hmm..  seems like I'm not explaining the my whole story here.  The purpose for 
this tinkering of admin schedules is to be as efficient as possible so I'm 
examining the repercussions of adjusting the expiration schedule.  We do in 
fact have a larger SATA pool we use for storing about a week's worth of backup 
data.  In addition to that, a few of our retention policies limit backup 
versions to only 2 or 7 versions.  Given these parameters, there may be 
instances where there is expired data on the SATA pools (devclass file).  I'm 
trying to avoid data movement (SATA to SATA or SATA to TAPE) of expired data 
which may still be processed if expire inventory has not yet run.  Seems like 
there would be little benefit in doing so.  However, we may be running into a 
situation from noon to 5pm where the only thing I will be allowed to do is 
reclamations or expirations.  Which is why I wanted to do migrations last.  
Well, back to the drawing board.

SF

-----Original Message----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Thomas Denier
Sent: Friday, August 28, 2009 11:24 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Daily TSM maintenance schedules

I don't understand what benefit to hope for in terms of 'processing
actual unexpired data'. You seem to be described a system in which
disk storage pools are short-term buffers for incoming backups.
With this usage pattern, disk storage pools will contain few
inactive backup files of any sort, and no backup files that have
been inactive long enough to be candidates for removal by an
expiration process.

The 'expire-reclaim-migrate' version of the proposed change will
cause reclaimed volumes to revert to scratch or 'Empty' status a
few hours earlier than they would under your current policy. The
'expire-migrate-reclaim' version of the proposed change would
eliminate even this marginal advantage.