Luke wrote, in part..
>     Is there a way to identify how the addition of a node affects the
> TSM database size?  I can capture the number of files and the amount of
> data that each additional node adds to the TSM server, but what I'm
> really looking for is a way to separate how a particular node affects
> the database size.  Even better would be to identify how much a
> particular type of workstation affects the TSM database.

Some of my Win workstations have a couple of hundred files and a
few megabytes in *SM and others have a couple of hundred thousand
and many gigabytes.  Further, some of my workstations have nothing
change in a week and others have tens of thousands of files and
gigabytes change in a day.

The good news is that DB size can be estimated, if you can make
good guesses as to what will be backed up and how long everything
must be saved.

I estimate that the DB will require 1 kilobyte per DB entry and that a
DB entry is a backed up (file or subdirectory) object (version). Yes, I
know it really takes less space, but this is an estimate and I want my
estimate to be a bit conservative.

Now, to really restate the obvious: the number of objects on a
workstation is probably not equal to the number of *SM DB objects!

A DB object is something that has been backed up. Forget that the
object contents rattle around the backup server, for this discussion.
It's only important to know that an object has been backed up to the
*SM server.