HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Hours:
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Error when using Mail

 
HarrinG
Advisor

Error when using Mail

Whenever I attempt to send OpenVMS mail as a user other than System I run into the following error:

%MAIL-E-OPENOUT, error opening SYS$SYSROOT:[USERNAME]MAIL_3596_SEND.TMP; as output
-RMS-E-DNF, directory not found
-SYSTEM-W-NOSUCHFILE, no such file
%MAIL-E-SENDABORT, no message sent

However when I do a "SHOW TRANSLATION SYS$LOGIN" the appropriate directory shows up. As I indicated this only occurs with users other than the System users. I am running OpenVMS 7.3-2 on an Alpha. The File protections on the home directories are System:RWE, Owner:RWE, Group:RE, World:RE with no ACL or other issues what could affect access.

What could be the problem?

Thanks
2 REPLIES
melvyn burnard
Honored Contributor

Re: Error when using Mail

posted in wrong forum, moved to more appropriate forum
My house is the bank's, my money the wife's, But my opinions belong to me, not HP!
Hoff
Honored Contributor

Re: Error when using Mail

MAIL and various other applications tend to use SYS$SCRATCH for scratch (temporary) files.

Issue the command:

SHOW LOGICAL SYS$SCRATCH

And follow that directory for existence and access.

By default, the SYS$SCRATCH translation is usually the same as the SYS$LOGIN value, or the translation is usually created on a per-user basis during SYLOGIN.COM or LOGIN.COM processing.

The value of SYS$LOGIN (and of SYS$SCRATCH) is derived from the SYSUAF file and the authorization database. Use AUTHORIZE to determine what the device and directory are.

In this case, it looks like the device might well be SYS$SYSROOT, and that's not usually where the users are configured. Most folks use DISK$volumelabel or SYS$SYSDEVICE or ddcu: physical spec as the device, and the same value as the username as the directory name specified. (It's best to use logical names and not physical specifications, where that's feasible.)

If the AUTHORIZE command COPY was used to clone the SYSTEM username, and the COPY didn't see the device name and (hopefully) also the UIC and other attributes reset, a situation such as what is reported here can potentially result. (You'll end up with a device spec that's a concealed rooted device spec, and most folks tend to create top-level directories for users.)

Fix:

UAF> MOD username/DEVICE=devicespec

Where the devicespec is a logical name or the physical device specification for the device holding the user's login directory.

--

If this current environment is a straight interactive login, the ignore the following paragraph: There can be second-level issues around detached processes and the authorization file; if you've created a detached process and are now attempting to execute various commands such as MAIL. I've seen folks manually assemble SYS$LOGIN and SYS$SCRATCH in these detached environments.

--

Some potentially-related topic areas, particularly for odd situations or if you want to manage your own scratch area, or (with resource identifiers) your own shared area:

http://h71000.www7.hp.com/wizard/wiz_4821.html
http://h71000.www7.hp.com/wizard/wiz_3681.html
http://h71000.www7.hp.com/wizard/wiz_3105.html

--

Stephen Hoffman
HoffmanLabs