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