Xref: utzoo comp.os.vms:8747 comp.unix.wizards:11187 Path: utzoo!attcan!uunet!husc6!cmcl2!rutgers!ucsd!ucsdhub!jack!elgar!crash!jeh From: jeh@crash.cts.com (Jamie Hanrahan) Newsgroups: comp.os.vms,comp.unix.wizards Subject: Re: VMS vs. UNIX file system Summary: Unix file systems? Just say NO! Message-ID: <3438@crash.cts.com> Date: 17 Sep 88 17:24:44 GMT References: <411@marob.MASA.COM> <3597@encore.UUCP> Reply-To: jeh@crash.CTS.COM (Jamie Hanrahan) Organization: CMKRNL Press, San Diego, CA Lines: 61 In article <3597@encore.UUCP> bzs@encore.UUCP (Barry Shein) writes: [much good stuff...] > >It's all a balancing act. In my ideal world there would be a variety >of standardized access methods and you would avoid using them like the >plague, especially in general system utilities, simple byte-stream >files should account for most input and output (a la Unix), ... I disagree. I much prefer VMS's variable-length-record text file format to Unix's byte-stream. Why? Because the Unix byte stream uses perfectly legitimate data as a record separator. To make matters worse, the standard C method for dealing with strings uses a *different* character as a string terminator! Unix has a lot of GREAT ideas in it, but this isn't one of them. 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 rather than a record-oriented interface (and, yes, the byte-stream i/f has GREAT advantages from a program style standpoint; non-believers, particularly those who have never looked inside Unix utilities, should take a look at Kernighan and Plauger's _Software Tools_ or _Software Tools in Pascal_ to see what I mean), you or the system can provide a set of byte-stream interface routines to do that with a record-oriented file system. (That DEC's VAX C RTL does this, shall we say, imperfectly, is a problem in the implementation, not the concept.) (Incidently, Barry's problem with EDT stems from Runoff's former use of print-format files, wherein carriage control information for each record is stored in a fixed-length field preceding the text information. A program that expects to read an ordinary text file can read such a file, but it won't see the fixed-length field, so if it's an editor it can't reconstruct the field on output. The print-format file is one use of "Variable with Fixed Control" record format, and I'm very happy to report that very few VMS programs generate such files these days; it's one record format that VMS could have done without. ) To give you an idea of the generality of VAX RMS, the system runs happily using just a few of the available file formats. Text is stored in variable- length-record, sequential files. So is object code (possible even though you can have null bytes, line feeds, etc., etc., in object records... because RMS doesn't use in-band data for record terminators!). Images and library files go in fixed-length-record files, essentially with their own internal format implemented by the programs that deal with them. There are a few indexed files like the user authorization file. And that's about it. For me, the bottom line is that it works, that RMS with all its fabled "inefficiencies" runs rings around most folks who try to bypass it (whoa, now! I said "most". This because most people don't do the good job with read-ahead and write-behind buffering that RMS does. Sure, if you do that, AND implement the record handling yourself, you can beat RMS, barely. My point is that you don't have to bother to get good performance), and that I've dealt with VMS's file system for years without feeling I was doing battle with it. No doubt if I was moved to a Unix environment I would gripe a lot for a few weeks about "those stupid byte-stream files", but I'd like to think that I'd adapt and figure out how to do things the Unix way and work with the system instead of fighting it. I'd like to think that most Unix folks who come to VMS would do the converse. I'm probably wrong on both counts... :-)