[Info-vax] New CEO of VMS Software

[Dan Cross]

In article <uncu14$q8b0$2 at dont-email.me>,
Arne Vajhøj  <arne at vajhoej.dk> wrote:
>On 1/6/2024 8:04 PM, Dan Cross wrote:
>> In article <uncrcr$q371$2 at dont-email.me>,
>> Arne Vajhøj  <arne at vajhoej.dk> wrote:
>>> On 1/6/2024 4:22 PM, Single Stage to Orbit wrote:
>>>> On Sat, 2024-01-06 at 02:33 +0000, Lawrence D'Oliveiro wrote:
>>>>> On Fri, 5 Jan 2024 09:23:36 -0500, Arne Vajhøj wrote:
>>>>>> Another example:
>>>>>>
>>>>>> SYS$SETPRV with PRV$M_SYSNAMÂ  followed by SYS$CRELNM with
>>>>>> LNM$_TABLE as
>>>>>> "LNM$SYSTEM_TABLE".
>>>>>>
>>>>>> The API is not that complex. The semantics on VMS is well
>>>>>> documented.
>>>>>>
>>>>>> But the code does not really make any sense on Linux. So what to
>>>>>> do?
>>>>>
>>>>> We can emulate logical names on Linux beyond the per-process ones
>>>>> with a server process and communication via some IPC mechanism. D-Bus
>>>>> or Varlink might be good enough for this.
>>>>
>>>> if setenv() and getenv() were thread-safe it'd be easier to use these.
>>>
>>> I see environment variables being closer to VMS symbols than to
>>> VMS logicals.
>>>
>>> But just closer not identical.
>> 
>> Eh.  Emulation of logical names would likely be done by
>> maintaining and consulting symbol tables in the DCL "shell" (or
>> whatever emulated DCL in this frankenstein "VMS on Linux"
>> monstronsity) for user mode logicals and a symbol table
>> maintained in a region of shared memory owned by some DSO-like
>> shared object for the others.
>> 
>> The idea of using some service that one communicates with via
>> dbus to emulate logical names is absurd.
>
>Direct access to shared memory would be more efficient
>than an IPC to a process. But it also increases the risk
>of data corruption. That is not a problem in VMS because
>the data structures can not be trashed from user mode code,
>but in the frankenstein "VMS on Linux" I don't know.

This could actually be handled relatively straight-forwardly.
If the data were provided in the form of a DSO, then the kernel
could manage the mapping of this region so that it was
read-only; since the kernel is providing the data, it would
catch the page fault on a write, fetch the faulting operation
from the (user) program, and emulate it with appropriate
interlocks to avoid corruption.  I don't know, but I imagine
VSI does already something similar in VMS on x86.

>Note that mode and table are (mostly) independent.
>Logicals can be user, supervisor, exec or kernel mode.
>Logicals reside in process, job, group, system, cluster,
>decwindows or a custom logical table.

Indeed.  This whole nonsense about "VMS on Linux" makes the
extent of the problem even more glaring.

	- Dan C.