- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- SYS$PUTMSG logical name
Categories
Company
Local Language
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
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
Community
Resources
Forums
Blogs
- 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
тАО05-27-2009 08:38 AM
тАО05-27-2009 08:38 AM
SYS$PUTMSG logical name
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-27-2009 08:44 AM
тАО05-27-2009 08:44 AM
Re: SYS$PUTMSG logical name
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-27-2009 10:33 AM
тАО05-27-2009 10:33 AM
Re: SYS$PUTMSG logical name
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-27-2009 11:01 AM
тАО05-27-2009 11:01 AM
Re: SYS$PUTMSG logical name
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-27-2009 03:11 PM
тАО05-27-2009 03:11 PM
Re: SYS$PUTMSG logical name
>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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-27-2009 03:18 PM
тАО05-27-2009 03:18 PM
Re: SYS$PUTMSG logical name
>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!)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-27-2009 04:11 PM
тАО05-27-2009 04:11 PM
Re: SYS$PUTMSG logical name
"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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-27-2009 05:50 PM
тАО05-27-2009 05:50 PM
Re: SYS$PUTMSG logical name
--
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-27-2009 08:01 PM
тАО05-27-2009 08:01 PM
Re: SYS$PUTMSG logical name
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?)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-28-2009 07:48 AM
тАО05-28-2009 07:48 AM
Re: SYS$PUTMSG logical name
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 ;