cobol, Record Length Inconsistency - Cause of corruption unknown

Record Length Inconsistency - Cause of corruption unknown

Author	Message
Mark Fletche #1 / 7	Record Length Inconsistency - Cause of corruption unknown We have reports of a problem which we find very difficult to understand. A MicroFocus COBOL/2 (V1.3) for SCO Unix compliled application has been running happily for years but we receive reports a random key length inconsistency errors at which point the file is unusable until the data element is re-sorted. The error is caused by the random insertion of records intended for other files. E.g. We have an indexed file which holds the menu structure. The file is static once installation has been completed, only a licence upgrade or addition of a new module will change this file. After months of operation without software change the customer reported a 3,9 error on the file (record length). On investigation we find that a record intended for a work file (also indexed) has been written in the middle of the data part of the menu file. To my knowledge you can't do this manually with COBOL. Therefore we're ruling out application coding errors. Currently we suspect a) the compiler was not intended for use on OpenServer machines - perhaps this is the reason, b) the RTS system has a flaw and is misbehaving, c) the hardware is faulty. c has been ruled out because it's happening on all kinds of kit. a & b are still on the suspect list. Has anyone else experienced similar? The compiler and RTS are now ancient retired products. Converting to a supported version of the compiler means code changes to make the product work with the new version. I think we're going to have to do this (and quite look forward to using some newer tools) but I don't want to commit customers to the RTS upgrade costs if there is an alternative solution. Any ideas? -- Regards Mark Sent via Deja.com http://www.--*.com/ Before you buy.
Sun, 07 Jul 2002 03:00:00 GMT

Russell Style #2 / 7	Record Length Inconsistency - Cause of corruption unknown How about makeing certain that all opens are input (No open IO), and flagging the file(s) read only. When upgrading, unflag. If it still happens, and the file is still read only, than what - operating system? Quote: > We have reports of a problem which we find very difficult to understand. > A MicroFocus COBOL/2 (V1.3) for SCO Unix compliled application has been > running happily for years but we receive reports a random key length > inconsistency errors at which point the file is unusable until the data > element is re-sorted. > The error is caused by the random insertion of records intended for > other files. E.g. We have an indexed file which holds the menu > structure. The file is static once installation has been completed, > only a licence upgrade or addition of a new module will change this > file. After months of operation without software change the customer > reported a 3,9 error on the file (record length). On investigation we > find that a record intended for a work file (also indexed) has been > written in the middle of the data part of the menu file. > To my knowledge you can't do this manually with COBOL. Therefore we're > ruling out application coding errors. > Currently we suspect a) the compiler was not intended for use on > OpenServer machines - perhaps this is the reason, b) the RTS system has > a flaw and is misbehaving, c) the hardware is faulty. > c has been ruled out because it's happening on all kinds of kit. a & b > are still on the suspect list. > Has anyone else experienced similar? The compiler and RTS are now > ancient retired products. Converting to a supported version of the > compiler means code changes to make the product work with the new > version. I think we're going to have to do this (and quite look forward > to using some newer tools) but I don't want to commit customers to the > RTS upgrade costs if there is an alternative solution. > Any ideas? > -- > Regards > Mark > Sent via Deja.com http://www.deja.com/ > Before you buy.
Sun, 07 Jul 2002 03:00:00 GMT

Rick Pric #3 / 7	Record Length Inconsistency - Cause of corruption unknown Are any files really large? Unix using the standard I/O can only handle files <= 2GB. Maybe your versions of MF Cobol thinks it can handle larger files. An old manual here said something like 'no limit on unix file sizes', which fooled us until we started getting problems on large files. I'm wondering if the MF Cobol thinks its updating an area in one file but that area belongs to another? However you mention a work file. I guess its unlikely for a work file to get really large. Rick Quote: > We have reports of a problem which we find very difficult to understand. > A MicroFocus COBOL/2 (V1.3) for SCO Unix compliled application has been > running happily for years but we receive reports a random key length > inconsistency errors at which point the file is unusable until the data > element is re-sorted. > The error is caused by the random insertion of records intended for > other files. E.g. We have an indexed file which holds the menu > structure. The file is static once installation has been completed, > only a licence upgrade or addition of a new module will change this > file. After months of operation without software change the customer > reported a 3,9 error on the file (record length). On investigation we > find that a record intended for a work file (also indexed) has been > written in the middle of the data part of the menu file. > To my knowledge you can't do this manually with COBOL. Therefore we're > ruling out application coding errors. > Currently we suspect a) the compiler was not intended for use on > OpenServer machines - perhaps this is the reason, b) the RTS system has > a flaw and is misbehaving, c) the hardware is faulty. > c has been ruled out because it's happening on all kinds of kit. a & b > are still on the suspect list. > Has anyone else experienced similar? The compiler and RTS are now > ancient retired products. Converting to a supported version of the > compiler means code changes to make the product work with the new > version. I think we're going to have to do this (and quite look forward > to using some newer tools) but I don't want to commit customers to the > RTS upgrade costs if there is an alternative solution. > Any ideas? > -- > Regards > Mark > Sent via Deja.com http://www.deja.com/ > Before you buy.
Mon, 08 Jul 2002 03:00:00 GMT

Douglas Mill #4 / 7	Record Length Inconsistency - Cause of corruption unknown Quote: >We have reports of a problem which we find very difficult to understand. >A MicroFocus COBOL/2 (V1.3) for SCO Unix compliled application has been >running happily for years but we receive reports a random key length >inconsistency errors at which point the file is unusable until the data >element is re-sorted. >The error is caused by the random insertion of records intended for >other files. E.g. We have an indexed file which holds the menu >structure. The file is static once installation has been completed, >only a licence upgrade or addition of a new module will change this >file. After months of operation without software change the customer >reported a 3,9 error on the file (record length). On investigation we >find that a record intended for a work file (also indexed) has been >written in the middle of the data part of the menu file. Possibly cross-linked files? Perhaps a corrupted disk directory erroneously associates the same physical area of disk with two or more files. -- dlmiller/at/netdirect/dot/net
Mon, 08 Jul 2002 03:00:00 GMT

Mark Fletche #5 / 7	Record Length Inconsistency - Cause of corruption unknown The error is picked up when the file is opened (of course) so there is no mileage in reworking the io of the corrupted file - I don't think I mentioned that the corrupted file appears to be random - The process that is corrupting the file is presumably happening somewhere else in the application and its not practical to make all those processes read only. The problem is certainly low level. (RTS, OS or HW) I'm hoping someone else has seen this and can throw us a lifeline. Rgds Sent via Deja.com http://www.deja.com/ Before you buy.
Mon, 08 Jul 2002 03:00:00 GMT

Mark Fletche #6 / 7	Record Length Inconsistency - Cause of corruption unknown The files aren't really that large. The whole database is rarely >1Gb. There could be something in your suggestion though. OpenServer introduced larger file size limits. Sent via Deja.com http://www.deja.com/ Before you buy.
Mon, 08 Jul 2002 03:00:00 GMT

Jerry #7 / 7	Record Length Inconsistency - Cause of corruption unknown We've seen (very rare) a bad disk controller card (or bad disk with built-in controller) slinging trash to random places on the disk.
Mon, 08 Jul 2002 03:00:00 GMT

Page 1 of 1

[ 7 post ]