No MAIL.MAI file

[da1nonly1]

Hi,

I’m trying to use my VMS mail, I can get into the MAIL utility, but if I try to do there something I get this message:

%MAIL-E-OPENIN, error opening
-RMS-E-FNF, file not found
%MAIL-E-NOMSGS, no messages

and indeed this file doesnt exist.
How can I create it?

Thanks, Yaron.

[EdgarZamora_1]

well one quick way would be to send a message to yourself.

[Hoff]

MAIL creates the MAIL.MAI file under normal conditions, so this could easily be a case where you do not have a login directory, where you have an invalid SYS$SCRATCH: directory, or there is something else odd about your context.

If you do have a default login directory (if DIRECTORY SYS$LOGIN:/SECURITY shows some files, and shows that you own the files, and if DIRECTORY SYS$SCRATCH:/SECURITY works similarly), then invoke MAIL. Within MAIL, issue the SHOW MAIL command. This will show if MAIL has been configured with a mail subdirectory.

If you have a mail subdirectory set, then it either doesn't exist, or it is somehow corrupt. You can RENAME the existing subdirectory, or otherwise save the contents somewhere else. Then issue a SET NOMAIL and a SET MAIL [.MAIL] to re-create the subdirectory and the MAIL.MAI file.

If you have no mail subdirectory set but you do have a mail subdirectory around (use SET DEFAULT SYS$LOGIN:, DIRECTORY [*...]MAIL.MAI to look for this directory), you will have to re-establish the mail subdirecory by renaming the entirre contents of the mail subdirectory back to the SYS$LOGIN: directory (RENAME ddcu:[dir]MAI*.MAI SYS$LOGIN:), and then issuing the MAIL command SET MAIL [.MAIL], or whatever other subdirectory you want your MAIL stored in to re-enable the subdirectory. This SET MAIL command will rename the pieces back into the subdirectory. (There are other ways to do this...)

FWIW: most folks use [.MAIL] for the name of the MAIL subdirectory.

If this is a cluster and particularly one with multiple system disks or with core system database files relocated, one of the more common triggers for this MAIL (mis)behaviour is a failure to properly configure the dozen or so files that must be shared. This can be a problem, as it means you'll have to reset some set of MAIL subdirectories when you re-establish a common MAIL profile. See the system default template file SYLOGICALS.TEMPLATE on V7.2 and later for the list of the various core files that should usually be shared, and that should be synchronized across all cluster systems.

Stephen Hoffman
HoffmanLabs

[Hoff]

And if one of those replies don't solve this for you, please post the OpenVMS version and some system configuration details, and the particular command(s) and sequence(s) you've tried that generate these error messages. Also look for MAIL or UPDATE ECO kits, as these tend to be available for most OpenVMS releases.

[Hein van den Heuvel]

I don't think versions or patches are going to matter for this. This is too big a problem to be VMS dependend. SImply a user issue.


>> %MAIL-E-OPENIN, error opening

It did not say just that did it?
Did it not include a file specification where it tried to find it?
Was that a reasonable file specification?
Did that directory exist?
Do you have the rigth to read/write there?

The mail (sub)directory may have been changed using MAIL> SET MAIL ...
This updates SYS$SYSTEM:VMSMAIL_PROFILE.DATA

To see that, as you get into VMSMAIL, at the MAIL> prompt type in "SHOW ALL"
:
Your mail file directory is :...
:

For yucks you can also verify VMSMAIL_PROFILE the hard (easy?) way:

$ open/read/share=write x sys$system:vmsmail_profile.data
$ read/key=HEIN x y
$ show sym y
Y = "HEIN ..........Hein van den Heuvel..........[.VMSMAIL]"
$ close x


At any rate... just send yourself a mail and you should get a fresh MAIL.MAI file, providing the directy path and protection are valid.

Regards,
Hein.

[EdgarZamora_1]

Perhaps I should elucidate on my one line response.

SOURCE> delete mail.mai.*
%DELETE-W-SEARCHFAIL, error searching for SYS$USERS:[EZAMORA]MAIL.MAI;*
-RMS-E-FNF, file not found
SOURCE>
SOURCE> mail

MAIL>
%MAIL-E-OPENIN, error opening SYS$USERS:[EZAMORA]MAIL.MAI as input
-RMS-E-FNF, file not found
%MAIL-E-NOMSGS, no messages

MAIL> send
To: ezamora
Subj: bingo!
Enter your message below. Press CTRL/Z when complete, or CTRL/C to quit:
Exit
New mail on node SOURCE from SOURCE::EZAMORA (15:44:32)

MAIL>

#1 19-JAN-2007 15:44:32.57 NEWMAIL
From: SOURCE::EZAMORA
To: EZAMORA
CC:
Subj: bingo!


MAIL> Exit
SOURCE> dir mail.mai

Directory SYS$USERS:[EZAMORA]

MAIL.MAI;1

Total of 1 file.
SOURCE>

[da1nonly1]

Hi,

Thanks for the answers. It didnt help sending an E-mail to myself, the message I got was the it cant open my home directory directory file - YARON.DIR
This MAI file never existed since my user account was created. It seems the mail utility thinks that my home directory directory file is the mail file. The system administrator copied another MAIL.MAI file to my directory, is that dangerous? can I safely now try using my mail?

thanks, Yaron.

[Jan van den Ende · Accepted solution]

Yaron,

>>>
Thanks for the answers. It didnt help sending an E-mail to myself, the message I got was the it cant open my home directory directory file - YARON.DIR
<<<

This does ring a bell (from long time ago, but then again, might weel be still applicable).

What _IS_ your home directory?
Specifically, what is the value of the /DEVICE specified for you in the SYSUAF.
_IF_ it is what I suspect, than that device is specified as a Logical Name. If so, check that this Logical Name is valid in the System or Cluster table AND IS SPECIFIED in EXECUTIVE mode !!
Long ago I spent many hours to find that Supervisor mode LNMs are NOT working for MAIL.

PS I am not feeling happy about the idea of a copied MAIL.MAI file..

hth.

Proost.

Have one on me.

jpe

[Hein van den Heuvel]

>> It didnt help sending an E-mail to myself, the message I got was the it cant open my home directory directory file - YARON.DIR


So that DID help, it told you where to look!
But did it not say something more?
Like: "insufficient privilege or file protection violation"

So that's you problem. Address it.

>> This MAI file never existed since my user account was created.

That's ok.

>> It seems the mail utility thinks that my home directory directory file is the mail file.

No, it just needs to go through there.
[re-read my prior reply on VMSMAIL_PROFILE]

>> The system administrator copied another MAIL.MAI file to my directory, is that dangerous?

No just silly. It's tricky to get the ownership and protection correct. Let VMSmail do it!

>> can I safely now try using my mail?

What are you waiting for?!

Anyway, the best route to resolution is probably to simply pay very close attention to the exact error message being reported.

Potentially use the AUDIT subsystem to see what it being touched and why it fails.

Personally I would borrow CMKRNL for a while and use SET WATC FILE
For example (cut down a little):

$ set prot=(s,o,g,w) vmsmail.dir
$ dir/prot vmsmail.dir
:
VMSMAIL.DIR;1 (,,,)
$SET WATCH FILE/CLA=MAJOR
$ mail
Access SYSUAF.DAT;6 (15948,535,0)
Access VMSMAIL_PROFILE.DATA;5 (7784,3,0)
MAIL> send/noedit
To: _hein
Subj: test
Access HEIN.DIR;1
Create/Access MAIL_19D680_SEND.TMP;1 (25949,1456,0)
Control function (25949,1456,0)
Enter your message below. Press CTRL/Z when complete, or CTRL/C to quit:
test
Modify MAIL_19D680_SEND.TMP;1 (25949,1456,0)

Deaccess (25949,1456,0) Reads: 0, Writes: 2
Access MAIL_19D680_SEND.TMP;1
Access VMSMAIL.DIR;1 (17691,4646,0) Status: 00000024
Create-if Access (0,0,0) Status: 00000024
%MAIL-E-SENDERR, error sending to user HEIN
-MAIL-E-OPENOUT, error opening DRA3[HEIN.VMSMAIL]MAIL.MAI as output
-RMS-E-PRV, insufficient privilege or file protection violation
Deaccess (25949,1456,0)
MAIL>

Access HEIN.DIR;1 (10537,3300,0)
Deaccess (10537,3300,0)
Delete MAIL_19D680_SEND.TMP;1 (25949,1456,0)
Access HEIN.DIR;1 (10537,3300,0)
Deaccess (10537,3300,0)
Deaccess (15948,535,0)
Deaccess (7784,3,0)

Have fun!
Hein.

[da1nonly1]

Thanks again. When I tried sending a mail to myself and I got the message about the YARON.DIR he also told that there is a permission or a protection problem (I dont want to try it again now after he copied the MAIL.MAI to my directory). And yes, my home directory is YARON. In this machine Im not allowed to go into the AUTHORIZE utility. I can suggest the system manager to check or change there, but what?

Thanks.

[Volker Halle]

Yaron,

try to send mail to yourself again. It will fails again. Please provide the full error message. Then we can tell you what's wrong and you can take this information to your system manager, so he can fix the problem.

Volker.

[Hoff]

I'll here assume your UIC is [yaron], and that your home (SYS$LOGIN:) directory is ddcu:[000000]yaron.DIR.

DIRECTORY/SECURITY ddcu:[000000]yaron.DIR;1

SHOW PROCESS

Compare the ownership of this directory with your User Identifier; with your UIC.

A privileged user may/will have to be involved in fixing this.

In all likelyhood, the solution will be something like the following:

SET FILE/OWNER=yaron ddcu:[000000]yaron.DIR

The above re-sets the ownership of the yaron directory to yaron.

If I were guessing, I'd guess your home (login) directory is owned by somebody else. That's a pretty easy mistake for a system manager to make. It's also possible that the directory itself protected against your own access, but that's rather less common. If you are the owner, the fix for the protection is usually:

SET PROTECTION=O:RWE ddcu:[000000]yaron.DIR

And do get rid of the copied MAIL.MAI file. That's a bad solution here, and -- unless everything got copied -- you'll probably be missing the larger files from the original owner's mail directory. And who knows what MAIL is in the file. As Hein writes, let MAIL create its own file.

And FWIW, there is an example tool around for what can be involved when creating uernames, look in SYS$EXAMPLES:ADDUSER.COM.

Stephen Hoffman
HoffmanLabs

[da1nonly1]

What I did notice here (by doing DIR/FULL)is that this directory file of my user has an ACL, this ACL is NOT my user name. Perhaps this is the problem, I also noticed that all the files I create have this same ACL. This ACL gives me full powers ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL) but the IDENTIFIER= is not me or my user name or numbers. The files I create have ownership format [, ] and so is that directory file of mine. But the ACL is not IDENTIFIER= my user. So is this the problem? if yes how can it be safely corrected? Perhaps by:
$ SET SECURITY/CLASS=FILE/ACL/DELETE YARON.DIR
I dont need ACL on my directory.

Thank you all, Yaron.

[Jan van den Ende]

Yaron,

be sure to correct (or have corrected by the Sys mgr) the (directory-)file ownerships (to become YOUR username) _BEFORE_ you remove the ACLs, or you will NOT be able to touch them any more, not ebven to log in.

Proost.

Have one on me.

jpe

[EdgarZamora_1]

Sounds like your Authorization file entry is screwed up, too. Have the system manager do a UAF> SHOW YARON then check out the UIC part. After the numeric [xxx,yyy] field it should show an Identifier (should be something like ([YARON]). If you see someone else's name then the system amanger should fix the identifiers. If you see just the same numeric code all over again, then an Identifier should be created for you, like:

UAF> add/id yaron /value=uic=[xxx,yyy]

After your authorization file entry is fixed, you should have the system manager remove the bad ACLs from your files and the set the ownership of the files and the directory file to you. And chak that the owner field of the file protections are O:RWED.

Good luck.

[da1nonly1]

Jan,

You wrote:
"be sure to correct (or have corrected by the Sys mgr) the (directory-)file ownerships (to become YOUR username) _BEFORE_ you remove the ACLs, or you will NOT be able to touch them any more, not ebven to log in."

Well, the ownership is mine but shown in numbers. The ACL is not me.

Thanks.

[Jan van den Ende]

Yaron,

>>>
Well, the ownership is mine but shown in numbers. The ACL is not me.
<<<

The good thing about that, that it is NOT another name!

As Edgar wrote, have the Sys Mgr add the identifier. But really, that IS only cosmetics.

Something else is wrong as well.
Does your SYSUAF record REALLY specify a PHYSICAL device name, like DKA... or DSA...?
And is that REALLY not sneakily a logical name to camouflage an historic move to quick-and-dirty hide the fact that they did NOT use LNMs where they better had?
(find out by SHOW LOG Else - re-read my comment about teh EXEC mode definition!

Proost.

Have one on me.

jpe

[Doug Phillips]

Yaron,

There are things wrong that only someone with more privileges than you can fix. If you show/explain the problem to your system manager, he/she can probably fix it.

Don't try to tell the system manager what to change or how to fix your problem; just explain the problem, show him/her the error messages you're getting, and let the person do his/her job.

Please don't be offended, but you don't know enough about how things work to provide the solution or you wouldn't need to ask here. This is a simple problem to fix, but not at your level of privilege.

Doug