Record Length Inconsistency - Cause of corruption unknown 
Author Message
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 
 [ 7 post ] 

 Relevant Pages 

1. Getting true length of a variable length record - IBM Mainframe

2. Finding Variable-Length Record Length

3. Tk_MeasureChars inconsistency causes text display problems

4. Convert comma-delimited records to fixed length records

5. Win95/WinNT buffering problems (causing Topspeed file corruption?)

6. What causes Topspeed file corruption?

7. memo to string causing corruption - why?

8. DataSocket example using ftp: causes file corruption ?

9. HELP: VRML HUD causing OpenGL Screen Corruption

10. OSDVL: Unknown cause of crash

11. 'proc unknown' causes package error

12. OLEGEN and a string of unknown length

 

 
Powered by phpBB® Forum Software