Greetings.

I recall Hoff once lamenting about logical names. He said they are mostly good for I/O redirection. And, IIRC, not liking using them to store application data.

I was wondering how people here (esp. Hoff!) feel about their use in batch queues and mail.

Just askin'.

On Saturday, September 10, 2022 at 7:35:08 PM UTC-4, alanfe...@gmail.com wrote:
> Greetings.
>
> I recall Hoff once lamenting about logical names. He said they are mostly good for I/O redirection. And, IIRC, not liking using them to store application data.
>
> I was wondering how people here (esp. Hoff!) feel about their use in batch queues and mail.
>
> Just askin'.

I have used them for creating separate environments for clients. Modifying the search order and adding application specific tables, using group level tables to create a complete environment separate from others, etc. Gave a talk about this at a bootcamp once.

I have seen logical names used as status strings, application "switches" and other things too.

Many uses, some good, some not so much.

Dan

On 9/10/2022 7:35 PM, alanfe...@gmail.com wrote:
> I recall Hoff once lamenting about logical names. He said they are
> mostly good for I/O redirection. And, IIRC, not liking using them to
> store application data.
>
> I was wondering how people here (esp. Hoff!) feel about their use in
> batch queues and mail.

My opinion:

files & directories => great
configuration => ok but a bit of a hack - a config file or command line
switch is usually better
process communication => bad - use something else

If for batch queue you mean a logical name pointing to a batch queue,
then I think it is fine - it is similar to files and directories.

If for mail you mean logicals used by EVE to auto format mail,
then it is a hack, but a hack that I have been using myself. If
something else please elaborate.

Arne

Den 2022-09-11 kl. 02:27, skrev Arne Vajhøj:
> On 9/10/2022 7:35 PM, alanfe...@gmail.com wrote:
>> I recall Hoff once lamenting about logical names. He said they are
>> mostly good for I/O redirection. And, IIRC, not liking using them to
>> store application data.
>>
>> I was wondering how people here (esp. Hoff!) feel about their use in
>> batch queues and mail.
>
> My opinion:
>
> files & directories => great
> configuration => ok but a bit of a hack - a config file or command line
> switch is usually better
> process communication => bad - use something else
>
> If for batch queue you mean a logical name pointing to a batch queue,
> then I think it is fine - it is similar to files and directories.
>
> If for mail you mean logicals used by EVE to auto format mail,
> then it is a hack, but a hack that I have been using myself. If
> something else please elaborate.
>
> Arne

We use log names a lot for naming ports to equipment and workplaces.

Like the two Zebra label printers at packing workplace number 36:

$ sh log P36PRT*
"P36PRT1" = "TNA2010:"
"P36PRT2" = "TNA2011:"

The TNA device can change from day to day, but always
point to the IP addresses of these printers, of course.
And the application doesn't need to know (the logical name
is used as-is in the QIOW call) which is the whole point
with logical names, of course.

On Saturday, September 10, 2022 at 7:35:08 PM UTC-4, alanfe...@gmail.com wrote:
> Greetings.
>
> I recall Hoff once lamenting about logical names. He said they are mostly good for I/O redirection. And, IIRC, not liking using them to store application data.
>
> I was wondering how people here (esp. Hoff!) feel about their use in batch queues and mail.
>
> Just askin'.
Alan,

I generally agree with Dan. Almost twenty years ago, 2004 to be precise, I authored an OpenVMS Technical Journal article entitled "Inheritance Based Environments in Stand-alone OpenVMS Systems and OpenVMS Clusters". It is available on my www site at: http://www.rlgsc.com/publications/vmstechjournal/inheritance.html.

Realtime use to signal status is sometimes seen, and is safe so long as there is a single writer. If there are multiple writers, the classic dangers of multiple modifiers of uninterlocked storage locations apply. At today's speeds, this is an ever more serious hazard. In "Resolving the Contention Problem with ASSIGN/DEFINE" (http://www.rlgsc.com/blog/openvms-consultant/assign-define-contention.html) I proposed the addition of a interlocking /COMPARE:"<string>" qualifier to ASSIGN/DEFINE to transform the underlying $CRELNM system service from a simple assignment to a "Compare&Swap" semantic.

IMHO, the use of logical names for Batch/Print queues and email is a reasonable practice. It is actually the subject of an upcoming column in my "OpenVMS Consultant" series.

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

It happens that alanfe...@gmail.com formulated :
> Greetings.
>
> I recall Hoff once lamenting about logical names. He said they are mostly
> good for I/O redirection. And, IIRC, not liking using them to store
> application data.
>
> I was wondering how people here (esp. Hoff!) feel about their use in batch
> queues and mail.
>
> Just askin'.

I consider logical names to be the equivalent of the windows registry.
Anything I need to store and that doesn't warrant a file is fair game.
Devices, directories, and files, of course, but also queue and device
names. And then everything else : statuses, switches, application
running modes, IP addresses, ... If read by 3GL code, it can even be
non printable ascii or binary, like VMS itself does it with licenses
in LMF$LICENSE_TABLE. I consider that much more convenient than
configuration or .INI files.

--
Marc Van Dyck

Bob Gezelter explained :
> If there are multiple writers, the classic dangers of
> multiple modifiers of uninterlocked storage locations apply. At today's
> speeds, this is an ever more serious hazard.

To get around this issue, I wrote a DCL jacket around $ENQ/$DEQ system
services. Anyone wanting to read or write in a shared table must
acquire
the corresponding lock beforehand and release it afterwards. Never
failed on me.

--
Marc Van Dyck

On 2022-09-10 23:35:06 +0000, alanfe...@gmail.com said:

> I recall Hoff once lamenting about logical names. He said they are
> mostly good for I/O redirection. And, IIRC, not liking using them to
> store application data.
>
> I was wondering how people here (esp. Hoff!) feel about their use in
> batch queues and mail.

The use of logical names within batch and mail... for what?

The OpenVMS mail app, batch-print for process control and scheduling,
and logical names as a volatile and exceedingly limited key-value
store, sure, if you're in the previous millennium, or have never met a
more modern app configuration data storage API.

There's no good alternative for I/O redirection on OpenVMS, which also
happens with email addresses and mail, and with batch-print and such.
Which where I'll usually use logical names.

There are better alternatives for app configuration data, and for
key-value stores. Unfortunately, OpenVMS forces app developers to write
their own here, past some DECwindows stuff and ilk, and probably tools
in Perl, Python, and Java, etc.

Not great, but more workable, less disjoint, app-local, and decidedly
less volatile:
https://developer.apple.com/documentation/foundation/preferences

Look at the OpenVMS C and Java run-time configuration logical names for
some of how storing configuration data becomes problematic.

Using and parsing logical names to read configuration data is something
I've done... but really don't prefer doing.

Having your app settings and your redirections disjoint and scattered
in files all over the place in a volatile and limited key-value store,
and parsing user-provided input, just gets... tedious.

And there's no way to adapt to future changes compatibly with a bevy of
logical names, given the lack of wildcards in the API. (This is a
variation of how RMS files can grow in numbers. q.v. cluster
configuration database. Which also uses logical names.)

OpenVMS lacks robust integration with LDAP and lacks robust app
configuration data storage, and lacks robust process management and
scheduling services, among other limits.

If you wanted a bad and volatile and file-disjoint ancestor of the
Windows registry, or want to write lots of your own code, logical names
absolutely do have you covered, of course.

--
Pure Personal Opinion | HoffmanLabs LLC

On 9/11/2022 11:55 AM, Marc Van Dyck wrote:
> It happens that alanfe...@gmail.com formulated :
>> Greetings.
>> I recall Hoff once lamenting about logical names. He said they are
>> mostly good for I/O redirection. And, IIRC, not liking using them to
>> store application data.
>>
>> I was wondering how people here (esp. Hoff!) feel about their use in
>> batch queues and mail.
>>
>> Just askin'.
>
> I consider logical names to be the equivalent of the windows registry.
> Anything I need to store and that doesn't warrant a file is fair game.

(cut out some usage that I agree with)

> If read by 3GL code, it can even be
> non printable ascii or binary, like VMS itself does it with licenses
> in LMF$LICENSE_TABLE. I consider that much more convenient than
> configuration or .INI files.

I see a few problems with that:
1) Logical names are not automatically persisted. They rely on
being defined at startup. Of course necessary logicals should
be set in the startup procedures, but we all know that
"should" is not 100% reliable.
2) The connection between application and logical names is
not always easy to make. It is way easier to connect a
config file in the app directory with that app.
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.

MS has also concluded that. Various old technologies including
COM used registry extensively, but .NET use config files
in app directory (either XML or JSON depending on .NET
version).

Arne

On Saturday, September 10, 2022 at 7:35:08 PM UTC-4, alanfe...@gmail.com wrote:
> Greetings.
>
> I recall Hoff once lamenting about logical names. He said they are mostly good for I/O redirection. And, IIRC, not liking using them to store application data.
>
> I was wondering how people here (esp. Hoff!) feel about their use in batch queues and mail.

I use VMS mail very little these days. Submitting to a queue by its logical name seems
sensible me. Programs by default submit to SYS$BATCH/SYS$PRINT, so a mechanism
to redirect those is handy.

IIRC, the original incarnation of logical names gave each a single value and you only had
process, group, and system tables. The latter 2 required privilege to (GRPNAM, SYSNAM)
to add names, since they were shared resources ($CREMBX added to the group table for
temporary mailboxes and system table for permanent, gated by different privilege bits).
The features that came with the big overhaul in OpenVMS 4 made abuse much more
tempting. My SSH server, for example, posted information about active connections to a
logical special logical name table so the system manager could easily see where the
connections were coming from (and match up the TCP port number with the connection
so she could kill it).

On Saturday, September 10, 2022 at 8:28:10 PM UTC-4, Arne Vajhøj wrote:
> On 9/10/2022 7:35 PM, alanfe...@gmail.com wrote:
> > I recall Hoff once lamenting about logical names. He said they are
> > mostly good for I/O redirection. And, IIRC, not liking using them to
> > store application data.
> >
> > I was wondering how people here (esp. Hoff!) feel about their use in
> > batch queues and mail.
> My opinion:
>
> files & directories => great
> configuration => ok but a bit of a hack - a config file or command line
> switch is usually better
> process communication => bad - use something else
>
> If for batch queue you mean a logical name pointing to a batch queue,
> then I think it is fine - it is similar to files and directories.
>
> If for mail you mean logicals used by EVE to auto format mail,
> then it is a hack, but a hack that I have been using myself. If
> something else please elaborate.
>
> Arne

You can use logical names for recipients! I don't know if this is a true story, but someone did a
$ DEFINE MORON <user-address>
And when the person received it, it should that it was sent to MORON!

I suppose that's harmless enough for personal use. I suppose one could make "public" logical names for positions like systems administrator, or HR Head, who might change from time to time.

On Monday, September 12, 2022 at 2:18:11 PM UTC-4, alanfe...@gmail.com wrote:
[...]
> You can use logical names for recipients! I don't know if this is a true story, but someone did a
> $ DEFINE MORON <user-address>
> And when the person received it, it should that it was sent to MORON!

Uh, make that "showed", not "should."

[...]

On Monday, September 12, 2022 at 2:18:11 PM UTC-4, alanfe...@gmail.com wrote:
> On Saturday, September 10, 2022 at 8:28:10 PM UTC-4, Arne Vajhøj wrote:
> > On 9/10/2022 7:35 PM, alanfe...@gmail.com wrote:
> > > I recall Hoff once lamenting about logical names. He said they are
> > > mostly good for I/O redirection. And, IIRC, not liking using them to
> > > store application data.
> > >
> > > I was wondering how people here (esp. Hoff!) feel about their use in
> > > batch queues and mail.
> > My opinion:
> >
> > files & directories => great
> > configuration => ok but a bit of a hack - a config file or command line
> > switch is usually better
> > process communication => bad - use something else
> >
> > If for batch queue you mean a logical name pointing to a batch queue,
> > then I think it is fine - it is similar to files and directories.
> >
> > If for mail you mean logicals used by EVE to auto format mail,
> > then it is a hack, but a hack that I have been using myself. If
> > something else please elaborate.
> >
> > Arne
> You can use logical names for recipients! I don't know if this is a true story, but someone did a
> $ DEFINE MORON <user-address>
> And when the person received it, it should that it was sent to MORON!
>
> I suppose that's harmless enough for personal use. I suppose one could make "public" logical names for positions like systems administrator, or HR Head, who might change from time to time.
Alan,

For role-based addressing, a practice I recommended in multiple editions of the "Computer Security Handbook", SET /FORWARD is a better choice than logical names.

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

On 9/12/22 1:43 PM, Bob Gezelter wrote:
> On Monday, September 12, 2022 at 2:18:11 PM UTC-4, alanfe...@gmail.com wrote:

>> You can use logical names for recipients! I don't know if this is a true story, but someone did a
>> $ DEFINE MORON <user-address>
>> And when the person received it, it should that it was sent to MORON!
>>
>> I suppose that's harmless enough for personal use. I suppose one could make "public" logical names for positions like systems administrator, or HR Head, who might change from time to time.
> Alan,
>
> For role-based addressing, a practice I recommended in multiple editions of the "Computer Security Handbook", SET /FORWARD is a better choice than logical names.
>

Why not distribution lists?

On 2022-09-12 18:18:09 +0000, alanfe...@gmail.com said:

> You can use logical names for recipients!

You can also use MAIL DECnet to probe the remote system configuration.
You can remotely detect the presence of add-on security apps that might
be running, for instance.

You can also detect remote network security teams using MAIL DECnet as
their preferred technique to probe the local system, and can then use
that detection to counter their probes.

You can also detect and can early-answer arriving MAIL DECnet messages
before the sender ^Z to finish sending a line-mode MAIL DECnet message.

MAIL DECnet is also subject to "slowloris"-style shenanigans.

> I don't know if this is a true story, but someone did a$ DEFINE MORON
> <user-address>
> And when the person received it, it should that it was sent to MORON!

You can do that with pretty much any mail tool, or with DNS translations, etc.

> I suppose that's harmless enough for personal use. I suppose one could
> make "public" logical names for positions like systems administrator,
> or HR Head, who might change from time to time.

Easier to use a forwarding entry in the database for forwarding
arriving OpenVMS MAIL to a fixed address (and SYSTEM, FIELD, etc., are
routinely forwarded on systems I have administered), but there are
limits. OpenVMS MAIL doesn't like multiple forwarders. Forwarding to a
forwarding server does work, as a workaround.

MAIL really doesn't work all that well by current standards. When open
and unsecured network connections are still permissible, MAIL does
provides a way to send logs and notifications. Though there are other
and more secure paths for that. I've used php and other tools to make
secure connections, where the target SMTP is operating with modern
settings and where security exceptions are discouraged.

OpenVMS MAIL (lack of) handling of MIME is still a mess, as well. Can
it be gotten to work? Sure. Mostly. VSI did just fix a MIME issue.

And absent add-ons past the inexplicably-still-an-add-on IP stack, MAIL
also doesn't work for SMTP messages when a mail server is not also
installed locally, which is just hilarious.

--
Pure Personal Opinion | HoffmanLabs LLC

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.

--
Marc Van Dyck

On Tuesday, September 13, 2022 at 3:58:47 AM UTC-4, 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.
>
> --
> Marc Van Dyck
Marc,

Concur. Did DECUS presentations on those techniques a long time ago, circa 2000. With conventional logins, rights identifiers work quite well, it is effectively parallels access badges.

Inserting logical name tables into the search path is documented, and removes the need for the application to be aware of the underlying structure. One can also use indirection, e.g., the application-specific logical names hinge on another logical name. For an example, consider SYS$SYSTEM, which references SYS$SPECIFIC and SYS$COMMON, which in turn reference SYS$SYSDEVICE. There is no requirement that they all must be in the same logical name table.

At one client, that little "trick" eliminated thousands, or possibly tens of thousands of process logical names across the active sessions. Realtime performance improved; paged pool decreased, and login-time was significantly reduced. The number of logical names per logged-in user went from hundreds to less than ten.

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

On 2022-09-13 07:58:46 +0000, Marc Van Dyck said:

> 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.

That's kinda the definition of not scaling well.

But as you have a small and self-contained environment with simple
requirements, by all means logical names can and should be used.

Again, my belief that logical names are a bad solution for
configuration data and are just complex and convoluted and volatile and
disjoint does not mean y'all shouldn't use them.

Logical names are what they are, and the available OpenVMS alternatives
for app and system configuration data storage are lacking. Which is why
logical names continue to get used. Later, rinse, repeat.

It's also why we get messes such as the DEC C logical name thicket, and
a more recent favorite of mine, and the ever-popular
defaults-to-an-open-relay-whoopsie SMTP server database.

OpenVMS doesn't do this app-local and app-isolated stuff at all well
(which tracks back to other issues and errors and limits), though it is
feasible to create a DSL with lib$table_parse, and it is possible to
use LDAP (though not so well nor so easily, strictly locally), and
various languages do have language-specific configuration storage
mechanisms.

--
Pure Personal Opinion | HoffmanLabs LLC

On 9/13/2022 4:23 PM, Stephen Hoffman wrote:
> On 2022-09-13 07:58:46 +0000, Marc Van Dyck said:
>
>> 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.
>
> That's kinda the definition of not scaling well.
>
> But as you have a small and self-contained environment with simple requirements,
> by all means logical names can and should be used.
>
> Again, my belief that logical names are a bad solution for configuration data
> and are just complex and convoluted and volatile and disjoint does not mean
> y'all shouldn't use them.

On that point I agree completely. Tools can always be misused, ie; hammer and
screw, screwdriver as prybar, and such.

But I have to ask, isn't the app configuration an issue for the app, not the
environment? I fail to see any logic in expecting an environment to provide
generic tools for such activity. Nor am I a big fan of "generic" in general.

> Logical names are what they are, and the available OpenVMS alternatives for app
> and system configuration data storage are lacking. Which is why logical names
> continue to get used. Later, rinse, repeat.

With a few logical names I can run many copies of an application on a single
system. That has always been valuable to me, though much less so in this era of
cheap hardware and systems dedicated to single applications.

> It's also why we get messes such as the DEC C logical name thicket, and a more
> recent favorite of mine, and the ever-popular defaults-to-an-open-relay-whoopsie
> SMTP server database.

To me that is a nightmare. What does the apps do if the logicals aren't set as
needed? Scary.

> OpenVMS doesn't do this app-local and app-isolated stuff at all well (which
> tracks back to other issues and errors and limits), though it is feasible to
> create a DSL with lib$table_parse, and it is possible to use LDAP (though not so
> well nor so easily, strictly locally), and various languages do have
> language-specific configuration storage mechanisms.

Have to ask, just what is LOGIN.COM? I'd suggest it is the place for some
configuration information, at least enough to get to a place where more details
are specified. Consider it an "ini" file for a process instead of for a single
executable.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

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 Vajhøj brought next idea :
>
> It requires changes to users login.com if I understand it
> correctly.
>
Not the way we have implemented it. The logic is common and included
in SYLOGIN.COM and it's all driven by the rights ids granted to the
different user accounts.

--
Marc Van Dyck

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

Den 2022-09-14 kl. 10:12, skrev Marc Van Dyck:
> Arne Vajhøj brought next idea :
>>
>> It requires changes to users login.com if I understand it
>> correctly.
>>
> Not the way we have implemented it. The logic is common and included
> in SYLOGIN.COM and it's all driven by the rights ids granted to the
> different user accounts.
>

On our system, the normal users doesn't even have an private
home directory, and even less a private LOGIN.COM. The dev/dir
setting in the UAF just points to a common scratch directory.
Nothing is ever written there anyway, apart from some process
dump or such. But nothing by-design from the applications.

Everthing is controlled by the menu system and one common LOGIN
file where any special setup for some specific user is handled.

On Wednesday, September 14, 2022 at 7:56:46 AM UTC-4, Jan-Erik Söderholm wrote:
> Den 2022-09-14 kl. 10:12, skrev Marc Van Dyck:
> > Arne Vajhøj brought next idea :
> >>
> >> It requires changes to users login.com if I understand it
> >> correctly.
> >>
> > Not the way we have implemented it. The logic is common and included
> > in SYLOGIN.COM and it's all driven by the rights ids granted to the
> > different user accounts.
> >
> On our system, the normal users doesn't even have an private
> home directory, and even less a private LOGIN.COM. The dev/dir
> setting in the UAF just points to a common scratch directory.
> Nothing is ever written there anyway, apart from some process
> dump or such. But nothing by-design from the applications.
>
> Everthing is controlled by the menu system and one common LOGIN
> file where any special setup for some specific user is handled.

There are many valid techniques that have been used over the years. In my case, the logicals were "controlled" by UIC groups. We built group level (and private tables) all triggered by the UIC group. This worked well for our application environment. Each group had their own private tables added to the search list in addition to the group level.

Dan

25 years ago or so I implemented query queues using logicals (and locks.) I thought the implementation would be replaced at some point, but it's still in use. Description from the sources:

! Query/Reply queues implemented using logical tables
! ! The data for each queue is stored in individual logicals in
! a logical table created for the queue in the system logical
! table directory.
! ! The logical table has four kinds of logical.
! Logical: Contains:
! VERSION current version of queue. The value is
! a hexadecimal time string.
! <version>_TAIL the index of the last item in the queue.
! The value is a decimal string.
! Item numbering starts at 1
! <version>_ENTRY_<n> The state of the <n>th item in the queue.
! The states are QUERY and REPLY and describe
! the contents of the buffer.
! <version>_BUFFER_<n> The buffer holding the data for the
! <n>th item in the queue. This logical
! may have multiple translations. The data
! is the concatenation of all the translations.
! ! Together the _<n> suffixed logicals constitute an item in the queue.
! ! The reason for the separate queue entry and buffer logicals:
! 1) The upper limit on a logical value is 255 bytes.
! 2) Buffers need to be larger than 255 bytes. The required
! larger buffers are implemented as logical arrays (search lists.)
! 3) Creating a logical array is not an atomic operation. A reader
! may see a partial array.
! 4) The logical arrays are created before the queue entries that
! point to them. The queue entries are created in an atomic
! operation.
! ! The version is used to avoid problems when a querier sets a timeout
! long enough for the replier to shutdown/die and restart. The replier
! creates a new queue, destroying any old queue. If there were no
! versions the querier might read someone-else's later query.

Jonathan