Xref: utzoo comp.os.vms:8758 comp.unix.wizards:11200 Path: utzoo!attcan!uunet!husc6!uwvax!oddjob!mimsy!chris From: chris@mimsy.UUCP (Chris Torek) Newsgroups: comp.os.vms,comp.unix.wizards Subject: Re: VMS vs. UNIX file system Message-ID: <13603@mimsy.UUCP> Date: 18 Sep 88 09:49:53 GMT References: <411@marob.MASA.COM> <3597@encore.UUCP> <3438@crash.cts.com> Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 30 In article <3438@crash.cts.com> jeh@crash.cts.com (Jamie Hanrahan) writes: >... the Unix byte stream uses perfectly legitimate data as a record >separator. Do you know what a `byte stream' is? Byte streams do not have records; they can hardly have record separators. If you want records in a Unix file system file, you must define them yourself. This is what Barry Shein was talking about. >Barry goes on to say that you should be able to open any file as a byte >stream and not get an error. Well, you can do the equivalent under VMS-- >you can open any file, sequential, relative, or indexed, for sequential >access, and RMS will happily hand you the records in order (in order by >primary key if it's an indexed file). And if you prefer a byte-stream >... you or the system can provide a set of byte-stream interface routines >to do that with a record-oriented file system. Simulating a byte stream on top of records is considerably more difficult than simulating records on top of a byte stream. I have been lead to believe that, under VMS, each different kind of record-oriented file must be read with a different primitive. (You must also provide a buffer that is as large as the largest record.) Hence to simulate a byte stream, you must know about every possible record format. On the other hand, to simulate a record format, you must know about every possible byte stream. Fortunately, there is only one possible byte stream, by the definition of `byte stream'. . . . -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris