[Info-vax] New CEO of VMS Software

[Chris Townley]

On 07/01/2024 01:25, Dan Cross wrote:
> 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.
> 

Even without VMS under linux, I have always wanted a dclsh. Remember 
that wonderful, very limited PCDCL? I wrote scripts with that to do 
things I couldn't do in a PC batch file. In a production environment.
Not that I need it now - I always write scripts in ksh, despite normally 
using bash under linux

-- 
Chris