Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site uscvax.UUCP Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!sdcrdcf!uscvax!tli From: tli@uscvax.UUCP (Tony Li) Newsgroups: net.arch Subject: Re: RMS useful? Message-ID: <1644@uscvax.UUCP> Date: Sat, 9-Feb-85 04:28:02 EST Article-I.D.: uscvax.1644 Posted: Sat Feb 9 04:28:02 1985 Date-Received: Mon, 11-Feb-85 04:42:48 EST References: <105@endot.UUCP> <1399@uscvax.UUCP> <248@scgvaxd.UUCP> <20079@lanl.ARPA> <1547@uscvax.UUCP> <20969@lanl.ARPA> Organization: CS&CE Depts, U.S.C., Los Angeles, CA Lines: 91 > 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. In my limited experience, I would suggest that you use the VMS standard variable length record sequential file. This would permit you to transfer a (possibly large) record at one time. You would have to deal with the problem of a record not precisely fitting into you n-bytes. I question if you really want your Read/Write n-bytes. Efficient file systems tend to transfer things in blocks. (Yes, even Unix, down deep has to block files). If n and the block size don't fit nicely, you get into problems. Nothing tough, mind you, just ugly. Perhaps if you told me what your application needs to do, instead of trying to make VMS look like Unix, you'd have more success. Emulating one OS on top of another is never simple -- look at Eunice. > 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. I'm sorry that I wasn't around, and yes, I'll believe that RMS is not as fast as doing a direct QIO. > 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. Well, yes, since that is a sequential file, I suppose that another type of sequential file is redundant. Fortunately, it's still useful. As to the relative file, I don't see the efficient implementation unless you permit n to be negative... In that case, I have no good ideas for you. It's true that you can write something that is more efficient than RMS, if you can guarantee that you'll never make a mistake in calling it. This is the price of 'bulletproof' software. It's also the price of general software. The advantage is that you have one file system for ALL applications and you don't have to roll your own each time you do something. > 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 VMS code). I find it hard to believe that you are having this type of problem. Direct QIO's to disk are pretty gross, and I'd try really hard (unless your application is real-time) to avoid using them. As to obscurity, I don't think that anyone using Unix should talk (unless you're talking about sources - I'll grant that I prefer reading Unix sources) about obscurity; the VMS system services manual and the RMS services manual are both on par with the size of the Unix programmers manual. The descriptions are clear and straightforward -- even I can understand them. From the VMS camp, -- Tony Li ;-) Usc Computer Science Uucp: {sdcrdcf,randvax}!uscvax!tli Csnet: tli@usc-cse.csnet Arpa: tli@usc-ecl