Path: utzoo!attcan!uunet!convex!killer!ames!ll-xn!mit-eddie!fenchurch.mit.edu!jbs From: jbs@fenchurch.MIT.EDU (Jeff Siegal) Newsgroups: comp.unix.wizards Subject: Re: VMS vs. UNIX file system Message-ID: <10105@eddie.MIT.EDU> Date: 20 Sep 88 20:05:08 GMT References: <411@marob.MASA.COM> <3597@encore.UUCP> <3438@crash.cts.com> <1210@unmvax.unm.edu> <69166@sun.uucp> Sender: uucp@eddie.MIT.EDU Reply-To: jbs@fenchurch.MIT.EDU (Jeff Siegal) Organization: MIT EE/CS Computer Facilities, Cambridge, MA Lines: 23 I'm not so much concerned with the issue of stream vs. record-oriented file access. One can always (perhaps not easily or quite so efficiently, but if you need to get the job done...) be used to simulate the other. I think a more fundamental advantage of the VMS I/O system is that QIO's can be queued to execute asynchronously (similarly for RMS operations). An AST (software trap) is delivered to your process when the I/O completes. The AST tells you which I/O operation completed, and the error status. On Unix, you can get asynchronous I/O by going through the buffer cache, but this doesn't provide a clean way for the error status to be returned (for example, NFS writes that go over quota can appear to complete, but return the error later, when performing another operation), and doesn't allow you full access to the device (for example, the buffered tape device only provides 1024 byte records. I believe certain VMS I/O operations are performed directly from/to process memory, rather than being copied from/to the kernel, but this is "only" a performance issue (and an arguable one at that). Jeff Siegal