home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / vmsnet / sysmgt / 221 < prev    next >
Encoding:
Internet Message Format  |  1992-07-27  |  3.0 KB
  1. Path: sparky!uunet!wupost!uwm.edu!fps.mcw.edu!brodie
  2. From: brodie@fps.mcw.edu
  3. Newsgroups: vmsnet.sysmgt
  4. Subject: Re: Using STARTUP$STARTUP_LAYERED
  5. Message-ID: <1992Jul27.110159.674@fps.mcw.edu>
  6. Date: 27 Jul 92 11:01:58 CST
  7. References: <1992Jul20.135138.938@beckman.com> <1992Jul21.092043.16621@pbs.org> <5940@npri6.npri.com>
  8. Distribution: world
  9. Organization: Medical College of Wisconsin,  Milwaukee, WI
  10. Lines: 52
  11.  
  12. In article <5940@npri6.npri.com>, richard@npri6.npri.com (Richard Head) writes:
  13. > sdroppers@pbs.org writes:
  14. > 
  15. >>In article <1992Jul20.135138.938@beckman.com>, dsroberts@beckman.com writes:> cluster.  He did not use the STARTUP$STARTUP_VMS and STARTUP$STARTUP_LAYERED
  16. >>> ...stuff removed...
  17. >>> In any case, perhaps some of you would like to share how your startup is
  18. >>> configured so perhaps I can glean some improvements that would apply to us.
  19. >>> 
  20. >>We have had very good results starting the batch queues and then sending
  21. >>jobs off in the batch queues.  We cut our reboot time from 45 minutes to about
  22. >>15 minutes this way.  We abandoned the DEC supplied startup since we could not
  23. >>specify the batch queue to start jobs in.
  24. >>
  25. >>By using batch queues we can also specify the exact order items are started.
  26. > 
  27. > Interestingly enough, I had the opportunity to view the startup procedures of
  28. > a large and strategically important Digital internal VAXcluster system.
  29. > I didn't bother to check if they were using the STARTUP$STARTUP_LAYERED data
  30. > file scheme, but they had a *lot* of startup procedures submitted to batch
  31. > queues.  Almost nothing was executed during SYSTARTUP_V5.  I counted at least
  32.  
  33. I use batch queues too.  (I have two single-threaded batch queues for this,
  34. so I "sort of" have parallel startup...  i.e., any jobs that are
  35. dependant on order (i.e., tcp/ip, mx, uucp, etc.) get submitted IN order
  36. to a specific queue).
  37.  
  38. Another side benefit of this is kind of having a "minimum" startup
  39. if I need to.  I.e., i may not necessarily want p1 set to 'MINIMUM',
  40. but I certainly have the option of stopping the batch queue(s) right
  41. away if I want to prevent further startup.
  42.  
  43. I haven't had the time to seriously investigate the SYSMAN startup
  44. procedures (mostly because I don't see the NEED.  Our system
  45. is a single large system.  If I was in a huge cluster, I'd probably
  46. more seriously consider the SYSMAN stuff...)
  47.  
  48. I wonder what's next...  SYSTARTUP_v6?   :-)
  49.  
  50. > I personally don't have enough products to even bother investigating this
  51. > bit of VMS "boot trivia", but I would favor the batch method if I did.
  52.  
  53. ditto.  (about the only thing I do DIRECTLY in SYSTARTUP is mount
  54. my disks, define logical names, and then fire off all the other
  55. batch jobs).   "works for me".
  56.  
  57. -- 
  58. Kent C. Brodie - Sr. Systems Manager        InterNet:  brodie@fps.mcw.edu
  59. Faculty Physicians & Surgeons            uucpNet:   fps.mcw.edu!brodie
  60. Medical College of Wisconsin            MaBellNet: +1 414 266 5080
  61.  
  62. "Little bunny FOO-FOO, hoppin' through the forest,
  63.    scoopin' up the field mice and boppin' 'em on the head.."  -childrens song
  64.