Discussion:
Process quota problem after upgrade to 8.4-2L1
Add Reply
Joukj
2020-12-21 09:26:10 UTC
Reply
Permalink
Hi all,

I recently upgraded my alpha's from OpenVMS 8.4 to 8.4-2L1. Everything
was fine and all the satelites came up smoothly with Decwindows running.
After some days I had to reboot a satelite, but it appears that is
booting correctly, but has problems to get the Decwindow-login screen on
the display. It continues retrying, but every time it fails.

When looking in the accounting logs I see entries like:

Username: SYSTEM UIC: [SYSTEM]
Account: <start> Finish time: 21-DEC-2020
09:27:35.09
Process ID: 23200367 Start time: 21-DEC-2020
09:27:35.01
Owner ID: 23200366 Elapsed time: 0
00:00:00.07
Terminal name: Processor time: 0
00:00:00.01
Remote node addr: Priority: 4
Remote node name: Privilege <31-00>: 4010E0A5
Remote ID: Privilege <63-32>: 00000060
Remote full name:
Posix UID: -2 Posix GID: -2 (%XFFFFFFFE)
Queue entry: Final status code: 0000001C
Queue name:
Job name:
Final status text: %SYSTEM-F-EXQUOTA, process quota exceeded
Page faults: 42 Direct IO: 0
Page fault reads: 9 Buffered IO: 10
Peak working set: 912 Volumes mounted: 0
Peak page file: 167408 Images executed: 1


Just wondering what quota is exceed. For user system I have the following:

Maxjobs: 0 Fillm: 5000 Bytlm: 2100000
Maxacctjobs: 0 Shrfillm: 0 Pbytlm: 0
Maxdetach: 0 BIOlm: 1024 JTquota: 60000
Prclm: 40 DIOlm: 1024 WSdef: 24000
Prio: 4 ASTlm: 300 WSquo: 66536
Queprio: 0 TQElm: 400 WSextent: 30000
CPU: (none) Enqlm: 2000 Pgflquo: 18000000

Can someone get me some hints how to solve this problem?


Regards
Jouk
Phillip Helbig (undress to reply)
2020-12-21 10:50:47 UTC
Reply
Permalink
Post by Joukj
I recently upgraded my alpha's from OpenVMS 8.4 to 8.4-2L1. Everything
was fine and all the satelites came up smoothly with Decwindows running.
After some days I had to reboot a satelite, but it appears that is
booting correctly, but has problems to get the Decwindow-login screen on
the display. It continues retrying, but every time it fails.
I believe that that is exactly the same problem I posted here a few
years ago, though in my case it was going from 7.3-2 to 8.4. Neither
the upgraded machine nor the satellites booting from it get to the
DECwindows screen. Which is why I left the other two nodes in the
cluster at 7.3-2. I spent about a month digging around, following
suggestions from the newsgroup, and so on, but was never able to figure
it out.

We've both done VMS upgrades many times. At least in my case, nothing
ever went wrong, and apart from the DECwindows problem, my 8.4 is OK.

I've decided that it isn't worth the trouble since I hope to go to VMS
on x86 as soon as feasible.
Joukj
2020-12-21 11:32:56 UTC
Reply
Permalink
Post by Phillip Helbig (undress to reply)
Post by Joukj
I recently upgraded my alpha's from OpenVMS 8.4 to 8.4-2L1. Everything
was fine and all the satelites came up smoothly with Decwindows running.
After some days I had to reboot a satelite, but it appears that is
booting correctly, but has problems to get the Decwindow-login screen on
the display. It continues retrying, but every time it fails.
I believe that that is exactly the same problem I posted here a few
years ago, though in my case it was going from 7.3-2 to 8.4. Neither
the upgraded machine nor the satellites booting from it get to the
DECwindows screen. Which is why I left the other two nodes in the
cluster at 7.3-2. I spent about a month digging around, following
suggestions from the newsgroup, and so on, but was never able to figure
it out.
We've both done VMS upgrades many times. At least in my case, nothing
ever went wrong, and apart from the DECwindows problem, my 8.4 is OK.
I've decided that it isn't worth the trouble since I hope to go to VMS
on x86 as soon as feasible.
In my case just after the upgrade everything was fine.

Then I upgraded some C/C++, fortran compileers and Decset.

After that rebooting gave the problem.
Volker Halle
2020-12-21 12:54:21 UTC
Reply
Permalink
Jouk,

enable image accounting (SET ACC/ENA=IMAGE) to find out exactly which image exits with %X1C (EXQUOTA). Then consider using System Service Logging (SSLOG, new in V8.4) to find out, which system service generates this error. This may give you an idea, about which quota is exceeded.

Assuming the image is DECW$STARTLOGIN.EXE, it seems to be invoked from DECW$STARTAPPS.COM, so you could enable SSLOG in this procedure, before the image is being invoked.

Volker.
Joukj
2020-12-21 13:57:32 UTC
Reply
Permalink
Post by Volker Halle
enable image accounting (SET ACC/ENA=IMAGE) to find out exactly which image exits with %X1C (EXQUOTA). Then consider using System Service Logging (SSLOG, new in V8.4) to find out, which system service generates this error. This may give you an idea, about which quota is exceeded.
Assuming the image is DECW$STARTLOGIN.EXE, it seems to be invoked from DECW$STARTAPPS.COM, so you could enable SSLOG in this procedure, before the image is being invoked.
Hmm... I get with SET ACC/ENA=IMAGE :


21-DEC-2020 14:29:12 PROCESS SUBPROCESS SYSTEM 23E0097A
0000001C
21-DEC-2020 14:29:14 IMAGE LOGINOUT SYSTEM 23E00979
00000000
21-DEC-2020 14:29:14 PROCESS DETACHED SYSTEM 23E00979
00000000

If you list in more detail you find that the problamtic process
(id=23E0097A) is started from process (id=23E00979), which is running
loginout.exe.
What does that one launche that is killed in seconds, whithout listing
an image.

Jouk
Joukj
2020-12-22 09:37:04 UTC
Reply
Permalink
Post by Volker Halle
enable image accounting (SET ACC/ENA=IMAGE) to find out exactly which
image exits with %X1C (EXQUOTA). Then consider using System Service
Logging (SSLOG, new in V8.4) to find out, which system service
generates this error. This may give you an idea, about which quota is
exceeded.
Assuming the image is DECW$STARTLOGIN.EXE, it seems to be invoked from
DECW$STARTAPPS.COM, so you could enable SSLOG in this procedure,
before the image is being invoked.
21-DEC-2020 14:29:12 PROCESS SUBPROCESS SYSTEM 23E0097A 0000001C
21-DEC-2020 14:29:14 IMAGE LOGINOUT SYSTEM 23E00979 00000000
21-DEC-2020 14:29:14 PROCESS DETACHED SYSTEM 23E00979 00000000
If you list in more detail you find that the problamtic process
(id=23E0097A) is started from process (id=23E00979), which is running
loginout.exe.
What does that one launche that is killed in seconds, whithout listing
an image.
Jouk
My guess is that the process 23E00979 supposed to be dtlogin, which
should run loginout.exe and should have subprocess, dtgreet, running
CDE$SYSTEM_COMMON:[BIN]dtgreet.exe, but that this last process crashes
everytime.
Joukj
2020-12-21 14:39:39 UTC
Reply
Permalink
Post by Volker Halle
enable image accounting (SET ACC/ENA=IMAGE) to find out exactly which image exits with %X1C (EXQUOTA). Then consider using System Service Logging (SSLOG, new in V8.4) to find out, which system service generates this error. This may give you an idea, about which quota is exceeded.
Assuming the image is DECW$STARTLOGIN.EXE, it seems to be invoked from DECW$STARTAPPS.COM, so you could enable SSLOG in this procedure, before the image is being invoked.
Tried to switch sslog on by
set proc/sslog=(status=on,count=4)
but no sslog.dat is created. So I'm putting it in the wrong place in the
.com-files or it does not work for me.
Joukj
2020-12-21 15:43:41 UTC
Reply
Permalink
Post by Volker Halle
enable image accounting (SET ACC/ENA=IMAGE) to find out exactly which image exits with %X1C (EXQUOTA). Then consider using System Service Logging (SSLOG, new in V8.4) to find out, which system service generates this error. This may give you an idea, about which quota is exceeded.
Assuming the image is DECW$STARTLOGIN.EXE, it seems to be invoked from DECW$STARTAPPS.COM, so you could enable SSLOG in this procedure, before the image is being invoked.
The process in which DECW$STARTAPPS.COM ends with:
Final status text: %CLI-S-NORMAL, normal successful completion

Jouk
Stephen Hoffman
2020-12-21 16:25:44 UTC
Reply
Permalink
Post by Joukj
I recently upgraded my alpha's from OpenVMS 8.4 to 8.4-2L1. Everything
was fine and all the satelites came up smoothly with Decwindows running.
After some days I had to reboot a satelite, but it appears that is
booting correctly, but has problems to get the Decwindow-login screen
on the display. It continues retrying, but every time it fails.
...
Final status text: %SYSTEM-F-EXQUOTA, process quota exceeded
...
Can someone get me some hints how to solve this problem?
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.
--
Pure Personal Opinion | HoffmanLabs LLC
Joukj
2020-12-22 09:21:01 UTC
Reply
Permalink
Post by Stephen Hoffman
Post by Joukj
I recently upgraded my alpha's from OpenVMS 8.4 to 8.4-2L1. Everything
was fine and all the satelites came up smoothly with Decwindows running.
After some days I had to reboot a satelite, but it appears that is
booting correctly, but has problems to get the Decwindow-login screen
on the display. It continues retrying, but every time it fails.
...
Final status text: %SYSTEM-F-EXQUOTA, process quota exceeded
...
Can someone get me some hints how to solve this problem?
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.
playing around with the quota, did not yet give anny solution to the
problem.

However, I was able to start the "Old" desktop.
So the decw-server seems to startup correctly

What do I need to track problems in the "new" (or CDE) desktop?
Joukj
2020-12-22 11:07:19 UTC
Reply
Permalink
Post by Stephen Hoffman
Post by Joukj
I recently upgraded my alpha's from OpenVMS 8.4 to 8.4-2L1. Everything
was fine and all the satelites came up smoothly with Decwindows running.
After some days I had to reboot a satelite, but it appears that is
booting correctly, but has problems to get the Decwindow-login screen
on the display. It continues retrying, but every time it fails.
...
Final status text: %SYSTEM-F-EXQUOTA, process quota exceeded
...
Can someone get me some hints how to solve this problem?
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.


Thanks all of you for the help
Phillip Helbig (undress to reply)
2020-12-22 14:33:25 UTC
Reply
Permalink
Post by Joukj
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.
Thanks all of you for the help
I'll see if this helps my problem. I remember adjusting quotas, but not
system parameters.

For comparison, what are the UAF parameters for an account which (now)
works and what hardware is it running on?
Joukj
2020-12-22 15:03:21 UTC
Reply
Permalink
Post by Phillip Helbig (undress to reply)
Post by Joukj
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.
Thanks all of you for the help
I'll see if this helps my problem. I remember adjusting quotas, but not
system parameters.
For comparison, what are the UAF parameters for an account which (now)
works and what hardware is it running on?
The system-account UAF quoata is as in the first entry

I Added in the modparams.dat:

MIN_PQL_MASTLM=200
MIN_PQL_MBIOLM=200
MIN_PQL_MBYTLM=200000
MIN_PQL_MDIOLM=200
MIN_PQL_MFILLM=200
MIN_PQL_MPGFLQUOTA=18000000
MIN_PQL_MPRCLM=20
MIN_PQL_MWSQUOTA=8192
MIN_PQL_MWSEXTENT=180000
MIN_PQL_MENQLM=600

But I think the change for MIN_PQL_MPGFLQUOTA is the most important one.
Joukj
2020-12-22 15:04:52 UTC
Reply
Permalink
Post by Phillip Helbig (undress to reply)
Post by Joukj
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.
Thanks all of you for the help
I'll see if this helps my problem. I remember adjusting quotas, but not
system parameters.
For comparison, what are the UAF parameters for an account which (now)
works and what hardware is it running on?
The ones where it failed were both DPWS500's, but I have not yet tested
on my XP1000 machines.
Phillip Helbig (undress to reply)
2020-12-22 21:24:46 UTC
Reply
Permalink
Post by Joukj
The ones where it failed were both DPWS500's, but I have not yet tested
on my XP1000 machines.
Very similar. I had the failure on XP100, and the 7.3-2 machines are
PWS500's.
Arne Vajhøj
2020-12-22 18:05:50 UTC
Reply
Permalink
Post by Phillip Helbig (undress to reply)
Post by Joukj
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.
I'll see if this helps my problem. I remember adjusting quotas, but not
system parameters.
My understanding is that setting PQL_MPGFLQUOTA sets
the minimum PGFLQUOTA so that even those usernames
with lower values in SYSUAF get the PQL_MPGFLQUOTA
value.

Are there scenarios where PQL_MPGFLQUOTA is required because
SYSUAF value is not used??

Arne
Chris Townley
2020-12-22 19:45:26 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Joukj
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.
I'll see if this helps my problem.  I remember adjusting quotas, but not
system parameters.
My understanding is that setting PQL_MPGFLQUOTA sets
the minimum PGFLQUOTA so that even those usernames
with lower values in SYSUAF get the PQL_MPGFLQUOTA
value.
Are there scenarios where PQL_MPGFLQUOTA is required because
SYSUAF value is not used??
Arne
I recollect that the PQL parameters are used for detached jobs - UAF for
interactive, and batch queue settings for batch jobs

Chris
Jan-Erik Söderholm
2020-12-22 23:13:01 UTC
Reply
Permalink
Post by Chris Townley
Post by Arne Vajhøj
Post by Joukj
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.
I'll see if this helps my problem.  I remember adjusting quotas, but not
system parameters.
My understanding is that setting PQL_MPGFLQUOTA sets
the minimum PGFLQUOTA so that even those usernames
with lower values in SYSUAF get the PQL_MPGFLQUOTA
value.
Are there scenarios where PQL_MPGFLQUOTA is required because
SYSUAF value is not used??
Arne
I recollect that the PQL parameters are used for detached jobs - UAF for
interactive, and batch queue settings for batch jobs
Chris
Hm... No, PQL params are *not* specific for detached processes. And there
is a dfference between the "default" and the "min" PQL params.

The "min" PQL parameters are always used for any process no matter how
it is started. I'm not sure that you can override them on the RUN command.
They override the UAF params for simple interactive logins, as an example.

Batch queue does not need to have any process parameters specified.
They can, but are not needed. The UAF for the user that runs the batch
job is normaly used.

The "default" params are used when there is no UAF parameters to use.
Like when you do a run/detach and specify your own EXE directly in the
RUN command.

If you do a run/detach/user=xxx and specify LOGINOUT.EXE (with your own
COM file that runs *your* EXE as the /INPUT paramater) a full login will
run and a DCL environment is created for your detached process. And in
that case the UAF params for the specifed username are used (overrided
by the PQL "min" params if they are higher).

The second way, using LOGINOUT.EXE, is needed if you need your process
to have process local logical names. You can then define them in the COM
file before you run your own EXE.

So in the second case using LOGINOUT.EXE, only the PQL "min" parameters
comes into play, the "default" does not replace the UAF parameters. And
your detached process runs in a full DCL environment.

If I'm not completely missing things here...

Jan-Erik.
Chris Townley
2020-12-23 00:13:04 UTC
Reply
Permalink
Post by Jan-Erik Söderholm
Post by Chris Townley
Post by Arne Vajhøj
Post by Joukj
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.
I'll see if this helps my problem.  I remember adjusting quotas, but not
system parameters.
My understanding is that setting PQL_MPGFLQUOTA sets
the minimum PGFLQUOTA so that even those usernames
with lower values in SYSUAF get the PQL_MPGFLQUOTA
value.
Are there scenarios where PQL_MPGFLQUOTA is required because
SYSUAF value is not used??
Arne
I recollect that the PQL parameters are used for detached jobs - UAF
for interactive, and batch queue settings for batch jobs
Chris
Hm... No, PQL params are *not* specific for detached processes. And there
is a dfference between the "default" and the "min" PQL params.
The "min" PQL parameters are always used for any process no matter how
it is started. I'm not sure that you can override them on the RUN command.
They override the UAF params for simple interactive logins, as an example.
Batch queue does not need to have any process parameters specified.
They can, but are not needed. The UAF for the user that runs the batch
job is normaly used.
The "default" params are used when there is no UAF parameters to use.
Like when you do a run/detach and specify your own EXE directly in the
RUN command.
If you do a run/detach/user=xxx and specify LOGINOUT.EXE (with your own
COM file that runs *your* EXE as the /INPUT paramater) a full login will
run and a DCL environment is created for your detached process. And in
that case the UAF params for the specifed username are used (overrided
by the PQL "min" params if they are higher).
The second way, using LOGINOUT.EXE, is needed if you need your process
to have process local logical names. You can then define them in the COM
file before you run your own EXE.
So in the second case using LOGINOUT.EXE, only the PQL "min" parameters
comes into play, the "default" does not replace the UAF parameters. And
your detached process runs in a full DCL environment.
If I'm not completely missing things here...
Jan-Erik.
Thanks - it was a long time ago, so forgive me if not quite right.

We used a lot of the RUN/DETACHED flavour to start detached job
controllers that started various (partially) parameter controlled
images. I had the job later of getting sensible quotas etc. after the
original developers had moved on.

Chris
Dave Froble
2020-12-22 19:49:48 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
Post by Joukj
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.
I'll see if this helps my problem. I remember adjusting quotas, but not
system parameters.
My understanding is that setting PQL_MPGFLQUOTA sets
the minimum PGFLQUOTA so that even those usernames
with lower values in SYSUAF get the PQL_MPGFLQUOTA
value.
Are there scenarios where PQL_MPGFLQUOTA is required because
SYSUAF value is not used??
Arne
This is from 30+ year old memory. Beware!

There are times when no user account is yet available. At that time,
the PQL quotas are used. Should one not be adequate, the debugging gets
"interesting".

At least that's my dim recollection of the issue.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
abrsvc
2020-12-22 19:59:01 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Joukj
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.
I'll see if this helps my problem. I remember adjusting quotas, but not
system parameters.
My understanding is that setting PQL_MPGFLQUOTA sets
the minimum PGFLQUOTA so that even those usernames
with lower values in SYSUAF get the PQL_MPGFLQUOTA
value.
Are there scenarios where PQL_MPGFLQUOTA is required because
SYSUAF value is not used??
Arne
This is from 30+ year old memory. Beware!
There are times when no user account is yet available. At that time,
the PQL quotas are used. Should one not be adequate, the debugging gets
"interesting".
At least that's my dim recollection of the issue.
--
David Froble Tel: 724-529-0450
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
PQL parameters are used when the particular values are not specified in the CREPRC call.
Dave Froble
2020-12-22 20:14:59 UTC
Reply
Permalink
Post by abrsvc
Post by Arne Vajhøj
Post by Joukj
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.
I'll see if this helps my problem. I remember adjusting quotas, but not
system parameters.
My understanding is that setting PQL_MPGFLQUOTA sets
the minimum PGFLQUOTA so that even those usernames
with lower values in SYSUAF get the PQL_MPGFLQUOTA
value.
Are there scenarios where PQL_MPGFLQUOTA is required because
SYSUAF value is not used??
Arne
This is from 30+ year old memory. Beware!
There are times when no user account is yet available. At that time,
the PQL quotas are used. Should one not be adequate, the debugging gets
"interesting".
At least that's my dim recollection of the issue.
--
David Froble Tel: 724-529-0450
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
PQL parameters are used when the particular values are not specified in the CREPRC call.
Yep, that's what I was about, creating detached processes.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Stephen Hoffman
2020-12-22 21:05:45 UTC
Reply
Permalink
Post by Phillip Helbig (undress to reply)
Post by Joukj
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.
I'll see if this helps my problem. I remember adjusting quotas, but
not system parameters.
My understanding is that setting PQL_MPGFLQUOTA sets the minimum
PGFLQUOTA so that even those usernames with lower values in SYSUAF get
the PQL_MPGFLQUOTA value.
Correct. That system parameter setting is a system-wide minimum. It's a
fairly large hammer, but one that can be necessary.
Are there scenarios where PQL_MPGFLQUOTA is required because SYSUAF
value is not used??
There are cases when the developer forgot to specify quotas such as on
a detached process creation, yes.

These arise both with defaulted RUN /DETACH commands, and with
defaulted $creprc calls.

Most developers eventually learn that the process quotas and the
mailbox quotas and the IOSBs and such should not be defaulted.

Eventually.

Due to compatibility, some bad ideas from closer to VAX-11/VMS got
rolling cannot be required.

These are among those.

Had a pair of apps years back, one blew up because the default mailbox
quotas were too small, and the other app blew up when the same settings
were too large.

Which is part of why I'm skeptical around the efficacy of containers,
save as a means of software licensing arbitrage.
--
Pure Personal Opinion | HoffmanLabs LLC
Dave Froble
2020-12-22 21:42:20 UTC
Reply
Permalink
Post by Stephen Hoffman
Post by Phillip Helbig (undress to reply)
Post by Joukj
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.
I'll see if this helps my problem. I remember adjusting quotas, but
not system parameters.
My understanding is that setting PQL_MPGFLQUOTA sets the minimum
PGFLQUOTA so that even those usernames with lower values in SYSUAF get
the PQL_MPGFLQUOTA value.
Correct. That system parameter setting is a system-wide minimum. It's a
fairly large hammer, but one that can be necessary.
Are there scenarios where PQL_MPGFLQUOTA is required because SYSUAF
value is not used??
There are cases when the developer forgot to specify quotas such as on a
detached process creation, yes.
Well, I didn't forget, I figured they were already set elsewhere.

:-)
Post by Stephen Hoffman
These arise both with defaulted RUN /DETACH commands, and with defaulted
$creprc calls.
Most developers eventually learn that the process quotas and the mailbox
quotas and the IOSBs and such should not be defaulted.
I haven't learned that, yet, but, I will agree that being specific is
the better practice.
Post by Stephen Hoffman
Eventually.
Unless one is as lazy as me ...

:-)
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Stephen Hoffman
2020-12-23 16:29:49 UTC
Reply
Permalink
Post by Dave Froble
Post by Stephen Hoffman
There are cases when the developer forgot to specify quotas such as on
a detached process creation, yes.
Well, I didn't forget, I figured they were already set elsewhere.
:-)
Or are mis-set elsewhere. Or are subject to conflicting requirements.
Or somebody skipped that step in the doc when installing, and the
product support folks later had to find that error.

There used to be open conflicts around folks wanting and not wanting to
perform AUTOGEN passes. Folks that swore off running AUTOGEN, or that
got hosed by an AUTOGEN pass. Those arguments are less common now
judging largely by what gets posted around here in the comp.os.vms
newsgroup, but that might only mean that folks are running AUTOGEN less
often. Because there are still apps that are dependent on parameters or
logical names being set or not being set as required; AUTOGEN-fragile
and logical-name-fragile apps.
Post by Dave Froble
Post by Stephen Hoffman
These arise both with defaulted RUN /DETACH commands, and with
defaulted $creprc calls.
Most developers eventually learn that the process quotas and the
mailbox quotas and the IOSBs and such should not be defaulted.
I haven't learned that, yet, but, I will agree that being specific is
the better practice.
Post by Stephen Hoffman
Eventually.
Unless one is as lazy as me ...
:-)
I've chased more than a few of these messes around.

Please specify that IOSB everywhere (and check it!) and please also
specify quota lists and mailbox quotas and the rest of that ilk.

I'd prefer those and other such not-really-optional arguments to be
promoted to required arguments, but that's not happening anytime soon...

Fixing that has cleaned up a number of weird behaviors in the apps I've
maintained or have been called in to extend or to troubleshoot.
--
Pure Personal Opinion | HoffmanLabs LLC
Stephen Hoffman
2020-12-22 15:22:54 UTC
Reply
Permalink
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
it?
--
Pure Personal Opinion | HoffmanLabs LLC
Dave Froble
2020-12-22 16:53:45 UTC
Reply
Permalink
Post by Stephen Hoffman
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.
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?
A long time ago when I was first working with detached processes I ran
into problems with the PQL quotas. Since then, I've always considered
them suspect when problems arise.

Quotas come from a bygone era when system resources were rather limited.
While I would not just get rid of the concept, since it does allow
customization in the few cases where it is needed.

I'm not much of a fan of just setting quotas to a gazillion and figure
the problem is solved. That can be interesting. I remember the case
where a user set the WSDEF to some high number, then complained because
process startup was so slow, while the system attempted to scrounge
enough memory to meet the WSDEF. (It was WSEXTENT that he should have
changed.)

I'd welcome some guidelines from VSI on reasonable quotas for today's
systems. Hope that's not too much to hope for. A utility for updating
to recommended minimums would be even better.

As mentioned, existing account information is not changed in an upgrade.
That leads to the dark side, sooner or later.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Craig A. Berry
2020-12-23 00:18:34 UTC
Reply
Permalink
Post by Dave Froble
I'd welcome some guidelines from VSI on reasonable quotas for today's
systems.  Hope that's not too much to hope for.
That would be nice.
Post by Dave Froble
A utility for updating to recommended minimums would be even better.
I have written a utility and attached it here that uses whatever
template account you specify to upgrade the quotas in the target account
to match. If you don't specify the template account, it uses the
DEFAULT account, which means you can set that to have whatever your new
system should have for new accounts going forward, and then use this
utility to upgrade older, migrated accounts to match.

This is a fairly dumb copy of the quota fields from one SYSUAF record to
another. The recommended minima and exactly which accounts should get
bumped are outside of its scope. But, it was a big help when we migrated
from Alpha to Itanium a decade ago.
Phillip Helbig (undress to reply)
2020-12-22 21:29:48 UTC
Reply
Permalink
Post by Stephen Hoffman
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.
Probably true today. On the other hand, they tend to be rebooted once a
day rather than once a decade, so non-dynamic parameters can be tested.
Post by Stephen Hoffman
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
I would really like the ability to do an upgrade to the OS without
affecting any customized settings. One has to jump through hoops to do
it, and after the upgrade look for more hoops for next time. Making
"official" a third (cluster-wide) translation to SYS$SYSROOT between
SYS$SPECIFIC (for the local node) and SYS$COMMON (for all machines
booting from this disk AND for all machines in the world) for
cluster-specific stuff would go a long way to improving things in that
area.
Dave Froble
2020-12-22 21:49:19 UTC
Reply
Permalink
Post by Phillip Helbig (undress to reply)
Post by Stephen Hoffman
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.
Probably true today. On the other hand, they tend to be rebooted once a
day rather than once a decade, so non-dynamic parameters can be tested.
Post by Stephen Hoffman
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
I would really like the ability to do an upgrade to the OS without
affecting any customized settings.
Ummm ... how can I say this?

You should really avoid customization of an OS, unless you're the OS
developer. I consider doing so is just asking for problems, both while
using the OS, and most definitely when upgrading.

Consider, as being discussed here, things such as existing user accounts
not being upgraded when the OS is upgraded. At least minimums should be
upgraded.

My practice is to insert required startup tasks in SYSTARTUP_VMS.COM,
which is preserved during an upgrade. Any more would require convincing
needs.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
David Jones
2020-12-22 21:59:22 UTC
Reply
Permalink
Post by Dave Froble
My practice is to insert required startup tasks in SYSTARTUP_VMS.COM,
which is preserved during an upgrade. Any more would require convincing
needs.
--
Software packages often need changes to system parameters and thus edits
to modparams.dat as well. Upgrades like to add their own stuff to modparams.dat
as well, making deciphering it way more arduous than is should be.
Phillip Helbig (undress to reply)
2020-12-22 23:40:21 UTC
Reply
Permalink
Post by Dave Froble
Post by Phillip Helbig (undress to reply)
Post by Stephen Hoffman
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.
Probably true today. On the other hand, they tend to be rebooted once a
day rather than once a decade, so non-dynamic parameters can be tested.
Post by Stephen Hoffman
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
I would really like the ability to do an upgrade to the OS without
affecting any customized settings.
Ummm ... how can I say this?
You should really avoid customization of an OS, unless you're the OS
developer. I consider doing so is just asking for problems, both while
using the OS, and most definitely when upgrading.
I'm talking about things like mounting disks, my TCPIP configuration,
and so on.
Post by Dave Froble
My practice is to insert required startup tasks in SYSTARTUP_VMS.COM,
which is preserved during an upgrade. Any more would require convincing
needs.
Yes, they are preserved. But, say, you have cluster-common stuff on
another disk, which has to be mounted earlier. Yes, there is the
.TEMPLATE and .COM. But on the other hand if one never touches the
user-modified files, one would never use any new functionality in the
templates.
Stephen Hoffman
2020-12-23 16:19:56 UTC
Reply
Permalink
Post by Phillip Helbig (undress to reply)
Post by Stephen Hoffman
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.
Probably true today. On the other hand, they tend to be rebooted once
a day rather than once a decade, so non-dynamic parameters can be
tested.
Probably? Fewer and fewer folks are even running the configuration, not
the least of which is because running an OpenVMS desktop satellite is
💸 expensive. Seriously expensive. And it's SaaS-licensed now.

Outside of the existing apps that depend on OpenVMS and the associated
(and old) X11, these cluster configurations are largely relegated to
hobbyists, due in no small part to the OpenVMS pricing and features,
which then factors into app availability and affordability.

And all that's before we start discussing the VSI focus on servers and
not on desktops and the apps and tools and media that many (most?)
folks find necessary. Those other than you, and some other stalwart
hobbyists, that is.

I don't like dealing with EDT to start with, and EDT support for file
formats is less than fun, and using a text editor with ^V support for
reformatting embedded controls and/or writing DCL to fix these sorts of
issues is no fun.

Quick, untested, fits-in-a-tweet
file-read-write-loop-reformatting-or-file-untangling DCL:

$ on warn then goto err
$ close/nolog if
$ open/read if ‘p1’
$ close/nolo of
$ open/write of ‘p2’
$ loop: read if x/end=eof/error=err
$ x=f$edit(x,”compress”) ! or whatevs
$ write of x
$ goto loop
$ err: write sys$output “p1: infil, p2: outfil”
$ eof: close if
$ close of
$ exit
Post by Phillip Helbig (undress to reply)
Post by Stephen Hoffman
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
I would really like the ability to do an upgrade to the OS without
affecting any customized settings. One has to jump through hoops to do
it, and after the upgrade look for more hoops for next time. Making
"official" a third (cluster-wide) translation to SYS$SYSROOT between
SYS$SPECIFIC (for the local node) and SYS$COMMON (for all machines
booting from this disk AND for all machines in the world) for
cluster-specific stuff would go a long way to improving things in that
area.
OpenVMS installs and re-installs and upgrades—both OpenVMS itself, and
layered products—are unnecessarily complex and baroque, compared with
what's possible and with what's available elsewhere.

Cluster system roots were a useful construct in the previous
millennium; when storage was precious and small and expensive. Now? Not
so much. And for all that approach does provide, there are now other
configurations with approaches based on LDAP and such.

Way too much user and LP "stuff" gets scattered around within the
system roots. Necessarily. Startup giblets for instance, because
there's no better approach than manually adding stuff to SYSMAN or to
SYSTARTUP_VMS.COM or ilk. The whole area of OpenVMS is hard to
automate, and clusters more so. Which then also means efforts toward
better operating system security that much more intractable—tracking
files and changes and corruptions, app additions and removals, etc.
--
Pure Personal Opinion | HoffmanLabs LLC
Tad Winters
2020-12-22 05:14:37 UTC
Reply
Permalink
Post by Joukj
Hi all,
I recently upgraded my alpha's from OpenVMS 8.4 to 8.4-2L1. Everything
was fine and all the satelites came up smoothly with Decwindows running.
After some days I had to reboot a satelite, but it appears that is
booting correctly, but has problems to get the Decwindow-login screen on
the display. It continues retrying, but every time it fails.
Username:          SYSTEM            UIC:               [SYSTEM]
Account:           <start>           Finish time:       21-DEC-2020
09:27:35.09
Process ID:        23200367          Start time:        21-DEC-2020
09:27:35.01
Owner ID:          23200366          Elapsed time:                0
00:00:00.07
Terminal name:                       Processor time:              0
00:00:00.01
Remote node addr:                    Priority:          4
Remote node name:                    Privilege <31-00>: 4010E0A5
Remote ID:                           Privilege <63-32>: 00000060
Posix UID:         -2                Posix GID:         -2 (%XFFFFFFFE)
Queue entry:                         Final status code: 0000001C
Final status text: %SYSTEM-F-EXQUOTA, process quota exceeded
Page faults:               42        Direct IO:                  0
Page fault reads:           9        Buffered IO:               10
Peak working set:         912        Volumes mounted:            0
Peak page file:        167408        Images executed:            1
Maxjobs:         0  Fillm:      5000  Bytlm:       2100000
Maxacctjobs:     0  Shrfillm:      0  Pbytlm:            0
Maxdetach:       0  BIOlm:      1024  JTquota:       60000
Prclm:          40  DIOlm:      1024  WSdef:         24000
Prio:            4  ASTlm:       300  WSquo:         66536
Queprio:         0  TQElm:       400  WSextent:      30000
CPU:        (none)  Enqlm:      2000  Pgflquo:    18000000
Can someone get me some hints how to solve this problem?
               Regards
                  Jouk
_______________________________________________
Info-vax mailing list
http://rbnsn.com/mailman/listinfo/info-vax_rbnsn.com
I'm probably not much help since I haven't anything more than v7.x on an
Alpha, but I seem to remember that even back then, without running
DECWindows, the Enqlm was more than 4000, and why do you have WSextent
smaller than WSquo?
The EXQUOTA error I remember seeing always seemed to stem from Pgflquo
being too small, but
Loading...