I know this won't help you now, but if you are running with LOGCOPY volumes 
I've been able to recover from a corrupted log file in
the past by renaming the primary log volumes in the filesystem and bringing up 
TSM. It will recognize that the primary log files
aren't there and use the copies. I've done this several times (all of the 
Windows..go figure!) in the past and been able to get the
server back up and running.

Then just rename them back and vary on to get them to re-sync.

Bill Boyer
"Proudly Serving My Corporate Masters"


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Michael Bartl
Sent: Monday, February 18, 2008 5:50 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Internal error DBLOG666 (5.4.0.3 Win32-Server)

Hi all,
first of all, many thanks for the fast replies. You've been right, we had a 
corrupted Recovery Log.
We've opened a PMR with IBM service and had to make this decision:

A) Restore the DB (Point in Time)
B) Do a DUMPDB, FORMATLOAD, LOADDB, AUDITDB

A) is painful regarding data-loss, B) is painful regarding time-loss.
We've decided to go for B), the first 3 steps used 1/2 day, let's see how 
AUDITDB performs.

I hope this all will fix our problem, but I have no idea what could have caused 
the problem...


Best regards,
Michael Bartl