DEC Windows wants to run autogen at startup

[Markus Waldorf_1]

Hi,

I'm on OpenVMS 7.2-1, with all the patches. The system was running fine for a week, but I'm still setting it up. Today I went to the console and it was showing that DEC Windows does not start due to insufficient GLBPAGES.

Please see below.

Here is my question: The server has 4 GB RAM and is going to run just TCP/IP and a custom application, which among some other parameters has MIN_GLBPAGES 140000 in modparams.dat

Why did DEC windows fail at startup? There should be enough GBLPAGES. If something fail, shouldn't it be the custom application above since DEC windows used its resources.

SYSGEN> SHO GBLPAGES
Parameter Name Current Default Min. Max. Unit Dynamic
-------------- ------- ------- ------- ------- ---- -------
GBLPAGES 150000 65536 10240 -1 Pagelets D
internal value 9375 4096 640 -1 Pages D

What are the internal values?

Should I not just add, let's say 300000, just to be save I don't run out of GBLPAGES if something else starts?




SYSTEM@NW1>@SYS$MANAGER:DECW$STARTUP
%DCL-I-SUPERSEDE, previous value of DECW$SERVER_DDX_GZ has been superseded
%DECW-W-BADVALUE, Free GBLPAGES is 80464, should be at least 92000
Some SYSGEN parameters must be reset for DECwindows to start. If you type
YES, AUTOGEN will change these parameters and reboot your system. If you type
NO, AUTOGEN will not run or cause a reboot, but DECwindows will not start.
Do you want the system to run AUTOGEN for you [YES]?

[Wim Van den Wyngaert · Accepted solution]

I have a 7.3 workstation and it's already using 165.000 pages after boot. You should modify modparams and increase the value. We use 300K as a minimum.

Internal : 1 page = 16 pagelets. It just shows both.

Wim

[Richard Brodie_1]

"which among some other parameters has MIN_GLBPAGES 140000 in modparams.dat"

Specifying a minimum for a pooled resource is a rather self-centred thing for an application to do. It knows what resources it wants, and doesn't consider the requirements for anything else.

"Why did DEC windows fail at startup?"

It starts fairly late in the startup, so it's always at the end of the queue for resources.

[Steven Schweda]

> Do you want the system to run AUTOGEN for you [YES]?

And, as I recall, letting this happen
automatically does (may?) not solve the
problem, so you end up going it manually.


I'm not trying to hijack this thread, but a
quick look at my system (XP1000, VMS V7.3-2)
was rather startling:

ALP $ gbl
Global pages: 3674022, free: 3237760, contiguous: 3231008.
Global sections: 1340, free: 231.

Why do I have so many GBLPAGES?

ALP $ search SYS$SYSTEM:MODPARAMS.DAT gbl
MIN_GBLPAGES = 440000
MIN_GBLSECTIONS = 1300
ALP $

SYS$SYSTEM:AGEN$PARAMS.REPORT says that it'd
like it even higher:

[...]
GBLPAGES parameter information:
Feedback information.
Old value was 3674022, New value is 3683430
Maximum used GBLPAGES: 444672
Global buffer requirements: 196864
Pagelets reserved for memory resident sections: 0
[...]

Eight times the "Maximum used" seems a bit
demanding (or generous, depending on which
side you're on). Or is one of us confused
between pages and pagelets?

[marsh_1]

hi,

i would say no to the autogen, de-install and re-install decwindows afterwards if you need it, this situation does loop round as steven has suggested.

hth

[Hoff]

This is an old OpenVMS version, and correspondingly old behavior.

Reserving room in the Global Page Table for an expansion of four million global pages requires three physical pages of overhead. You are using 24 MB of memory to have room for four million global pages, plus whatever memory you actually use to store the global pages.

A page table migration to S2 space and the calculations here around the costs of the system parameter handling for various parameters (including VIRTUALPAGECNT) were all considered and were altered around eight years ago to better contend with the cost of GBLPAGES as compared with the cost of managing GBLPAGES.

Have a read through:

http://labs.hoffmanlabs.com/node/461

The designs and limits provided by various system parameters made sense when systems had sixteen or sixty-four megabytes of memory and the 31-bit space of S0/S1 system space, but not when systems routinely have several gigabytes or more and when the page tables are located in S2 space.

There is a second (old) bug here with old versions and AUTOGEN and DECwindows. That bug led to a AUTOGEN-reboot loop, as the parameter update implemented was insufficient to pass the boot-time parameter check, and thus the value was detected as insufficient and triggered another AUTOGEN-reboot. The fix there is a conversational bootstrap, use a MIN_ or otherwise set the parameter manually (usually via a conversational bootstrap), and to then (once stable) add the MIN_ setting into MODPARAMS.DAT to avoid the loop going forward.

On OpenVMS Alpha V7.3 and later and on OpenVMS I64, VIRTUALPAGECNT and friends are usually set huge.

[Markus Waldorf_1]

Well, I said no to the autogen prompt and put "ADD_GLBPAGES=300000".

From what I have seen so far this does not seem to be the best solution, but it works, for now, and does not prompt for autogen again. I'm quite under stress right now to get the system up and running for production - a last minute call.

Why actually bother so much? Why not setting GLBPAGES and others just simply higher and let programs use what the want to consume. I guess in the old days when RAM was more precious it did matter more, and I assume it helped to prevent programs from running that would toast the system. But that's just based on my deluded perseption with zero research.

sho memory really looks like it can handle a lot more memory demands:

Physical Memory Usage (pages): Total Free In Use Modified
Main Memory (4096.00Mb) 524288 509553 14008 727

So why not setting GBLPAGES to something really large and avoid running into problems later? Which value would sound reasonable?

Thanks,
Markus

[John Gillings]

re: Steven

>Eight times the "Maximum used" seems a
>bit demanding (or generous, depending on
>which side you're on). Or is one of us
>confused between pages and pagelets?

There are other places which contribute to AUTOGEN calculations which may explain your high value. For example, see SYS$SYSTEM:CLU$PARAMS.DAT. There are a number of MIN and ADD clauses for different products, which may include DECwindows and DECNET.

As of V7, GBLPAGES is cheaper than before, so it's better to overallocate.

(At one time the "forced AUTOGEN" behavior of DECwindows was a potential problem, as it would jack up PQL_MPGFLQUOTA without asking. On space constrained systems, this could result in processes having PGFLQUOTAs too high for the available physical page file space. Of course, that's no longer a problem, because everyone has invested a few dollars in page files far larger than they'll ever need! right?)

[Steven Schweda]

> [...] see SYS$SYSTEM:CLU$PARAMS.DAT.

Editing out some %SEARCH-I-NULLFILE's:

ALP $ sea SYS$SYSTEM:*.DAT GBLPAGES

******************************
SYS$SYSROOT:[SYSEXE]AGEN$ADDHISTORY.DAT;1

ADDHIST_GBLPAGES = 83544

******************************
SYS$SYSROOT:[SYSEXE]AGEN$FEEDBACK.DAT;106

GBLPAGES_CUR = 3674022
GBLPAGES_PEAK = 444672

******************************
SYS$SYSROOT:[SYSEXE]MODPARAMS.DAT;32

MIN_GBLPAGES = 440000

******************************
SYS$SYSROOT:[SYSEXE]PARAMS.DAT;73

GBLPAGES_CUR = 3674022
GBLPAGES_PEAK = 444672
DW_MOTIF$MIN_GBLPAGES = 150000 !SET BY DW-MOTIF
DW_MOTIF$ADD_GBLPAGES = 28544 !SET BY DW-MOTIF
DECNET_PLUS$ADD_GBLPAGES = 55000 !SET BY DECNET-PLUS
DECNET_PLUS$MIN_GBLPAGES = 100000 !SET BY DECNET-PLUS
MIN_GBLPAGES = 440000

******************************
SYS$SYSROOT:[SYSEXE]SETPARAMS.DAT;130

set GBLPAGES 3683430

******************************
SYS$COMMON:[SYSEXE]CLU$PARAMS.DAT;11

DW_MOTIF$MIN_GBLPAGES = 150000 !Set by DW-MOTIF
DW_MOTIF$ADD_GBLPAGES = 28544 !Set by DW-MOTIF
DECNET_PLUS$ADD_GBLPAGES = 55000 !Set by DECnet-Plus
DECNET_PLUS$MIN_GBLPAGES = 100000 !Set by DECnet-Plus

The only huge value I see is the current one.

I'm not losing any sleep over it, it's just
that when I checked to see how my system
compared with the one in the question, I (and
my 2GB of memory) seemed to be in a
completely different neighborhood, which,
although barely relevant, seemed mysterious
(and still does).