[Info-vax] Use of logical names other than I/O redirection

[Bob Gezelter]

On Tuesday, September 13, 2022 at 8:32:16 PM UTC-4, Arne Vajhøj wrote:
> On 9/13/2022 3:58 AM, Marc Van Dyck wrote: 
> > Arne Vajhøj has brought this to us : 
> >> 3) Logical names does not scale well. 50 fine, 100 fine, 
> >>     200 fine but 100000 does not work. Windows registry is 
> >>     a fine example of something that has become so big that 
> >>     it is difficult to find things. 
> >> 
> > Not if you use separate, dedicated logical name tables. Putting 
> > everything in LNM$SYSTEM is of course not good practice, but desiging 
> > applications to use their own table(s), use rights ids to grant access 
> > to them, and connect automatically to the right tables at login time 
> > works perfectly for me. We also use such mechanisms for our development 
> > environment, so that each version of each application gets its own 
> > set of tables.
> I am sure that it works. 
> 
> But it is very customized solution. 
> 
> It requires changes to users login.com if I understand it 
> correctly. 
> 
> And I don't think it makes things easily searchable 
> (unless there are a number of conventions everybody 
> need to know). 
> 
> Arne
Arne,

Separate per-product logical name tables are quite feasible, see my OpenVMS Technical Journal paper on Hierarchical Logical Names, "Inheritance Based Environments in Stand-alone OpenVMS Systems and OpenVMS Clusters (February 2004)" at http://www.rlgsc.com/publications/vmstechjournal/inheritance.html.

As to LOGIN.COM, Marc's suggestion of SYS$MANAGER:SYLOGIN.COM works for global definitions. If one desires a more precision approach to manage individually authorized applications, or different versions of the same application, or for that matter, some mixture of both, one can straightforwardly implement a group-wide login.com, as described in "Group-wide LOGIN Profiles Lower Risk, Decrease Cost", the September 30, 2010 installment of The OpenVMS Consultant, http://www.rlgsc.com/blog/openvms-consultant/group-wide-login.html.

When I used the rights identified approach at a client, I was dealing with a large collection of applications, and a far larger workforce, each with an individual login. Individuals had to be checked out on each application by a supervisor, and then granted access when a work order required them to use the application. In effect, their captive account screen menu would only show the applications they were cleared to work on that particular shift. Granting/revoking these identifiers was delegated to the section supervisors, who similarly had an application (DCL-implemented) to check-in/check-out batches of work. Tens of operators per shift; worked smoothly for years.

Of course, all application directories and files were tagged with appropriate access control lists, so applications could not be executed without the required identifiers. 

An effective analog of access control badges, but within the user environment.

- Bob Gezelter, http://www.rlgsc.com