Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site lanl.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!whuxl!whuxlm!akgua!sdcsvax!dcdwest!ittvax!decvax!genrad!panda!talcott!harvard!seismo!cmcl2!lanl!jlg
From: jlg@lanl.ARPA
Newsgroups: net.arch
Subject: Re: RMS {SHORT}
Message-ID: <23480@lanl.ARPA>
Date: Tue, 19-Mar-85 13:32:55 EST
Article-I.D.: lanl.23480
Posted: Tue Mar 19 13:32:55 1985
Date-Received: Sat, 23-Mar-85 04:24:42 EST
References: <552@decwrl.UUCP>, <50@daisy.UUCP> <130@stl.UUCP> <251@tilt.FUN>
Sender: newsreader@lanl.ARPA
Organization: Los Alamos National Laboratory
Lines: 34

> >When I first started to use VMS I thought all that Index Sequential stuff was
> >way over the top - but now I'm wiser and actually use IS files I find they
> >are very effective - but still amazingly complex to fully define.  What I
> >find very impressive is that you DON'T NEED TO BOTHER about all the 
> >complexity - DEC have a special editor (EDIT/FDL) which designs the file
> >organisation for you - you answer its questions about how many records you'll
> >have/where and what the keys are/do you expect records to be entered in 
> >sequential order or not/etc.  and it does the rest - even tells you how good
> >it thinks the result will be.  It's the sort of programme which would be called
> >'AI' if written in LISP but as it's probably in BLISS ...
> > 
> >Other file system developers please copy!
> 
> Other file system developers please ignore.  There's no reason why you can't
> have IS/VSAM/* files but keep them out of the kernel.  Use a simple stream
> model and supply the routines and the above program as a user library and
> a user program.

Hear, Hear!  (Where, where :-)  I am a file system developer. And I plan
to include indexed files at a very high level - if at all.  As I have pointed
out several times in the past, this type of low level implementation is
my main objection to VMS/RMS.  The above note contains some of the reasons
why.  1) the tool tells you how good it thinks the result will be -
translation: the tool can't implement some data structures very efficiently
since it has only one model of indexed files to translate into.  2) the
built-in file tools are inadequate for database management so you require
off-line tools to do part of the job (most of the job usually).  Why not
have the whole idea of indexed files removed from the system since only
a woefully inadequate piece is there anyway.  3) this is not from the above
article, but it is clear that users that don't need indexed files are
paying for them involuntarily (and unnecessarily) since they are in the
lowest level file handler.

J. Giles