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

[Phillip Helbig---undress to reply]

Please read through to the end before replying.

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. 

A long time ago, to decrease the number of MAIL$* files per directory, I 
used the FILE command to move messages to several new MAIL files in 
several directories (but on the same disk).

So far, so good.

Yesterday, I did

   MAIL> DIR MAIL/START=99999

and didn't see, as expected, some recent messages, but rather the last 
one was from 13-SEP-2009.  After

   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

and the same error with another command:

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

I then made a BACKUP of the file.  I haven't touched the backup copy 
(MAIL.BCK).  I then RENAMEd the MAIL.MAI to MAI.SAV.  I then sent a mail 
to myself so that a new MAIL.MAI file was created.  I haven't noticed 
any problems with this new mail file.

The disk in question shows no errors.

A few minutes ago, I did 

   MAIL> SET FILE DISK$USER:[HELBIG.MAIL.MAIL]MAIL.SAV

(i.e. I'm now using the RENAMEd MAIL.MAI which was having problems).  
Now,

   MAIL> DIR MAIL/START=99999

works as expected, as does

   MAIL> LAST/EDIT

Questions:

What could have caused this problem?

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

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?

I don't think I have done anything unsupported.  My configuration might 
not be optimal in terms of performance, but could the problems have 
arisen by overstepping some (inofficial) boundaries such as the size of 
MAIL.MAI (it was 28985 blocks), the number of files in the directory 
where it resides, the number of messages etc?

I emptied my MAIL.MAI file (created yesterday) by deleting or moving all 
the files in all of the folders.  I then RENAMEd the MAIL.SAV file back 
to MAIL.MAI.  It now works as expected, i.e. no errors.

Possibly relevant information: The disk in question is a 3-member shadow
set.  For a bit over a month, it has been reduced to a 2-member shadow
set because a node in the cluster hosting the 3rd member died (problem
with the power supply) and I haven't gotten around to replacing it. Both
the remaining members are on the same node.  I now see the following
entry in the operator log from that node: 

***************
%%%%%%%%%%%  OPCOM  23-NOV-2009 16:13:51.76  %%%%%%%%%%%
$22$DKA100: (DANEEL) has been removed from shadow set.

%%%%%%%%%%%  OPCOM  23-NOV-2009 16:13:51.83  %%%%%%%%%%%

In other words, a few hours after I noticed the problem, one of the
members of the shadow set where the MAIL.MAI file resides was removed
(so that I am now down to one member).  Obviously, my first priority now
will be getting this shadow set back to three members.  (Fortunately, I
have enough identical disks so that I can replace some should they be
physically defective.  They are SX910800N.  I started out with a pair of
these (used when I got them) back in 2002 and for several years they ran
continuously with no problem.  Back in the spring one disk then failed
(whether permanently damaged I don't know) and I replaced it with a new
(to me) disk and shortly after added a third disk to the shadow set. 
This was a few months ago.  This ran without problems (as far as I know)
until the node hosting one member got the problem with the power supply.
That was more than a month ago, so I've had the two-node shadow set
(both members are those which I put in back in the spring) since then 
(until yesterday).

I'm sending this message now and will then investigate more.  Any help 
is appreciated.