On Fri, 17 Sep 2004, Richard Sims wrote:

> Interesting propsal, Mike: effectively a -preview mode for Backup.
> Note that, on Unix systems at least, an analogous function may be
> performed via the 'find' command, using a -mtime value relative to
> the last backup time for the filespace, which is granular to 24 hour
> time intervals.  (Finer granularity could be had by using 'find'
> -mtime and -exec, to have a small Perl module do a stat() and test
> the file's last-modified time; or the more ambitious could write it
> all in Perl or C.)
> But it would take a dsmc facility as you propose to report the more
> interesting case of files now gone from the client which are still
> TSM space.
>
>    Richard Sims    http://people.bu.edu/rbs
>
> On Sep 17, 2004, at 8:04 AM, Mike wrote:
>
> >Since dsmc already knows how to read the local filesystem,
> >how to parse the dsm.opt/dsm.sys/inclexcl.list, and how
> >to talk with the tsm server, please (whomever) enhance dsmc
> >with a switch such that when run on a local node, not with
> >-virtualnodename, the program will load the dsm.opt, scan
> >all local files, and scan the repository, then generate a
> >list to stdout of all files on the local system that do not
> >exist in the repository.
> >
> >Mike
>

I am looking for something more than a -mtime. My concern is a
mistake in the dsm.opt/dsm.sys/inclexcl.list that creates a
situation where only directories are backedup and no files in
those directories. I'm not asking for a list of files that
should be backed up now, though I really like that idea (-preview),
what I'm looking for is a set subtraction. Take a list of all
files in the live filesystems, subtract the set of all files
within the TSM repository, then give me the results. I'll look
at the results and see if they are 'resonable' not to be in
tsm, or decide that I need to modify my inclexcl.list, etc.

Mike