jlg@lanl.ARPA (02/04/85)
> 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
rcb@rti-sel.UUCP (Random) (02/06/85)
Why not read the manual. The primatives are called block I/O. They will let you do what you want. Random Research Triangle Institute ...!mcnc!rti-sel!rcb
friesen@psivax.UUCP (Stanley Friesen) (02/08/85)
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
tli@uscvax.UUCP (Tony Li) (02/09/85)
> 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
ddb@mrvax.DEC (DAVID DYER-BENNET MRO1-2/L14 DTN 231-4076) (02/13/85)
While I'm not fan of VMS RMS, the fact that it provides reasonably consistent and compatible file structures is a big win; Since all indexed files on the system are RMS files, any program g can read any file. Contrast this to the mess of unique file structures "optimized" for particular applications, and completely unreadable by anybody else. I'm not totally convinced that this is enough to justify the problems that RMS often causes. But wouldn't it be nice to have some standard subroutines to implement some standard more-complex file organizations? Wouldn't it be nice to read your dbaseII indexed file into a C program? Or to type your indexed file (assuming only textual data in it) and see it in order by prin primary key? Yes, you can do a special-case tool for each of these, but what a crock! -- David Dyer-Bennet -- ...decwrl!dec-rhea!dec-mrvax!ddb
chris@umcp-cs.UUCP (Chris Torek) (02/14/85)
I don't quite understand (nor do I know what this discussion is doing in
net.arch). Why should every program need to understand indexed files?
All you need to do is pipe the output of the indexed-file reader into the
other program.
What, you say you don't have pipes in VMS? Maybe you'd better put them
into RMS. :-)
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris@maryland