corrupt MAIL.MAI

[John Kittel]

VMS 6.2

I have a corrupt MAIL.MAI file. What are my options? ( just restore mail.mai from latest backup? ) What are likely / possible causes of this?


MAIL> dir
%MAIL-E-READERR, error reading DISK$USERS:[KITTEL.MAIL]MAIL.MAI
-RMS-F-CHK, bucket format check failed for VBN = 79093
%MAIL-E-NOMSGS, no messages



First Data Bucket VBN: 4
*** VBN 82342: Bucket check byte is out of phase.
*** VBN 82342: Record at offset %X'03F5' has invalid data record compression.
*** VBN 80353: Bucket check byte is out of phase.
*** VBN 79093: Bucket check byte is out of phase.
*** VBN 79093: Record at offset %X'01D7' has invalid data record compression.
*** VBN 79093: Pointer size of 3 is invalid in data record.
Unrecoverable error encountered in structure of file.


Thanks,
John

[John Kittel]

that second bit of output there in my original post was from ANA/RMS

- John

[Uwe Zessin]

Hello John,
I haven't looked into any details, but I would first check if a simple
$ CONVERT MAIL.MAI MAIL.NEW

is able to 'fix' any problems.

[Hein van den Heuvel · Accepted solution]

To begin with you should rename the corrupted file and allow VMSmail to create a new file for your new mail.

It is not too hard to merge the newest mail with the older mail later.


That older mail may have to come from backup, or from recovery efforts on the corrupted file.

You do want to restore a recent backup for several reason.
1- to use it!
2- to learn whether perhaps is also corrupted but you did not notice.
3- as an example how the buckets might have looked like.

I'm a little worried about the number of errors... yikes. Is the disk going bad? Multiply allocated block? ANAL/DISK?

A straight convert, as suggested might just work, because the corruption would be in the secondary key, the 'SIDR' arrea. When you do a plain "DIR" mail will use RMS $GET to start at secondary key = "MAIL" and stop (RAB$V_LIM) when the end of that secondary key value is reached.

You want to DUMP (with DUMP or ANA/RMS/INT) the reported bad buckets to just 'see' what they look like. All zeroes? a command file contents where structure should be?

Check my RMS_TOOLS directory on the freeware.
The ZAP tool might come in handy, and the RMS_TUNING powerpoint has a section on recovery if you have the drive to go that route.

Good luck!
Hein.



Y

[Hein van den Heuvel]

Oh.... 6.2 isn't that the version where I broke CONVERT/RECLAIM, which get's activated for a MAIL COMPRESS?

Did you compress/purge your mail file recently?
It's been a while, but there was a known problem in that space, around that time.
Find patches, upgrade VMS, or replace 'MAIL compress" with a plain CONVERT (faster, better).

And finally, if you do a plain convert,
judging by the range of buckets mentioned I'd go for a specialized FDL and not accept the standard 5-block-bucket design.
Go big... you'r worth it! :-).
Sample FDL below.


Hein.


IDENT " Hein "

FILE
FILE_MONITORING yes
GLOBAL_BUFFER_COUNT 42
ORGANIZATION indexed
PROTECTION (system:RW, owner:RW, group:, world:)
RECORD
FORMAT variable
SIZE 2048
AREA 0
ALLOCATION 48000
BEST_TRY_CONTIGUOUS yes
BUCKET_SIZE 24
EXTENSION 4800

AREA 1
ALLOCATION 120
BEST_TRY_CONTIGUOUS yes
BUCKET_SIZE 24
EXTENSION 120

AREA 2
ALLOCATION 1200
BEST_TRY_CONTIGUOUS yes
BUCKET_SIZE 24
EXTENSION 120

KEY 0
CHANGES no
DATA_KEY_COMPRESSION no
DATA_RECORD_COMPRESSION yes
DATA_AREA 0
DATA_FILL 100
DUPLICATES no
INDEX_AREA 1
INDEX_COMPRESSION no
INDEX_FILL 100
LEVEL1_INDEX_AREA 1
NAME ""
NULL_KEY no
PROLOG 3
SEG0_LENGTH 8
SEG0_POSITION 0
TYPE bin8

KEY 1
CHANGES yes
DATA_KEY_COMPRESSION yes
DATA_AREA 2
DATA_FILL 50
DUPLICATES yes
INDEX_AREA 2
INDEX_COMPRESSION yes
INDEX_FILL 100
LEVEL1_INDEX_AREA 2
NAME ""
NULL_KEY yes
NULL_VALUE 0
SEG0_LENGTH 39
SEG0_POSITION 9
TYPE string

[John Kittel]

Thanks Uwe and Hein.

The CONVERT failed.

The disk is going bad, 270 errors since this morning ( it was fine last night when checked by batch disk check job).

I am going to replace disk and restore from backup.

- John

[John Kittel]

We've been at 6.2 forever ( little chance of changing that now)... but I do compress the mail regularly ( not in the last month on this particular account), and it has not been a problem before.

- John

[Himanshu_3]

Hi John,

There is a freeware utility for recovering the corrupt mail file.You may get success using this,

http://www.tmk.com/ftp/vms-freeware/mathog/?C=S;O=A

the Name of the tool is mail_mai_tools.zip

Regards,
Himanshu

[Jan van den Ende]

John,

please visit

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=760811

Proost.

Have one on me.

Jan

[John Kittel]

Thanks again everyone.

Once I got my VMS hat back on properly, I got the disk replaced, and the mail.mai file restored from the full backup done a day previously, and all is now well ( with *that* system).

It would be nice to satisfy my curiosity and explore the file convert and repair tools and techniques that were suggested, but didn't want to take the time.

Onward to the next problem, 2 systems in a remote corner of the plant are unreachable this morning ( une VMS, one True-64)... probably a bad network device...

- John

[John Kittel]

That's all folks!