>Also, I didn't see anything in the ADSM Admin. Reference manual about
>"unloading" the *SM DB.

It's in the Admin Guide.  Also in ADSM.QuickFacts.
I'm not convinced that this has any net positive effect, or that it's
worth the protracted effort.  It's going to compact database records -
bring them closer together, not compress them.  The database does not
become "smaller", as some vernacular suggests: the database is always
the same size, with data in it just reorganized.  (The Pct Util, is,
after all, just a measure of even just partially used pages.)  With
everything mooshed together, operations now have to go outside that
amalgam to write to free space, rather than intermingled free space
(presuming that this db works like many others), and this seems less
efficient to me for general db usage.  And how long does it stay
compacted vs. the effort undertaken to get it that way?

I'd like to see Tivoli publish a study on the value of this procedure,
showing a typical database's performance before compaction, immediately
after, and then periodically thereafter as a normal amount of activity
causes refragmentation.  Otherwise we're just speculating on its value.

   Richard Sims, BU