On Aug 24, 2007, at 2:16 PM, Allen S. Rout wrote:

On Fri, 24 Aug 2007 13:16:10 -0400, Richard Sims <rbs AT BU DOT EDU> said:

I would want to, as wild stuff like this may signal file system
corruption, which I would want called out and addressed ASAP.
Bizarre inode data is scary stuff.  If there is file system
corruption, you definitely don't want further backups sending new
Active files containing useless crud, thus displacing the earlier
versions of the file(s), which may contain good data, which you may
well want for restoral.  At a minimum, I would investigate how those
files entered the file system.

I have the same initial response.  We know how they got there: this is
a computer-science research group's filesystem, and they're writing
stuf.... shall I say, "unusually" ?  :)

That recalls the movie, "Weird Science".  Good thing they're not in
chemistry.   :-)

But while the discussion goes on about how one ought to write files,
it'd be nice to be able to tell TSM "Carry on".

That brings up the longstanding issue of the TSM Exclude function
having failed to evolve, to cover real-world needs.  There are some
areas in TSM where innovation just doesn't happen, and there the
product remains in the 1980s.  The CLI is a conspicuous example of
this, having remained moribund for many years (and even backward,
like artificially restricting the number of command line filenames to
20).  Exclude has long needed to provide far more flexibility than
TSM Development management has been willing to give it, so that we
can exclude pointless, empty files from backups; or files having a
certain creator name; or files having a specified date range.  And,
in your case, the ability to say to exclude files that are unsound,
and continue on so as not to fail to back up good files that day.

The stagnation in basic functionality of the product is tragic; and
most of that is in the underdeveloped client.  A remarkable
deficiency in the client is to perform a 'dsmc Query Backup', and not
be able to determine something as basic as whether the object is a
file, a directory; or to not have the management class name truncated
to 10 characters because of a lame programming decision someone make
15 years ago.  There's no way to generate useful reports from the
crippled command line client interface (and you can't get any file
detail info at all from server queries).  This is a very sad state of
affairs.  And it's all needless neglect, in no commitment to keep the
CLI modern and relevant, as vitally needed for batch and automated
processing.

   Richard Sims