In examining the output of reclamation under ADSMv3 I noticed something
interesting: data that was stored on the server some time ago without
aggregation (as in the case of a volume produced under ADSMv2, or where
too-small TXNGroupmax and TXNBytelimit values conspire to limit or effectively
prevent aggregation) is simply transferred as-is: the output is likewise *not*
aggregated. (You can verify with Query Content ... F=D.)  No effort is made to
construct output aggregates of some nice size, ostensibly because the data is
being kept in a size known to be a happy one for the client, to facilitate
restorals. Thus, in some cases, a Move Data (which does no aggregate
tampering) may be just as effective as a reclamation, while taking far less
time because of its limited processing.

Shops with long-lived data, originally stored under versions of ADSM prior to
v3 may not realize that more database and tape space than necessary under
contemporary software technology is being consumed in the storage of their
data.  (One solution, where feasible, is to rename the backup version of the
filespace, perform a fresh backup, and delete the renamed safety copy after
some reasonable amount of time.)  Remember also that HSM data is not
aggregated.

Just one of those little things to be aware of.

    Richard Sims, BU