RM Corrupt Index 1

[hammy]

Hi,

I have a RM Cobol file that appears to have a corrupt index. The records on the table when read appear as :
AAA WEA
AAA WEB
BBB REJ
AAA WEC
AAA WHD

When I recover the file the records are indexed as I would expect, e.g.

AAA WEA
AAA WEB
AAA WEC
AAA WHD
BBB REJ

Any idea why I would not be getting an error on this file, even though I know the index or something must be corrupt?

Cheers,

Hammy.

 

[fredericofonseca]

What to you mean "appears to have a corrupt index".

Do you mean that you do a start/read next on that key and the records are out of order?

or something else?


Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

 

[hammy]

Yep,

Basically the output above is produced from an convert to sequential file for the indexed file, starting at the beginning and running through the file. In reality the file has 4500 records. It prints in alphabetic order and then in the middle of the AAA set of records the BBB appears.

Running a recover2.cob and then a convert from Binary to Index resolves.

The problem is that no error is produced, other than I noticed it.

 

[fredericofonseca]

What is the code used to read the indexed file in the first place!
Select + FD + start and/or read instructions please

Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

 

[hammy]

Hi Fredrico,
Select
SELECT IT-FILE ASSIGN TO RANDOM, BR-IT-FILENAME
ORGANIZATION IS INDEXED ;
ACCESS MODE IS DYNAMIC;
RECORD KEY IS IT-CODE1;
ALTERNATE RECORD KEY IS IT-KEY1 WITH DUPLICATES;
ALTERNATE RECORD KEY IS IT-KEY2 WITH DUPLICATES;
ALTERNATE RECORD KEY IS IT-KEY3 WITH DUPLICATES;
ALTERNATE RECORD KEY IS IT-KEY4 WITH DUPLICATES;
FILE STATUS IS WFS.

FD (Key part anyways)

FD IT-FILE.
01 IT-RECORD.
05 IT-KEY1.
07 IT-INSCO PIC X(4).
07 IT-CODE1 PIC X(14).
07 IT-CODE2 REDEFINES IT-CODE1.
09 IT-POL-CODE PIC X(10).
09 IT-POL-SEQ PIC X(4).
07 IT-CODE3 REDEFINES IT-CODE1.
09 IT-POL-CODE2 PIC X(9).
09 IT-POL-SEQ2 PIC X.
09 FILLER PIC X(4).
05 IT-KEY2.
07 IT-INSCO2 PIC X(4).
07 IT-DATE PIC 9(8).
05 IT-KEY3.
07 IT-INSCO3 PIC X(4).
07 IT-NUMBER PIC X(20).
05 IT-KEY4.
07 IT-INSCO4 PIC X(4).
07 IT-INVOICE PIC 9(5).
05 IT-REFERENCE PIC X(10).
05 IT-TYPE PIC X(1).
.....rest of file

Code to Start/Read is simply :
MOVE LOW-VALUES TO IT-KEY.
START WIT KEY NOT < IT-KEY INVALID KEY
GO TO AA090.
AA020.
READ WIT NEXT AT END
GO TO AA090.
Rest of code just dumps out field by field to sequential file and then goes back to AA020 for next record.

Any help is appreciated,

Hammy.

 

[fredericofonseca]

The start/read you posted does not match the Select.
Also please mention what are the fields that contain the data you have shown on your first post.

Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

 

[hammy]

Oops sorry,

The FD and select where taken from files used to build catalogues for relativity with meaningful names, the start etc. was from existing cobol source, should read :

MOVE LOW-VALUES TO IT-KEY1.
START IT-FILE KEY NOT < IT-KEY1 INVALID KEY
GO TO AA090.
AA020.
READ IT-FILE NEXT AT END
GO TO AA090.

Above again was just an example - tried to minimze what I wrote - Actual Data from IT-KEY1 is

AXA WERI01001Z0009
AXA WERI01001Z0010
QUI REJO17002Z0011
AXA WERI01001Z0012
AXA WHCO02001Z0001

Thanks again

 

[baruch]

Hi Hammy
I am working with RM for 25 year, and didn't met such an event.

For the few times that the file was corrupt, an error was output.

Maybe, 1 a declarativ ststement ignore such corrupt file.
2. you made start with the main key (IT-CODE1) and
disply for checking IT-KEY1.
Regards
Barry

 

[hammy]

Cheers Barry,

Same here, first time I have ever seen this happen, usually I would get an error 98. That is why I am trying to see if there is a way to track this "error" down.

Once I recover the file, the details list as I would expect from the program.

 

[ShadowFox333]

Why don't you change the access mode to sequential and just read at end.

Bob

 

[hammy]

Reading the file is not the problem. The problem is that I have found a corrupt file on a customers site that is not being reported by cobol as corrupt.

I was hoping that someone would have seen this before and known of a way to identify easily. Then at least I could have done something to check important tables on site.

 

[k5tm]

Hammy,

Do you still have a copy of the 'corrupt' file prior to the recovery? If so, perhaps you can send it along to our tech support, or me, and we can investigate. My guess that will be far more productive and definitive than for us to speculate here, with incomplete information.

Tom Morrison

http://www.liant.com

 

[webrabbit]

I have seen this same problem several times with Micro Focus COBOL at customer sites. The index has been corrupted, but the file manager system does not notice that fact. It's the same symptoms: A seqential read and a random read do not get the same record(s). There is no error message associated with it.

 

[k5tm]

Hammy sent along the bad file as I suggested, and we (well, actually, mostly Rob, xyzzy) have it under the microscope. Here are some findings so far:[ul][li]the file was created by an older version (by several years) of the file system[/li][li]there is considerable evidence that the 'system' suffered a power outage (or, if this was a PC network, someone turned off a PC) during a delete operation[/li][li]Hammy would have received an immediate 'possible corrupt file indicator' immediately if he had opened the file in a nonshared mode[/li][li]Hammy would have received a 'corrupt file indicator' if he had been reading by three of the alternate keys. (The fact that he didn't on the prime key was a freak accident.)[/li][/ul]

If our analysis is correct, Hammy would have been well served by our most recent file system improvements, available for quite some time. This version allows an atomic I/O capability - not an explosive, but rather the ability to know that either the operation worked or it didn't (unsplit by any power outage -- thereby atomic). The type of failure evidenced in the file would not happen.

We are awaiting information about Hammy's RM/COBOL version so we can best advise him. However, recover1 will fix the file, as Hammy has already discovered.

Tom Morrison

http://www.liant.com

 

[hammy]

Thanks Tom,

At least this answers my question on how to replicate. I can write a program that will run down the file on each of the indexes and is I should get an error.

Very much appreciated.

Hammy.