home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / bit / listserv / pmdfl / 1633 < prev    next >
Encoding:
Text File  |  1992-07-25  |  3.5 KB  |  75 lines

  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!paladin.american.edu!auvm!SIGURD.INNOSOFT.COM!NED
  3. Errors-to: epmdf@YMIR.BITNET
  4. X-Envelope-to: PMDF-L@IRLEARN.BITNET
  5. X-VMS-To: IN%"SMITH%NYUMED.BITNET@ymir.claremont.edu"
  6. X-VMS-Cc: IPMDF
  7. MIME-version: 1.0
  8. Content-type: TEXT/PLAIN; CHARSET=US-ASCII
  9. Content-transfer-encoding: 7BIT
  10. Message-ID: <01GMRNNIL3Z69GVM20@YMIR.CLAREMONT.EDU>
  11. Date:         Sat, 25 Jul 92 03:59:15 GMT
  12. Sender:       PMDF Distribution List <PMDF-L@IRLEARN>
  13. From:         "Ned Freed (Postmaster)" <NED@SIGURD.INNOSOFT.COM>
  14. Subject:      RE: Request for minor changes to installation procedure
  15. X-To:         SMITH@NYUMED, IPMDF@YMIR
  16. Newsgroups: bit.listserv.pmdf-l
  17. Lines: 56
  18.  
  19. > Now that we are in nit-pick mode, I guess it is fair to ask again that the
  20. > PMDF logicals, like those that provide the Organization name and the periodic
  21. > job frequency be preserved in the PMDF_STARTUP file.
  22.  
  23. The problem here is your assumption that these are simple strings that
  24. can be set and preserved in PMDF_STARTUP. This is not a valid assumption at
  25. many sites.
  26.  
  27. > It is really easy to
  28. > build these back in to the file when it is constructed, automatically.
  29.  
  30. I beg to differ. Take PMDF_POST_INTERVAL as an example. I've seen
  31. configurations where the setting of this logical is changed dynamically
  32. throughout the week. I've seen other setups where this logical is set
  33. differently in different tables so that mutiple periodic jobs could be run at
  34. different intervals. I've even seen procedures that calculate values for this
  35. logical to insure that the periodic job runs during specific time intervals.
  36.  
  37. The same applies to PMDF_ORGANIZATION, but in spades. I've seen systems set up
  38. with different values of this logical in the group tables for different
  39. organizations sharing the same system.
  40.  
  41. An alternate approach would be to preserve the actual DCL from the old version
  42. of PMDF_STARTUP, but prowling through source files looking for this sort of
  43. thing is very risky and perilous. It is not the kind of technology that should
  44. be used in startup files.
  45.  
  46. > My
  47. > brain works in manual, howver, (and very slowly at that) and it usalyy takes
  48. > me a week to figure out that things are not quite right after a re-install,
  49. > and that there are still a few post-installation tasks I have overlooked.
  50.  
  51. An additional problem is that there are dozens of PMDF logicals. These interact
  52. in complex ways; preserving a subset of them is probably worse that preserving
  53. none of them at all, especially if the logic for setting some of them is more
  54. complex than a single simple system-wide logical name value.
  55.  
  56. > The point is that the preservation of these small local customizations  would
  57. > really save lots of time currently spent trying to figure out what has been
  58. > forgotten....  :-)
  59.  
  60. The proper approach is to put these things collectively into a site-specific
  61. startup file. This file should then be run immediately after PMDF_STARTUP is
  62. run. This eliminates the possibility that these settings will be lost after an
  63. upgrade. It also eliminates the possibility that we'll lose your changes, and
  64. it eliminates the need to scan the old startup looking for changes.
  65.  
  66. You can even have your local startup run the real startup; then once
  67. you've trained yourself to only run your local startup you'll never forget to
  68. run them both!
  69.  
  70. Note that all this only applies to logicals that are not set by PMDF_STARTUP;
  71. there are many things that PMDF_STARTUP must do and we always try for as much
  72. flexibility as possible in setting what must be set by PMDF_STARTUP.
  73.  
  74.                                 Ned
  75.