home *** CD-ROM | disk | FTP | other *** search
- Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
- Path: sparky!uunet!paladin.american.edu!auvm!SIGURD.INNOSOFT.COM!NED
- 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
- Message-ID: <01GMRNNIL3Z69GVM20@YMIR.CLAREMONT.EDU>
- Date: Sat, 25 Jul 92 03:59:15 GMT
- Sender: PMDF Distribution List <PMDF-L@IRLEARN>
- 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
- Lines: 56
-
- > 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
-