Behaviour of F$TRNLNM

[Hoff]

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]

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 · Accepted solution]

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.

[Bart Zorn_1]

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