Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"SMITH%NYUMED.BITNET@ymir.claremont.edu"
X-VMS-Cc: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Sat, 25 Jul 92 03:59:15 GMT
From:         "Ned Freed (Postmaster)" <NED@SIGURD.INNOSOFT.COM>
Subject:      RE: Request for minor changes to installation procedure
X-To:         SMITH@NYUMED, IPMDF@YMIR
Newsgroups: bit.listserv.pmdf-l

> Now that we are in nit-pick mode, I guess it is fair to ask again that the
> PMDF logicals, like those that provide the Organization name and the periodic
> job frequency be preserved in the PMDF_STARTUP file.

The problem here is your assumption that these are simple strings that
can be set and preserved in PMDF_STARTUP. This is not a valid assumption at
many sites.

> It is really easy to
> build these back in to the file when it is constructed, automatically.

I beg to differ. Take PMDF_POST_INTERVAL as an example. I've seen
configurations where the setting of this logical is changed dynamically
throughout the week. I've seen other setups where this logical is set
differently in different tables so that mutiple periodic jobs could be run at
different intervals. I've even seen procedures that calculate values for this
logical to insure that the periodic job runs during specific time intervals.

The same applies to PMDF_ORGANIZATION, but in spades. I've seen systems set up
with different values of this logical in the group tables for different
organizations sharing the same system.

An alternate approach would be to preserve the actual DCL from the old version
of PMDF_STARTUP, but prowling through source files looking for this sort of
thing is very risky and perilous. It is not the kind of technology that should
be used in startup files.

> My
> brain works in manual, howver, (and very slowly at that) and it usalyy takes
> me a week to figure out that things are not quite right after a re-install,
> and that there are still a few post-installation tasks I have overlooked.

An additional problem is that there are dozens of PMDF logicals. These interact
in complex ways; preserving a subset of them is probably worse that preserving
none of them at all, especially if the logic for setting some of them is more
complex than a single simple system-wide logical name value.

> The point is that the preservation of these small local customizations  would
> really save lots of time currently spent trying to figure out what has been
> forgotten....  :-)

The proper approach is to put these things collectively into a site-specific
startup file. This file should then be run immediately after PMDF_STARTUP is
run. This eliminates the possibility that these settings will be lost after an
upgrade. It also eliminates the possibility that we'll lose your changes, and
it eliminates the need to scan the old startup looking for changes.

You can even have your local startup run the real startup; then once
you've trained yourself to only run your local startup you'll never forget to
run them both!

Note that all this only applies to logicals that are not set by PMDF_STARTUP;
there are many things that PMDF_STARTUP must do and we always try for as much
flexibility as possible in setting what must be set by PMDF_STARTUP.

                                Ned
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU