>To go along with the information I originally submitted here is a snippet of
>the dsmerror.log. Does this make sense to any of the Unix folks out there?
>
>05/07/03   03:13:35 TransErrno: Unexpected error from lstat, errno = 22

>From my programming notes, Unix errno 22 is...

EINVAL          22      Invalid argument.
                        Invalid argument to a library function.

You could look in your Tru64's /usr/include/errno.h to get the name of the
errno; then do 'man lstat' on the Tru64 system and look at what EINVAL
indicates.  The man page that I could find on the web was misleading so I
won't cite it.

Taking it from the abstract, then: lstat() is used to get information on a
symbolic link.  It has two arguments, a path spec and a buffer address.
Probability suggests that the program has the buffer address correct, so
something is wrong with the path.  Whereas the TSM operation was an incremental
backup, it would seem that the TSM client was acting on the file system objects
list it got from the server and was going to check what it thought was a
symbolic link - which may not be so now, and so Tru64 reacts as you found, which
results in weird conclusions by the client.

What to do?  You might retry the operation and see if the same thing results.
If so, I would do a 'find ... -ls' through the file system(s) and see if any
anomalies turn up with that OS command.  If nothing, and the Incremental backup
remains hopeless, I would do a full backup (Selective, or MODE=ABSolute) to
cause a non-comparative backup which would ostensibly "fix" the inconsistency.
At least in this case.

You might see if the Tru64 system is up to date on patches, which may play a
role in this situation.  Beyond that, refer to TSM Support.  If nothing else,
the wacky concluding statistics need work.

   Richard Sims, BU