On 2022-08-15, Dave Froble <davef@tsoft-inc.com> wrote:
>
> Can't everybody just let the itanic boat anchor sink quietly into the mud, never
> to be seen again?
>

It's getting there, but there's still the legacy installed base.
A legacy installed base which has permanent licences BTW, so things
like that are going to factor into various decisions.

BTW, over a couple of days (I think it was a weekend :-)) I had a look
at what would be involved in writing a full-system Itanium emulator.

At the end of those couple of days, I had come to the conclusion that
I would be more likely to succeed with doing something less insane
such as writing a modern web browser by myself. :-)

IOW, writing an Itanium full-system emulator would be a major undertaking.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-08-14, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> Macro-11, VMS Pascal and VMS Basic are a rewrite from scratch
> on Linux. All LIB$ and SYS$ calls would need to be changed
> on Linux no matter the language. Lots of VMS concepts are not 1:1
> portable to Linux including logical names and queue system.
> Rdb is not available on Linux. RMS index-sequential files
> would (except for Cobol) require a third party software solution
> and change of calls to use API of that. No DCL on Linux so all
> script would be rewrite from scratch. VMS to Linux is not easy - not
> impossible either but expensive and risky.
>

There's the third-party porting toolkits that can help with this.

Simon.

PS: BTW Arne, Macro-11 ??? :-)

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

abrsvc schrieb am 15.08.2022 um 01:01:
>
>> A $10K emulator that performs efficiently and fast, would still be
>> cheaper than going with any unnecessary hardware or OS upgrades. I think
>> AlphaVM-Pro VTALpha and Cahron-Alpha have all proven that fact.
>>
>> DT
>
> No to be picky, but the Stromasys product is called Charon/AXP.

in fact, it is called CHARON-AXP :-)

> Dan
>
> (Currently working for Stromasys)

Hans.

(Stromasys partner)

On 8/15/2022 2:19 PM, Simon Clubley wrote:
> On 2022-08-14, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>
>> Macro-11, VMS Pascal and VMS Basic are a rewrite from scratch
>> on Linux. All LIB$ and SYS$ calls would need to be changed
>> on Linux no matter the language. Lots of VMS concepts are not 1:1
>> portable to Linux including logical names and queue system.
>> Rdb is not available on Linux. RMS index-sequential files
>> would (except for Cobol) require a third party software solution
>> and change of calls to use API of that. No DCL on Linux so all
>> script would be rewrite from scratch. VMS to Linux is not easy - not
>> impossible either but expensive and risky.
>
> There's the third-party porting toolkits that can help with this.

Yes. Sector7 etc.. But without diminishing their products I would
not expect a silver bullet.

> PS: BTW Arne, Macro-11 ??? :-)

Ooops.

Macro-32

Arne

On 2022-08-15 20:06, Simon Clubley wrote:
> On 2022-08-13, Johnny Billquist <bqt@softjar.se> wrote:
>> On 2022-08-13 02:21, Stephen Hoffman wrote:
>>> To make some of these cross-mode shenanigans somewhat more supportable,
>>> OpenVMS also implements a P1 window into system space at CTL$GL_PHD,
>>> allowing supervisor code to poke at kernel data. But I digress.
>>
>> That is digressing. Supervisor code is not normal user processes.
>>
>
> On VMS, there is no such thing as a normal user process.

Sorry. But here is where you go into nonsense. I probably should have
avoided the word "process", since the point was normal programs. Any and
every program will at least do calls into kernel mode, if nothing else,
at one or another point in their execution. But that is calls to code
that is not a part of the program. But it's done within the context of a
process. This is normal.

> There is one process that at various times during its lifecycle
> executes a mixture of code running in all four modes (KESU).

The fact that code in those different modes are invoked is irrelevant.
It's not code I wrote or compiled. Makes no difference if it's all in
kernel, or a mix of different modes.
It can all just as well be compressed into one mode as well. Makes no
difference. I know that you constantly is missing that point, and think
you've found security holes where there actually aren't any. Why don't
you actually understand this, and go hunt for other actual bugs and issues?

My program was not written to run in any other mode than user mode, and
that's what a normal program does. Sorry if I used the word "process" in
a way that confused you.

Johnny

On 2022-08-15 19:28, Simon Clubley wrote:
> On 2022-08-12, Johnny Billquist <bqt@softjar.se> wrote:
>> On 2022-08-12 15:10, Simon Clubley wrote:
>>> In addition, VMS has a major problem that simply doesn't exist in Linux
>>> and that is whereas the vast majority of interaction between a Linux
>>> userland binary and Linux itself is via a nice well-defined syscall
>>> interface, VMS binaries have a nasty habit of looking at data cells
>>> which exist directly in the VMS process's address space.
>>>
>>> Such data cell access would have to be recognised and emulated in such
>>> a userland level emulator.
>>
>> I find that claim incredibly hard to believe. Can you give some examples
>> of this? Because even RSX, which is just a primitive predecessor of VMS
>> do not have such behavior. Everything in the kernel is completely hidden
>> and out of scope for a process, and the only way to do or get to
>> anything is through system calls. And that is generally true of almost
>> any reasonable multiuser, timesharing, memory protected operating system.
>>
>
> As you now know Johnny, you were (once again) very very wrong to try
> and compare the two. :-)

There is so much more that is common between RSX and VMS, than there are
things different between them. Not sure if you know that, but anyway.
Way more than between VMS and any Unix, for instance.

> BTW, the fact you immediately switched to talking about kernel mode,
> makes me wonder if you are even aware of P1 space in a VMS process.

Yes, I'm very aware of P1 space.

>> There is absolutely nothing Unix/Linux specific about this.
>>
>
> Oh yes there is.

No there isn't. Most operating systems have a clean separation between
user code and the kernel. Including all PDP-11 OSes. It turned out that
VMS does not, which rather makes VMS the exception here, not Unix.

> Unix/Linux sets up a new process to run an image and then deletes
> it immediately afterwards and has no such thing as P1 space.

Yes.
Well, technically, P1 space is an artifact of the hardware, and as such,
P1 space exists also for Unix systems running on VAX, and possibly also
Alpha.

VMS just keeps P1 space around a bit more disconnected from the program
you might be executing.

> A normal VMS session only ever has one process that is reused over
> and over again to run programs (unless you choose to start a subprocess
> for some reason.)

Well, not really true. Every time you start a program, it gets a new
process ID, with new resources allocated in the kernel for it. Just that
P1 space is retained between them, unless I remember wrong.

Johnny

On 2022-08-15 19:47, Simon Clubley wrote:
> On 2022-08-13, Johnny Billquist <bqt@softjar.se> wrote:
>> By the way, since people asked about IA64 emulators, and the general
>> belief that they don't exist and are too difficult to do.
>>
>> They do exist, and have for a long time. It's not that complex from this
>> point of view, but of course, performance is probably nowhere near where
>> anyone would actually want to use it for production.
>>
>> See: http://www.irisa.fr/caps/projects/ArchiCompil/iato/
>>
>> Last updated in 2004. But that is how they developed all the tooling and
>> so on before they had actual hardware.
>>
>
> I've just had a quick look at this. This emulator is no good for VMS.

Never claimed it was. My point was that emulators for IA64 do exist, and
are not impossible or unobtanium, as some people suggested.

Obviously that project was not interested in VMS. Does not mean it
couldn't be done. IA64 isn't that hard to emulate, as such. But again -
performance is another question.

Johnny

On 8/15/2022 7:40 PM, Johnny Billquist wrote:
> On 2022-08-15 19:28, Simon Clubley wrote:
>> A normal VMS session only ever has one process that is reused over
>> and over again to run programs (unless you choose to start a subprocess
>> for some reason.)
>
> Well, not really true. Every time you start a program, it gets a new
> process ID, with new resources allocated in the kernel for it. Just that
> P1 space is retained between them, unless I remember wrong.

Same process with same process id.

I would say that P0 space is not retained. But there is no
difference in substance between P0 not retained (implicit
P1 retained) and P1 retained (implicit P0 not retained).

Arne

On 8/15/2022 7:40 PM, Johnny Billquist wrote:
> On 2022-08-15 19:28, Simon Clubley wrote:
>> Unix/Linux sets up a new process to run an image and then deletes
>> it immediately afterwards and has no such thing as P1 space.
>
> Yes.
> Well, technically, P1 space is an artifact of the hardware, and as such,
> P1 space exists also for Unix systems running on VAX, and possibly also
> Alpha.
>
> VMS just keeps P1 space around a bit more disconnected from the program
> you might be executing.

The big difference is that DCL is living in P1 space (stack space)
while a Unix shell is living in heap space (P0 space on a VAX).

Arne

On Thursday, August 11, 2022 at 3:48:21 PM UTC-7, David Turner wrote:
> Does anyone here think that this is an option for people not willing or
> able to move over to x86-64 yet?
> An HP Integrity emulator, emulating something like an rx2800 i2 i4 or i6
> (16 cores max)
>
> I could imagine it would be useful if stuck with HP-UX or OpenVMS for
> Integrity for some reason?!?
>
> Why am I asking? Well, HPE Integrity servers are getting scarce. I have
> probably purchased 80% of the ones on the market and some companies are
> buying up whatever is available
>
>
> Comments please.
>
>
> David Turner

HPE has an Integrity emulator for running HP-UX - it's called Portable HP-UX and runs on Linux; you can request access if you have an active contract. I suspect running VMS was not of particular interest to them during development, though.

On 2022-08-16 01:53, Arne Vajhøj wrote:
> On 8/15/2022 7:40 PM, Johnny Billquist wrote:
>> On 2022-08-15 19:28, Simon Clubley wrote:
>>> Unix/Linux sets up a new process to run an image and then deletes
>>> it immediately afterwards and has no such thing as P1 space.
>>
>> Yes.
>> Well, technically, P1 space is an artifact of the hardware, and as
>> such, P1 space exists also for Unix systems running on VAX, and
>> possibly also Alpha.
>>
>> VMS just keeps P1 space around a bit more disconnected from the
>> program you might be executing.
>
> The big difference is that DCL is living in P1 space (stack space)
> while a Unix shell is living in heap space (P0 space on a VAX).

Well. P0 isn't just heap. P0 is basically all memory that you want to
look at as either static or growing upward. So heap is one part, but
plain executable code is also in P0. P1 is static stuff as well, and
data growing downward, like a stack for example.

So yes, DCL sits in P1, while Unix shells sits in P0 *and* P1, just as
any other binary. The Unix shell hangs around because you normally fork
and then execute something else in place, while DCL hangs around by
sitting P1 which is not as process local in VMS as it is in Unix.

Johnny

On 2022-08-15, Johnny Billquist <bqt@softjar.se> wrote:
> On 2022-08-15 19:28, Simon Clubley wrote:
>> Unix/Linux sets up a new process to run an image and then deletes
>> it immediately afterwards and has no such thing as P1 space.
>
> Yes.
> Well, technically, P1 space is an artifact of the hardware, and as such,
> P1 space exists also for Unix systems running on VAX, and possibly also
> Alpha.
>
> VMS just keeps P1 space around a bit more disconnected from the program
> you might be executing.
>

It's what VMS does with that address space that makes it so different
from other operating systems.

>> A normal VMS session only ever has one process that is reused over
>> and over again to run programs (unless you choose to start a subprocess
>> for some reason.)
>
> Well, not really true. Every time you start a program, it gets a new
> process ID, with new resources allocated in the kernel for it. Just that
> P1 space is retained between them, unless I remember wrong.
>

That is completely and totally utterly wrong. However, if you really
believe that (instead of you just doing a David by trolling by making
false statements :-)) it also explains your confusion because VMS works
so differently to what you are clearly used to.

The PID does _not_ belong to the program. It belongs to the process itself.
At many times during the lifecycle of a typical VMS process, there will not
even _be_ a user-mode program loaded into the process P0 address space.

In Linux, there is no such thing as an executing process without a
user-mode program, regardless of whether that user-mode program is
a shell, a user's application program, or something else. Also, every
time the shell runs a new program, the program is run in a new and
different process.

OTOH, in VMS, having a process you can interact with, but without
having any user-mode P0 program loaded, is a perfectly normal thing.

When you ask DCL to run a program, _it_ maps the requested program
into the P0 address space, sets it up, and then calls it to start
execution of the user program.

When the user program exits, the user-mode pages used by that program,
but _only_ those user-mode pages, are removed from the process address
space, and control returns to DCL to await your next command.

There is no "new process ID, with new resources allocated in the kernel
for it". It's the same physical process that gets used over and over
again during the user's session to run different user-mode programs.

Running a user program on VMS from DCL is much more like DCL doing
a dlopen() on the user program into P0 space and then doing a call
to it, instead of the Linux/Unix approach of creating a whole new
fresh process for each program the shell wants to run.

_Now_ do you understand why I am describing the VMS approach in the
way I am ?

For the record, I prefer the Unix approach, but I am trying to make
you understand how the VMS approach actually works, not how you think
it works.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-08-15, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 8/15/2022 7:40 PM, Johnny Billquist wrote:
>> On 2022-08-15 19:28, Simon Clubley wrote:
>>> Unix/Linux sets up a new process to run an image and then deletes
>>> it immediately afterwards and has no such thing as P1 space.
>>
>> Yes.
>> Well, technically, P1 space is an artifact of the hardware, and as such,
>> P1 space exists also for Unix systems running on VAX, and possibly also
>> Alpha.
>>
>> VMS just keeps P1 space around a bit more disconnected from the program
>> you might be executing.
>
> The big difference is that DCL is living in P1 space (stack space)
> while a Unix shell is living in heap space (P0 space on a VAX).
>

Actually, the _major_ difference is that on VMS, they are in the same
process. In Unix land, they are in different processes.

Also, the other major difference is that parts of P1 space are
directly accessible by a user-mode VMS program, so to get back to the
topic, such access would have to be detected and emulated in any
user-mode binaries level emulator (as opposed to a full-system emulator).

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-08-15, Johnny Billquist <bqt@softjar.se> wrote:
> On 2022-08-15 19:47, Simon Clubley wrote:
>>
>> I've just had a quick look at this. This emulator is no good for VMS.
>
> Never claimed it was. My point was that emulators for IA64 do exist, and
> are not impossible or unobtanium, as some people suggested.
>

I know you didn't, but it was still worth me looking at it, to see if
it could be something useful. Unfortunately, that does not appear to
be the case, as it doesn't offer anything over what Ski already does,
and Ski would be only a small part of any required full-system emulator.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-08-15, Sunset Ash <hpeintegrity@gmail.com> wrote:
>
> HPE has an Integrity emulator for running HP-UX - it's called Portable HP-UX and runs on Linux; you can request access if you have an active contract. I suspect running VMS was not of particular interest to them during development, though.

This:

https://downloads.linux.hpe.com/SDR/project/c-ux-beta/

appears to be the download page for anyone interested in it.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

In article <tdgm1h$45ik$2@dont-email.me>,
clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:

> Actually, the _major_ difference is that on VMS, they are in the
> same process. In Unix land, they are in different processes.

It is a quirk of UNIX-style OSes that process creation is extremely cheap,
and is thus used for all kinds of things. Most other OSes, including VMS
and its mutant child Windows NT, take rather longer to create processes.

John

On 8/16/22 15:25, John Dallman wrote:
> In article <tdgm1h$45ik$2@dont-email.me>,
> clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:
>
>> Actually, the _major_ difference is that on VMS, they are in the
>> same process. In Unix land, they are in different processes.
>
> It is a quirk of UNIX-style OSes that process creation is extremely cheap,
> and is thus used for all kinds of things. Most other OSes, including VMS
> and its mutant child Windows NT, take rather longer to create processes.

Quirk? :-)

bill

On 8/16/22 1:08 PM, Simon Clubley wrote:
> On 2022-08-15, Sunset Ash <hpeintegrity@gmail.com> wrote:
>>

>> HPE has an Integrity emulator for running HP-UX - it's called
>> Portable HP-UX and runs on Linux; you can request access if you have an
>> active contract. I suspect running VMS was not of particular interest to
>> them during development, though.
>
> This:
>
> https://downloads.linux.hpe.com/SDR/project/c-ux-beta/
>
> appears to be the download page for anyone interested in it.

It claims to be a full-system emulator that uses JIT for some
instructions. The release posted there is a beta release from May 2019
that only supports HP-UX. Whether it actually works or is still under
active development? Your guess is as good as mine.

On 8/16/2022 2:01 PM, Simon Clubley wrote:
> On 2022-08-15, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 8/15/2022 7:40 PM, Johnny Billquist wrote:
>>> On 2022-08-15 19:28, Simon Clubley wrote:
>>>> Unix/Linux sets up a new process to run an image and then deletes
>>>> it immediately afterwards and has no such thing as P1 space.
>>>
>>> Yes.
>>> Well, technically, P1 space is an artifact of the hardware, and as such,
>>> P1 space exists also for Unix systems running on VAX, and possibly also
>>> Alpha.
>>>
>>> VMS just keeps P1 space around a bit more disconnected from the program
>>> you might be executing.
>>
>> The big difference is that DCL is living in P1 space (stack space)
>> while a Unix shell is living in heap space (P0 space on a VAX).
>
> Actually, the _major_ difference is that on VMS, they are in the same
> process. In Unix land, they are in different processes.

(they being shell and programs)

That is the same thing. It is possible because DCL is in P1.

Arne

On 2022-08-16 19:54, Simon Clubley wrote:
> On 2022-08-15, Johnny Billquist <bqt@softjar.se> wrote:
>> On 2022-08-15 19:28, Simon Clubley wrote:
>>> Unix/Linux sets up a new process to run an image and then deletes
>>> it immediately afterwards and has no such thing as P1 space.
>>
>> Yes.
>> Well, technically, P1 space is an artifact of the hardware, and as such,
>> P1 space exists also for Unix systems running on VAX, and possibly also
>> Alpha.
>>
>> VMS just keeps P1 space around a bit more disconnected from the program
>> you might be executing.
>>
>
> It's what VMS does with that address space that makes it so different
> from other operating systems.

It's certainly been a long time since I looked inside VMS. Which I get
called out on every time I make some mistake/assumption/remember things
wrong. Embarassing each time...

>>> A normal VMS session only ever has one process that is reused over
>>> and over again to run programs (unless you choose to start a subprocess
>>> for some reason.)
>>
>> Well, not really true. Every time you start a program, it gets a new
>> process ID, with new resources allocated in the kernel for it. Just that
>> P1 space is retained between them, unless I remember wrong.
>>
>
> That is completely and totally utterly wrong. However, if you really
> believe that (instead of you just doing a David by trolling by making
> false statements :-)) it also explains your confusion because VMS works
> so differently to what you are clearly used to.

No. I did believe that. I had some recollection that the PIDs were
allocated each time a program was started. Partly (again) coming from
RSX. Structures like PCB, TCB, task headers and so on are setup when a
program is started, and thus every time a program starts, you have a new
context in this sense.
But this is also a place where RSX and VMS differs the most, since in
RSX, the "shell" is in a sense even weirder than VMS, or any other OS I
know of.

But the end result is that every time a program is started, it has it's
own process id. That DCL under VMS actually will be starting everything
as a part of its own process is really weird, and it makes me also
wonder how things like spawning another program from a program under VMS
works, since it would need to create a new DCL instance then. On the
other hand, I now recollect that VMS don't have spawn as a system call
like RSX do.

But that certainly explains why creating a new process under VMS is even
heaver.

So yeah, I certainly seem to have been totally lost on this detail.

> The PID does _not_ belong to the program. It belongs to the process itself.

That was something I thought I remembered being different.

> At many times during the lifecycle of a typical VMS process, there will not
> even _be_ a user-mode program loaded into the process P0 address space.

That on the other hand isn't any strange to me, and does not necessarily
follow, or lead to the topics of the PID itself.

> In Linux, there is no such thing as an executing process without a
> user-mode program, regardless of whether that user-mode program is
> a shell, a user's application program, or something else. Also, every
> time the shell runs a new program, the program is run in a new and
> different process.

Yes.

> OTOH, in VMS, having a process you can interact with, but without
> having any user-mode P0 program loaded, is a perfectly normal thing.

Yes.

> When you ask DCL to run a program, _it_ maps the requested program
> into the P0 address space, sets it up, and then calls it to start
> execution of the user program.

But you say that not only that - it also uses the context of DCL. So
that from an accounting point of view, it's still the same process. What
about process quotas like runtime limits? Do DCL reset these, and DCL
itself is excluded from such? And accounting. When a program runs and is
finished, you get accounting information on how much cpu time was used,
memory, and all kind of stuff. Is DCL then doing that accounting
processing, and not the kernel? A process calling something like exit
will not terminate the process, but just jump back to DCL?

> When the user program exits, the user-mode pages used by that program,
> but _only_ those user-mode pages, are removed from the process address
> space, and control returns to DCL to await your next command.

Does DCL do that, or the kernel?

> There is no "new process ID, with new resources allocated in the kernel
> for it". It's the same physical process that gets used over and over
> again during the user's session to run different user-mode programs.

That was something I had forgotten/misunderstood/never realized.

> Running a user program on VMS from DCL is much more like DCL doing
> a dlopen() on the user program into P0 space and then doing a call
> to it, instead of the Linux/Unix approach of creating a whole new
> fresh process for each program the shell wants to run.

I can understand that bit. But I then wonder about the whole winding
down of the running of the program, as commented above.

> _Now_ do you understand why I am describing the VMS approach in the
> way I am ?

In part, yes. I still do not consider DCL to be part of userspace, user
programs or anything like that. It's an OS component, and have rights
and privileges which means it can do anything really. Your ranting about
security issues around that topic is still nonsense to me. But VMS is
certainly doing things a bit odd in some ways that I think are unwise here.

> For the record, I prefer the Unix approach, but I am trying to make
> you understand how the VMS approach actually works, not how you think
> it works.

And as I observed, this is hardly Unix specific. The fact that VMS do
things odd is just a bit more surprising to me, since I know how RSX
works, upon which so much of VMS is based, but this is one place where
RSX works more like Unix. So how VMS diverged there is an interesting
topic in my head.
(Not that RSX actually is like Unix, RSX is actually sortof different in
another way, but in the perspective of how VMS works, RSX isn't close here.)

Johnny

Johnny Billquist <bqt@softjar.se> writes:

> No. I did believe that. I had some recollection that the PIDs were
> allocated each time a program was started. Partly (again) coming from
> RSX. Structures like PCB, TCB, task headers and so on are setup when a
> program is started, and thus every time a program starts, you have a new
> context in this sense.
> But this is also a place where RSX and VMS differs the most, since in
> RSX, the "shell" is in a sense even weirder than VMS, or any other OS I
> know of.

Interestingly, RSX does things the way TOPS-20 (< TENEX) does them, while VMS
does them very much like the way Tops-10 does them! I would never have guessed
that.

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

On 2022-08-17, Johnny Billquist <bqt@softjar.se> wrote:
> On 2022-08-16 19:54, Simon Clubley wrote:
>>
>> That is completely and totally utterly wrong. However, if you really
>> believe that (instead of you just doing a David by trolling by making
>> false statements :-)) it also explains your confusion because VMS works
>> so differently to what you are clearly used to.
>
> No. I did believe that. I had some recollection that the PIDs were
> allocated each time a program was started. Partly (again) coming from
> RSX. Structures like PCB, TCB, task headers and so on are setup when a
> program is started, and thus every time a program starts, you have a new
> context in this sense.
> But this is also a place where RSX and VMS differs the most, since in
> RSX, the "shell" is in a sense even weirder than VMS, or any other OS I
> know of.
>
> But the end result is that every time a program is started, it has it's
> own process id. That DCL under VMS actually will be starting everything
> as a part of its own process is really weird, and it makes me also
> wonder how things like spawning another program from a program under VMS
> works, since it would need to create a new DCL instance then. On the
> other hand, I now recollect that VMS don't have spawn as a system call
> like RSX do.
>

VMS has LIB$SPAWN(), which is a library wrapper around the lower-level
system services. It also has a "$ spawn" DCL command.

This allows you to either 1) run something in a subprocess while you
carry on in the main process or 2) wait for the subprocess to complete
(depending on the options you use).

This most certainly is _NOT_ the way you normally run a program on VMS
however. :-)

For example, all user programs listed in the DCL command table run in
the same process as the DCL instance that loads and executes them.

>> When you ask DCL to run a program, _it_ maps the requested program
>> into the P0 address space, sets it up, and then calls it to start
>> execution of the user program.
>
> But you say that not only that - it also uses the context of DCL. So
> that from an accounting point of view, it's still the same process. What
> about process quotas like runtime limits? Do DCL reset these, and DCL
> itself is excluded from such? And accounting. When a program runs and is
> finished, you get accounting information on how much cpu time was used,
> memory, and all kind of stuff. Is DCL then doing that accounting
> processing, and not the kernel? A process calling something like exit
> will not terminate the process, but just jump back to DCL?
>

The quotas are against the process, not the program. When you try to
run a program that doesn't fit into those quotas, the account or system
quotas need adjusting to give the _process_ (not the program) more quota.

Accounting is the same, unless there are some exceptions I don't know about.
Try hitting Ctrl-T repeatedly while at the DCL prompt and watch the I/O
count increase.

A user-mode exit() in a program run from DCL never terminates the process.
The user-mode program exits and control is returned to DCL.

>> When the user program exits, the user-mode pages used by that program,
>> but _only_ those user-mode pages, are removed from the process address
>> space, and control returns to DCL to await your next command.
>
> Does DCL do that, or the kernel?
>

Both. There are system services, but they are called under the control
of DCL. What I can't remember is if they need to be called manually
from DCL code as part of the cleanup or if they are run automatically
as part of some exit handler previously established by DCL. (It's been
a while since I've been in that part of the I&DS manual :-)).

(IIRC, sys$rundwn() is called with a user-mode flag to cause the user-mode
part of the process to be run down. Everyone feel free to correct me if
I am wrong about that. :-))

>> _Now_ do you understand why I am describing the VMS approach in the
>> way I am ?
>
> In part, yes. I still do not consider DCL to be part of userspace, user
> programs or anything like that. It's an OS component, and have rights
> and privileges which means it can do anything really. Your ranting about
> security issues around that topic is still nonsense to me. But VMS is
> certainly doing things a bit odd in some ways that I think are unwise here.
>

It's only nonsense until you realise that, unlike on Linux, DCL has access
to the privileges of the programs it runs.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-08-17 21:02, Simon Clubley wrote:
> On 2022-08-17, Johnny Billquist <bqt@softjar.se> wrote:
>> On 2022-08-16 19:54, Simon Clubley wrote:
>>>
>>> That is completely and totally utterly wrong. However, if you really
>>> believe that (instead of you just doing a David by trolling by making
>>> false statements :-)) it also explains your confusion because VMS works
>>> so differently to what you are clearly used to.
>>
>> No. I did believe that. I had some recollection that the PIDs were
>> allocated each time a program was started. Partly (again) coming from
>> RSX. Structures like PCB, TCB, task headers and so on are setup when a
>> program is started, and thus every time a program starts, you have a new
>> context in this sense.
>> But this is also a place where RSX and VMS differs the most, since in
>> RSX, the "shell" is in a sense even weirder than VMS, or any other OS I
>> know of.
>>
>> But the end result is that every time a program is started, it has it's
>> own process id. That DCL under VMS actually will be starting everything
>> as a part of its own process is really weird, and it makes me also
>> wonder how things like spawning another program from a program under VMS
>> works, since it would need to create a new DCL instance then. On the
>> other hand, I now recollect that VMS don't have spawn as a system call
>> like RSX do.
>>
>
> VMS has LIB$SPAWN(), which is a library wrapper around the lower-level
> system services. It also has a "$ spawn" DCL command.
>
> This allows you to either 1) run something in a subprocess while you
> carry on in the main process or 2) wait for the subprocess to complete
> (depending on the options you use).

Under RSX, SPWN$ is the system call. And it creates a new process, which
is also associated with a terminal, and a UIC, which is given as
arguments to SPWN$. The new process have it's own virtual memory, in
which the task image is loaded, all shared libraries are setup with
regards to memory mapping, and all that kind of stuff. SPWN$ is sortof
like a combo of fork() and exec() under Unix.

Which obviously is rather different than what VMS does then.

> This most certainly is _NOT_ the way you normally run a program on VMS
> however. :-)
>
> For example, all user programs listed in the DCL command table run in
> the same process as the DCL instance that loads and executes them.

That is no surprise and not so different from lots of systems. Heck,
even in Unix shells, and bunch of stuff are actually built into the
shell itself, and when you give the command, it's all done within the
shell process itself. Some commands are even *required* to be run within
the shell itself, and it would not work to run them as separate programs.

>>> When you ask DCL to run a program, _it_ maps the requested program
>>> into the P0 address space, sets it up, and then calls it to start
>>> execution of the user program.
>>
>> But you say that not only that - it also uses the context of DCL. So
>> that from an accounting point of view, it's still the same process. What
>> about process quotas like runtime limits? Do DCL reset these, and DCL
>> itself is excluded from such? And accounting. When a program runs and is
>> finished, you get accounting information on how much cpu time was used,
>> memory, and all kind of stuff. Is DCL then doing that accounting
>> processing, and not the kernel? A process calling something like exit
>> will not terminate the process, but just jump back to DCL?
>>
>
> The quotas are against the process, not the program. When you try to
> run a program that doesn't fit into those quotas, the account or system
> quotas need adjusting to give the _process_ (not the program) more quota.

Um. Sure, I can see that for things like memory limits. But if we talk
about CPU runtime limits, it's usually meant for that specific program
you run. Or are you saying that VMS can't have a runtime limit?
(runtime, like in, you're not allowed to use more than 2 CPU seconds,
and when you hit that, you'll be killed.)

> Accounting is the same, unless there are some exceptions I don't know about.
> Try hitting Ctrl-T repeatedly while at the DCL prompt and watch the I/O
> count increase.

Well. No surprise about that. The whole login session does have such
counting, since that's what accounting wants to have, in order to
(potentially) charge users with used resources.
But accounting usually can also report how much CPU time, I/O, memory
and so on individual programs used. I was pretty sure VMS could report
that as well, which would be something logged as soon as a program
finishes. But since this is all done within the DCL context, it means
the process is not finished. So how does this happen, or can VMS not
have accounting that gives this kind of information?
(Yes, it's been a bloody long time since I was admining VMS systems...)

> A user-mode exit() in a program run from DCL never terminates the process.
> The user-mode program exits and control is returned to DCL.

So things jumps back to DCL at that point. So exit() would not terminate
the process at all.

>>> _Now_ do you understand why I am describing the VMS approach in the
>>> way I am ?
>>
>> In part, yes. I still do not consider DCL to be part of userspace, user
>> programs or anything like that. It's an OS component, and have rights
>> and privileges which means it can do anything really. Your ranting about
>> security issues around that topic is still nonsense to me. But VMS is
>> certainly doing things a bit odd in some ways that I think are unwise here.
>>
>
> It's only nonsense until you realise that, unlike on Linux, DCL has access
> to the privileges of the programs it runs.

DCL runs as a part of the kernel. It has the potential to have any
privilege it wants, if it was malicious. User privileges are pretty
irrelevant and uninteresting. And yes, bugs in DCL can be rather serious
because of the rights and abilities it has.
This is where you seem to miss the point. DCL is already at a point
where, if it wanted, it could do anything. Which is why users cannot
write their own replacements for DCL and run them, without having
serious privileges.
And partly also why there are almost no alternatives to DCL. It's a bit
of a mess, and pretty tricky to write another CLI for VMS.
MCR did exist at one point, and might still, but I'm not sure I ever saw
anything else.

Johnny

On 8/18/22 15:43, Johnny Billquist wrote:
>
> And partly also why there are almost no alternatives to DCL. It's a bit
> of a mess, and pretty tricky to write another CLI for VMS.
> MCR did exist at one point, and might still, but I'm not sure I ever saw
> anything else.

Actually, there was. When they came out with the first POSIX subsystem
(I really don't know what else to call it) it came with a version of the
Bourne Shell that could be installed on a per user basis as the login
CLI instead of DCL. I know I did it but only for testing. I don't
remember how it was done. Something set up with SYSUAF, I think.
None of my users ever asked for it and even being primarily a Unix user
I preferred DCL on VMS.

bill

On Thursday, August 18, 2022 at 4:48:06 PM UTC-4, Bill Gunshannon wrote:
> On 8/18/22 15:43, Johnny Billquist wrote:
> >
> > And partly also why there are almost no alternatives to DCL. It's a bit
> > of a mess, and pretty tricky to write another CLI for VMS.
> > MCR did exist at one point, and might still, but I'm not sure I ever saw
> > anything else.
> Actually, there was. When they came out with the first POSIX subsystem
> (I really don't know what else to call it) it came with a version of the
> Bourne Shell that could be installed on a per user basis as the login
> CLI instead of DCL. I know I did it but only for testing. I don't
> remember how it was done. Something set up with SYSUAF, I think.
> None of my users ever asked for it and even being primarily a Unix user
> I preferred DCL on VMS.
>
> bill
Also, Cerner had their clinical application that was a replacement for DCL. At the time, it was the only CLI replacement application known.

Dan