Eric,

        Thanks for the response!

        Why bother?  For the same reason that using TSM 'Incremental
Forever' approach makes sense.  TSM, without co-location, has the same
problem you mentioned, about the fragmentation for restores.  TSM already
does the scan and checking of attributes to allow its Incremental approach
to work.  And using the TSM Journal even helps with that some.

        My thought is that this is if TSM is already paying the price (for
the most part), then it might make sense to do the next step in
optimization.  Especially for any enterprise site that is backing up a
number of (at least on the systems partition) substantially similar
machines.

        Even if it didn't work out, this would be a good study for
IBM/Tivoli TSM support team to make to see if it is 'worth it', to them and
to us as paying customers.

        I have no illusion that every suggestion will be taken, but ones
that make sense, and give an edge in the market place, with 'minimal' effort
(easy for me to say, I'm not the developer ;) - could be a good thing.

        In my not understanding the internals of TSM, I would think it would
need a field added to the DB record for each file (a big hit on DB size) to
keep an MD5 or similar checksum, update the server software to accept this
update and use it as an indexed search key, update the client to send and
check on the MD5 also, and update the Journal software to allow the cache to
hold and use the MD5 key. (I suggest MD5 as it is a well known algorithm
that should cover most sins, but I am sure a real statistical study would be
needed to see what is sufficient to give an assurance that it is really the
file needed.

        I am sure this will add some overhead, but hopefully enough would be
gained to overcome the cost!

        ... Still, it is just an idea.  And the TSM team has probably
thought of it anyway, and already dealt with it in house.

        ... Jack