[Info-vax] Logical Name - remove with deassign and executive mode

[Stephen Hoffman]

On 2021-10-21 14:44:30 +0000, HCorte said:

> After creating a logical name "olmteste"
> ...
> does exists a default command procedure or file that can have some 
> personalized rules for deassign remove of logical names?

Logical names can translate from any table in the default list of 
logical name tables and in the table order specified, and translated 
from modes in ascending order of least to most privilege in each table.

First translation wins, the rest get ignored.

Creation and deletion of privileged-mode logical names involves 
privileges (CMEXEC, CMKRNL, etc), and involves explicit specification 
of mode.

If the logical name is not in the default searchlist of tables, the 
table of residence will need be explicitly specified.

Logical name translations can be restricted to trusted modes by 
explicit request (usually for security), or by operating in certain 
trusted contexts (for security), or by selecting a list of tables to 
translate from.  This because the first translation wins, which can be 
entirely untrusted and least-privileged translation if not otherwise 
restricted during the logical name translation request.

Logical name tables can be protected by protection 
(S:RWED,O:RWED,G:RWED,W:RWED) bitmask and by access control list. The 
tables are considered security objects, for the purpose of OpenVMS 
security.

Logical name translations have a chaotic little feature of ignoring 
leading underscores in various translation contexts, sort of. This was 
supposedly a means to restrict translations to physical devices (which 
can have a leading underscore), but it doesn't work that way now. The 
overhaul at VAX/VMS V4.0 didn't fully implement what earlier and 
simpler logical name implementations had provided here: in earlier 
versions, a leading underscore had stopped translations. Now that's 
sorta-kinda the concealed and terminate options on the logical name 
definition.

This whole area all works rather similar to the logical-name based 
searchlist logical names used for the system disk too, with the added 
wrinkle of needing to create directories in each translation lest 
errors arise for some operations. You read from all translations, you 
write to the first translation. (This is how inexperienced cluster 
system administrators can fill their cluster roots with files too, 
while intending to share the files from within the common root.)  To 
get these to work, parallel the translation options on SYS$SYSROOT and 
related translations, as the correct operation of searchlist logical 
names are entirely dependent on the specified translation options.

Logical names are a bad means of providing configuration information to 
apps past temporary and transient device and file redirections, not 
that OpenVMS has looked at this area since VAX/VMS V4.0 or so, and not 
that OpenVMS has really looked at app-level context APIs and features 
for that matter. Logical names for app management purposes past device 
and file redirections do have virtue of being simple for the developer 
to start using and harder to properly implement and far harder quit, 
which is why we've been enjoying bad app configuration management 
interfaces ~everywhere on OpenVMS for decades. Once you see how awful 
logical names really are as compared with purpose-built app 
configuration APIs, seeing the logical names used everywhere is... 
frustrating.

I'd suggest having a look at the OpenVMS User's Manual and the OpenVMS 
Programming Concepts manuals for some background in the lower-level 
platform features. The manuals are scattershot around coverage of 
specific topic areas, such as logical names; "recipe" or "cookbook" 
stuff from that era was usually provided over in the support database, 
and that material was slowly or variously never incorporated into the 
documentation information design.



-- 
Pure Personal Opinion | HoffmanLabs LLC