Agreed.
"expire inventory" is actually something of a misnomer.

If you have your retention set to 14 versions, and someone takes the 15th
backup, the oldest version expires right then, you can't get it back.  That
type of "expiration" takes place, no matter whether EXPIRE INVENTORY runs or
not.

The EXPIRE INVENTORY is what updates the %utilization on your tapes, based
on the files that have expired.  I think it also does some cleanup to make
space in the DB for the expired files reusable.

So you want to run EXPIRE INVENTORY before reclaim.
But I don't think it affects your migration in any way.

W

On Fri, Aug 28, 2009 at 11:23 AM, Thomas Denier <
Thomas.Denier AT jeffersonhospital DOT org> wrote:

> -----Sergio O. Fuentes wrote: -----
>
> >I'm revising my TSM administrative schedules and wanted to take an
> >informal poll on how many of you lay out your daily TSM maintenance
> >routines.  Functions I'm talking about here include:
> >
> >BACKUP DISK STGPOOLS
> >BACKUP TAPE STGPOOLS
> >BACKUP DEVCONFIG
> >BACKUP VOLHIST
> >BACKUP DB TYPE=FULL
> >PREPARE
> >DELETE VOLHIST
> >MIGRATE STG
> >EXPIRE INV
> >RECLAIM TAPE
> >RECLAIM OFFSITES
> >CLIENT BACKUP WINDOW STARTS (back to top)
> >
> >The above sequence is roughly how I handle our maintenance and is
> >based off of the IBM Redbook (sg247379) TSM Deployment Guide for 5.5
> >(page 300).  I'm seriously considering altering it in this manner:
> >
> >BACKUP STGPOOLS
> >BACKUP DEVCONFIG
> >BACKUP VOLHIST
> >BACKUP DB
> >PREPARE
> >DELETE VOLHIST
> >EXPIRE INV
> >RECLAIM
> >MIGRATE STG
> >CLIENT BACKUP WINDOW STARTS (back to top)
> >
> >The key difference here, is that I'd be expiring right after the DB
> >Backups, and reclaiming space before migration.  I feel that this
> >would be more efficient in terms of processing actual unexpired data
> >and data storage (since reclamation would have freed up storage
> >space).  I would be concerned that migration would run in perpetuity
> >in cases where the migration window runs into the client backup
> >window.  Therefore, I might have migrations run before reclamations.
> >Does anyone else expire data right after your DB backups on a daily
> >basis?  Suggestions from anyone?  Thank you kindly.
>
> 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.
>