Use of logical names other than I/O redirection

[alanfe...@gmail.com]

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

[abrsvc]

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

[Arne Vajhøj]

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

[Jan-Erik Söderholm]

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.

[Bob Gezelter]

On Saturday, September 10, 2022 at 7:35:08 PM UTC-4, alanfe...@gmail.com wrote:

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

[Marc Van Dyck]

It happens that alanfe...@gmail.com formulated :

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

[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

[Stephen Hoffman]

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

[Arne Vajhøj]

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

[David Jones]

On Saturday, September 10, 2022 at 7:35:08 PM UTC-4, alanfe...@gmail.com wrote:

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

[alanfe...@gmail.com]

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.

[alanfe...@gmail.com]

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

[...]

[Bob Gezelter]

On Monday, September 12, 2022 at 2:18:11 PM UTC-4, alanfe...@gmail.com wrote:

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.

[Craig A. Berry]

Why not distribution lists?

[Stephen Hoffman]

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.

[Marc Van Dyck]

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

[Bob Gezelter]

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.

[Stephen Hoffman]

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.

[Dave Froble]

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: da...@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[Arne Vajhøj]

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

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

--
Marc Van Dyck

[Bob Gezelter]

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.

[Jan-Erik Söderholm]

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.

[abrsvc]

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

[Jonathan]

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

[Arne Vajhøj]

On 9/14/2022 7:31 AM, Bob Gezelter wrote:
> 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).
>

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

Sounds like some people are doing some pretty advanced stuff
with logicals.

:-)

Arne

[David Jones]

On Wednesday, September 14, 2022 at 5:32:40 PM UTC-4, Jonathan wrote:
> ! 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.

As far as I can tell from the ISD, replacing a logical name is an
atomic operation. A single LNMB is created with all the LNMX
blocks for the equivalence names embedded within it. Then
IPL is raised and the block is inserted in the table, possibly
deleting an existing block.

Usually the trouble you have is reading the name since you don't
know the max index ahead of time, creating a race condition
from multiple $TRNLNM calls.

[Phillip Helbig (undress to reply)]

In article <60a6807f-fbb7-400a...@googlegroups.com>,
"alanfe...@gmail.com" <alanfe...@gmail.com> writes:

> 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 use logical names for many things, also I/O redirection, but that is
relatively minor. They really come into their own with cluster-wide
logical names. In particular, one can have, say, a logical name table
with access for a group but, due to the parent table, available
cluster-wide.

[Phillip Helbig (undress to reply)]

In article <4f5300c2-b306-43be...@googlegroups.com>,
abrsvc <dansabr...@yahoo.com> writes:

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

Yes, another great example.

[Phillip Helbig (undress to reply)]

In article <54860c09-5d3c-463a...@googlegroups.com>,

"alanfe...@gmail.com" <alanfe...@gmail.com> writes:

> You can use logical names for recipients! I don't know if this is a true

> story, but someone did a=20

> $ DEFINE MORON <user-address>
> And when the person received it, it should that it was sent to MORON!

I think that one can also do DEFINE USERNAME OTHER_USER so mail sent to
USERNAME will go to OTHER_USER.

[alanfe...@gmail.com]

On Saturday, September 10, 2022 at 7:49:21 PM UTC-4, abrsvc wrote:
> 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

I did the same c. 1999! I set up a test database for export experiments.

[alanfe...@gmail.com]

On Monday, September 12, 2022 at 4:40:49 PM UTC-4, Stephen Hoffman wrote:
> On 2022-09-12 18:18:09 +0000, alanfe...@gmail.com said:
>
> > 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!
> 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.

The MORON bit was an unintentional thing. The sender didn't know it would appear as "To: MORON" to the recipient. The sender must have assumed that MAIL would show the recipient the translation, not the actual logical name.

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

The only time I use VMS MAIL is on EISNER, and it's always initiating by the system manager. I'm just curious about how people here feel about logical names, other than I/O direction.

[...]

> Pure Personal Opinion | HoffmanLabs LLC

Alan

[Phillip Helbig (undress to reply)]

In article <a881a1ce-5ba7-46f8...@googlegroups.com>,

"alanfe...@gmail.com" <alanfe...@gmail.com> writes:

> On Monday, September 12, 2022 at 4:40:49 PM UTC-4, Stephen Hoffman wrote:
> > On 2022-09-12 18:18:09 +0000, alanfe...@gmail.com said:
> >
> > > 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!
> > 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.
>
> The MORON bit was an unintentional thing. The sender didn't know it
> would appear as "To: MORON" to the recipient. The sender must have
> assumed that MAIL would show the recipient the translation, not the
> actual logical name.

So were you the sender or the recipient? :-)

> The only time I use VMS MAIL is on EISNER

I've been using VMS MAIL for 30 years.

> I'm just curious about how people here feel about logical names, other
> than I/O direction.

I use them for all kinds of things. With the modes, tables, parent
tables, search lists, concealed devices, etc., they are really powerful.
Often a topic in the "why can't linux do this?" discussions. :-)