- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- -RMS-F-CHK, bucket format check failed for VBN
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-25-2007 11:54 PM
10-25-2007 11:54 PM
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.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-26-2007 12:26 AM
10-26-2007 12:26 AM
Re: -RMS-F-CHK, bucket format check failed for VBN
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-26-2007 01:49 AM
10-26-2007 01:49 AM
SolutionThe '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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-26-2007 02:05 AM
10-26-2007 02:05 AM
Re: -RMS-F-CHK, bucket format check failed for VBN
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-26-2007 02:18 AM
10-26-2007 02:18 AM
Re: -RMS-F-CHK, bucket format check failed for VBN
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-27-2007 04:02 AM
10-27-2007 04:02 AM
Re: -RMS-F-CHK, bucket format check failed for VBN
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-27-2007 04:24 AM
10-27-2007 04:24 AM
Re: -RMS-F-CHK, bucket format check failed for VBN
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 ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-27-2007 05:39 AM
10-27-2007 05:39 AM
Re: -RMS-F-CHK, bucket format check failed for VBN
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,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-27-2007 08:01 AM
10-27-2007 08:01 AM
Re: -RMS-F-CHK, bucket format check failed for VBN
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-27-2007 09:36 AM
10-27-2007 09:36 AM
Re: -RMS-F-CHK, bucket format check failed for VBN
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.