home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!zaphod.mps.ohio-state.edu!news.acns.nwu.edu!network.ucsd.edu!mvb.saic.com!arizona.edu!telcom.arizona.edu!leonard
- Newsgroups: vmsnet.sysmgt
- Subject: Re: System startup options
- Message-ID: <1992Jul21.143016.3516@arizona.edu>
- From: leonard@telcom.arizona.edu (Aaron Leonard)
- Date: 21 Jul 92 14:30:14 MST
- Reply-To: Leonard@Arizona.EDU
- References: <1992Jul20.135138.938@beckman.com> <1992Jul21.103543.939@beckman.com>
- Distribution: world,local
- Organization: University of Arizona Telecommunications
- Nntp-Posting-Host: bugs.telcom.arizona.edu
- Lines: 33
-
- In article <1992Jul21.103543.939@beckman.com>, dsroberts@beckman.com writes:
-
- | Has anyone tried using spawn/nowait in their startup?
- |
- | I don't think it's a very good idea,
-
- No, it's not a good idea.
-
- | since the spawned process could be killed
- | by the spawning process completing, and I don't see how it can be that much
- | less overhead than queuing such that it would make that much difference.
-
- Exactly.
-
- Here's a *good* idea (at any rate, it's what I've been doing for years):
-
- $ RUN/DETACH SYS$SYSTEM:LOGINOUT.EXE /INPUT=your-comfile.com -
- /OUTPUT=your-comfile.log
-
- One nice thing about this approach is that it leaves fun-to-read logfiles
- lying around on disk, so that you have some record if you had errors in
- your startup, rather than having the stuff go to OPA0.
-
- Batch queues are OK too, I guess, but this will work even if the queueing
- system isn't up.
-
- Best,
-
- Aaron
-
- Aaron Leonard (AL104), <Leonard@Arizona.EDU>
- University of Arizona Network Operations, Tucson AZ 85721
- |> If it ain't broke, break it.
-