[Info-vax] System parameters (and a marketing suggestion), was: Re: What Will Drive More OpenVMS Adoption?

[Bill Gunshannon]

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