j.lance wilkinson, 814865-1818 wrote:
> Yes, it had to happen to somebody who still has email saved from more than 20
> years ago still squirrelled away.
>
> A MAIL.MAI file in a separate directory (actually SYS$LOGIN:[.DLT_MAIL]DLT.MAI
> has become corrupted.
>
> $ show log dlt
> "DLT" = "LCS$STAFF:[LCS.JLW.DLT_MAIL]DLT.MAI" (LNM$PROCESS_TABLE)
> $ PMDF/MAIL
> ...
> EMAIL> set file dlt
> EMAIL> dir/folder
> Listing of folders in LCS$STAFF:[LCS.JLW.DLT_MAIL]DLT.MAI
> Press CTRL/C to cancel listing
> ACCESS ACROBAT
> ADMIN AUTHORIZATIONS
> BENEFITS BENEFITS.MPDP
> CAC CACERT.ORG
> CONFERENCES CURL
> DELL DELL.WIN2K
> %MAIL-E-READERR, error reading LCS$STAFF:[LCS.JLW.DLT_MAIL]DLT.MAI
> -RMS-F-CHK, bucket format check failed for VBN = 2922
> EMAIL>
>
> There were probably 75 folders in this mail file, and 98%+ of the messages
> saved in these folders exist as separate files of the MAIL$*.MAI variety (2147
> of them).
>
> Does anybody have, or can anybody recommend, a tool that could recover these
> MAIL$*.MAI files into a replacement for my corrupted DLT.MAI file? That is,
> create a NEW MAIL.MAI file in that [.DLT_MAIL] directory, with a single folder
> MAIL (or some other such name, I don't care), with the messages in that folder
> being the appropriate linking records for all the MAIL$*.MAI files in the
> directory?
>
> I could then slowly plow thru the reconstructed folder and move the
> messages to appropriate folders.
>
> Better yet, of course, is a way to recover the corrupted file. But I'm
> not familiar with the level of impact the bucket format check failure
> might have, so I don't hold a lot of hope for that.
>
> Time is of the essense as the powers-that-be plan to shut down VMS by the
> end of December. By then I need to migrate this all from VMS Mail Store
> under PMDF to PMDF MsgStore on Solaris.
>
> +----"Never Underestimate the bandwidth of a station wagon full of mag tapes"--+
> | J.Lance Wilkinson ("Lance") InterNet: Lance.Wilkinson@psu.edu
> | Systems Design Specialist - Lead AT&T: (814) 865-1818
> | Digital Library Technologies FAX: (814) 863-3560
> | 3 Paterno Library "I'd rather be dancing..."
> | Penn State University A host is a host from coast to coast,
> | University Park, PA 16802 And no one will talk to a host that's close
> | Unless the host that isn't close
> | EMail Professional since 1978 Is busy, hung or dead.
> +---------"He's dead, Jim. I'll get his tricorder. You take his wallet."-------+
> [apologies to DeForest Kelley, 1920-1999]
> home page
> junk mail declaration
> -- /"\
> \ / ASCII RIBBON CAMPAIGN
> X AGAINST HTML MAIL
> / \

[Something went wrong with an earlier attempt to post. Trying again.]


j.lance wilkinson, 814865-1818 wrote:
:
> EMAIL> dir/folder
> Listing of folders in LCS$STAFF:[LCS.JLW.DLT_MAIL]DLT.MAI
:
> DELL DELL.WIN2K
> %MAIL-E-READERR, error reading LCS$STAFF:[LCS.JLW.DLT_MAIL]DLT.MAI
> -RMS-F-CHK, bucket format check failed for VBN = 2922
> EMAIL>
:
> Does anybody have, or can anybody recommend, a tool that could recover these
> MAIL$*.MAI files into a replacement for my corrupted DLT.MAI file? That is,
:
> Better yet, of course, is a way to recover the corrupted file.


You really should focus on finding a backup, even an old one, and
trying to understand the extent of the corruption helping you judge
how easy it is restore the corrupted file. This block 2922 may be the
beginning of the end (all zeroes, or random data from an other file),
or it might ust have 1 bit 'fallen over'. Flip it back, or bypass the
bucket and you may be all set in 5 minutes. The (old) backup may help
showing what that VBN (and the next 4 making up the bucket) should
look like.

Heck, the corruption MIGHT be in the secondary key (folder) structure
in which case a simple CONVERT will bring the file back to live. Did
you try that?


In the RMS_TOOLS directory on the VMS freeware you'll find a
powerpoint with several slides giving you a starting point in
recoverring from the corruption.


Just for grins I hacked up a DCL script which will integrate MAIL$xxx
files into a fresh xxx.MAI file. See below. It works 'knowing' the
mail record layout, just using a DUMP/recor=count=3 from a known mail
file. You'll quickly recognize
- primary key = shuffled date
- folder name length byte
- secondary key = folder
- flag
- external file name
- Tag Length Value items for Sender, Subject, CC,...


Script below.
Enjoy.


$ purge
$ type findmail.com
$found_file = "FOUND.MAI"
$folder = "FOUND"
$sender = "Unknown"
$
$null = "1234"
$null[0,32] = 0
$nulls = null + null + null + null + null + null + null + null + null +

null
$record = f$extr(0,92+f$len(sender),nulls + nulls + nulls + nulls +
nulls)
$record[8*8,8] = f$len(folder)
$record[9,f$len(folder)] := "''folder'"
$record[48*8,16] = 8 ! External
$record[64*8,32] = %x00140007 ! Tag 7, Len 20, all zeroes
$record[90*8,16] = f$len(sender) ! Tag 0 = from, Len from data
$record[92,f$len(sender)] := "''sender'"
$
$open/write found tmp.tmp
$loop:
$file = f$parse(f$search("mail$*.mai"),,,"NAME")
$if file.eqs."" then goto done
$record[2*8,16] = %x'f$extrac(9,4,file)
$record[4*8,16] = %x'f$extrac(5,4,file)
$record[6*8,16] = %x'f$extrac(17,4,file)
$record[60*8,32] = %x'f$extrac(13,8,file)
$record[56*8,32] = %x'f$extrac(5,8,file)
$write found record
$goto loop
$done:
$close found
$conv/fdl=sys$input tmp.tmp 'found_file
FILE; ALLOC 300; ORG INDEXED
RECORD; SIZE 2048
KEY 0; SEG0_LEN 8; SEG0_POS 0; TYPE bin8
KEY 1; DUP yes; CHANGES yes; SEG0_LEN 39; SEG0_POS 9
$

In article , jlw@psulias.psu.edu
(j.lance wilkinson, (814) 865-1818) writes:

> Yes, it had to happen to somebody who still has email saved from more than 20
> years ago still squirrelled away.
>
> A MAIL.MAI file in a separate directory (actually SYS$LOGIN:[.DLT_MAIL]DLT.MAI
> has become corrupted.

As someone who relies on VMS MAIL for practically everything, I am very
interested in HOW the file became corrupted!