VMS vs. UNIX file system

[Jamie Hanrahan]

In article <3597 at encore.UUCP> bzs at 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... :-)