Posted by Bob A on October 18, 2010 at 05:23:32:
In Reply to: Re: single bit error on a disk.... has anybody seen it recently (i.e. within the posted by Jim Guerber on October 16, 2010 at 05:47:51:
Here's the scenario again:
1) the (NON IMAGE/non CSV) record was properly written by COMET on my PROD system (I viewed it with QTILITY/MAINT)
2) the entire file was copied over to my TEST system using WINDOWS EXPLORER over the network
3) a program died reading this same file at one record which had @22@ in the middle of a numeric field
4) I wrote a program to read every record and dump the key of any record that returns EXCP=46 (non-numeric data)
5) the record that caused the dump in 3 was the only "bad" record in the file
6) I re-checked the original file on PROD and there were no records causing EXCP=46
7) I deleted the bad record from the TEST system
8) I copied the "good" record from PROD to TEST as a one record file
9) I used QTILITY/COPY with "M"erge to put it back in the file
10) I re-checked the file.... the record was now corrupted after this one-record COPY/MERGE
I believe it's not a problem in writing, it's not a problem in FORMAT, it's not a problem in anything COMET related
the only thing I could think of to do now would be:
1) delete the record again
2) add a dummy record and hope it would fill in the "bad" portion of the disk
3) copy my 1 record file again and see if this "does the trick" (i.e. the record is not corrupted)
again... this kind of thing where 20h (0010 0000)b gets set to 22h (0010 0010)b, because bit 1 (numbering the bits as (7654 3210) from the right) will not CLEAR, is something I haven't seen since my Friden/Singer days in the early 1970s
Each file can be a maximum of 1MB in length Uploaded files will be purged from the server on a regular basis.