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