Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Behaviour of F$TRNLNM

SOLVED
Go to solution
Bart Zorn_1
Trusted Contributor

Behaviour of F$TRNLNM

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
13 REPLIES
Ian Miller.
Honored Contributor

Re: Behaviour of F$TRNLNM

I guess its because DCL runs in supervisor mode.
____________________
Purely Personal Opinion
Bart Zorn_1
Trusted Contributor

Re: Behaviour of F$TRNLNM

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
Trusted Contributor

Re: Behaviour of F$TRNLNM

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
Honored Contributor

Re: Behaviour of F$TRNLNM

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
Wim Van den Wyngaert
Honored Contributor

Re: Behaviour of F$TRNLNM

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
Wim Van den Wyngaert
Honored Contributor

Re: Behaviour of F$TRNLNM

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
Wim
Jess Goodman
Esteemed Contributor

Re: Behaviour of F$TRNLNM

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

I have one, but it's personal.
John Gillings
Honored Contributor

Re: Behaviour of F$TRNLNM

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.
A crucible of informative mistakes
John Gillings
Honored Contributor

Re: Behaviour of F$TRNLNM

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")

A crucible of informative mistakes
Hoff
Honored Contributor

Re: Behaviour of F$TRNLNM

This behavior looks to be a variation of the typical privileged image activation. Privileged images will deliberately skip the translations from the outer modes, and will ignore even privileged definitions in unprivileged tables.

The table and the logical name must all be in the requested mode, or in a more privileged mode. If you try to aim the translation elsewhere from a less-privileged mode and/or a definition in a less-privileged table, it will be ignored.

Bart Zorn_1
Trusted Contributor

Re: Behaviour of F$TRNLNM

Thanks for all your reactions.

However, In my initial post I already stated what the real problem was, and nobody answered my question: why isn't there an EXEC mode definition of LNM$DCL_LOGICAL in the first place?

Bart
John Gillings
Honored Contributor
Solution

Re: Behaviour of F$TRNLNM

Bart,

>why isn't there an EXEC mode definition of
>LNM$DCL_LOGICAL in the first place?

Because it wasn't needed. The only reason for defining EXEC mode logical names is to provide a distinction between privileged and non-privileged access. The EXEC mode definition can be limited to a trusted search path, and prevents non-privileged definitions from hijacking translations to (potentially) introduce trojan horses. By not defining an EXEC mode translation at all, the logical name is eliminated as a potential security hole.

LNM$DCL_LOGICAL is a bit of an oddity and rather obscure. It isn't used in many places. Before VMS V4, there were only 3 hardcoded logical name tables PROCESS, GROUP and SYSTEM. When the logical name architecture was radically changed in V4 to include multiple tables, a mechanism was required to provide compatibility with the older architecture and the $TRNLOG system service (and now obselete and undocumented lexical function F$TRNLOG). See entries in LNM$SYSTEM_DIRECTORY for LOG$* and TRNLOG$* - these replicate the seven old search paths within the new mechanism. LNM$DCL_LOGICAL was originally the default compatibility search path LOG$PROCESS, LOG$GROUP, LOG$SYSTEM, but over time it's been changed to be LNM$FILE_DEV, and therefore redundant.

On potential solution to your issue would be to change F$TRNLNM to default the table name to LNM$FILE_DEV (which does have an EXEC mode translation). I'd guess the reason that hasn't happened is no one has asked, so there's no incentive to invest the resources required to change the code and documentation. If you feel strongly about it, log a case.

In the mean time, it should be safe for you to define an EXEC mode translation for LNM$DCL_LOGICAL (I'd suggest pointing it at LNM$FILE_DEV), however, this makes any code you write using F$TRNLNM and EXEC mode dependent on your non-standard environment. On the other hand, if you simply add the table name LNM$FILE_DEV to your call, it will work on all standard OpenVMS environments, and will continue to work even if F$TRNLNM is changed in the future.
A crucible of informative mistakes
Bart Zorn_1
Trusted Contributor

Re: Behaviour of F$TRNLNM

Thanks, John.

I think that specifying LNM$FILE_DEV in the call is the best solution.

However, changing the explicit /super into /exec in SYS$STARTUP:VMS$INITIAL-050_VMS.COM in a future update of OpenVMS will not break anything, and I do not see how it could add a security risk.

Regards,

Bart