-RMS-F-CHK, bucket format check failed for VBN

[yaron1]

Hi,

I’m getting an error message on an indexed file:
-RMS-F-CHK, bucket format check failed for VBN = 1827505
This started when there was a disk problem with the volume this indexed file sits on. A convert didnt help.
The file is now over 4 million blocks and was not converted for years (fragmentation?). The platform is VMS 5.5 on a VAX cluster.
What can be done to restore the file or it’s data? If I do dump/records=(start:1,count:100) I see that its in record 11. Is that possible to read records until the bad record and from after the bad record? If that is possible then I can write them to a different file.

thanks for answers.

[Robert Gezelter]

yaron1,

My first recommendation is to immediately make one or more backup copies of the file using OpenVMS BACKUP, which will ignore the internal structure of the RMS indices. One of the most common errors in situations of this type is to fail to make adequate provisions for safe backups before working with the file.

It is hard to say what you will find when you investigate a case of disk corruption. Until you have processed the entire file, there is no accurate way to assess the overall damage.

One shortcut that sometimes works is accessing the file by a secondary index. If the problem is in the primary index, this has the effect of bypassing the damage.

If unloading the file by one index or another does not help, I would consider retaining some outside assistance [Disclaimer: My firm does provide services in this area on a consulting basis, as do Hoff, Hein, and others).

- Bob Gezelter, http://www.rlgsc.com

[Hein van den Heuvel · Accepted solution]

The easiest solution is often at application level as you suggest yourself. Find a suitable program in your applicaiton which can read the broken file by primary key. Datatrieve would be great. Start reading at the begin, like you did. On error, search for the next valid key and read some more. Glue everything together when done.
The 'next' valid key search might be
- a binary search algortime,
- a brute force increment untill it works again.
- or might use a restored older version of the file for sample keys,
- or might be obtained from an application audit or log file.
- Or from a parallel file with similar data.
- or might use keys obtained from the index structures using ANAL/RMS/INT.

Bob>> My first recommendation is to immediately make one or more backup copies of the file using OpenVMS BACKUP

And my first recommendation would be to find a backup, and restore it.

Both advises are valid.

You might not want or need to use all the restored data, but it is LIKELY, but not certainly, going to have a reasonable copy of the broken data areas.

Now get my presenation from the freeware:
http://h71000.www7.hp.com/freeware/freeware60/rms_tools/rms_tuning.ppt
Carefully read slide 40 and onwards.
Done? Now read them again.

The most fruitful advise is often to patch around a broken zone. Good old 'patch' will do fine. But I would (of course) suggest my ZAP tool: http://h71000.www7.hp.com/freeware/freeware60/rms_tools/zap.exe

You may also want to try:
http://h71000.www7.hp.com/freeware/freeware60/rms_tools/bonus/indexed_file_patch.bas

Once you patched (The bucket NEXT pointers) around the broken area, it is time to CONVERT the file.

Now back-fill the missing records from teh restored older copy. DATATRIEVE is the most suitable tool to help do this.

If you think the restored backup has the 'right' blocks, or at least better blocks for the corrupted zone, then you can copy those blocks using the attached tool.

If this file is 'serious' and you'd like (for fee) further help with restoring data, then be sure to contact me!

Hope this helps some,
Hein van den Heuvel (at gmail dot com)
HvdH Performance Consulting

[Robert Gezelter]

Hein,

I would concur for preserving any existing backups containing the file, one never knows if the damage was one incident, or a progressive series of incidents.

However, I would advise a VERY cautionary note: DO NOT restore over the existing, damaged file. I have seen situations where the backups were in a worse state, and restoring the file just made things worse (and lost data).

The general recommendation: If you do choose to restore backups, restore them to an alternate location. DO NOT, IN ANY CASE, destroy the current, albeit damaged file.

- Bob Gezelter, http://www.rlgsc.com

[Hein van den Heuvel]

Thanks for pointing that out Bob.
I should have made that point very explicit: restore to different location.
It should be obvious from reading the rest of my reply, but one can not be careful enoug in these matters.

Cheers,
Hein.

[Hein van den Heuvel]

Yaron.

Please update us on the outcome.
(at least send me a quick Email pretty please?)

Extracted remaining records and moved on?
Patched it? Simple restore?

btw... I have put a /START on the wish list for CONVERT to facilitate these kind of recoveries as was as monthly/yearly file clean ups.

Hein.

[Joseph Huber_1]

Although I have no solution - I notice the file size of >2GB on a VMS 5.5 system: wasn't there a 2GB file size limit, and the corruption is due to reaching that limit ?

[yaron1]

Hi,

Thank you all for the great answers.
I will go on the restore from tapes option most probably and let you know how it went. I prefer the file in the state of before the disaster for data consistency and run the job again after a convert.

For Joseph,
I have an indexed file of over 7 million blocks on a different VAX OpenVMS version 7.1.

Thanks,

[Hein van den Heuvel]

Joseph wrote> Although I have no solution - I notice the file size of >2GB on a VMS 5.5 system: wasn't there a 2GB file size limit, and the corruption is due to reaching that

Any 2GB limit tends to arise from using BYTE offsets. On VMS only the C-RTL did.

RMS itself never did. Its bytes are addressed with 32 bit VBN numbers and 512 byte offsets within those. This allows for 1 or 2 TB (Tera byte) files depending on whether you trust all is well with the sign bit usage.

There was a 5.5 limitation with the VMB.EXE having to be located at an LBN under 1GB, the system failing to boot otherwise.

fwiw... I work with several Indexed files larger than 100 GB. Of course you want to treat those files with respect, simple actions take lots of time. As an example, a 222M block file with 63M records and 3 keys, with careful planning, took 70 minutes for a convert.

fwiw,
Hein.

[Hoff]

>>>There was a 5.5 limitation with the VMB.EXE having to be located at an LBN under 1GB, the system failing to boot otherwise<<<

Eh?

There was a console addressing limit on some older VAX consoles; the VAXstation 3100 series and the oldest of the MicroVAX 3100 series being salient examples. This is independent of OpenVMS VAX version.

There was a newer wrinkle contributed by BACKUP, where it wasn't properly detecting a bootable disk when VMB.EXE was out past 24 bits in its LBN; VMB out past 8.58 GB. That case can be fixed with WRITEBOOT, or a BACKUP ECO. This one surfaced long after V5.5, given that disks with 24 bits of blocks (and enough other "stuff" to get VMB out past that) weren't usually seen on VAX.

There was an 8.38 GB limit pre V6.0, and also an 8.58 GB limit around DKDRIVER.

LBN addressing below 1 GB and V5.5 and VMB is not a particular combination I immediately recall, though.