[Info-vax] need help with corrupt MAIL.MAI file

[Hein RMS van den Heuvel]

On Nov 24, 3:02 am, hel... at astro.multiCLOTHESvax.de (Phillip Helbig---
undress to reply) wrote:
> I've had essentially the same MAIL.MAI file since 1992.  It has moved
> across several physical disks, VAX and ALPHA machines and versions of
> VMS.  I've occasionally done a COMPRESS (the last time on 6-APR-2009) or
> PURGE/RECLAIM.

So the first opening line is BS. When you compress, you get a brand
spanking new mail file with a brand spanking new (odd expression that
is!) RMS indexed structure.
You messages are the same, but the file is not.



>    MAIL> DIR MAIL/START=99999
:
>    MAIL> DIR MAIL
>
> I got
>
>    %MAIL-E-READERR, error reading DISK$USER:[HELBIG.MAIL.MAIL]MAIL.MAI
>    -RMS-F-CHK, bucket format check failed for VBN = 27201

Those two commands both equally make RMS read the file by alternate
key 1,  the folder key. They would touch the very same buckets, as RMS
(unfortunately) does not have a function to just read the index. It
always touches the data buckets also.

So one time reading bucket 27201 it recevieved different results than
an onther timer.
That means either a hardware error,  or a shadow set out of sync.


> I then made a BACKUP of the file.  I haven't touched the backup copy
> (MAIL.BCK).  

Fine, but may have  potentially backed up somewhat random data.

What you should have done is DUMP/HEADER/BLOC=COUNT=0 to figure out
the mapping of VBN  27201 and the 4 blocks following (assuming a
default 5 block bucket size).
Then dump the LOGICAL blocks behind those LBN, FOR EACH SHADOW
MEMBER.
Of course you'd also want to DUMP/BLO=(COUN=5,STAR=27201), but

>>  I then RENAMEd the MAIL.MAI to MAI.SAV.
Good. Better than copy.
>> MAIL> SET FILE DISK$USER:[HELBIG.MAIL.MAIL]MAIL.SAV
>    MAIL> DIR MAIL/START=99999
> works as expected, as does
>    MAIL> LAST/EDIT

That's much like the first command working and the second did not.
It apparently has 2 sources, and you happen to pick the right one
again.

> What could have caused this problem?

Hardware, or shadowing, or a VBN cache going awry, or Multiple -
Allocated block style disk corruption?

RMS indexed files is one of the few (only) tools to perform a handful
of checks before using any data just read. As such they are often
'canaries in the coal mine' for underlying problems. Other files may
just silently return random data.

> Why did the problem go away after I RENAMEd the MAIL.MAI file?

It didn't. It only seemed that way.

> Should I try out MAIL.BCK (the BACKUP copy of the corrupt file) with
> some read-only commands, or should I not touch it at all for safety's
> sake until I have more information?

You can fart around with a copy as much as you like. Why go easy?
You have the backup right?

> could the problems have
> arisen by overstepping some (inofficial) boundaries such as the size of
> MAIL.MAI (it was 28985 blocks),

There are no boundaries. 30,000 blocks may seem big for an Emial files
to some, but it is not, and as an RMS indexed file to hold that
strucure it is very small.
I daily work with RMS indexed file multiple thousands of  times bigger
than that.

>>  I then RENAMEd the MAIL.SAV file back to MAIL.MAI.  It now works as expected, i.e. no errors.

Now _that_ is scary, about 1000 times more scary than starting to work
on the backup. You are now working on the very blocks that have been
know

> Possibly relevant information: The disk in question is a 3-member shadow
> set.
... a yeah!


A simple CONVERT or Email COMPRESS may be all that is needed IF the
VBN corruption is not in a data bucket.

If that fails, you can either try to assemble the file from records
read around the dad spot, or try to fix up the broken bucket(s). There
is likely more than 1 broken bucket.
If you want help with that, then you need to provide a DUMP for the
(whole) bucket and maybe a block before an after.

Good luck!
Hein.