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