>I'm not convinced that this isn't just a "let's-try-it-and-see-what-
>happens kind of answer either.

If you have sufficient extra disk space, a possibility is to basically
simulate the ADSM server directory elsewhere (separate system, perhaps)
and run the DSMSERV AUDITDB there on viable images of your ADSM
database, the purpose being to see if any errors are detected and
corrected, plus find out how long it will really take.  You wouldn't
really care how long this took as it is out of the way, and would let
you know if a "real" run was worth it.
I wonder if anyone out there has tried this in the past?
(Actually, doing something like this every six months or so might not be
a bad idea for peace of mind, as all of us wonder if any discrepancies
have crept into our databases.  Getting a sense of "when" would be
helpful, too.)

It would be helpful if IBM, when pursuing such problems with the customer,
could identify in what logical area such a database error exists and if
the error would go away with some kind of deletion.  I'm sure a lot of
customers would find it preferable to delete an inconsequential filespace
or ADSM definition rather than go through a protracted database repair.

    Richard Sims, BU