>If you start the server in the foreground it will be easier to determine what
>is happending by looking at the start-up mesages

As I mentioned, I had started the server manually, and there were no messages.
Only a handful of the usual processes appeared, indicating that the server was
stuck on something as it was coming up.  I resolved to run an AUDITDB FIX=NO
in that the manual's example suggested that it would yield messages as to its
progress.  It got as far as "ANR0353I Recovery log analysis pass in progress."
and then churned on that phase for 14 hours, devouring massive CPU time but
yielding nothing and going no farther.  Using a 3590 cartridge I tar'ed all
the database and recovery log files to have an "as it was" backup, then began
a dsmserv DUMPDB, INSTALL, LOADDB, and AUDITDB (on that phase now).  This
AUDITDB flew past the recovery log analysis pass that it had previously been
stuck on; so it was the recovery log which had been a problem.  (There had
been no ADSM activity of significance around the time of whatever incited this
problem, so loss of the recovery log contents is inconsequential.  I was
thinking that it might have been as good to simply dsmfmt the recovery logs
and then try an AUDITDB rather than go through the DUMPDB/LOADDB, but I did
want to experience these recovery aids.)  For those who haven't run AUDITDB or
LOADDB before, expect about 2 hours per gigabyte on an IBM RS/6000 595 (a lot
like watching grass grow if you're time-pressured; but there is a tremendous
amount of I/O occurring).  DUMPDB is much faster.

For the ADSM server developers out there: Please code some awareness into the
server such that it puts out messages and terminates when it runs into a
hopeless situation as in this instance.  It's bad when a customer is trying
to restore service and the server just endlessly churns with no indication of
what's going on.  Too many customers have encountered this nerve-racking
situation under pressure.

    Richard Sims  Boston University OIT