[Info-vax] 8.4 and DECwindows CDE login box not coming up

[Paul Sture]

On 2015-05-23, Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:
> On 2015-05-23 06:18:52 +0000, Paul Sture said:
>
>> Have you tried increasing GBLPAGES as well?
>> 
>> I'll suggest adding 50,000 to GBLPAGES.  Yes that's a figure plucked
>> from the air, but I'm deliberately erring on the generous side.
>
> IIRC, configuring each 128 pages requires four bytes.   By my 
> probably-bad memory and probably-equally-bad math, configuring 262144 
> GBLPAGES requires committing ONE PAGE of Alpha or Itanium memory.  
> Over-configuring has very low costs, and avoids hassles later.  In 
> short, crank it.

That's close enough to the formula I was trying to recall to sound right.
This and the memory requirements of various other major Sysgen parameters
were in the configuration manual of a third party product I used when I
first started with VMS.


>> There was a known problem with that parameter in earlier versions of 
>> VMS where DECwindows would see a shortage, and try to remedy it by 
>> adding an entry to MODPARAMS.DAT (or maybe one of the INCLUDEd Autogen 
>> files - I forget the precise details), but fail to do so correctly.
>
> IIRC, that morass amounted to missed testing and two sources of truth; 
> the checks and the adjustments.  The parameter addition did not match 
> the requirements of the parameter test.   The layered product software 
> tests missed this case entirely.   Rinse, lather, repeat.

Yes, and my "plucked out of the air" comment left out that I bumped into
this very problem on many occasions; the figure I gave was based on
solid experience.  On a new installation of a development system for
example, a much lower figure will get you past the DECwindows problem,
but you'll still need to raise GBLPAGES for the subsequent installation
of compilers, Datatrieve etc etc.

> This is part of why I think how AUTOGEN and the layered product 
> installs should be overhauled, and particularly support for application 
> profiles added.   Register the system parameters and the user settings 
> at install, then adjust the parameters post-installation and reboot if 
> needed, and check the quotas at image startup.

The Stan Rabowitz tale "A Day in the Life of the Image Activator" was
all the more funny for having gone through the process of identifying
and then applying INSTALL /OPEN / HEADER to the images Datatrieve uses.

I did that for even the stub images for products not installed and saw
a significant decrease in Datatrieve startup times.  I don't recall the
wall clock time, but it saved at least 1 second's CPU time on an 11/780.

For readers who haven't seen it, "A Day in the Life of the Image
Activator", by Stan Rabowitz:

<http://www.sture.ch/node/90>

> Having rolled out explicit process and parameter quota checks into 
> applications and seen the resulting and massive decreases in weird 
> errors, the current design and current interface is far too dependent 
> on the correct operations of humans.  The resulting errors secondary to 
> quota depletions tend to be awful to troubleshoot, too.
>
> But I digress.

Not really digression in the context of this problem.  The last time I
ran into it was sufficiently late in the day that I though it really
ought to have been fixed by then.

FWIW I've still got an old modparams.dat file on my V8.3 system which
has the section quoted below.  I don't recall (maybe my faulty memory)
seeing these changes being propagated into versions later than 7.3-1,
which is why I kept that file around:

!*** The following entries have been added by the RMS remedial kit
!*
ADD_PIOPAGES = 100     !***Entered by RMS (ASB increase)
ADD_IMGIOCNT = 100     !***Entered by RMS (ASB increase)
MIN_PIOPAGES = 675     !***Entered by RMS (ASB increase)
MIN_IMGIOCNT = 228     !***Entered by RMS (ASB increase)
!*
!*** End of RMS remedial kit entries
!
!^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
!
! End of SYS$SYSDEVICE:[SYS0.SYSEXE]MODPARAMS.DAT
! Created during upgrade to OpenVMS AXP V7.3-1  6-OCT-2002 12:36:33.64
!

> Quota limits and parameter limits and related decisions need to be 
> periodically re-evaluated, lest they become impediments to easier 
> operations, and for what can become no positive values.  In three to 
> five years, if the users don't have servers with eight or sixteen 
> gigabytes — that's typical of decent-grade x86-64 laptops now, and new 
> x86-64 servers with a terabyte of RAM are now priced at US$15K to 
> US$20K, after all — then start down the path to require memory hardware 
> upgrades or to de-support those older and under-configured boxes on 
> newer releases.  Relegate the old and under-configured boxes that can't 
> be upgraded to long-term support releases, or schedule and de-support 
> them.

Indeed.  A few years ago I thought that dealing with files of 1 or 2 GB
was something I would only be likely to do in an enterprise environment,
yet I'm merrily chucking those around on a 2011 model Mac mini, not even
close to the server grade kit available now.

> Or don't support underconfigured boxes to start with.

That was a pet peeve of mine back in the 90s.  Microsoft and various
others would quote a minimum requirement which was maybe adequate for
casual users but fell way short of what intensive use required.  The
beancounters of course would believe the providers.

> With x86-64, we are NOT in the same hardware world that VAX, Alpha or 
> even Itanium existed in.
>
> But I digress, again.
>
> Related <http://labs.hoffmanlabs.com/node/1374> 

LOL: I'd forgotten about that post :-)

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



-- 
I don't know what the language of the year 2000 will look like, but I
know it will be called Fortran.                    -- Tony Hoare 1982