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

[Stephen Hoffman]

On 2015-05-24 13:45:52 +0000, Paul Sture said:

> On 2015-05-23, Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:
>> On 2015-05-23 06:18:52 +0000, Paul Sture said:
>>> 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.

If the defaults aren't revisited, the problems persist and new problems 
are introduced.  Problems that are intentionally triggered because it 
was appropriate to limit the activity or the sequence in an old 
environment, but enforcing that same limit is now just plain stupid in 
the current environment.  Or that limit needs to be a whole lot higher, 
if it's still applicable.   Much like cost-of-living adjustments in 
legal and regulatory policies as budgets and prices change over, system 
parameters and process quotas can also need adjustments, and some 
limits should simply be removed.

There's a need to revisit other areas of an operating system or major 
application, too.   This can involve older code that's known to be 
broken or to be limited but is left around for application 
compatibility.  It's broken code, it was replaced for a reason.  It can 
be broken beyond what's already known — security problems, other bugs — 
and that can cause problems.   It also slows down the build, and slows 
down the testing.   Remove it.   For applications that provide 
programmability or for operating systems, there are source code 
programming examples with latent diagnostics or design errors or errors 
of omission — error checks that weren't done, common cases that weren't 
handled, etc.

Ponder how many bad end-user applications can arise from bad or broken 
or incomplete source code examples, ponder how long those can continue 
to be in use, and what that means for long-term support and user 
satisfaction.

Also ponder the lack of common data stores and the lack of a database 
past RMS, and what that means for applications and system code that 
then implement what a database would have provided, whether support for 
transactional changes or online backups or otherwise.

How there's no good distributed logging in OpenVMS, so some 
applications roll their own, some use syslog or syslog-ng, and many 
just barf up some stackdump or maybe write a crashdump, and perishingly 
few can (yes, opt-in!) upload the crash data to the vendor for 
analysis.  There's no framework for uploading crash data, either — so 
you skip this, or you roll your own.

It's all connected.  Maintaining a large and customizable application, 
or maintaining an operating system, is a ginormous and an ongoing and 
evolving project.  The need to reevaluate and rework the whole is not 
at all unusual with large projects, however: 
<http://www.citylab.com/work/2015/04/the-fascinating-neverending-job-of-painting-the-golden-gate-bridge/390453/> 


But I digress.

> 
>> 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.

The downside of the image activator and quotas: there's can be no 
diagnostic path out available out of that code when some quota limit is 
struck and breaks the activation.  Hopefully the updates to the x86-64 
image activator will improve this area somewhat.   Even emitting 
startup diagnostics via a kernel ring buffer would be better than the 
morass that we have now.

> 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

That's the OpenVMS Engineering version of the usual sort of parameter 
crap — yes, crap — that ends up building up in MODPARAMS.DAT.   Changes 
that were once appropriate, but that become little more than historical 
cruft or confusion or — rarely — this sequence looks reasonable though 
it'll require manual or automated removal or it'll leak the ADD when 
some subsequent OpenVMS ADD_ adds are added, but some of these 
parameter settings can later cause some systems to fail in weird ways — 
and these settings are hard to get rid of.

Off the top, there should be profile support here and those changes 
should be in a profile (or an object or module or hunk or AUTOGEN 
include file or whatever you want to call the "list of demands" from 
some particular hunk of system or application code) , and it should 
have which RMS kit requested it, and why, and when the changes can be 
or should be backed out, or the changes should be backed out 
automatically.  This stuff is inevitably going to happen.  Additions.  
Superseding changes.  Removals.  Expect it.  Plan for it.  Design for 
it.  Avoid getting into the rut of hacking in separate and unique 
changes and individually crafted and integrated across multiple tools 
and products and releases, particularly if a more generic solution is 
going to be cheaper in aggregate, and easier to maintain longer-term.  
Or if you do, then make that trade-off knowing full well you're 
accruing technical debt.

>> 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.

Some of my OS X customers are running with 36 TB of array storage.  And 
more.   At present, 64 TB is two dinky hardware RAID arrays; in 
aggregate, physically smaller than an AlphaStation XP1000 box.   (That 
then led to some brief puzzlement from the recent thread around leaking 
4 GB here in comp.os.vms — leakage which seemed inconsequential, until 
I remembered that Phillip was still on 9 GB drives.)


-- 
Pure Personal Opinion | HoffmanLabs LLC