Xref: utzoo comp.os.vms:8749 comp.unix.wizards:11189
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: Just because YOU don't use it...
Keywords: RMS, file system, stream files
Message-ID: <3442@crash.cts.com>
Date: 17 Sep 88 18:08:48 GMT
References: <411@marob.MASA.COM> <178@arnold.UUCP>
Reply-To: jeh@crash.CTS.COM (Jamie Hanrahan)
Organization: CMKRNL Press, San Diego, CA
Lines: 43

In article <178@arnold.UUCP> dave@arnold.UUCP (Dave Arnold) writes:
>The VMS file system doesn't buy you anything, unless your application
>requires ISAM---However, how often do you need ISAM?
>
>I think the VMS filesystem is overly complicated, and one of the major
>downfalls of VMS (but can be tolerated).  If the original DEC designers
>had it to do over again, I suspect they would have stuck with a
>Stream-only based filesystem (Like UNIX), and provided ISAM libraries.
>The FORTRAN record format, FIXED SIZE RECORDS, VARIABLE LENGTH,
>CARRAIGE RETURN CARRIAGE CONTROL... Oh, don't forget the VFC record
>format...  These are all completely archaic, and date the VMS
>operating system.

I strongly disagree.  I answered this in another note, but there are a
few other points here... 

How often do you need ISAM?  Well, if you have to implement it yourself,
probably you'll do without.  But if it's there it gets used, for good and
sufficient reasons.  There are MANY great applications for indexed files...
Netnews, for instance.  Some folks at BYU did a netnews workalike for VMS,
relying heavily upon indexed files to keep track of the newsgroup contents,
but storing the articles in individual files just as Unix netnews does.  It's
a VERY clean design, and they can process a batch of received news MUCH 
faster than Unix can running on the same hardware.  (To be as exact as dim
memory allows, I think they said ten times faster or so, and that the Unix
folks at the site were both amazed and jealous.)

Someone will likely complain that "all that RMS code" costs a lot in terms
of efficiency.  I offer this challenge:  Take a simple Unix filter like
DETAB running on some Unix system on a VAX (Ultrix, BSD, AT&T, whatever).
Rewrite it to use record-oriented I/O under VMS.  Boot VMS on the same 
hardware (or the equivalent).  We've done this and the VMS/RMS versions
run *at least* twice as fast, sometimes five or six times.  (The much greater
improvement in BYU News comes from a redesign to take advantage of indexed
files, not just conversion from stream- to record-oriented I/O.)

I know, I know -- for many applications stream I/O makes for much cleaner
program design.  But for others, it doesn't, at least not when you have
good alternatives available.  

I don't think that fixed vs.variable length records, implied
carriage control, etc., are archaic at all.  Variable with fixed control,
on the other hand, is right down there with punched cards and paper tape!