OC.CIVIL@CU20B.COLUMBIA.EDU (Holt Farley) (01/09/87)
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? Thanks in advance... Holt Farley Columbia Univ. Civil Eng. -------
dp@JASPER.PALLADIAN.COM (Jeffrey Del Papa) (01/12/87)
Date: Fri 9 Jan 87 15:01:04-EST
From: Holt Farley <OC.CIVIL@CU20B.COLUMBIA.EDU>
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?
Thanks in advance...
Holt Farley
Columbia Univ. Civil Eng.
-------
this is caused by a bad bit in the records length field at the start of the record.
the only thing to do is use a disk zapper to patch the byte.. (it is an issue of
relegion.. someone in the RMS group hates terminating bytes, and would rather have
a single byte error render much of a file unreadable.)
<dp>LEICHTER-JERRY@YALE.ARPA (01/12/87)
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
-------EVERHART%ARISIA@rca.com ("GLENN EVERHART, 609 486 6328") (01/12/87)
Re the message of a disk failure corrupting ACCOUNTNG.DAT and making the data beyond the faulted section inaccessible... This kind of clobbering can be repaired but needs some hand work to do so. The file in question is variable record length sequential, so the data is in the form <2 bytes of record size><record data> records. Such a file is read by grabbing the record size and then using it to get the data AND locate the start of the next record. Once the record size is out of sync, anywhere along the file, the system is unlikely to be able to get back into sync, since it will try to use random data bytes as record size. The way to patch this is with a file patcher (just about any one will do) that treats the file NOT as a sequential file, but as a set of blocks. (I tend to use DDT22 since I am familiar with it; patch could work too or lots of others that have appeared in DECUS circles over the years). You then find the block before the bad one and note its' last record count (since the last part of its record will be in the corrupted block). Now you have to build dummy records (or at least the record size words) in the bad block so the chain will be unbroken. To find how many bytes long to make the last you need to look in the next virtual block of the file to see how far in the next size word is. Doing this is simplest for text files where the size words appear as incongruous control characters among readable text. For a file like ACCOUNTNG.DAT the recognition will be harder (you'll have to find the internal format of the file documented somewhere or stare hard...) but it should be possible. In fact a dump of mine looks like the record size is fairly clear... You'll wind up with a few records of garbage by this procedure BUT the whole file will be readable. The only thing really important for this is that the chain of record sizes MUST be relinked (and hopefully you'll not make any record sizes longer than the utilities can handle... my dir/full says 159 bytes is the max...) Glenn Everhart Everhart%Arisia@rca.com 609 486 6328
rcb@mcnc.org@rti-sel.UUCP (Random) (01/12/87)
In article <8701120529.AA08491@ucbvax.Berkeley.EDU> <LEICHTER-JERRY@YALE.ARPA> writes: > > 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. > Why don't you write a program that uses RMS and reads the records of the file and writes them to another file. Give it a nice large read buffer, but do not write out any large records to the output file. No problem. --------- Random (Randy Buckland) Research Triangle Institute ...!mcnc!rti-sel!rcb
gayman@ARI-HQ1.ARPA.UUCP (01/12/87)
RE: Corrupt accounting file ... If you're not familiar with modifying files via PATCH or CONVERT there is an excellent article in the June 1986 VAX PROFSSIONAL, Vol. 8, No. 3. This is about recovering RMS Indexed files but will make for good reading assuming you will be using one or more of the tools discussed in it. Good Luck. Elizabeth Gayman (GAYMAN@ARI-HQ1.ARPA) ------
carl@CITHEX.CALTECH.EDU (Carl J Lydick) (01/14/87)
> If you're not familiar with modifying files via PATCH or CONVERT there > is an excellent article in the June 1986 VAX PROFSSIONAL, Vol. 8, No. 3. > This is about recovering RMS Indexed files but will make for good > reading assuming you will be using one or more of the tools discussed in > it. Of course, for those of us who don't want to learn how to use PATCH or CONVERT to do such things, there's always the option of diddling the record format to make RMS believe that the file has fixed-length, 512-byte records, then using DCL to make the repairs. I know it sounds crude, but I've successfully repaired "corrupted" directories (someone needed to mount a disk that had been used for awhile under VMS v4.x on a VAX running v3.6), as well as the index file (the home block, in particular) on one disk that had problems. Since VMS v4.x allows long symbols symbols (up to 1006 characters last I checked), and the WRITE/SYMBOL command allows you to write records at least 512 bytes long, I've found DCL quite sufficient for such repairs (if you don't have a utility to change the record format of a file, it's not difficult to write one in DCL, given that you have write access to the index file on the disk).