TCPIP$SMTP issue - "bug" or intended behaviour ?

[Willem Grooters]

My mistake - minor glitch in the system startup - but the SMTP service won't work!

Regular users on my system have their home directory on USER:[] where USER is defined as '$FRNLNM("USERDISK")'[USER.] (trans=(c,t), of course).
However, this disk wasn't mounted yet so this logical USER was just "[USER.]".

When an user now logs in, his login will succeed with errors and his environment isn't setup well. Software referring to this location doesn't work well (that's how I found it) - nor will the SMTP server be able to deliver mail:

%MAIL-E-SENDERR, error sending to user WILLEM
-MAIL-E-OPENOUT, error opening USER:[WILLEM]MAIL.MAI as output
-SYSTEM-F-IVDEVNAM, invalid device name
Failed to deliver local mail to
%MAIL-E-SENDERR, error sending to user !AS

Defining this logical properly will solve any related issue, except for TCPIP$SMTP. It will keep signalling the same error even if the definition is changed. It needs a restart before the definition is recognized.

Of course, in a well defined system this shouldn't happen, but I think that any chnage in a (system) logical should be recognized by software without a restart. Other (VMS-based) software does - why doesn't TCPIP$SMTP?

(VMS 8.2, TCPIP 5.5, patched up to August 2006)

[Wim Van den Wyngaert]

Willem,

This seems a normal performance optimzation for me. You too built a logical based upon userdisk without rebuilding it on every usage.

Wim

[Jan van den Ende]

Willem,

a not so uncommon situation, which CAN be easily prevented.

Early in the boot process (ie, in or from SYLOGICALS.COM) DEFINE/EXEC the logicals for your disks.
In the system table, or even better, in the cluster-wide system table.

Now, the _LNM_ already exists, whether or not the disk is mounted, so any derived function also works as intended.
Extra bonus: Now you can also MOUNT your disks by specifying the LNM.
This we you can (and we _DO_, even religuously) concentrate ALL references to physica; device names into ONE single file.
Makes for much flexibility of the configuration!.

hth

Proost.

Have one on me.

jpe

[Willem Grooters]

I _KNOW_ I made an error, so it's obvious that the service could not access the intended location. Obviously, $ DIR USER:[000000] gave exactly the same error. Nothing wrong with that.
After:
$ DEFINE/SYSTEM/TRANS=(C,T) USER :[.]
the result of $ DIR USER:[000000] was exacvtly as I expected (and I did NOT restart my session) but any mail send to me on that system ended in EXACTLY the same error. As I found out, BTW, the same after restarting the service. It was that I defined this logical with /EXEC that is actually got around the problem.
Other programs that I usually use (like WASD) have no trouble either: I had the same problem with PHP logicals missing, but after defining them there was no more trouble - without restrating (warm or cold) of the webserver.
And THAT's the behaviour I would expect from a VMS program.

[Jan van den Ende]

Willem,

seems I mis-understood your problem.

I did not read from it that the ONLY problem was sending MAIL.
OTOH, I SHOULD have been triggered. I have known for 2 decades that MAIL is one of those programs that REQUIRE any device logicals from SYSUAF to be /EXEC.
Maybe Volker or John know exactly why and when this requirement arises, and step in to explain? I, for one, am curious.

fwiw,

Proost.

Have one on me.

jpe

[Willem Grooters]

Jan,
Due to the fact that SYS$LOGIN (USER:[WILLEM]) wasn't properly defined, I obviously had trouble with ALL access to SYS$LOGIN:MAIL.MAI:
* The TCPIP$SMTP mail service - for receiving mail - failed
* Accessing my (VMS)Mail folders via a web-interface failed.
* Obviously, I would have had trouble sending mail if I would have tried ;-)

As steted elsewhere, specifying /EXEC makes a difference. The point is that the mail server needs to be restarted after that has been proerly defined. I can live with a rewquirement of a restart when logicals and files that are constantly used by the application are changed (translated once as a performance gain), but I don't see why that holds for other logicals as well. In my view, any user's MAIL.MAI file is 'just a file' and a change of a logical in the spec of this file should be transparent to the program - and NOT require a restart.

[Willem Grooters]

Accepted to be an optimization (read once) and security (DEF /EXEC), requiring a restart on change