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!cbosgd!ihnp4!mhuxn!mhuxm!mhuxi!mhuxh!mhuxv!mhuxt!mhuxr!ulysses!allegra!bellcore!decvax!genrad!panda!talcott!harvard!seismo!cmcl2!lanl!jlg
From: jlg@lanl.ARPA
Newsgroups: net.arch
Subject: RMS useful?
Message-ID: <20969@lanl.ARPA>
Date: Mon, 4-Feb-85 15:48:35 EST
Article-I.D.: lanl.20969
Posted: Mon Feb  4 15:48:35 1985
Date-Received: Sat, 9-Feb-85 04:36:00 EST
References: <105@endot.UUCP> <1399@uscvax.UUCP> <248@scgvaxd.UUCP> <20079@lanl.ARPA> <1547@uscvax.UUCP>
Sender: newsreader@lanl.ARPA
Organization: Los Alamos National Laboratory
Lines: 54

> Those 31 RMS services are more useful than any version of a file system than
> I've ever heard of on a Unix system.


I have the following problem. Perhapes you can tell me how to use this
'useful' set of RMS calls to achieve my goals.

   The ONLY two primitives I need for I/O are Read/Write n-bytes between
   disk address i (zero based, in bytes) and memory address j (zero based,
   in bytes).  The primitives should be as efficient as possible and should
   only check for end of file conditions.  No data conversion of ANY kind
   is desired (i.e. no end_of_record marks interpreted, etc.).

At first glance, it seems that 'stream' record formats would be suitable.
But this is allowable only for sequential files (no random disk addressing).
Closer inspection shows that records in 'stream' format are delimited by
form feeds, carriage returns, line feeds, or vertical tabs.  So if my data
has the same bit patterns as any of these delimiters I wont be able to
read it back correctly.  The other two file formats (relative and indexed)
each put additional data and structure into the file which I don't want or
intend.

The truth is that RMS stands in the way of efficient implementation of the
the two primitives above.  The Fortran compiler on VMS uses RMS as it's I/O
interface.  It (I assume) uses the most efficient RMS method to implement
each of the Fortran features.  Yet several months ago the discussion arose
on this network (I think it was actually net.lang) that unformatted I/O was
a factor of SIX slower than the equivalent data transfers bypassing RMS.

While I'm sure that the above two primitives can be implemented (somehow)
with RMS I don't think the criterion for efficiency can be met.  This is
because there is so much checking, data movement, shuffling, etc. between
the user code and the disk when you go through RMS.  The end user should
NEVER have to pay for a feature that he is not using - a philosophy which
is definitely NOT followed by the RMS programmers.

As for the 'useful features' - if I had the above two primitives then
sequential and relative files would become redundant (I could do them
myself REAL easily and probable end up with more efficient code than RMS
has).  I never have a use for indexed files (not the standard RMS type).
I know how to build indexed databases and I can tailor the file structure
to the application and the type of data MUCH more efficiently than I ever
could through RMS.

In view of the fact that RMS stands in the way of what I DO want to do and
it provides 'features' which I DON'T need; why should I consider it an
advantage to have it?  I am somewhat vehement on this subject because I am
porting an I/O library between several machine/system combinations and the
the task of moving to VMS is particularly difficult BECAUSE of RMS.  For
our application we will have to bypass RMS altogether and use direct QIO
calls (which no one is familiar with and are probable as obscure as the
rest of VSM code).

J. Giles