home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!haven.umd.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!usc!news.service.uci.edu!unogate!mvb.saic.com!macro32
- From: "SYSTEM SUPPORT" <SYSTEM_JM@unode2.nswc.navy.mil>
- Newsgroups: vmsnet.internals
- Subject: Re: Call for (mostly)-baked ideas: $QIO replacement?
- Message-ID: <9212211901.AA30748@cunixf.cc.columbia.edu>
- Date: 21 Dec 92 13:58:00 EST
- Organization: Macro32<==>Vmsnet.Internals Gateway
- X-Gateway-Source-Info: Mailing List
- Lines: 30
-
- >> Subject: Call for partly-baked ideas: $QIO replacement?
- >>
- >> Are you happy with the $QIO system service? If you were building a new O/S
- >> from scratch, would you make the "basic I/O call" that's available for
- >> non-privileged programs look like $QIO, or like something else? If the
- latter,
- >> what? If you could specify a new I/O interface to supplement $QIO in VMS,
- what
- >> would it look like?
- >>
- I thought I heard a collective "Hmmm..." when this was posted :-)
-
- I've been tinkering with Security Enhanced VMS (SEVMS) which follows a
- write-up-read-down scheme. The bummer of it all is that VMS needs to do a
- read to see if the file exists before it'll write a new file. Yes, you can
- write custom procedures to get around this, but it would be nice if the $QIO
- routines were already "trusted" to handle this for the unpriv'ed user.
-
- Overall, I've been happy with the $QIO service. I'm interested to hear what
- your ideas are. How about "broadcasting" the $QIO to a set of CPU's and the
- first CPU to complete the task "wins".
-
- *******************************************************************************
- ** Jim Matthews **
- ** Naval Surface Warfare Center Dahlgren Division **
- ** Code N23A **
- ** Dahlgren, VA 22448-5000 **
- ** Internet: system_jm@unode2.nswc.navy.mil **
- *******************************************************************************
-
-