As stated previously, TSM will not give you the original file size OR the
real size after compression on the back end.  So all you can look at is file
counts.

Another possible approach to the file counts is sampling

When I had to do this, I actually pulled ALL the entries from the backup
table for a just a handful of clients in categories that we considered
"typical", and used a SAS program to read and count them.

>From that we extrapolated the results over the entire population of clients.

That approach only works if you can group your clients into categories of
"similar" machines.

But, give the size of my data base and the fact that a query against the
whole backups table without using the index will NEVER complete, it's the
best I could come up with!





-----Original Message-----
From: Richard Sims [mailto:rbs AT BU DOT EDU]
Sent: Wednesday, April 02, 2003 2:08 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Sum of inactive versions


As discussed on this List in the past, you can't get client file sizes
from server queries, so there is no way therein to sum the savings of
changing retention policies.  You could approach it on the basis of
client queries on Inactive files.  Another approach is proportion: if
you have a good idea of the population of Inactive files relative to
total possible population per your retention policies, then reducing
the policy number by a certain percent would result in a proportional
percent drop in your current server storage pool numbers.

  Richard Sims, BU