On 12/5/2021 10:55 AM, Phillip Helbig (undress to reply) wrote:
> In article <soin99$1ac$1@dont-email.me>, Dave Froble
> <davef@tsoft-inc.com> writes:
>
>>>> With the VSI Community License Program, members of the community can
>>>> download OpenVMS for free for learning, open source development, and
>>>> exchanging knowledge of the operating system on Alpha and Integrity
>>>> systems. This program replaces the HP Hobbyist program.
>>>
>>> The wording has changed a bit. But it is still non-commercial.
>>> Open-source can be non-commercial, but it can also be commercial.
>>
>> Isn't there a difference between working on commercial software, such
>> as porting to VMS, and using commercial software?
>
> Using commercial software has nothing to do with VMS licenses.

Huh ?????????????????

> AT BEST, the hobbyist license could be construed to be valid for working
> on commercial software, but without receiving any sort of financial
> reward, directly or indirectly, for doing so.
>

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

In article <soj03a$202$2@dont-email.me>, Dave Froble
<davef@tsoft-inc.com> writes:

> >>>> With the VSI Community License Program, members of the community can
> >>>> download OpenVMS for free for learning, open source development, and
> >>>> exchanging knowledge of the operating system on Alpha and Integrity
> >>>> systems. This program replaces the HP Hobbyist program.
> >>>
> >>> The wording has changed a bit. But it is still non-commercial.
> >>> Open-source can be non-commercial, but it can also be commercial.
> >>
> >> Isn't there a difference between working on commercial software, such
> >> as porting to VMS, and using commercial software?
> >
> > Using commercial software has nothing to do with VMS licenses.
>
> Huh ?????????????????

????????

Obviously VMS is commercial and its use involves VMS licenses. That is
not the topic here. The question is whether the hobbyist license would
cover open-source development on VMS for commercial software and, if so,
if that would be the case only if the developer received no
compensation.

On Friday, December 3, 2021 at 5:44:29 PM UTC+13, Mike K. wrote:
> Honestly, I think that any new users will probably be coming out of the hobbyist/community license program. Basically people who try it out and use it for personal projects, and decide that they like it so much compared to Linux or Windows that when the time comes, they push to use VMS as a server platform for a work project. For this to happen, though, VMS needs to actually have all the pieces in place to serve a modern web app. This means not just a web server, but things like PHP, Python, node.js, etc. And a DBMS that folks can actually use. While Oracle may be planning to port Rdb to x86 eventually, it's not there yet, and even when it comes, will not have any hobbyist option available to allow new users to get to know it. This needs to be fixed, either by beating Oracle with a clue stick until something happens (unlikely) or by updating the woefully outdated version of MariaDB currently available for VMS.
>
> Documentation specifically aimed at new users who are primarily familiar with Linux of Window would be a help, as would a more reasonable set of default system parameter values that don't require an AUTOGEN cycle every time a significant software package is installed.

Even if OpenVMS had all the pieces in place and could run modern workloads, why choose OpenVMS over Linux? What can OpenVMS do that Linux simply cant? What can it do significantly better than Linux? What makes the license cost and yearly renewals worth it?

Right now Linux is the native platform for most major software development tools and a lot (most?) of the server software people care about. Here OpenVMS has some of the same challenges as Windows. Why pay extra to run Linux software on Windows when you could just do what everyone else is doing and run Linux software on Linux? Why pay extra for worse support and extra bugs because windows ports are often a lower priority?

Are there any proprietary operating systems that have actually managed to take market share from Linux besides MacOS on the desktop? All the proprietary unixes are basically dead (aside from Solaris which survives in open-source form as Illumos) and Windows Server is probably loosing market share outside of Azure. I doubt IBM is gaining a lot of new mainframe customers.

On 12/5/2021 6:14 PM, David Goodwin wrote:
> Even if OpenVMS had all the pieces in place and could run modern
> workloads, why choose OpenVMS over Linux? What can OpenVMS do that
> Linux simply cant? What can it do significantly better than Linux?
> What makes the license cost and yearly renewals worth it?
>
> Right now Linux is the native platform for most major software
> development tools and a lot (most?) of the server software people
> care about. Here OpenVMS has some of the same challenges as Windows.
> Why pay extra to run Linux software on Windows when you could just do
> what everyone else is doing and run Linux software on Linux? Why pay
> extra for worse support and extra bugs because windows ports are
> often a lower priority?
>
> Are there any proprietary operating systems that have actually
> managed to take market share from Linux besides MacOS on the desktop?
> All the proprietary unixes are basically dead (aside from Solaris
> which survives in open-source form as Illumos) and Windows Server is
> probably loosing market share outside of Azure. I doubt IBM is
> gaining a lot of new mainframe customers.

Interesting question.

VSI is currently focusing a lot on existing VMS customers and
not so much on how to get new VMS customers.

But new VMS customers would of course be nice.

First I think we need to realize that VMS is unlikely to ever compete
with Linux in the commodity server market.

If you need to run thousands of servers with PHP or node.js, then
the OS price matters. VMS will be too expensive. Heck - a lot
of them consider RHEL too expensive and goes for RockyLinux or
Ubuntu.

VMS market will definitely be the slightly more expensive
server market where the OS cost is a very small part of
total cost and competitors are RHEL and Windows Server.

I don't think OS cost is a big issue in healthcare, finance,
defense etc..

Going after that market combined with a pricing that is competitive
with RHEL and Windows Server will handle the cost issue.

(HW cost of VMS boxes will be resolved by the x86-64 port)

And even though this market may only be like 10% of the server
market then the market is still more than big enough for VMS.

It is obviously a prerequisite for VMS to get new customers to
provide a decent set of tools and platform products - otherwise
VMS will be disqualified.

But that still leaves the question why would new customer choose
VMS over Linux.

Maybe VSI can try pushing "less is more" / "small is good". Both
Linux and Windows has become huge. To some extent they can be tailored
down (especially Linux), but still a simple OS may have a justification.

Arne

On 2021-12-03, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 12/3/2021 1:55 PM, Simon Clubley wrote:
>> I think VSI have done some work with parameter defaults so at least
>> some of them will not be an issue on x86-64 VMS.
>>
>> Is there any option in VMS where, if a system/process goes past some
>> percentage (say 80% to 90%) of any system parameter designed to limit
>> use of a resource, VMS will issue an OPCOM warning about that system
>> parameter (and maybe log it elsewhere as well) ? If not, would this
>> be a good option to add to VMS ?
>
> I think VSI should get rid of >95% of SYSGEN and SYSUAF limits.
>
> They made sense with a 256 KB VAX but not so much on a 256 GB x86-64.
>

Agreed, but it would be nice if they would retain an overall ability
to stop a single runaway process from gobbling up all the resources
without at the same time having to micromanage resources as needed to
be done on the resource limited systems of old.

Simon.

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

On 12/6/2021 1:29 PM, Simon Clubley wrote:
> On 2021-12-03, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 12/3/2021 1:55 PM, Simon Clubley wrote:
>>> I think VSI have done some work with parameter defaults so at least
>>> some of them will not be an issue on x86-64 VMS.
>>>
>>> Is there any option in VMS where, if a system/process goes past some
>>> percentage (say 80% to 90%) of any system parameter designed to limit
>>> use of a resource, VMS will issue an OPCOM warning about that system
>>> parameter (and maybe log it elsewhere as well) ? If not, would this
>>> be a good option to add to VMS ?
>>
>> I think VSI should get rid of >95% of SYSGEN and SYSUAF limits.
>>
>> They made sense with a 256 KB VAX but not so much on a 256 GB x86-64.
>
> Agreed, but it would be nice if they would retain an overall ability
> to stop a single runaway process from gobbling up all the resources
> without at the same time having to micromanage resources as needed to
> be done on the resource limited systems of old.

Sure. But if we have a MAXCPU, a MAXMEMORY and a MAXOPENFILES
then how much more do we need.

Arne

On 2021-12-05, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> But that still leaves the question why would new customer choose
> VMS over Linux.
>
> Maybe VSI can try pushing "less is more" / "small is good". Both
> Linux and Windows has become huge. To some extent they can be tailored
> down (especially Linux), but still a simple OS may have a justification.
>

The one thing you have not addressed in your reply are the time-limited
production licences.

Why would a manager new to the VMS world make a decision where you had
to pay for new licences for your newly acquired systems on a regular
basis or those new systems would suddenly stop working ?

It's one thing to stop getting support if a vendor goes bust.

It's a completely different thing to have your systems suddenly stop
working if a vendor previously unknown to them (VSI) suddenly goes bust.

Why would they ever agree to that ?

Even _if_ they could be convinced VSI would be taken over, how do you
address the question of a VSI collapse happening right when those new
licences were needed ?

How do you address the question that the customer has no control over the
price of the renewal licences and that a replacement company could charge
a stiff price increase because they have a captive market ?

Why would a manager new to the VMS world ever agree to that when they
have their job and their pension to think about and have several other
alternatives where this simply is not a concern to the manager ?

People here are looking at pushing VMS from a technical viewpoint.

I OTOH am looking at this from a human nature viewpoint of managers
in a client company who want to keep their jobs.

Simon.

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

On 2021-12-06, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 12/6/2021 1:29 PM, Simon Clubley wrote:
>> On 2021-12-03, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 12/3/2021 1:55 PM, Simon Clubley wrote:
>>>> I think VSI have done some work with parameter defaults so at least
>>>> some of them will not be an issue on x86-64 VMS.
>>>>
>>>> Is there any option in VMS where, if a system/process goes past some
>>>> percentage (say 80% to 90%) of any system parameter designed to limit
>>>> use of a resource, VMS will issue an OPCOM warning about that system
>>>> parameter (and maybe log it elsewhere as well) ? If not, would this
>>>> be a good option to add to VMS ?
>>>
>>> I think VSI should get rid of >95% of SYSGEN and SYSUAF limits.
>>>
>>> They made sense with a 256 KB VAX but not so much on a 256 GB x86-64.
>>
>> Agreed, but it would be nice if they would retain an overall ability
>> to stop a single runaway process from gobbling up all the resources
>> without at the same time having to micromanage resources as needed to
>> be done on the resource limited systems of old.
>
> Sure. But if we have a MAXCPU, a MAXMEMORY and a MAXOPENFILES
> then how much more do we need.
>

Not as many as we currently have. :-)

Simon.

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

On 2021-12-05, Chris Townley <news@cct-net.co.uk> wrote:
> On 05/12/2021 11:30, Phillip Helbig (undress to reply) wrote:
>> In article <soi3r4$8c2$1@dont-email.me>, Chris Townley
>> <news@cct-net.co.uk> writes:
>>
>>> On 05/12/2021 08:57, William wrote:
>>>> Some sort of free license so that open source developers can do
>> OpenVMS ports and so that sites like GitLab can give projects an option
>> of including OpenVMS in CI pipelines.
>>
>>> Isn't the community/hobbyist license just that? Or the ISV scheme?
>>
>> Hobbyist? No. ISV? Probably.
>>
>
> From the VSI Website:
>
> With the VSI Community Li?ense Program, members of the community can
> download OpenVMS for free for learning, open source development, and
> exchanging knowledge of the operating system on Alpha and Integrity
> systems. This program replaces the HP Hobbyist program.
>

I just had a look at the licence itself to see if it makes things
clearer and it actually confuses things a little bit more. :-)

|Non-commercial means not used for commercial advantage, direct monetary
|compensation, or indirect monetary compensation.

What is "indirect monetary compensation" ? Would this include getting
a pay rise or a new job as a result of learning a new skill using the
hobbyist licence ?

|You will not modify, reverse engineer, disassemble, decrypt, decompile, or
|make derivative works of the Software. Where You have other rights mandated
|under statute, You will provide VSI with reasonably detailed information
|regarding any intended modifications, reverse engineering, disassembly,
|decryption, or decompilation and the purposes therefore.

Does this prohibit some forms of security research ?

|In partial consideration of the license granted hereunder, you agree to
|provide reasonable participation in the online Software community forums,
|including without limitation such activities as answering questions and
|contributing articles and how-to videos to the OpenVMS online Software
|community at https://forum.vmssoftware.com.

Do VSI enforce this, or would taking part in comp.os.vms instead be enough ?

Simon.

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

On 2021-12-05, Phillip Helbig (undress to reply) <helbig@asclothestro.multivax.de> wrote:
> In article <soj03a$202$2@dont-email.me>, Dave Froble
><davef@tsoft-inc.com> writes:
>
>> >>>> With the VSI Community License Program, members of the community can
>> >>>> download OpenVMS for free for learning, open source development, and
>> >>>> exchanging knowledge of the operating system on Alpha and Integrity
>> >>>> systems. This program replaces the HP Hobbyist program.
>> >>>
>> >>> The wording has changed a bit. But it is still non-commercial.
>> >>> Open-source can be non-commercial, but it can also be commercial.
>> >>
>> >> Isn't there a difference between working on commercial software, such
>> >> as porting to VMS, and using commercial software?
>> >
>> > Using commercial software has nothing to do with VMS licenses.
>>
>> Huh ?????????????????
>
> ????????
>
> Obviously VMS is commercial and its use involves VMS licenses. That is
> not the topic here. The question is whether the hobbyist license would
> cover open-source development on VMS for commercial software and, if so,
> if that would be the case only if the developer received no
> compensation.
>

I think David might be asking if you can run commercial software on
a hobbyist system.

For example, if you could somehow get hold of a legal copy of Word Perfect
for Alpha, could you run it on a hobbyist system for personal use ?

If so, that's a good question, and I don't know the answer.

Simon.

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

On 12/6/2021 2:12 PM, Simon Clubley wrote:
> On 2021-12-05, Phillip Helbig (undress to reply) <helbig@asclothestro.multivax.de> wrote:
>> In article <soj03a$202$2@dont-email.me>, Dave Froble
>> <davef@tsoft-inc.com> writes:
>>
>>>>>>> With the VSI Community License Program, members of the community can
>>>>>>> download OpenVMS for free for learning, open source development, and
>>>>>>> exchanging knowledge of the operating system on Alpha and Integrity
>>>>>>> systems. This program replaces the HP Hobbyist program.
>>>>>>
>>>>>> The wording has changed a bit. But it is still non-commercial.
>>>>>> Open-source can be non-commercial, but it can also be commercial.
>>>>>
>>>>> Isn't there a difference between working on commercial software, such
>>>>> as porting to VMS, and using commercial software?
>>>>
>>>> Using commercial software has nothing to do with VMS licenses.
>>>
>>> Huh ?????????????????
>>
>> ????????
>>
>> Obviously VMS is commercial and its use involves VMS licenses. That is
>> not the topic here. The question is whether the hobbyist license would
>> cover open-source development on VMS for commercial software and, if so,
>> if that would be the case only if the developer received no
>> compensation.
>
> I think David might be asking if you can run commercial software on
> a hobbyist system.
>
> For example, if you could somehow get hold of a legal copy of Word Perfect
> for Alpha, could you run it on a hobbyist system for personal use ?
>
> If so, that's a good question, and I don't know the answer.

A license is an agreement between the software vendor and the software
user and can include limitations on software use.

VSI can and does limit use of VMS under CL. And given that an OS is
used for everything on a system then it practically limits the use
of the entire system.

So a CL licensed system cannot be used for anything commercial.

It does not make any sense for VSI to limit what SW can be installed
on the system and what licenses they come under. And I do not remember
there being anything like that in the CL license.

So I cannot see why you cannot install your paid WP software
on the system - just note that even though the WP license may
permit it then the VMS license still prohibits commercial
work including in WP as WP use the OS.

Arne

On 12/6/2021 2:07 PM, Simon Clubley wrote:
> On 2021-12-05, Chris Townley <news@cct-net.co.uk> wrote:
>> On 05/12/2021 11:30, Phillip Helbig (undress to reply) wrote:
>>> In article <soi3r4$8c2$1@dont-email.me>, Chris Townley
>>> <news@cct-net.co.uk> writes:
>>>
>>>> On 05/12/2021 08:57, William wrote:
>>>>> Some sort of free license so that open source developers can do
>>> OpenVMS ports and so that sites like GitLab can give projects an option
>>> of including OpenVMS in CI pipelines.
>>>
>>>> Isn't the community/hobbyist license just that? Or the ISV scheme?
>>>
>>> Hobbyist? No. ISV? Probably.
>>
>> From the VSI Website:
>>
>> With the VSI Community Li?ense Program, members of the community can
>> download OpenVMS for free for learning, open source development, and
>> exchanging knowledge of the operating system on Alpha and Integrity
>> systems. This program replaces the HP Hobbyist program.
>>
>
> I just had a look at the licence itself to see if it makes things
> clearer and it actually confuses things a little bit more. :-)
>
> |Non-commercial means not used for commercial advantage, direct monetary
> |compensation, or indirect monetary compensation.
>
> What is "indirect monetary compensation" ? Would this include getting
> a pay rise or a new job as a result of learning a new skill using the
> hobbyist licence ?

Not likely. Impossible not to learn something that could potentially
be beneficial in some way.

Common sense says:

Commercial advantage => you cannot run your businesses accounting on the
system.

Direct monetary compensation => you cannot let your neighbor run his
business accounting on the system for 50 pound per month.

Indirect monetary compensation => you cannot let your neighbor run his
business accounting on the system and he clears snow from your driveway
in return.

> |You will not modify, reverse engineer, disassemble, decrypt, decompile, or
> |make derivative works of the Software. Where You have other rights mandated
> |under statute, You will provide VSI with reasonably detailed information
> |regarding any intended modifications, reverse engineering, disassembly,
> |decryption, or decompilation and the purposes therefore.
>
> Does this prohibit some forms of security research ?

Seems likely. The prohibition against disassemble and decompile could
be a problem.

> |In partial consideration of the license granted hereunder, you agree to
> |provide reasonable participation in the online Software community forums,
> |including without limitation such activities as answering questions and
> |contributing articles and how-to videos to the OpenVMS online Software
> |community at https://forum.vmssoftware.com.
>
> Do VSI enforce this,

I have never heard of it.

> or would taking part in comp.os.vms instead be enough ?

It is pretty broadly worded.

Arne

On 12/6/2021 1:46 PM, Simon Clubley wrote:
> On 2021-12-05, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> But that still leaves the question why would new customer choose
>> VMS over Linux.
>>
>> Maybe VSI can try pushing "less is more" / "small is good". Both
>> Linux and Windows has become huge. To some extent they can be tailored
>> down (especially Linux), but still a simple OS may have a justification.
>
> The one thing you have not addressed in your reply are the time-limited
> production licences.
>
> Why would a manager new to the VMS world make a decision where you had
> to pay for new licences for your newly acquired systems on a regular
> basis or those new systems would suddenly stop working ?
>
> It's one thing to stop getting support if a vendor goes bust.
>
> It's a completely different thing to have your systems suddenly stop
> working if a vendor previously unknown to them (VSI) suddenly goes bust.
>
> Why would they ever agree to that ?
>
> Even _if_ they could be convinced VSI would be taken over, how do you
> address the question of a VSI collapse happening right when those new
> licences were needed ?
>
> How do you address the question that the customer has no control over the
> price of the renewal licences and that a replacement company could charge
> a stiff price increase because they have a captive market ?
>
> Why would a manager new to the VMS world ever agree to that when they
> have their job and their pension to think about and have several other
> alternatives where this simply is not a concern to the manager ?
>
> People here are looking at pushing VMS from a technical viewpoint.
>
> I OTOH am looking at this from a human nature viewpoint of managers
> in a client company who want to keep their jobs.

There is an outstanding issue about the expiring licenses.

But I think the OP was looking for something more general/fundamental -
this issue could be fixed in no time by VSI.

Arne

PS: And you know how I think VSI should fix this.

On 12/6/2021 2:12 PM, Simon Clubley wrote:
> On 2021-12-05, Phillip Helbig (undress to reply) <helbig@asclothestro.multivax.de> wrote:
>> In article <soj03a$202$2@dont-email.me>, Dave Froble
>> <davef@tsoft-inc.com> writes:
>>
>>>>>>> With the VSI Community License Program, members of the community can
>>>>>>> download OpenVMS for free for learning, open source development, and
>>>>>>> exchanging knowledge of the operating system on Alpha and Integrity
>>>>>>> systems. This program replaces the HP Hobbyist program.
>>>>>>
>>>>>> The wording has changed a bit. But it is still non-commercial.
>>>>>> Open-source can be non-commercial, but it can also be commercial.
>>>>>
>>>>> Isn't there a difference between working on commercial software, such
>>>>> as porting to VMS, and using commercial software?
>>>>
>>>> Using commercial software has nothing to do with VMS licenses.
>>>
>>> Huh ?????????????????
>>
>> ????????
>>
>> Obviously VMS is commercial and its use involves VMS licenses. That is
>> not the topic here. The question is whether the hobbyist license would
>> cover open-source development on VMS for commercial software and, if so,
>> if that would be the case only if the developer received no
>> compensation.
>>
>
> I think David might be asking if you can run commercial software on
> a hobbyist system.
>
> For example, if you could somehow get hold of a legal copy of Word Perfect
> for Alpha, could you run it on a hobbyist system for personal use ?
>
> If so, that's a good question, and I don't know the answer.
>
> Simon.
>

No. David took one look at the statement:

"Using commercial software has nothing to do with VMS licenses."

Now, if Phillip meant to refer to hobbyist or CL or ISV licenses, he should have
written that. He didn't.

--
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 12/6/2021 1:29 PM, Simon Clubley wrote:
> On 2021-12-03, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 12/3/2021 1:55 PM, Simon Clubley wrote:
>>> I think VSI have done some work with parameter defaults so at least
>>> some of them will not be an issue on x86-64 VMS.
>>>
>>> Is there any option in VMS where, if a system/process goes past some
>>> percentage (say 80% to 90%) of any system parameter designed to limit
>>> use of a resource, VMS will issue an OPCOM warning about that system
>>> parameter (and maybe log it elsewhere as well) ? If not, would this
>>> be a good option to add to VMS ?
>>
>> I think VSI should get rid of >95% of SYSGEN and SYSUAF limits.
>>
>> They made sense with a 256 KB VAX but not so much on a 256 GB x86-64.
>>
>
> Agreed, but it would be nice if they would retain an overall ability
> to stop a single runaway process from gobbling up all the resources
> without at the same time having to micromanage resources as needed to
> be done on the resource limited systems of old.
>
> Simon.
>

I see no reason to remove system parameters. I think that many parameters could
be evaluated from the perspective of the anticipated systems being used, and
where there is no reason to not do so, set defaults to take advantage of those
anticipated systems. This should get rid of much of the need for AUTOGEN. This
should get rid of most of the need for any tuning.

However, getting rid of the parameters would then not allow specific tuning for
the perhaps handful of uses where such tuning might be necessary. I'm mainly
thinking of desired restrictions. Just because I cannot think of any such usage
doesn't mean it will never happen.

--
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 Monday, December 6, 2021 at 8:26:38 PM UTC-5, Dave Froble wrote:
> On 12/6/2021 1:29 PM, Simon Clubley wrote:
> > On 2021-12-03, Arne Vajhøj <ar...@vajhoej.dk> wrote:
> >> On 12/3/2021 1:55 PM, Simon Clubley wrote:
> >>> I think VSI have done some work with parameter defaults so at least
> >>> some of them will not be an issue on x86-64 VMS.
> >>>
> >>> Is there any option in VMS where, if a system/process goes past some
> >>> percentage (say 80% to 90%) of any system parameter designed to limit
> >>> use of a resource, VMS will issue an OPCOM warning about that system
> >>> parameter (and maybe log it elsewhere as well) ? If not, would this
> >>> be a good option to add to VMS ?
> >>
> >> I think VSI should get rid of >95% of SYSGEN and SYSUAF limits.
> >>
> >> They made sense with a 256 KB VAX but not so much on a 256 GB x86-64.
> >>
> >
> > Agreed, but it would be nice if they would retain an overall ability
> > to stop a single runaway process from gobbling up all the resources
> > without at the same time having to micromanage resources as needed to
> > be done on the resource limited systems of old.
> >
> > Simon.
> >
> I see no reason to remove system parameters. I think that many parameters could
> be evaluated from the perspective of the anticipated systems being used, and
> where there is no reason to not do so, set defaults to take advantage of those
> anticipated systems. This should get rid of much of the need for AUTOGEN. This
> should get rid of most of the need for any tuning.
>
> However, getting rid of the parameters would then not allow specific tuning for
> the perhaps handful of uses where such tuning might be necessary. I'm mainly
> thinking of desired restrictions. Just because I cannot think of any such usage
> doesn't mean it will never happen.
> --
> David Froble Tel: 724-529-0450
> Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
> DFE Ultralights, Inc.
> 170 Grimplin Road
> Vanderbilt, PA 15486

It would seem to me that the cost to update VMS to remove the parameters would be more than VSI wants to pay. Why remove them, make them arbitrarily high (or low) such that they are effectively "not there". Why make all kinds of source changes just to remove something that has little overhead? Do the values change over time, yes. It is difficult to make those changes, NO. Are changes made frequently, NO. Seems to me that this is one case where "if it aint broke..."

Haing the flexibility to alter how the system uses resources will always benefit someone somewhere. I would rather have control than not. But I have had the pleasure of using this system for 40 years and know it well enough to know how to use those controls effectively. Yes, in the hands of people that don't know better, bad things can happen, but the same can be said of other areas too.

On 12/6/2021 10:20 PM, abrsvc wrote:
> On Monday, December 6, 2021 at 8:26:38 PM UTC-5, Dave Froble wrote:
>> On 12/6/2021 1:29 PM, Simon Clubley wrote:
>>> On 2021-12-03, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>>>> On 12/3/2021 1:55 PM, Simon Clubley wrote:
>>>>> I think VSI have done some work with parameter defaults so at least
>>>>> some of them will not be an issue on x86-64 VMS.
>>>>>
>>>>> Is there any option in VMS where, if a system/process goes past some
>>>>> percentage (say 80% to 90%) of any system parameter designed to limit
>>>>> use of a resource, VMS will issue an OPCOM warning about that system
>>>>> parameter (and maybe log it elsewhere as well) ? If not, would this
>>>>> be a good option to add to VMS ?
>>>>
>>>> I think VSI should get rid of >95% of SYSGEN and SYSUAF limits.
>>>>
>>>> They made sense with a 256 KB VAX but not so much on a 256 GB x86-64.
>>>>
>>>
>>> Agreed, but it would be nice if they would retain an overall ability
>>> to stop a single runaway process from gobbling up all the resources
>>> without at the same time having to micromanage resources as needed to
>>> be done on the resource limited systems of old.
>>>
>>> Simon.
>>>
>> I see no reason to remove system parameters. I think that many parameters could
>> be evaluated from the perspective of the anticipated systems being used, and
>> where there is no reason to not do so, set defaults to take advantage of those
>> anticipated systems. This should get rid of much of the need for AUTOGEN. This
>> should get rid of most of the need for any tuning.
>>
>> However, getting rid of the parameters would then not allow specific tuning for
>> the perhaps handful of uses where such tuning might be necessary. I'm mainly
>> thinking of desired restrictions. Just because I cannot think of any such usage
>> doesn't mean it will never happen.
>> --
>> David Froble Tel: 724-529-0450
>> Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
>> DFE Ultralights, Inc.
>> 170 Grimplin Road
>> Vanderbilt, PA 15486
>
> It would seem to me that the cost to update VMS to remove the parameters would be more than VSI wants to pay. Why remove them, make them arbitrarily high (or low) such that they are effectively "not there". Why make all kinds of source changes just to remove something that has little overhead? Do the values change over time, yes. It is difficult to make those changes, NO. Are changes made frequently, NO. Seems to me that this is one case where "if it aint broke..."
>
> Haing the flexibility to alter how the system uses resources will always benefit someone somewhere. I would rather have control than not. But I have had the pleasure of using this system for 40 years and know it well enough to know how to use those controls effectively. Yes, in the hands of people that don't know better, bad things can happen, but the same can be said of other areas too.
>

I'll always remember one event. A customer decided to adjust default working
set rather high, "for better performance". Unfortunately, when starting up the
process, the OS had to go and gather all that memory and assign it to the new
process. Not only was the login rather slow, but, the rest of the running
processes got real slow.

Me: Did you read the manual before playing with the system parameters?
Marie: No.
Me: Did you think the manual should be ignored?
Marie: No.

Now women are never wrong, right? I could see Marie was getting a bit upset
with my attitude. So I backed off, explained what she had done, and settled for
a promise (do women keep them?) that she would ask me before doing such things,
and saved my life.

:-)

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

In article <solnaj$uvn$5@dont-email.me>, Simon Clubley
<clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

> >> > Using commercial software has nothing to do with VMS licenses.
> >>
> >> Huh ?????????????????
> >
> > ????????
> >
> > Obviously VMS is commercial and its use involves VMS licenses. That is
> > not the topic here. The question is whether the hobbyist license would
> > cover open-source development on VMS for commercial software and, if so,
> > if that would be the case only if the developer received no
> > compensation.
>
> I think David might be asking if you can run commercial software on
> a hobbyist system.
>
> For example, if you could somehow get hold of a legal copy of Word Perfect
> for Alpha, could you run it on a hobbyist system for personal use ?
>
> If so, that's a good question, and I don't know the answer.

VMS licenses are relevant for running VMS. It is clear that the
hobbyist license is not applicable if I use VMS, or anything running on
it, for commercial purposes, meaning that I profit from it. But if
someone write a program which does something which I, as a hobbyist,
want to do---say, just as an example, that it prints out prime
numbers---and charges money for it (thus it is commercial for that
programmer), what type of license VMS is running under is irrelevant.

I can barely conceive of the mindset which thinks that a commercial VMS
license would be needed to run a program which costs money.

In article <61ae67a5$0$693$14726298@news.sunsite.dk>,
=?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:

> >>>> Using commercial software has nothing to do with VMS licenses.
> >>>
> >>> Huh ?????????????????
> >>
> >> ????????
> >>
> >> Obviously VMS is commercial and its use involves VMS licenses. That is
> >> not the topic here. The question is whether the hobbyist license would
> >> cover open-source development on VMS for commercial software and, if so,
> >> if that would be the case only if the developer received no
> >> compensation.
> >
> > I think David might be asking if you can run commercial software on
> > a hobbyist system.
> >
> > For example, if you could somehow get hold of a legal copy of Word Perfect
> > for Alpha, could you run it on a hobbyist system for personal use ?
> >
> > If so, that's a good question, and I don't know the answer.
>
> A license is an agreement between the software vendor and the software
> user and can include limitations on software use.
>
> VSI can and does limit use of VMS under CL. And given that an OS is
> used for everything on a system then it practically limits the use
> of the entire system.
>
> So a CL licensed system cannot be used for anything commercial.
>
> It does not make any sense for VSI to limit what SW can be installed
> on the system and what licenses they come under. And I do not remember
> there being anything like that in the CL license.
>
> So I cannot see why you cannot install your paid WP software
> on the system - just note that even though the WP license may
> permit it then the VMS license still prohibits commercial
> work including in WP as WP use the OS.

Right. "Commercial" with regard to VMS licenses means whether the owner
of that license profits or not. What other software is running on the
system and what licenses it requires is completely irrelevant.

In article <som4dg$edu$1@dont-email.me>, Dave Froble
<davef@tsoft-inc.com> writes:

> On 12/6/2021 2:12 PM, Simon Clubley wrote:
> > On 2021-12-05, Phillip Helbig (undress to reply) <helbig@asclothestro.multivax.de> wrote:
> >> In article <soj03a$202$2@dont-email.me>, Dave Froble
> >> <davef@tsoft-inc.com> writes:
> >>
> >>>>>>> With the VSI Community License Program, members of the community can
> >>>>>>> download OpenVMS for free for learning, open source development, and
> >>>>>>> exchanging knowledge of the operating system on Alpha and Integrity
> >>>>>>> systems. This program replaces the HP Hobbyist program.
> >>>>>>
> >>>>>> The wording has changed a bit. But it is still non-commercial.
> >>>>>> Open-source can be non-commercial, but it can also be commercial.
> >>>>>
> >>>>> Isn't there a difference between working on commercial software, such
> >>>>> as porting to VMS, and using commercial software?
> >>>>
> >>>> Using commercial software has nothing to do with VMS licenses.
> >>>
> >>> Huh ?????????????????
> >>
> >> ????????
> >>
> >> Obviously VMS is commercial and its use involves VMS licenses. That is
> >> not the topic here. The question is whether the hobbyist license would
> >> cover open-source development on VMS for commercial software and, if so,
> >> if that would be the case only if the developer received no
> >> compensation.
> >>
> >
> > I think David might be asking if you can run commercial software on
> > a hobbyist system.
> >
> > For example, if you could somehow get hold of a legal copy of Word Perfect
> > for Alpha, could you run it on a hobbyist system for personal use ?
> >
> > If so, that's a good question, and I don't know the answer.
> >
> > Simon.
> >
>
> No. David took one look at the statement:
>
> "Using commercial software has nothing to do with VMS licenses."
>
> Now, if Phillip meant to refer to hobbyist or CL or ISV licenses, he should have
> written that. He didn't.

The statement quoted immediately above was not written by me, merely
quoted by me.

In article <soms96$1nen$3@gioia.aioe.org>,
helbig@asclothestro.multivax.de (Phillip Helbig (undress to reply))
writes:

> In article <som4dg$edu$1@dont-email.me>, Dave Froble
> <davef@tsoft-inc.com> writes:
>
> > On 12/6/2021 2:12 PM, Simon Clubley wrote:
> > > On 2021-12-05, Phillip Helbig (undress to reply) <helbig@asclothestro.multivax.de> wrote:
> > >> In article <soj03a$202$2@dont-email.me>, Dave Froble
> > >> <davef@tsoft-inc.com> writes:
> > >>
> > >>>>>>> With the VSI Community License Program, members of the community can
> > >>>>>>> download OpenVMS for free for learning, open source development, and
> > >>>>>>> exchanging knowledge of the operating system on Alpha and Integrity
> > >>>>>>> systems. This program replaces the HP Hobbyist program.
> > >>>>>>
> > >>>>>> The wording has changed a bit. But it is still non-commercial.
> > >>>>>> Open-source can be non-commercial, but it can also be commercial.
> > >>>>>
> > >>>>> Isn't there a difference between working on commercial software, such
> > >>>>> as porting to VMS, and using commercial software?
> > >>>>
> > >>>> Using commercial software has nothing to do with VMS licenses.
> > >>>
> > >>> Huh ?????????????????
> > >>
> > >> ????????
> > >>
> > >> Obviously VMS is commercial and its use involves VMS licenses. That is
> > >> not the topic here. The question is whether the hobbyist license would
> > >> cover open-source development on VMS for commercial software and, if so,
> > >> if that would be the case only if the developer received no
> > >> compensation.
> > >>
> > >
> > > I think David might be asking if you can run commercial software on
> > > a hobbyist system.
> > >
> > > For example, if you could somehow get hold of a legal copy of Word Perfect
> > > for Alpha, could you run it on a hobbyist system for personal use ?
> > >
> > > If so, that's a good question, and I don't know the answer.
> > >
> > > Simon.
> > >
> >
> > No. David took one look at the statement:
> >
> > "Using commercial software has nothing to do with VMS licenses."
> >
> > Now, if Phillip meant to refer to hobbyist or CL or ISV licenses, he should have
> > written that. He didn't.
>
> The statement quoted immediately above was not written by me, merely
> quoted by me.

Sorry, it was. See below. But when I wrote it, the text I quoted makes
it clear that I was referring to the VSI community license.

----------8<--------------------------------------------------------------------

Path: aioe.org!1XSHQO4JptEK3D6Pc9T+OA.user.46.165.242.75.POSTED!not-for-mail
From: helbig@asclothestro.multivax.de (Phillip Helbig (undress to reply))
Newsgroups: comp.os.vms
Subject: Re: What Will Drive More OpenVMS Adoption?
Date: Sun, 5 Dec 2021 15:55:48 -0000 (UTC)
Organization: Multivax C&R
Message-ID: <soine4$ovr$1@gioia.aioe.org>
Xref: aioe.org comp.os.vms:132863

In article <soin99$1ac$1@dont-email.me>, Dave Froble
<davef@tsoft-inc.com> writes:

> >> With the VSI Community License Program, members of the community can
> >> download OpenVMS for free for learning, open source development, and
> >> exchanging knowledge of the operating system on Alpha and Integrity
> >> systems. This program replaces the HP Hobbyist program.
> >
> > The wording has changed a bit. But it is still non-commercial.
> > Open-source can be non-commercial, but it can also be commercial.
>
> Isn't there a difference between working on commercial software, such
> as porting to VMS, and using commercial software?

Using commercial software has nothing to do with VMS licenses.

AT BEST, the hobbyist license could be construed to be valid for working
on commercial software, but without receiving any sort of financial
reward, directly or indirectly, for doing so.

> "Using commercial software has nothing to do with VMS licenses."

I guess that it can depend on what one means by "commercial software". I
took it to mean "software which has been purchased" and, indeed, as far
as I know, that has nothing to do with what type of VMS license one has.
Some might take it to mean "software with which money is earned"
(whether that software was purchased, obtained for free, or
self-written), in which case, of course, a commercial VMS license is
needed.

On 12/6/21 11:40 PM, Dave Froble wrote:
> On 12/6/2021 10:20 PM, abrsvc wrote:
>> On Monday, December 6, 2021 at 8:26:38 PM UTC-5, Dave Froble wrote:
>>> On 12/6/2021 1:29 PM, Simon Clubley wrote:
>>>> On 2021-12-03, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>>>>> On 12/3/2021 1:55 PM, Simon Clubley wrote:
>>>>>> I think VSI have done some work with parameter defaults so at least
>>>>>> some of them will not be an issue on x86-64 VMS.
>>>>>>
>>>>>> Is there any option in VMS where, if a system/process goes past some
>>>>>> percentage (say 80% to 90%) of any system parameter designed to limit
>>>>>> use of a resource, VMS will issue an OPCOM warning about that system
>>>>>> parameter (and maybe log it elsewhere as well) ? If not, would this
>>>>>> be a good option to add to VMS ?
>>>>>
>>>>> I think VSI should get rid of >95% of SYSGEN and SYSUAF limits.
>>>>>
>>>>> They made sense with a 256 KB VAX but not so much on a 256 GB x86-64.
>>>>>
>>>>
>>>> Agreed, but it would be nice if they would retain an overall ability
>>>> to stop a single runaway process from gobbling up all the resources
>>>> without at the same time having to micromanage resources as needed to
>>>> be done on the resource limited systems of old.
>>>>
>>>> Simon.
>>>>
>>> I see no reason to remove system parameters. I think that many
>>> parameters could
>>> be evaluated from the perspective of the anticipated systems being
>>> used, and
>>> where there is no reason to not do so, set defaults to take advantage
>>> of those
>>> anticipated systems. This should get rid of much of the need for
>>> AUTOGEN. This
>>> should get rid of most of the need for any tuning.
>>>
>>> However, getting rid of the parameters would then not allow specific
>>> tuning for
>>> the perhaps handful of uses where such tuning might be necessary. I'm
>>> mainly
>>> thinking of desired restrictions. Just because I cannot think of any
>>> such usage
>>> doesn't mean it will never happen.
>>> --
>>> David Froble Tel: 724-529-0450
>>> Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
>>> DFE Ultralights, Inc.
>>> 170 Grimplin Road
>>> Vanderbilt, PA 15486
>>
>> It would seem to me that the cost to update VMS to remove the
>> parameters would be more than VSI wants to pay.  Why remove them, make
>> them arbitrarily high (or low) such that they are effectively "not
>> there".  Why make all kinds of source changes just to remove something
>> that has little overhead?  Do the values change over time, yes.  It is
>> difficult to make those changes, NO.  Are changes made frequently,
>> NO.  Seems to me that this is one case where "if it aint broke..."
>>
>> Haing the flexibility to alter how the system uses resources will
>> always benefit someone somewhere.  I would rather have control than
>> not.  But I have had the pleasure of using this system for 40 years
>> and know it well enough to know how to use those controls
>> effectively.  Yes, in the hands of people that don't know better, bad
>> things can happen, but the same can be said of other areas too.
>>
>
> I'll always remember one event.  A customer decided to adjust default
> working set rather high, "for better performance".  Unfortunately, when
> starting up the process, the OS had to go and gather all that memory and
> assign it to the new process.  Not only was the login rather slow, but,
> the rest of the running processes got real slow.
>
> Me: Did you read the manual before playing with the system parameters?
> Marie: No.
> Me: Did you think the manual should be ignored?
> Marie: No.
>
> Now women are never wrong, right?  I could see Marie was getting a bit
> upset with my attitude.  So I backed off, explained what she had done,
> and settled for a promise (do women keep them?) that she would ask me
> before doing such things, and saved my life.
>
> :-)
>

Cute. I may have told this one here before but just in case I haven't.
:-)

In another lifetime I worked with COBOL and Fortran on a Univac 1100
running Exec-8. Exec-8 has a control language like JCL. One of the
uses is to assign memory for processes before they are run. I got
assigned the project of finding out why a certain program would stop
running for an extended period of time and then just continue as if
nothing had happened. Turned out someone thought the COBOL SORT was
going to need a lot of memory so they added a parameter tot he ECL
stream to ask for all the system memory before running. So, every
time the process was run it would run fine until it hit that point.
Then it would sit there waiting for every other process to end grabbing
the memory each time until it had all the memory. Of course this also
stopped other jobs from coming out of the batch queue making it seem
like the machine was hung. Once it had all the memory the sort ran
in about a minute released the excess memory and the machine went
back to normal. Lesson learned: Parameters do matter. using a more
reasonable value in the memory allocation resulted in normal operations
and no more late night calls about a hung machine. :-)

bill

On 12/6/2021 11:40 PM, Dave Froble wrote:

> Now women are never wrong, right? I could see Marie was getting a
> bit upset with my attitude. So I backed off, explained what she had
> done, and settled for a promise (do women keep them?) that she would
> ask me before doing such things, and saved my life.

How about leaving the misogyny out of your narrative?

--

-- Rob

On 12/6/2021 10:20 PM, abrsvc wrote:
> It would seem to me that the cost to update VMS to remove the
> parameters would be more than VSI wants to pay. Why remove them,
> make them arbitrarily high (or low) such that they are effectively
> "not there". Why make all kinds of source changes just to remove
> something that has little overhead? Do the values change over time,
> yes. It is difficult to make those changes, NO. Are changes made
> frequently, NO. Seems to me that this is one case where "if it aint
> broke..."

It would be hard to justify removing them as a separate project. But if
some code needed a major overhaul for other reasons, then they could be
ripped out.

> Haing the flexibility to alter how the system uses resources will
> always benefit someone somewhere. I would rather have control than
> not. But I have had the pleasure of using this system for 40 years
> and know it well enough to know how to use those controls
> effectively. Yes, in the hands of people that don't know better, bad
> things can happen, but the same can be said of other areas too.

Old VMS'ers knows about this stuff.

But for any new VMS'ers it is just something that looks unnecessary
complicated.

Arne