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:[EMAIL PROTECTED] On Behalf Of Michael Bartl Sent: Monday, February 18, 2008 5:50 PM To: [email protected] 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
