The symptoms you are describing sound more like retries of files that changed 
while TSM was reading them than growth in the size of individual files. Having 
the 'compress' option set to 'no' would, as far as I know, rule out the 
possibility of growth in the size of individual backup files. The worst growth 
I have ever seen for individual files was about 30%, not the almost 100% you 
mention. Retries caused by changing files would be noted explicitly in the 
client log files.

Thomas Denier
Thomas Jefferson University

-----Gary Lee wrote: -----

I have at least two linux clients v6.4 tsm server 6.3.4 whose bytes backed up 
are nearly double the bytes inspected.
Compress is set to no.

I would like to find the offending files which are growing.

The following script shows files backed up yesterday, for a specific node, 
(thanks andy raibeck), but I would like to add and order by file size.

How do I add the object_id field for comparison with the contents table, but 
not print it?
Script follows:

[Script removed]
The information contained in this transmission contains privileged and 
confidential information. It is intended only for the use of the person named 
above. If you are not the intended recipient, you are hereby notified that any 
review, dissemination, distribution or duplication of this communication is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender by reply email and destroy all copies of the original message.

CAUTION: Intended recipients should NOT use email communication for emergent or 
urgent health care matters.