Post by Joukj Post by Stephen Hoffman
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
Pure Personal Opinion | HoffmanLabs LLC