Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!YALE.ARPA!LEICHTER-JERRY From: LEICHTER-JERRY@YALE.ARPA Newsgroups: mod.computers.vax Subject: Re: Corrupt VMS accounting file Message-ID: <8701120529.AA08491@ucbvax.Berkeley.EDU> Date: Mon, 12-Jan-87 00:29:15 EST Article-I.D.: ucbvax.8701120529.AA08491 Posted: Mon Jan 12 00:29:15 1987 Date-Received: Mon, 12-Jan-87 03:47:11 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Organization: The ARPA Internet Lines: 33 Approved: info-vax@sri-kl.arpa I had a disk failure that corrupted the accountng.dat data file on one of our systems. Approximately 1/3rd of the way into the file the accounting utility reports a read error of the sort: %ACC-E-READERR -RMS-W-RTB, 1171 byte record too large for user's buffer and then gives up. DEC Software Support claims they know of no way to read the data past the error. Surely there is a way to get to the good data beyond the corrupt records without resorting to using the ACR$ system calls. Any suggestions? What are the ACR$ calls? Anyway...one thing to try - which probably won't work, but you never know - is to apply CONVERT to the file. If there is damage to the file, this should fix it; you may lose a couple of records, but then again things may recover. If that doesn't work, you are reduced to hacking. The accounting file is a variable length record sequential file, so you have a bunch of records that start of with lengths. If the length of a record is clobbered, there isn't much you can do to figure out where the rest of the records are other than staring at them and re-synchronizing by hand. Try dumping the file and staring at it a while. You should be able (eventually) to figure out exactly how much is damaged and where the boundaries of the valid stuff are. Then you'll have to reconstruct the file somehow - possible with PATCH, or you could write a one-time program to do it. I'm afraid you are likely to be in for a lot of boring, time-consuming work. -- Jerry -------