Thanks for the response, Greg (and everyone else)...
> Wayne...I would suggest carefully the policies you make available to
> your clients.  For example, your situation (from what I can gather)
> may warrant you creating a 2nd policy domain...one for your servers
> and 1 for your workstations.  The workstation policy domain could
> have policies that only allow 1-2 versions of backups to be kept, instead
> of 4...which might be needed for your server files.  This is just
> one idea in the short term...greg tevis

I have 2 policy domains now, but for these transient files, there is
never more than one copy that ever exists, so for these "problem"
files it doesn't matter whether I keep 1 or 1,000 versions.  The
expiration period of course does matter, but this affects the quality
of our backup service as we decrease it (from, gulp, now 90 to 60 days).

As others have recognized, there are two areas of enhancement needed.

1   - We need tools to understand what is in the database.  I don't
    need a statistical package; relatively raw data that I can massage
    would be great.  Any "point-in-time" future capability will be
    strongly applauded, but will make enhancements in this area even
    more important!

2   - DSM.OPT has been a maintenance problem.  We still have nodes
    that haven't "upgraded" to use ERRORLOGRETENTION and
    SCHEDLOGRETENTION.  It's next to impossible to accomplish anything
    on a wide scale.

    We can say (and have said) that we need to tailor DSM.OPT at our
    site before our clients download and install ADSM, but new
    features and new "temp" directories still would only be used by
    "new" clients.  I think we need some server-centric policy help in
    this area. Can ADSM designers share some of the possibilities that
    are being considered to solve these problems, please?

Thanks for listening and cheers,
wayne

Wayne T. Smith               mailto:wts AT maine.maine DOT edu
Systems Group -- CAPS        University of Maine System