TSM 3.7.3.0 running on OS/390 2.9

Last night our automated processes to shut the system down didn't take into
account that TSM would take a few extra minutes to halt due to reclamation
running. The automation script ended up taking TCPIP and CA-TLMS and
DFSMSRmm (in warn mode) down while TSM was still up and trying to close out
his tape processing. TSM ended up abending with a EC6. After our downtime,
TSM wouldn't come back up. It would sit there in a CPU loop with no I/O. The
last message in the joblog was "ANR0306I Recovery log volume mount in
progress." WOuld come up any farther. I managed to get an DUMPDB to run and
it took only 1/2 hour and dumped over 78million database entries for a total
of 6.9MB. I then did a FORMAT for all the db/log volumes and started the
LOADDB last night at 20:15. It is still running and it is now 22 hours later
and has only processed 70million of those database entries.

I searched the archives, but there wasn't much on LOADDB. Should LOADDB take
this long when the DUMPDB only took 1/2hour? Good thing this is a holiday
weekend or the users and managers would be more upset than they
are. I tell them, Hey it wasn't my shutdown script that corrupted the
system!!!

Also, if anyone has any ideas on how I could have averted having to do the
DUMP/LOADDB processes I would be more than happy to hear them. I just
couldn't think of any way to bypass the recovery log processing during
startup, or to have the load cleared by itself.

TIA,
Bill Boyer
"Some days you are the bug, some days you are the windshield." - ??