Recover2: Bad record overhead after block/record

[opa6x57]

Similar situation to: thread209-437606

File: index-filename - Bad record overhead after block/record block number/record label.

recover2 has encountered a data record with inconsistent overhead structures. Any records in the block subsequent to the indicated record are not written to the unload file. Processing continues with the next block.

I'm trying to run 'recover2' on some files in RM/COBOL.
The runtime version: RM/COBOL Runtime - Version 7.10.00 for Linux (Intel).

I get the error above on EVERY block in the file - the dump file contains zero records.

Some of the other files in the same database will 'recover2' just fine - all records are output.

I have no idea why this process would work with some files - and not with other files in the same project.

Any ideas? More importantly, anyway I can get past this and recover these files?

I have already completed a 'recover1' on the files - that didn't help. Also, it didn't report that it was unable to 'recover1' them - no errors were generated.

 

[k5tm]

One possibility is that the information about the file structure, which is stored in the first few blocks of the file, is corrupted. Without the correct information about the file structure, one could easily imagine a situation, such as a corrupted block size, where every block appears to be incorrectly formatted.

Run rmmapinx utility and see what you can determine from that. For example, does the information about the file structure meet what you expect from the file description? Perhaps you can post the rmmapinx output for one of the failing files.

Unfortunately, version 7.1 has been an unsupported version for many years; the current version is 12. Later versions of recover1 have a capability to overcome corrupted file structure information, but I am not sure that capability was in version 7.1.

Tom Morrison
Micro Focus

 

[opa6x57]

Unfortunately, I do not have available the rmmapinx utility. That program is not included in the backup I have available to me.

 

[mrregan]

How big is the file? Are you sure it is indexed? Do you have the record definition?

 

[opa6x57]

The two files (from the set) that are reacting this way - one is 1,224 KB and the other is 7,424 KB. The recover1 utility reports information on them as if they are, indeed, indexed.

I have examined the file header (using a hex editor) and ...
bytes 6-9 contain: "RMKF"
bytes 50-53 contain the binary representation of the reported number of records.

I do NOT have the record definition. Only the record length.