CHAA006%vaxb.rhbnc.ac.uk@CS.UCL.AC.UK (01/20/87)
>>> 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. That's very useful information; I for one hadn't realised that CONVERT was capable of repairing broken files. >>> 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.... But there I disagree - I had a similar problem whilst I was in Waterloo last year, and I wrote a program to repair the file. It's not difficult - you know the maximum record length, from the file header, so you need only search for possible <length> words whose value is less than or equal to that. Then search ahead, and if the <length>s chain properly, you're OK; if not, you probably picked something that wasn't a <length>, so try again. Writing the program is _much_ faster than repairing the file by hand. Unfortunately I left the program in Waterloo, so I can't mail it. If it becomes desperate, let me know, and I'll ask Waterloo to look for it (but I haven't much hope it's still there). ** Phil. Philip Taylor (Royal Holloway & Bedford New College; University of London; U.K) Bitnet/NetNorth/Earn: chaa006@vaxa.rhbnc.ac.uk (or) chaa006%rhbnc.vaxa@ac.uk (or) : chaa006@vaxb.rhbnc.ac.uk (or) chaa006%rhbnc.vaxb@ac.uk Arpa : chaa006%vaxa.rhbnc.ac.uk@ucl-cs.arpa (or) : chaa006%vaxb.rhbnc.ac.uk@ucl-cs.arpa