Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site psivax.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxb!mhuxn!mhuxm!mhuxj!houxm!vax135!cornell!uw-beaver!tektronix!decvax!ittvax!dcdwest!sdcsvax!sdcrdcf!psivax!friesen
From: friesen@psivax.UUCP (Stanley Friesen)
Newsgroups: net.arch
Subject: Re: RMS useful?
Message-ID: <314@psivax.UUCP>
Date: Thu, 7-Feb-85 18:53:54 EST
Article-I.D.: psivax.314
Posted: Thu Feb  7 18:53:54 1985
Date-Received: Wed, 13-Feb-85 03:09:57 EST
References: <105@endot.UUCP> <1399@uscvax.UUCP> <248@scgvaxd.UUCP> <20079@lanl.ARPA> <1547@uscvax.UUCP> <20969@lanl.ARPA>
Reply-To: friesen@psivax.UUCP (Stanley friesen)
Organization: Pacesetter Systems Inc., Sylmar, CA
Lines: 39
Summary: 

In article <20969@lanl.ARPA> jlg@lanl.ARPA writes:
>> 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.).
>
>
>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 fact I will go even further, these primitives are *already*
implemented in UNIX, they are the system calls 'read', and 'write'!
At least if you add 'seek'.  And I must agree, given these primitives
*any* I/O protocol can be implemented with consummate ease. And since
they would be(and in fact *are*) subroutines the system overhead would
be smaller than the "double level interrupts" of the RMS services.
The UNIX file system is ultimately flexible(no assumptions), and simple
(only 7 operations, each with a max of 3 parameters). Compare this
to the complexity and rigid structuring of the RMS calls.
-- 

				Sarima (Stanley Friesen)

{trwrb|allegra|cbosgd|hplabs|ihnp4|aero!uscvax!akgua}!sdcrdcf!psivax!friesen
 or
quad1!psivax!friesen