On 12/7/2021 10:40 AM, Robert A. Brooks wrote:
> 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?
>

I didn't, and don't, and never will, consider it that word that isn't in my
vocabulary. Neither is "politically correct".

I'm a realist. Some things just are. Ignoring them doesn't change 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

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

> Some things just are. Ignoring them doesn't change that.

Good self-description there. :-)

On 12/7/21 10:54 AM, Dave Froble wrote:
> On 12/7/2021 10:40 AM, Robert A. Brooks wrote:
>> 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?
>>
>
> I didn't, and don't, and never will, consider it that word that isn't in
> my vocabulary.

Thanks for explaining that your misogyny is due to willful ignorance
rather than unconscious bias. It's still not welcome here.

On 2021-12-06, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> 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.
>

Yes, it could indeed be fixed very easily by VSI.

However, until they actually do fix it, this affects potential new
customers right here in 2021 and not just in some future time period.

Very few customers would agree to tie the future of their own companies
so closely to the future viability of VSI.

As things stand at the moment, those potential customers will be
severely damaged if VSI fails and their VMS systems suddenly stop
working one day when the licences expire.

Why would a manager in a customer company ever agree to such a thing
unless they were _absolutely_ forced to go to VSI ?

This policy by VSI could easily push more customers directly towards a
move to another OS, even if the cost of the port to the other OS
would otherwise have been greater than the customer was originally
willing to pay.

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

And that's the annoying thing. There are multiple ways to fix this,
but VSI are taking a short-term approach even with the long-term
effect it is going to have on potential customers thinking of going
to VSI. Just look at VSI's reaction to the French customers trying
to discuss this with VSI.

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 19:45, Arne Vajhøj 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.

Well, there is certainly a big difference between max physical memory
allowed, and max virtual memory.

And you probably want to have a reasonable working set at all times. And
if you go below some lower threshold, you probably don't want to
schedule the process, but instead wait until some more resources are
available. And meanwhile maybe swap out whatever is in there to free up
more resources for others.

And what does maxcpu mean? You're only allowed to use this much of a CPU
no matter how idle it is?

Johnny

On Wednesday, December 8, 2021 at 6:46:27 AM UTC-5, Johnny Billquist wrote:
..
>
> And what does maxcpu mean? You're only allowed to use this much of a CPU
> no matter how idle it is?
>
> Johnny

Yes. There is a CPU field within the authorize record that limits the CPU time available for a process or one session.
This goes back to the timesharing days when CPU time was charged and accounts were limited by time (both CPU and elapsed).
I haven't seen this used on over 35 years. All accounts these days have this set to 0 which is infinite time allowed.

Dan

On 08/12/2021 14:25, abrsvc wrote:
> On Wednesday, December 8, 2021 at 6:46:27 AM UTC-5, Johnny Billquist wrote:
> .
>>
>> And what does maxcpu mean? You're only allowed to use this much of a CPU
>> no matter how idle it is?
>>
>> Johnny
>
> Yes. There is a CPU field within the authorize record that limits the CPU time available for a process or one session.
> This goes back to the timesharing days when CPU time was charged and accounts were limited by time (both CPU and elapsed).
> I haven't seen this used on over 35 years. All accounts these days have this set to 0 which is infinite time allowed.
>
> Dan
>

I have seen it used whan there is a danger of a batch job going into an unstoppable loop

--
Mike R.
Home: http://alpha.mike-r.com/
QOTD: http://alpha.mike-r.com/qotd.php
No Micro$oft products were used in the URLs above, or in preparing this message.
Recommended reading: http://www.catb.org/~esr/faqs/smart-questions.html#before
and: http://alpha.mike-r.com/jargon/T/top-post.html
Missile address: N31.7624/E34.9691

On 12/8/2021 6:46 AM, Johnny Billquist wrote:
> On 2021-12-06 19:45, Arne Vajhøj 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.
>
> Well, there is certainly a big difference between max physical memory
> allowed, and max virtual memory.

True. I was thinking physical.

But if necessary MAXPHYSMEM and MAXVIRTMEM.

The current number of WS parameters seems excessive.

> And you probably want to have a reasonable working set at all times. And
> if you go below some lower threshold, you probably don't want to
> schedule the process, but instead wait until some more resources are
> available. And meanwhile maybe swap out whatever is in there to free up
> more resources for others.

But does this need to be configurable and tunable or could we just leave
that to the OS?

I am advocating to leave it to the OS.

> And what does maxcpu mean? You're only allowed to use this much of a CPU
> no matter how idle it is?

That is usually a blocker of code going into infinite loop or
crazy stuff so yes.

Arne

On 2021-12-08 13:25, abrsvc wrote:
> On Wednesday, December 8, 2021 at 6:46:27 AM UTC-5, Johnny Billquist wrote:
> .
>>
>> And what does maxcpu mean? You're only allowed to use this much of a CPU
>> no matter how idle it is?
>>
>> Johnny
>
> Yes. There is a CPU field within the authorize record that limits the CPU time available for a process or one session.
> This goes back to the timesharing days when CPU time was charged and accounts were limited by time (both CPU and elapsed).
> I haven't seen this used on over 35 years. All accounts these days have this set to 0 which is infinite time allowed.

I had forgotten all about that. Thanks for reminding me. :-)

But that wouldn't be in system parameters, but accounting... And
potentially different for different users or processes. But I guess the
system parameter could give an upper limit, maybe... But some processes
obviously needs to be excluded from that limit.

Johnny

On 12/15/2021 4:05 AM, Johnny Billquist wrote:
> On 2021-12-08 13:25, abrsvc wrote:
>> On Wednesday, December 8, 2021 at 6:46:27 AM UTC-5, Johnny Billquist
>> wrote:
>> .
>>>
>>> And what does maxcpu mean? You're only allowed to use this much of a CPU
>>> no matter how idle it is?
>>>
>>> Johnny
>>
>> Yes.  There is a CPU field within the authorize record that limits the
>> CPU time available for a process or one session.
>> This goes back to the timesharing days when CPU time was charged and
>> accounts were limited by time (both CPU and elapsed).
>> I haven't seen this used on over 35 years.  All accounts these days
>> have this set to 0 which is infinite time allowed.
>
> I had forgotten all about that. Thanks for reminding me. :-)
>
> But that wouldn't be in system parameters, but accounting... And
> potentially different for different users or processes. But I guess the
> system parameter could give an upper limit, maybe... But some processes
> obviously needs to be excluded from that limit.

Very different.

But when I said that I think VSI could drop most of all those
limits I was thinking all limits (SYSGEN parameter, SYSUAF
limits etc.).

Arne