We had a similar situation recently.  Our ADSM server is V2.1.10 on AIX,
though.  Our recovery log had gone to 100% and ADSM just sat there and
wasn't doing much of anything.  We canceled whatever we could and it
still stayed at 100%.  We defined some temporary log space and extended
the log, then restarted ADSM.

I opened a pmr with IBM to see what else we could've done.  Apparently
there is an undocumented ADSM command called:   ckpt    .  This forces a
checkpoint on the log and will 'normally' reduce it.  We've not tried
the command to see if it works yet.  To see what caused the log to fill,
IBM gave us series of show commands.  (these would have to be done
before the ckpt command, of course).  They are:

q se f=d                        q log f=d
q pr                    show dbtxn
show threads            show logseg
show locks              show logv
show txnt               show dbvars
show dbtxnt


Angel Boles

Westinghouse Electric
(412) 642-5944
Win 272-5944
bolesav AT westinghouse DOT com

>----------
>From:  Dianne Sharp[SMTP:DSHARP AT clear.co DOT nz]
>Sent:  Thursday, May 08, 1997 9:40 PM
>To:    ADSM-L AT VM.MARIST DOT EDU
>Subject:       ADSM Recovery Log filling up
>
>We're running ADSM Server V1 for MVS.
>
>Last night, our ADSM Recovery Log filled up, causing several backups to
>be missed.
>When I did a Q SESS command, there was only one active session showing
>for a Netware client which had been in a Wait state for over 12 hours.
>Investigating the logs on that client, I figured out that a session
>started at 18:30.  Then at 19:39 there was a TCP/IP connection failure.
>A retry occured and another session was established at 19:59 and the
>backup completed OK.  However, the first session was never stopped.
>
>I cancelled the "hung" session and the recovery log was still over 96%
>full, so I ended up restarting the ADSM Server and the recovery log
>utilisation went down to under 1%.
>
>My theory is that the "hung" session somehow caused the recovery log to
>fill.  Has anyone else experienced the same problem?  If so, what's the
>solution?
>
>Dianne Sharp
>Operations Analyst
>ISS CUSTOMER SUPPORT
>Ext 4208
>