On Jul 9, 2008, at 2:25 PM, Bell, Charles (Chip) wrote:

Does that plan apply, considering (something I don't think I
mentioned) that
only the most recent numerical mount point is getting changed data?
Most of
the other mount point backups are getting few to no files changed. A
co-worker and I were discussing a similar script...

Yes; it would be the most recent generation mount point which would be
treated to the Incrbydate, the presumption being that file timestamps
reflect when the file was written to the volume, so as to be later
than the last such backup.  The previous generation mount point would
deserve an Incremental at that time, to catch any files added to it
which filled it to the app's 80% threshold level to incite going on to
a next generation volume.  Thereafter, the elder volumes would have
assured backups of the older data, and could be gone at every once in
a while to pick up the minor deltas.

This makes the most sense to me, rather than lavishing TSM attention
on essentially static volumes by way of complex Journaling et al. Ye
olde philosophy of keeping things as simple as possible.

   Richard Sims