I had this problem once before, and it was caused by a bad recovery log.
Did you mirror your recovery log (have multiple files defined?)?  If so,
try renaming the first one so ADSM can't find it.  It will go to the second
one.  Once it's up again, you can delete the corrupted recovery log, format
a new one, and add it back into ADSM.

BTW, I'm surprised that ADSM doesn't go to the mirrored copies
automatically when it encounters a corrupt log.

      /
  /  *  /  Alan Hamilton
 *     *   alanh AT primenet DOT com


----------
> From: Karl Roessmann <roess AT AND.MPI-STUTTGART.MPG DOT DE>
> From: Karl Roessmann <roess AT AND.MPI-STUTTGART.MPG DOT DE>
> Date: Friday, July 4, 1997 04:14 AM
>
> hello
> we had a power supply failure on our ADSM server.
> After restarting the server, we get...
>
> ANR0900I Processing options file dsmserv.opt.
> ANR0990I ADSM server restart-recovery in progress.
> ANR0200I Recovery log assigned capacity is 768 megabytes.
> ANR0201I Database assigned capacity is 704 megabytes.
> ANR0306I Recovery log volume mount in progress.
> ANR0353I Recovery log analysis pass in progress.
> ANR9999D Monitor mutex acquisition failed; thread 0 (tid 4028737168).
> ANR7838S Server operation terminated.
>   0x1000625C *UNKNOWN*
>   0x10006300 *UNKNOWN*
>   0x100061D0 *UNKNOWN*
>   0x10006B04 *UNKNOWN*
>   0x10006D78 *UNKNOWN*
>   0x10007228 *UNKNOWN*
>   0x10005F18 *UNKNOWN*
>   0x100067B4 *UNKNOWN*
>   0x10019AA0 CreateLatch
>   0x1004FCCC AllocBufDesc
>   0x100529C4 bufAddDirtyPage
>   0x1007B140 RestartAnalysis
>   0x1007B5AC DbRestartRecovery
>   0x101FBC8C dbInit
>   0x10294DAC *UNKNOWN*
>   0x10000724 *UNKNOWN*