Hi Richard,

>>Yes, you can compress the database as long as you are running TSM 3.7.
>>There is a new server utility called UNLOADDB.

>There is no datbase "compress" - there is only compaction, as in
>bringing data together rather than shrinking it.  See List archives.
>In that compaction does not reduce what is in the database, you should
>not expect the percent utilization to drop.i

OK, maybe I used the wrong term. Perhaps degragment or reorganise might be a 
better. Whatever term is unsed, the UNLOADDB/LOADDB most certainly can reclaim 
large amounts of your database space. As I said in my note yesterday, we are 
seeing in testing of this utility a redection in utilisation of a 40+GB 
databases from 90%+ utilisation to around 60%.

As it was explained to me some time back, when you remove entire filespaces, 
some pointers are retained within the database in order to keep the b-trees 
balanced for performance reasons. The UNLOADDB/LOADDB removes these pointers 
and returns the freed up database pages to you.

See the TSM 3.7 Administrators Reference manual, Appendix A. There is a new 
DSMSERV subcommand called UNLOADDB. The quote from the manual, "Use this 
command to recover the contents of the database when the server is offline. 
This command unloads the database in key order so when the database is reloaded 
the space required for the database is minimized.".

We are doing our first production UNLOADDB/LOADDB this coming weekend. I am 
expecting not only a reduction in database utilisation but also some degree of 
performance gain. I'll post some results next week.


regards,

Trevor