Behaviour of F$TRNLNM

[Bart Zorn_1]

Hello,

It appears that F$TRNLNM("",,,"EXECUTIVE") always returns a null string.

Reason for this is that the second argument defaults to LNM$DCL_LOGICAL, which is defined (only) in SUPERVISOR mode in LNM$SYSTEM_DIRECTORY.

LNM$DCL_LOGICAL translates to LNM$FILE_DEV, which has both a SUPERVISOR and an EXECUTIVE mode version in LNM$SYSTEM_DIRECTORY.

If an EXECUTIVE mode version of LNM$DCL_LOGICAL is added (either to LNM$SYSTEM_DIRECTORY or LNM$PROCESS_DIRECTORY), F$TRNLNM behaves in a more natural manner; it will translate EXECUTIVE mode logical names normally.

Of course, I can add this second definition of LNM$DCL_LOGICAL at system startup, but I wonder: is there a compelling reason why it exists only in SUPERVISOR mode?

Any thoughts?

Regards,

Bart Zorn

[Ian Miller.]

I guess its because DCL runs in supervisor mode.

[Bart Zorn_1]

Ian,

Although true, that is not the reason why LNM$DCL_LOGICAL is defined in SUPERVISOR mode.

In SYS$STARTUP:VMS$INITIAL-050_VMS.COM LNM$DCL_LOGICAL is defined with an explicit /SUPER qualifier.

I could just as easily have been /EXEC !

Bart

[Bart Zorn_1]

Hmm... of course I meant:

It could just as easily have been /EXEC !

Bart

(I don't think I want to be /EXEC)

[Wim Van den Wyngaert]

You specified 4 "," before executive.
Then it's not the translation but the item to report.
When "executive" is after 2 "," it works fine.

Wim

[Wim Van den Wyngaert]

Haast en spoed is zelden goed.

The word executive after 2 "," should indicate the index. "executive" is accepted but not used (???). So it does return exec logicals.

It's after 3 "," that you have the mode. And yes, it doesn't work.

Wim

[Wim Van den Wyngaert]

It does work when the table is specified. May be the intention is that you MUST specify a table when using exec logicals.

Fwiw

Wim

[Jess Goodman]

Many years ago I did your suggested work-around and have not had any problems due to it. In my SYSTARTUP_VMS.COM I have:

$DEFINE/NOLOG/TABLE=LNM$SYSTEM_DIRECTORY/EXEC -
LNM$FILE_DEV - LNM$PROCESS,LNM$JOB,LNM$GROUP,LNM$SYSTEM,DECW$LOGICAL_NAMES

[John Gillings]

re: Jess

(defining LNM$FILE_DEV in EXEC mode)

I'm not sure if that's a good idea... Note that by default, OpenVMS already defines both SUPER and EXEC mode translations for LNM$FILE_DEV:

$ show log/full/table=lnm$system_directory lnm$file_dev*

(LNM$SYSTEM_DIRECTORY) [kernel] [shareable,directory]
[Protection=(RWC,RWC,R,R)] [Owner=[SYSTEM]]

"LNM$FILE_DEV" [super] = "LNM$PROCESS"
= "LNM$JOB"
= "LNM$GROUP"
= "LNM$SYSTEM"
= "DECW$LOGICAL_NAMES"
"LNM$FILE_DEV" [exec] = "LNM$PROCESS"
= "LNM$JOB"
= "LNM$GROUP"
= "LNM$SYSTEM"


The reason is the EXEC mode translation is used for "trusted" logical name translation. The above is V7.3-2, in (much?) older versions, the exec mode translation only contained LNM$SYSTEM. It was relaxed to make it possible to have duplicate file names for installed images (circa V6, at the same time global section names got "mangled").

Although defining the logical name is most unlikely to break anything, it does allow a wider scope for trusted logical name translation, and thus potentially more tables that you implicitly trust. In the above case, the only difference is the DECW$ logical name table, which is *probably* trustworthy. Just be very careful about including any other logical name tables that might be writeable from non-trustworthy processes.

Re: Bart,

I think there's a bug here. F$TRNLNM is just a jacket for SYS$TRNLNM. If you call $TRNLNM from a non-privileged process you can correctly translate logical names by mode (I've tried it for user, super and exec, but not kernel since there's no simple way to create them!)

Please log a case with HP customer services to get it fixed!

Let me know if you want a simple test program.

[John Gillings]

Oops, sorry, I'll take that back...

$TRNLNM requires a table name. F$TRNLNM does not - it defaults to LNM$DCL_LOGICAL. Calling the system service with LNM$DCL_LOGICAL does not find exec mode logical names in the search path:

%SYSTEM-F-NOLOGNAM, no logical name match

The SSRM doesn't say that the table name logical name is required to be at least at MODE, but I guess it makes a kind of sense.

Simple workaround:

F$TRNLNM("","LNM$FILE_DEV",,"EXECUTIVE")