[Info-vax] SOLVED : Re: Process quota problem after upgrade to 8.4-2L1

[Stephen Hoffman]

On 2020-12-22 11:07:19 +0000, Joukj said:

> Stephen Hoffman wrote:
>> 
>> Check the PQL minimum parameter settings, check the current SYSTEM 
>> quotas from a fresh OpenVMS install and also check those quotas against 
>> current DECwindows requirements, and then failing that incrementally 
>> double each of the pooled process quotas (BYTLM, ENQLM, FILLM, 
>> PGFLQUOTA, PRCLM, TQELM) until it starts working again.
>> 
>> OpenVMS upgrades and DECwindows upgrades don't raise user quotas to any 
>> newly-applied minimums that might have gotten shipped.
>> 
>> ~Forty years in, we're also prolly not going to see better logging 
>> implemented within $creprc, or see $creprc switching to the 
>> long-available quota-specific errors due to "compatibility", either.
>> 
> Thanks Hoff, You pointed me to the Right solution: Doubling all the 
> pql_m* parameters did not help. But setting PQL_MPGFLQUOTA to 18000000 
> (may be too high but set the same as for "user" system) did the trick.
> So also Tad's suggestion was correct. It wer the pagefile-quota.

Ah, I meant keep doubling the quotas and the PQLs until it works, and 
not to double the settings just once. And for cases such as this, it's 
usually involving a pooled quota.

Something within OpenVMS and/or DECwindows here either isn't specifying 
quotas, or isn't specifying sufficient quotas. Which has happened 
before. There was an annoying DECwindows quota bug a while back, where 
a low quota was detected, but the quota-increasing code, well, didn't. 
So the low-quota triggered again. Lather, rinse, repeat.)

SYSTEM quotas have been increased once or twice before too, and may 
well need another increase. IIRC, those quota increases were not 
applied to existing SYSTEM usernames, just to newly-created ones.

I can guarantee you that there are stale quota listings in various 
parts of the OpenVMS docs too, and the older the docs the staler the 
settings. Not unless VSI has implemented a feedback connection between 
the testing environment and the doc. Which has been discussed, but I'd 
doubt exists. And most of us are working with more memory and more 
storage than before. Most of us only look at quotas when something 
blows up, and very few watch quota usage trends.

Cluster satellite workstations are also not configurations I'd expect 
to see a whole lot of usage or testing, generally. I'd expect little 
usage of these configurations outside of hobbyist environments. We'd 
see yet fewer of these cases too, if OpenVMS were better about its 
installation and re-installation and provisioning and which would ease 
cloning in combination with better LDAP support—storage is cheap, 
network-served system storage is slow, and few (~nobody?) is running 10 
GbE or 40 GbE satellites.

Years ago, I wrote some code that detected and automatically increased 
quotas on all users of an environment to established minimum values, 
and that solved a large number of weird problems within the 
environment. Nowadays, I prefer to combine that app quota startup check 
with a C run-time settings startup check. But establishing new minimum 
quotas was still a manual process, even if then raising the users' 
settings was automatic.

Here's a question for each of us to ponder for our own environments: 
when was the last time that a quota check actually prevented a wider 
hang in our local environments, rather than triggering a failure? Most 
of us have seen run-away leaks, but how many have seen one of those app 
leaks then cause system-wide effects rather than blowing out whatever 
the leaking app was? Are our possibly-too-low-quota settings even worth 
it?


-- 
Pure Personal Opinion | HoffmanLabs LLC