SYS$PUTMSG logical name

[Jess Goodman]

A weird thing happened to my interactive process. It stopped displaying any VMS messages.

SYS$OUTPUT and SYS$ERROR were defined normally, and F$ENVIRONMENT("MESSAGE") showed everything enabled.

I dimly remembered this happening once before and eventually having to log out and back in. This time I decided to look a little deeper. I found this logical name:

$ SHOW LOGICAL/FULL SYS$PUTMSG
"SYS$PUTMSG" [user] = ".........." (LNM$SYSTEM_TABLE)

The name translated to 10 binary bytes:
0000 00000000 0000011B

$ DEASSIGN/SYSTEM/USER SYS$PUTMSG
fixed my process. My questions are:

1) This logical is an apparent undocumented VMS "feature". I found no reference to it in the usual places, but I did find one old reference to it that pointed to VMS source module TRACE.MAR. Can someone who has access to source listings check this out and let us know how this logical is used and what are its meaningful values?

2) The fact that the logical name was left defined that way for my process is an apparent VMS bug (V7.3-2). I have not been able to reproduce it, but just before I noticed the problem I was testing a program that used SYS$CRELNM to define various /EXECUTIVE logicals (not SYS$PUTMSG of course). I turned SYSNAM privilege on and off for my process to check how the program would handle it. Without SYSNAM, calling $CRELNM in user-mode always creates /USER mode logical names with no error. So could this be related to the bug?

[Jess Goodman]

Oh, I just remembered. The SYS$PUTMSG logical was (as shown) defined in the SYSTEM table and so it affected not just my process, but all processes on the system - new and old. So logging out and back in would not have helped this time, and I was close to having to reboot the system to fix the issue. So this was pretty serious VMS bug.

[Hoff]

From memory...

I tend to use lib$set_logical in preference to sys$crelnm for most cases, and it is most definitely necessary to have the correct privileges enabled when you're working with logical names; the requested access modes can get silently demoted even within the use of the DCL commands.

The behavior of sys$putmsg in the area of Process Permanent Files (PPFs) is briefly discussed in an obscure corner of the OpenVMS manuals IIRC, but the topic and the specifics are discussed in more detail in the IDSM. That prefix is the I/O channel.

That user-mode logical names in shared tables don't get rundown as you might expect has been longstanding behavior.

Whether or not this is considered a bug or a feature or whether or not (if it's a bug) it'll get fixed is a question for the OpenVMS engineering folks to answer.

[Jess Goodman]

Well LIB$SET_LOGICAL can't handle /EXEC mode, but the program I was testing is, I'm sure, unrelated to the issue. I mentioned it only to explain why I was toggling SYSNAM on and off, which might have been the trigger for this bug.

And yes, since this SYS$PUTMSG logical was created by VMS in the system table, and left there to affect all processes, it was definitely a bug.

[John Gillings]

Jess

>This logical is an apparent undocumented VMS
>"feature".

It's not really possible to document the specific behaviours of all potential stray logical names. Beware of creating any logical name containing "$", as it's reserved to OpenVMS use. There doesn't need to be an explicit reference to a logical name, as file name processing can implicitly translate a logical name. I'm not sure if your experience with SYS$PUTMSG falls into this category.

But the issue is worse than that. You should also beware of creating any logical name with the same name as any image in SYS$SYSTEM or SYS$SHARE. The classic examples are "DEBUG" and "TRACE". These are fairly obvious logical names to use for application signalling, but if defined, they break debugging and traceback handling.

I've always considered logical name definition silently dropping the mode in the absence of SYSNAM to be a bug. I've had a few goes at getting it fixed, approaching from a few different angles. The answer is always "been that way forever, too late to change it now". Which I consider a cop out, and another example of OpenVMS compatibility fanaticism taken to illogical extremes. At the very least, it should be possible to leave the outcome the same, but issue a warning, (or even informational!) status & message.

[John Gillings]

>That user-mode logical names in shared
>tables don't get rundown as you might expect
>has been longstanding behavior.

And, if you think about it, the only possible choice. Apart from the performance concern of searching all visible logical name tables for user mode logical names at image run down, there's the issue for shared tables. Should a user mode logical name be deleted when ANY process that can see the table does an image rundown?

That would make user mode logical names unusable in shared tables, as their lifetime would be unpredictable. (though, arguably, the purpose of user mode logical name in the system table is somewhat questionable!)

[Jess Goodman]

John, you said:

"It's not really possible to document the specific behaviours of all potential stray logical names."

That's a perfect description - it was a "stray" logical name that was left around when it should have been deleted by whatever created it.

"Beware of creating any logical name containing "$", as it's reserved to OpenVMS use."

Duh! But, I DIDN'T CREATE THE LOGICAL NAME! VMS did! That's the point I would like to address.

"There doesn't need to be an explicit reference to a logical name, as file name processing can implicitly translate a logical name. I'm not sure if your experience with SYS$PUTMSG falls into this category."

How could it?? SYS$PUTMSG is not the name of any file - it is the name of a VMS system service.

I'm sorry that in my OP I brought up the well-known issue of "logical name definition silently dropping the mode in the absence of SYSNAM". I didn't want to start another discussion about that.

I mentioned it because here is my best guess about how this dangerous SYS$PUTMSG logical name got left in the SYSTEM table. Whatever part of VMS defined it (trace back handler?) thought SYSNAM was enabled when it wasn't; it tried to create it in /EXEC mode; so when VMS tried to deassign the logical it didn't find the /USER mode logical.

The obvious problem with my theory is why on earth would this logical be created in the system table? I was not playing any games with logical table names or directories.

I was really hoping someone could take a quick look at the source and see what tables and modes this SYS$PUTMSG logical is supposed to be created in, and what is supposed to delete it.

[Robert Brooks_1]

I was really hoping someone could take a quick look at the source and see what tables and modes this SYS$PUTMSG logical is supposed to be created in, and what is supposed to delete it.

--

If you have a support contract, I'd open a call with the information you've posted here.

There should be enough information for someone to sort this out.

-- Rob

[John McL]

I've just searched all .EXEs in SYS$SYSTEM and SYS$LIBRARY and found the following that contain the text string "SYS$PUTMSG".

SYS$COMMON:[SYSEXE]ANALYZSSL.EXE
SYS$COMMON:[SYSEXE]PCA$ANALYZER.EXE
SYS$COMMON:[SYSEXE]RAID$CLI_MAIN.EXE
SYS$COMMON:[SYSEXE]RAID$SERVER_MAIN.EXE
SYS$COMMON:[SYSEXE]SCA$DECW.EXE
SYS$COMMON:[SYSLIB]DBI$SHR.EXE
SYS$COMMON:[SYSLIB]LSESHR.EXE
SYS$COMMON:[SYSLIB]NSDS$DDI_RMS_SHR.EXE
SYS$COMMON:[SYSLIB]NSDS$SHR.EXE
SYS$COMMON:[SYSLIB]PCA$COLLECTOR.EXE
SYS$COMMON:[SYSLIB]SCA$SHARE.EXE
SYS$COMMON:[SYSLIB]SYS$PUBLIC_VECTORS.EXE
SYS$COMMON:[SYSLIB]SYS$SSISHR.EXE
SYS$COMMON:[SYSLIB]TRACE.EXE

If none of these ring any bells then I wonder if your problem is related to running SYS$CRELNM just prior to noticing this problem. Were you perhaps running some C code and picked up some old data on the stack? (Or if you prefer, did you initialise the fields correctly in your routine that called SYS$CRELNM?)

[David Jones_21]

Here is whtat the source listing for 7.2-1 say about how the SYS$PUTMSG logical is used:

12751 ; TRANSLATE THE LOGICAL NAME SYS$PUTMSG TO SEE IF THE FILE IS ALREADY
12752 ; OPENED VIA A PREVIOUS CALL. IF THE LOGICAL NAME EXISTS, ITS TRANSLATION
12753 ; CONSISTS OF THE ISI'S FOR THE OUTPUT AND ERROR RABS, SO RE-ESTABLISH
12754 ; THE EXISTING STREAM AND BYPASS THE OPENS.
12755 ;
12756 ; $TRNLOG is used rather than $TRNLNM, as it will not signal errors, despite
12757 ; system service failure mode being enabled ($SETSFM).

I've created mischief at times with the discrepency between $TRNLOG and $TRNLNM.
12758 ;