[Info-vax] Changing SMTP server presented hostname in UCX

[Stephen Hoffman]

On 2014-09-10 19:12:05 +0000, Paul Sture said:

> Firstly, having all your parsing done by common routines.  In a 
> development culture where everyone parses their own text files you get 
> a multitude of parsers.  It's reinventing the wheel and no doubt the 
> same mistakes are made time and again.

VMS suffers from this.  There's SYSTARTUP_VMS.COM and SYLOGICALS.COM 
(which are configuration files), MODPARAMS.DAT, that pesky new SMTP 
configuration file, SYSGEN / SYSMAN and the PAR file, SYSMAN and its 
data files, AUTHORIZE and SYSUAF and RIGHTSLIST, MAIL and its profile 
file, NCP and its bevy of files, NCL and its files, DEC C and its bevy 
of logical names, Apache and its files (and yes, we're long past where 
Apache should be part of the base OS), DECwindows and the various X 
environments have their own configuration files and routines, there's 
OPCOM and its logical names, SYLOGIN.COM and LOGIN.COM and who could 
forget DECW$LOGIN.COM for the user login context settings (again, 
configuration files masquerading as a wad of DCL — and yes, I'm aware 
of the tools that load symbols from a data file), clustering and its 
dozen or so configuration files and the stuff underneath 
CLUSTER_CONFIG[_LAN],

... are we beginning to notice a pattern here?

That's before you get to the layered product configuration files from 
various sources, and some of those are utter crap.

Toss in the need to push out configuration changes to a bunch of user 
profiles or a bunch of systems — we're long past the era (error?) of 
individually-managed systems — and this whole house of text hackery can 
come crashing down into a heap of complexity.

Ever pushed out changes to a dozen VMS systems, where you need to 
increase the process quotas for specific users to a new minimum value, 
but not ever reduce the quota settings when larger?

Have you ever written your own syntax-checker for a flat configuration 
file, or other free-form input?  Users are just so utterly creative in 
how they (don't) interpret and how they (don't) follow the 
instructions, aren't they?

Logging that syntax error latent within a startup file a month or two 
after the change isn't all that helpful, though.

IIRC, one of the few configuration file libraries I've encountered on 
OpenVMS is the one buried in X, and very few folks even know that 
exists.  It's pretty limited, too.   So we all then invent and write 
our own tools, hopefully using lib$table_parse or better or using some 
packaged parser and with proper syntax checking, or sometimes DCL as 
happens underneath AUTOGEN and the startup procedures, and sometimes 
creating a configuration mechanism on operations and on end-users 
that's not far past freshly-flung monkey feces.

Then you get into how much of a hassle it is to add and to extend and 
to upgrade the data within the context of classic configuration files 
and classic RMS data files, and why (for instance) SYSUAF changes were 
such a hassle for OpenVMS Engineering.  Anybody here worked through how 
to upgrade a configuration file?  Sure, flat text files work nicely 
here, but now you get to deal with parsers — and potentially across 
versions — and syntax errors, and of pushing out changes, and 
cross-version compatibility, and pretty soon this stuff starts looking 
like timekeeping for the hassle factor that can arise.

Then you've got to document all of this, because, well, the alternative 
to documenting this is to perpetually answer support questions instead 
of working on new features.  (Not that you won't still be answering 
support questions, when your tool tips over a month after some 
configuration change was made and forgotten about, just because there 
wasn't immediate syntax-checking feedback for the end user.)

> Secondly, by enforcing a workflow where your text config files have to 
> go through a syntax checker first you are guaranteed that the 
> application will come up.

Ayup.  Which is where various folks will recommend rebooting OpenVMS 
once in a while, just to shake out the bugs in the 
not-otherwise-syntax-checked startup configuration (DCL) files.

> 
>> And There are many other places where efficiency can be improved in 
>> most programs but no one seems to care about system efficiency any more.
> 
> I won't disagree with that.

Customers and vendors aren't always willing to pay for the development 
work related to improving efficiency, but that's fodder for another 
discussion.

==

Is there a perfect, all-encompassing configuration mechanism?  No.  Are 
flat configuration files workable?  Sure.  But they get into hassles, 
such as when you're writing the parsers, dealing with updates, and 
particularly when trying to automate the operations across multiple 
systems.    We can do a damn better job than this current half-arsed 
morass we have now, though.


-- 
Pure Personal Opinion | HoffmanLabs LLC