- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Error when using Mail
Operating System - OpenVMS
1753726
Members
4727
Online
108799
Solutions
Forums
Categories
Company
Local Language
юдл
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
юдл
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-31-2007 08:14 AM
тАО01-31-2007 08:14 AM
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
%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 2
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-31-2007 09:03 AM
тАО01-31-2007 09:03 AM
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-31-2007 10:03 AM
тАО01-31-2007 10:03 AM
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
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
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP