Den 2022-08-18 kl. 21:43, skrev Johnny Billquist:

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

Process quotas are *process* quotas. Doesn't matter if you run 1 or 10 EXEs
in that process.

Don't mixup process quotas with the accounting features.

> I was pretty sure VMS could report that as
> well, which would be something logged as soon as a program finishes.

Yes, you can enable that. But that is an *accounting* feature,
not some quota for the process. The resources used by the EXE
are still accumulated against the *process* quotas.

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

It depends.
If the EXE runs in an DCL context, the process will return to DCL.
If the EXE runs without an DCL context, exit from the EXE terminates the
process.

It depends on how the process was created.

If you just do a RUN /DETACH on the target EXE itself, there is no DCL
environment. Exit of the EXE terminates the process.

If you RUN /DETACH the image named LOGINOUT.EXE and give it a COM
file as the /input parameter, you will have an DCL environment and
you can do whatever you like in the COM file. Exit from the/an EXE
just return to DCL and the COM file.

On 8/18/2022 4:48 PM, 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.

SYSUAF> MOD username /CLI=xxxxxx

It could also be done for session when logging in by user:

Login: username/CLI=xxxxxx

Arne

On 8/18/22 19:21, Arne Vajhøj wrote:
> On 8/18/2022 4:48 PM, 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.
>
> SYSUAF> MOD username /CLI=xxxxxx
>
> It could also be done for session when logging in by user:
>
> Login: username/CLI=xxxxxx
>

Thank you. That jogged my memory.

bill

On 2022-08-18, Johnny Billquist <bqt@softjar.se> wrote:
> On 2022-08-17 21:02, Simon Clubley wrote:
>>
>> 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.
>

No. To this point in the process lifecycle, a spawn on VMS ends up doing
the same as you describe above with RSX in that you do end up with another
process with its own PID.

It's just that after this, a subprocess behaves in the same way as in the
main process, in that the DCL instance running in the subprocess starts
any user programs in the same subprocess just as DCL running in the main
process starts any user programs in the same main process.

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

In VMS, CPU runtime limits are documented as being against the process,
although I've never used them. For example:

SUBMIT

/CPUTIME

/CPUTIME=time

Defines a CPU time limit for the batch job. You can specify time
as delta time, 0, INFINITE, or NONE. If the queue on which the
job executes has a defined CPUMAXIMUM value, the smaller of
the SUBMIT command and queue values is used. If the queue on
which the job executes does not have a specified maximum CPU time
limit, the smaller of the SUBMIT command and user authorization
file (UAF) values is used. If the queue on which the job executes
does not have a specified maximum CPU time limit and the UAF has
a specified CPU time limit of NONE, either the value 0 or the
keyword INFINITE allows unlimited CPU time. If you specify the
keyword NONE, the specified queue or UAF value is used. CPU time
values must be greater than or equal to the number specified by
the system parameter PQL_MCPULM.

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

Jan-Erik pointed out one thing I had forgotten about and that was the
optional image-level accounting in addition to the overall process-level
accounting. You still get the normal process-level accounting on top of
the image-level accounting if you use that option however.

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

Actually, no I am not. The point I am making is that a DCL which behaves
in this way increases the available attack surface, compared to more
secure options such as how Unix shells work.

Simon.

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

On 8/18/22 19:21, Arne Vajhøj wrote:
> On 8/18/2022 4:48 PM, 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.
>
> SYSUAF> MOD username /CLI=xxxxxx
>
> It could also be done for session when logging in by user:
>
> Login: username/CLI=xxxxxx
>

This was kind of like Software Tools for Pr1mos or Cygwin for Windows. It
was just enough like Unix to seem familiar, but not enough like Unix to
actually be familiar. It was just enough different to be frustrating...
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

Den 2022-08-19 kl. 14:24, skrev Simon Clubley:

> Jan-Erik pointed out one thing I had forgotten about and that was the
> optional image-level accounting in addition to the overall process-level
> accounting.

Well, both PROCESS and IMAGE are possible to enable or disable.

So you *can* have image accounting *without* process accounting... :-)

On 8/19/22 09:02, Scott Dorsey wrote:
> On 8/18/22 19:21, Arne Vajhøj wrote:
>> On 8/18/2022 4:48 PM, 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.
>>
>> SYSUAF> MOD username /CLI=xxxxxx
>>
>> It could also be done for session when logging in by user:
>>
>> Login: username/CLI=xxxxxx
>>
>
> This was kind of like Software Tools for Pr1mos or Cygwin for Windows. It
> was just enough like Unix to seem familiar, but not enough like Unix to
> actually be familiar. It was just enough different to be frustrating...

Are you talking about the CLI or the POSIX Subsystem? The POSIX
Subsystem was very much like the Softwware Tools Virtual Operating
System (not to be confused with the Kernighan & Plauger Software
Tools which was a handful of utilities but no API). But the ability
to run the Bourne Shell (or any other alternate CLI) is something
much different. It could not be done on Pr1mos and I don't believe
it can be done on Windows. An alternate shell can only be run as
a sub-process to the normal OS CLI. And that can be done on most
any OS, really. STVOS ran on a lot of different systems (including
all the DEC OSes) but I was never aware of a way to make the shell
an alternate CLI like you could do with VMS and the POSIX Subsystem.

And I have long said that the whole POSIX concept was nothing more
than STVOS revived and warmed over. Imagine what POSIX could have
been if the development of the STVOS had continued from its origin
until the present instead of lying fallow for decades only to be
tried again starting from scratch.

On another side note, I wonder if being able to run a Unix like
shell as a CLI would help with using the install scripts under
GNV?

bill

Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>>
>> This was kind of like Software Tools for Pr1mos or Cygwin for Windows. It
>> was just enough like Unix to seem familiar, but not enough like Unix to
>> actually be familiar. It was just enough different to be frustrating...
>
>Are you talking about the CLI or the POSIX Subsystem? The POSIX
>Subsystem was very much like the Softwware Tools Virtual Operating
>System (not to be confused with the Kernighan & Plauger Software
>Tools which was a handful of utilities but no API). But the ability
>to run the Bourne Shell (or any other alternate CLI) is something
>much different. It could not be done on Pr1mos and I don't believe
>it can be done on Windows. An alternate shell can only be run as
>a sub-process to the normal OS CLI. And that can be done on most
>any OS, really. STVOS ran on a lot of different systems (including
>all the DEC OSes) but I was never aware of a way to make the shell
>an alternate CLI like you could do with VMS and the POSIX Subsystem.

SWT on Primos gave you a shell that was kind of like the Bourne Shell
until you tried to do something useful with it and then it turned out
it wasn't exactly like it. It had pipes and redirection but they didn't
quite work the way they did under Unix with easy forks.

>And I have long said that the whole POSIX concept was nothing more
>than STVOS revived and warmed over. Imagine what POSIX could have
>been if the development of the STVOS had continued from its origin
>until the present instead of lying fallow for decades only to be
>tried again starting from scratch.

Posix shells and compatibility libraries exist on various operating systems
and exist only to allow them to bid for specific government contracts. In
many cases they pass the compatibility test suites without actually working
in any useful way.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 2022-08-19 00:10, Jan-Erik Söderholm wrote:
> Den 2022-08-18 kl. 21:43, skrev Johnny Billquist:
>
>> 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.)
>>
>
> Process quotas are *process* quotas. Doesn't matter if you run 1 or 10
> EXEs in that process.
>
> Don't mixup process quotas with the accounting features.

It's more being lazy. I was hoping people would understand the concepts
here without having to write every detail in some very specific form.

>> I was pretty sure VMS could report that as well, which would be
>> something logged as soon as a program finishes.
>
> Yes, you can enable that. But that is an *accounting* feature,
> not some quota for the process. The resources used by the EXE
> are still accumulated against the *process* quotas.

Well. CPU usage limit would be something you would expect to be applied
to the program you run, and not to your session as a whole. But I'm
starting to get the feeling that VMS can't do this then.

And if a program finishes, but it just means you get back to DCL, then
I'm still wondering how the accounting is done, since the process is
still there, the kernel don't have as much clue about what happened.

>> So things jumps back to DCL at that point. So exit() would not
>> terminate the process at all.
>
> It depends.
> If the EXE runs in an DCL context, the process will return to DCL.
> If the EXE runs without an DCL context, exit from the EXE terminates the
> process.
>
> It depends on how the process was created.
>
> If you just do a RUN /DETACH on the target EXE itself, there is no DCL
> environment. Exit of the EXE terminates the process.
>
> If you RUN /DETACH the image named LOGINOUT.EXE and give it a COM
> file as the /input parameter, you will have an DCL environment and
> you can do whatever you like in the COM file. Exit from the/an EXE
> just return to DCL and the COM file.

But how is this done from a technical point of view? There is a huge
difference between the kernel getting a call/signal/whatever that the
process should die, and the kernel removes all associated resources, and
a return being done to DCL, from where the program was called.

Or is a program terminating always going into the kernel, and the kernel
then notices that there is a CLI associated here, and it then moves the
execution back to the CLI with some additional information that the
program terminated?

Johnny

On 2022-08-19 14:24, Simon Clubley wrote:
> On 2022-08-18, Johnny Billquist <bqt@softjar.se> wrote:
>> On 2022-08-17 21:02, Simon Clubley wrote:
>>>
>>> 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.
>>
>
> No. To this point in the process lifecycle, a spawn on VMS ends up doing
> the same as you describe above with RSX in that you do end up with another
> process with its own PID.
>
> It's just that after this, a subprocess behaves in the same way as in the
> main process, in that the DCL instance running in the subprocess starts
> any user programs in the same subprocess just as DCL running in the main
> process starts any user programs in the same main process.

Meaning there is always DCL? That seems to contradict what Jan-Erik said.

>>> 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.)
>>
>
> In VMS, CPU runtime limits are documented as being against the process,
> although I've never used them. For example:

CPU limits for a batch process is actually for the whole thing, and not
for individual programs.

Not sure if VMS have CPU limits for individual programs. After all these
messages, it almost sounds like it don't.

In RSX, it's a switch to RUN. Like this:

..help run ins tim

RUN [ddnn:][$]filename /TIME=nM
/TIME=nS

Sets the time limit for a task that uses the CPU. When the time limit
expires,
the task is aborted and a message is displayed. If the task being run is
privileged, this keyword is ignored.

Specify the time limit in minutes (M) or in seconds (S); M is the
default.
(Valid only on systems with Resource Accounting.)

Obviously, if RSX had worked like VMS here, you would have a serious
headache if DCL was running in the same process context, as that process
context is killed at that point.

>>> 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.
>
> Actually, no I am not. The point I am making is that a DCL which behaves
> in this way increases the available attack surface, compared to more
> secure options such as how Unix shells work.

That there are more risks with code that have such rights is hardly new,
is it?
You could argue that this design makes it more sensitive to bugs causing
security problems, and I'm sure everyone would agree.

No different than any other part of the kernel. A bug anywhere in the
kernel have the same potential problem.

From a security point of view then, minimizing the size of the kernel
and other subsystems that runs with such elevated rights makes the risk
easier to assess, analyze and fix. Nothing new in that either.

So there isn't really anything new under the sun here. If you find a bug
in DCL, good. Report it, and let's hope it gets fixed. Is there a
security issue that DCL gets the rights of the executing program? Nope.

Johnny

Den 2022-08-21 kl. 17:18, skrev Johnny Billquist:
> On 2022-08-19 14:24, Simon Clubley wrote:
>> On 2022-08-18, Johnny Billquist <bqt@softjar.se> wrote:
>>> On 2022-08-17 21:02, Simon Clubley wrote:
>>>>
>>>> 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.
>>>
>>
>> No. To this point in the process lifecycle, a spawn on VMS ends up doing
>> the same as you describe above with RSX in that you do end up with another
>> process with its own PID.
>>
>> It's just that after this, a subprocess behaves in the same way as in the
>> main process, in that the DCL instance running in the subprocess starts
>> any user programs in the same subprocess just as DCL running in the main
>> process starts any user programs in the same main process.
>
> Meaning there is always DCL? That seems to contradict what Jan-Erik said.
>
>>>> 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.)
>>>
>>
>> In VMS, CPU runtime limits are documented as being against the process,
>> although I've never used them. For example:
>
> CPU limits for a batch process is actually for the whole thing, and not for
> individual programs.
>
> Not sure if VMS have CPU limits for individual programs. After all these
> messages, it almost sounds like it don't.
>
> In RSX, it's a switch to RUN. Like this:
>
> .help run ins tim
>
>  RUN [ddnn:][$]filename /TIME=nM
>                         /TIME=nS
>
>  Sets the time limit for a task that uses the CPU. When the time limit
> expires,
>  the task is aborted and a message is displayed. If the task being run is
>  privileged, this keyword is ignored.
>
>  Specify the time limit in minutes (M) or in seconds (S); M is the default.
>  (Valid only on systems with Resource Accounting.)
>

Sure, na RSX "task" is like a VMS "process".

You can of course start an VMS EXE in a new "detached process" and
run it without an DCL envionment. Then there is nothing but that
EXE running in that process. And when the EXE exits, the process
is deleted.

But you can also, if you want or need, start the same EXE in a DCL
environment by calling LOGINOUT.EXE and having a COM file as the
sys$input to that EXE where you run your main EXE. You might need
to have a "script" environment in your detached process where you
run different EXEs.

>
> Obviously, if RSX had worked like VMS here, you would have a serious
> headache if DCL was running in the same process context, as that process
> context is killed at that point.

I'd say that in most cases you just run the EXE in the detached
process without a DCL envionment. So it is a bit like running
an RSX EXE in a new "task".

>
>>>> 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.
>>
>> Actually, no I am not. The point I am making is that a DCL which behaves
>> in this way increases the available attack surface, compared to more
>> secure options such as how Unix shells work.
>
> That there are more risks with code that have such rights is hardly new, is
> it?
> You could argue that this design makes it more sensitive to bugs causing
> security problems, and I'm sure everyone would agree.
>
> No different than any other part of the kernel. A bug anywhere in the
> kernel have the same potential problem.
>
> From a security point of view then, minimizing the size of the kernel and
> other subsystems that runs with such elevated rights makes the risk easier
> to assess, analyze and fix. Nothing new in that either.
>
> So there isn't really anything new under the sun here. If you find a bug in
> DCL, good. Report it, and let's hope it gets fixed. Is there a security
> issue that DCL gets the rights of the executing program? Nope.
>
>   Johnny

On 8/21/2022 11:18 AM, Johnny Billquist wrote:
> On 2022-08-19 14:24, Simon Clubley wrote:
>> On 2022-08-18, Johnny Billquist <bqt@softjar.se> wrote:
>>> On 2022-08-17 21:02, Simon Clubley wrote:
>>>>
>>>> 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.
>>>
>>
>> No. To this point in the process lifecycle, a spawn on VMS ends up doing
>> the same as you describe above with RSX in that you do end up with another
>> process with its own PID.
>>
>> It's just that after this, a subprocess behaves in the same way as in the
>> main process, in that the DCL instance running in the subprocess starts
>> any user programs in the same subprocess just as DCL running in the main
>> process starts any user programs in the same main process.
>
> Meaning there is always DCL? That seems to contradict what Jan-Erik said.

Actually, I'm not sure of that.

An interactive process haws a CLI, whatever is specified in the SYSUAF record
for that user account. Usually DCL, but it does not have to be DCL.

A batch job has a batch command file that specifies activity.

A detached process can read from a command file, however, I do not think it has
to have such. While I've used detached processes, I usually have a command file
for activity. Not sure it is required.

Now, normally on VMS, there is some kind of SYS$COMMAND, SYS$INPUT, SYS$OUTPUT,
and SYS$ERROR. Or some other method of seeing completion, whether successful or
not.

The I&DS book(s) would be helpful ...

>>>> 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.)
>>>
>>
>> In VMS, CPU runtime limits are documented as being against the process,
>> although I've never used them. For example:
>
> CPU limits for a batch process is actually for the whole thing, and not for
> individual programs.
>
> Not sure if VMS have CPU limits for individual programs. After all these
> messages, it almost sounds like it don't.

It's been a while, but I'm pretty sure that CPU and time limits are on a
process. I've never used them.

> In RSX, it's a switch to RUN. Like this:
>
> .help run ins tim
>
> RUN [ddnn:][$]filename /TIME=nM
> /TIME=nS
>
> Sets the time limit for a task that uses the CPU. When the time limit expires,
> the task is aborted and a message is displayed. If the task being run is
> privileged, this keyword is ignored.
>
> Specify the time limit in minutes (M) or in seconds (S); M is the default.
> (Valid only on systems with Resource Accounting.)

If I wished such, I'd most likely use a timer AST.

> Obviously, if RSX had worked like VMS here, you would have a serious headache if
> DCL was running in the same process context, as that process context is killed
> at that point.
>
>>>> 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.
>>
>> Actually, no I am not. The point I am making is that a DCL which behaves
>> in this way increases the available attack surface, compared to more
>> secure options such as how Unix shells work.
>
> That there are more risks with code that have such rights is hardly new, is it?
> You could argue that this design makes it more sensitive to bugs causing
> security problems, and I'm sure everyone would agree.

A friend got tired of hearing about bugs, so he implimented a "bug" in the
terminal I/O routines. If active, the "bug" would come out and crawl around the
screen. Some people are easily bored.

> No different than any other part of the kernel. A bug anywhere in the kernel
> have the same potential problem.
>
> From a security point of view then, minimizing the size of the kernel and other
> subsystems that runs with such elevated rights makes the risk easier to assess,
> analyze and fix. Nothing new in that either.

Not having bugs is an even better idea ...

> So there isn't really anything new under the sun here. If you find a bug in DCL,
> good. Report it, and let's hope it gets fixed. Is there a security issue that
> DCL gets the rights of the executing program? Nope.

I don't have a problem with that.

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

Den 2022-08-21 kl. 20:52, skrev Dave Froble:
> On 8/21/2022 11:18 AM, Johnny Billquist wrote:
>> On 2022-08-19 14:24, Simon Clubley wrote:
>>> On 2022-08-18, Johnny Billquist <bqt@softjar.se> wrote:
>>>> On 2022-08-17 21:02, Simon Clubley wrote:
>>>>>
>>>>> 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.
>>>>
>>>
>>> No. To this point in the process lifecycle, a spawn on VMS ends up doing
>>> the same as you describe above with RSX in that you do end up with another
>>> process with its own PID.
>>>
>>> It's just that after this, a subprocess behaves in the same way as in the
>>> main process, in that the DCL instance running in the subprocess starts
>>> any user programs in the same subprocess just as DCL running in the main
>>> process starts any user programs in the same main process.
>>
>> Meaning there is always DCL? That seems to contradict what Jan-Erik said.
>
> Actually, I'm not sure of that.

There is an DCL environment if you start your detached process
by using the LOGINOUT.EXE system image to start/create it.

But you do not have to, if you do not need an DCL environment,
then you just let your detached process run your own EXE directly.

Without a DCL environment:

$ run /detached [other switches as needed] MYEXE.EXE

With a DCL envionment:

$ run /detached /input=myexe.com sys$system:loginout.exe

LOGINOUT does a full "login" of the detached process and creates
a DCL envionment in it and starts reading the /input file just
as when DCL processes any COM file.

The MYEXE.COM file can have any setup needed for the main EXE
and then do a normal RUN of it. Such as process unique logical
names or whatever.

We have background (deteched) processes started in both ways
depening on the requirement of the process.

>
> An interactive process haws a CLI, whatever is specified in the SYSUAF
> record for that user account.  Usually DCL, but it does not have to be DCL.
>
> A batch job has a batch command file that specifies activity.
>

I expect any batch job to have a DCL envionment.

> A detached process can read from a command file, however, I do not think it
> has to have such.  While I've used detached processes, I usually have a
> command file for activity.  Not sure it is required.

No, you can start an EXE directly, if that is fine.

>
> Now, normally on VMS, there is some kind of SYS$COMMAND, SYS$INPUT,
> SYS$OUTPUT, and SYS$ERROR.  Or some other method of seeing completion,
> whether successful or not.

But those are the process "permanent" logical names. As far as I know,
any process has these defined by the system at process creation.

>
> The I&DS book(s) would be helpful ...
>
>>>>> 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.)
>>>>
>>>
>>> In VMS, CPU runtime limits are documented as being against the process,
>>> although I've never used them. For example:
>>
>> CPU limits for a batch process is actually for the whole thing, and not for
>> individual programs.
>>
>> Not sure if VMS have CPU limits for individual programs. After all these
>> messages, it almost sounds like it don't.
>
> It's been a while, but I'm pretty sure that CPU and time limits are on a
> process.  I've never used them.

Sometimes you'd wished you had, when you get that run-away process... :-)

>
>> In RSX, it's a switch to RUN. Like this:
>>
>> .help run ins tim
>>
>>  RUN [ddnn:][$]filename /TIME=nM
>>                         /TIME=nS
>>
>>  Sets the time limit for a task that uses the CPU. When the time limit
>> expires,
>>  the task is aborted and a message is displayed. If the task being run is
>>  privileged, this keyword is ignored.

But that creates a new RSX process (called "task" in RSX).

It is the same doing this on VMS:

$ run /detached /time_limit=00:10:00 [other switches as needed] MYEXE.EXE

A 10 min CPU limit in that case. Can also be used for the other
case with an DCL envionment, of course. It is still valid för the
whole process, no matter if it is a single EXE or a DCL environment.

$ help run process /time

RUN

Process

/TIME_LIMIT

/TIME_LIMIT=limit

Specifies the maximum amount of CPU time (in delta time) a
created process can use. CPU time is allocated to the created
process in units of 10 milliseconds. When it has exhausted its
CPU time limit quota, the created process is deleted.

On 2022-08-21, Johnny Billquist <bqt@softjar.se> wrote:
>
> And if a program finishes, but it just means you get back to DCL, then
> I'm still wondering how the accounting is done, since the process is
> still there, the kernel don't have as much clue about what happened.
>

The image-level accounting records are probably written during the
user-mode rundown system service call, but that's just a guess as this
is a part of VMS I have not really looked at.

>
> But how is this done from a technical point of view? There is a huge
> difference between the kernel getting a call/signal/whatever that the
> process should die, and the kernel removes all associated resources, and
> a return being done to DCL, from where the program was called.
>

As already mentioned, DCL is responsible for kicking off the cleanup of
the resources allocated to the user-mode program when that _program_ exits.
The kernel does the normal process-level cleanup when the _process_ exits.

> Or is a program terminating always going into the kernel, and the kernel
> then notices that there is a CLI associated here, and it then moves the
> execution back to the CLI with some additional information that the
> program terminated?
>

The CLI is between the user-mode program exiting and the process exiting.

If you manage to crash DCL itself so DCL exits, the process itself exits
as a result.

Simon.

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

On 2024-02-27, John Dallman <jgd@cix.co.uk> wrote:
> In article <tdaror$bap$1@news.misty.com>, bqt@softjar.se (Johnny
> Billquist) wrote:
>
>> On 2022-08-14 14:28, Jan-Erik Söderholm wrote:
>> > Doesn't work for me. Gives "www.irisa.fr doesn't respond".
>> >
>> > First hit when googling "irisa" is www.irisa.fr, but doesn't work
>> > either.
>> Seems to have stopped working for me as well now.
>> I got the link from the Itanium wikipedia page.
>
> Working now, and I took the chance to grab all the files.
>

Is this a full-system emulator or just a CPU emulator ?

[From what I can tell from the webpage, it appears to be another CPU
emulator only, just like Ski.]

Thanks,

Simon.

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

On 2024-02-27, John Dallman <jgd@cix.co.uk> wrote:
>
> If the documentation is correct, then making an IA64 VMS emulator for
> x96-64 VMS would require, at least:
>
> * Extending the ELF library to cope with dynamically linked executables
> and libraries.
> * Creating a system call translation layer for VMS. This would be a lot
> easier with the VMS source available.
> * Fixing bugs that doubtless exist in the libraries.
> * Getting the instruction set library to run at a reasonable speed.
>

Thanks John.

So direct execution of some standalone Itanium VMS user-mode executables
might be possible with enough effort, but no running Itanium VMS as an
entity in its own right.

It really does speak to how complex the Itanium architecture is that
nobody has ever done an Itanium 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 2/28/2024 1:03 PM, Simon Clubley wrote:
> On 2024-02-27, John Dallman <jgd@cix.co.uk> wrote:
>> If the documentation is correct, then making an IA64 VMS emulator for
>> x96-64 VMS would require, at least:
>>
>> * Extending the ELF library to cope with dynamically linked executables
>> and libraries.
>> * Creating a system call translation layer for VMS. This would be a lot
>> easier with the VMS source available.
>> * Fixing bugs that doubtless exist in the libraries.
>> * Getting the instruction set library to run at a reasonable speed.

> So direct execution of some standalone Itanium VMS user-mode executables
> might be possible with enough effort, but no running Itanium VMS as an
> entity in its own right.
>
> It really does speak to how complex the Itanium architecture is that
> nobody has ever done an Itanium full-system emulator. :-)

That and lack of demand (demand = businesses willing to
pay for such an emulator not hobbyists that think it could
be fun with such an emulator).

Maybe it will change. HP-UX is not being ported to x86-64
as far as I know, so *if* some businesses do not want to
migrate from HP-UX/Itanium to Linux/x86-64, then demand
for an Itanium emulator may rise.

(note the *if* - I don't know any HP-UX people)

Arne

On 2/28/2024 1:03 PM, Simon Clubley wrote:
> On 2024-02-27, John Dallman <jgd@cix.co.uk> wrote:
>>
>> If the documentation is correct, then making an IA64 VMS emulator for
>> x96-64 VMS would require, at least:
>>
>> * Extending the ELF library to cope with dynamically linked executables
>> and libraries.
>> * Creating a system call translation layer for VMS. This would be a lot
>> easier with the VMS source available.
>> * Fixing bugs that doubtless exist in the libraries.
>> * Getting the instruction set library to run at a reasonable speed.
>>
>
> Thanks John.
>
> So direct execution of some standalone Itanium VMS user-mode executables
> might be possible with enough effort, but no running Itanium VMS as an
> entity in its own right.
>
> It really does speak to how complex the Itanium architecture is that
> nobody has ever done an Itanium full-system emulator. :-)
>
> Simon.
>

What would be the point?

Before it was considered a bad idea, it was still available. They are still
available used. I got one which hasn't been powered on in months. Want it?

Emulators allowed use of discontinued architectures that people actually wanted
to run. I don't know anyone who really wants to run an itanic. Do you?

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

Dave Froble <davef@tsoft-inc.com> wrote:
>Before it was considered a bad idea, it was still available. They are still
>available used. I got one which hasn't been powered on in months. Want it?
>
>Emulators allowed use of discontinued architectures that people actually wanted
>to run. I don't know anyone who really wants to run an itanic. Do you?

Well, that's sort of the thing. MAYBE the Itanium might actually have been
a viable architecture if the compilers could have been made smart enough.
But this turned out to be a whole lot harder than the Intel crew expected.

The idea was that with the long instruction word, compilers could have
multiple operations taking place across the chip in ways that pipelining
microcoded machines could not do. But in fact, the actual utilization of
processor elements was much worse when it actually came down to the wire.
Could this have been corrected with smarter compilers? That's the question
nobody can really answer. And now there is no interest in answering it.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

Arne Vajhøj schrieb am 28.02.2024 um 20:20:
> On 2/28/2024 1:03 PM, Simon Clubley wrote:
>> On 2024-02-27, John Dallman <jgd@cix.co.uk> wrote:
>>> If the documentation is correct, then making an IA64 VMS emulator for
>>> x96-64 VMS would require, at least:
>>>
>>> * Extending the ELF library to cope with dynamically linked executables
>>>    and libraries.
>>> * Creating a system call translation layer for VMS. This would be a lot
>>>    easier with the VMS source available.
>>> * Fixing bugs that doubtless exist in the libraries.
>>> * Getting the instruction set library to run at a reasonable speed.
>
>> So direct execution of some standalone Itanium VMS user-mode executables
>> might be possible with enough effort, but no running Itanium VMS as an
>> entity in its own right.
>>
>> It really does speak to how complex the Itanium architecture is that
>> nobody has ever done an Itanium full-system emulator. :-)
>
> That and lack of demand (demand = businesses willing to
> pay for such an emulator not hobbyists that think it could
> be fun with such an emulator).
>
> Maybe it will change. HP-UX is not being ported to x86-64
> as far as I know, so *if* some businesses do not want to
> migrate from HP-UX/Itanium to Linux/x86-64, then demand
> for an Itanium emulator may rise.
>
> (note the *if* - I don't know any HP-UX people)

Well... I know VMS customers who stepped back from Itanium to Alpha
because an Alpha emulator was available (they used a specific PCI(e)
card for their application).

HP-UX customers could step back to PA-RISC instead of porting to Linux.
Stromasys offers a PA-RISC emulator.

Hans.

On 2/28/2024 6:57 PM, Hans Bachner wrote:
> Arne Vajhøj schrieb am 28.02.2024 um 20:20:
>> Maybe it will change. HP-UX is not being ported to x86-64
>> as far as I know, so *if* some businesses do not want to
>> migrate from HP-UX/Itanium to Linux/x86-64, then demand
>> for an Itanium emulator may rise.
>>
>> (note the *if* - I don't know any HP-UX people)
>
> Well... I know VMS customers who stepped back from Itanium to Alpha
> because an Alpha emulator was available (they used a specific PCI(e)
> card for their application).
>
> HP-UX customers could step back to PA-RISC instead of porting to Linux.
> Stromasys offers a PA-RISC emulator.

HP-UX/PA - I was not even aware that recent HP-UX still run on PA.

That could be an option for the HP-UX people.

Does the relevant ISV's like Oracle still support HP-UX/PA?

Arne

On 2/29/2024 3:06 AM, John Dallman wrote:
> In article <uro126$1pab$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj)
> wrote:
>> Maybe it will change. HP-UX is not being ported to x86-64
>> as far as I know, so *if* some businesses do not want to
>> migrate from HP-UX/Itanium to Linux/x86-64, then demand
>> for an Itanium emulator may rise.
>
> HP-UX isn't all that different from Linux, and I seriously doubt there
> would be enough businesses that want to stay with HP-UX badly enough.

Could be.

People liking HP-UX and liking Itanium may be a very small group.

Arne

On 2/29/2024 12:49 PM, John Dallman wrote:
> In article <urq94k$m8rf$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj)
> wrote:
>> On 2/29/2024 3:06 AM, John Dallman wrote:
>>> HP-UX isn't all that different from Linux, and I seriously doubt
>>> there would be enough businesses that want to stay with HP-UX
>>> badly enough.
>> People liking HP-UX and liking Itanium may be a very small group.
>
> "Liking" doesn't mean so much when lots of money is involved. A decade
> ago, a fair few people may have expressed loyalty to HP-UX/Itanium, but
> it was obvious then that it wasn't going to grow, and the writing has
> been on the wall for Itanium since 2019.
>
> Moving almost any kind of HP-UX software to Linux is much easier than
> moving VMS software that uses VMS hard to anything else.
>
> John
>

Yes, and while I've never been in this situation, some users must have well
documented testing and validation of their software. This can involve large
amounts of that money you mention. It could be possible for some that just
about anything is cheaper than a new validation job.

It would be my guess that anyone is such a situation just might have the
re-validation to do if switching to an emulator.

--
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 2024-02-28, Dave Froble <davef@tsoft-inc.com> wrote:
>
> What would be the point?
>

With x86-64 VMS, very little.

> Before it was considered a bad idea, it was still available. They are still
> available used. I got one which hasn't been powered on in months. Want it?
>

No. :-) Noisy, bulky hardware, neither of which is true when running it
in an emulated environment.

> Emulators allowed use of discontinued architectures that people actually wanted
> to run. I don't know anyone who really wants to run an itanic. Do you?
>

5 years ago, maybe. Today, no way.

Simon.

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

On 2/29/2024 3:39 AM, John Dallman wrote:
> In article <uroeg8$b8$1@panix2.panix.com>, kludge@panix.com (Scott Dorsey)
> wrote:
>
>> Well, that's sort of the thing. MAYBE the Itanium might actually
>> have been a viable architecture if the compilers could have been
>> made smart enough. But this turned out to be a whole lot harder
>> than the Intel crew expected.
>
> No, it couldn't. The problem is the delays in accessing memory.
>
> EPIC requires the compilers to issue speculative loads far enough in
> advance to keep the processor from stalling waiting for memory for most
> of the time. However, that doesn't work: the information isn't available
> enough of the time. The compiler also doesn't know what's in what level
> of cache, because it's /impossible/ to know that when code is running on
> a multi-tasking OS that is taking interrupts.
>
> Out-of-order execution, as used on modern x86 processors (and ARM, POWER,
> IBM Z, and anything else that's still competitive) deals with the memory
> and cache problems by letting the data dependencies for instructions be
> resolved dynamically as data arrives. This works much better.
>
> EPIC only made sense in a system that was running a single process and
> taking few, if any, interrupts. That was how early embedded systems,
> which were Intel's original market, worked in the 1970s and early 1980s.
> Trying to apply that to a processor that appeared in 2001 was a massive
> failure of concept and project management. Itanium was obsolete when it
> shipped.
>
> John
>

In case we're looking for "blame", remember that EPIC wasn't Intel's brain fart,
it came from HP, who somehow got Intel to adopt it. You are correct, EPIC was
shown to be a poor choice before it even shipped. But someone(s) were too
stubborn to listen to their own people.

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