...ANR0990I Server restart-recovery in progress.
ANR0200I Recovery log assigned capacity is 13312 megabytes.
ANR0201I Database assigned capacity is 24520 megabytes.
ANR0306I Recovery log volume mount in progress.
ANR0287W Contents of the page shadow file DBPGSHDW.BDT are not valid.
ANR0285I Database page shadowing started using file DBPGSHDW.BDT.
ANR0353I Recovery log analysis pass in progress.
ANR0354I Recovery log redo pass in progress.
ANR0355I Recovery log undo pass in progress.
ANR9999D pkthread.c(791): ThreadId<0> Run-time assertion failed:
"CmpLsn(
*pageLsnP, hdrP->updtLsn ) != LESSTHAN", Thread 0, File dblog.c, Line
1061.
...

There has been no prior posting indicating what that ANR9999D message
actually means, but I would guess that it reflects a Recovery Log
problem, maybe even that the log (over)filled, as perhaps for lack of
scratches when the Dbbackuptrigger level was reached. (Letting spaces
fill to their maximum is dangerous in that such boundary conditions
typically see little or not testing in most program development, and
odd symptoms may result. This is an old TSM level, so may exhibit odd
behavior when limits are reached.) Unfortunately, the administrator of
that system disregarded best practices and maximized the size of the
Recovery Log to 13 GB, which all but eliminates "wiggle room" in being
able to add a small increment to get by restart. You might attempt to
add a few megabytes to the Recovery Log to see if that allows you to
get by the condition. I would set "NOMIGRRECL" and "DISABLESCheds Yes"
in the server options file for the restart attempt, to try to eliminate
extraneous ingredients. You could also try applying a higher level 4.2
patch level, but I'd be disinclined to. You may have to perform a DB
restoral to get past this.

    Richard Sims