dww@stl.UUCP (David Wright) (03/14/85)
When I first started to use VMS I thought all that Index Sequential stuff was way over the top - but now I'm wiser and actually use IS files I find they are very effective - but still amazingly complex to fully define. What I find very impressive is that you DON'T NEED TO BOTHER about all the complexity - DEC have a special editor (EDIT/FDL) which designs the file organisation for you - you answer its questions about how many records you'll have/where and what the keys are/do you expect records to be entered in sequential order or not/etc. and it does the rest - even tells you how good it thinks the result will be. It's the sort of programme which would be called 'AI' if written in LISP but as it's probably in BLISS ... Other file system developers please copy!
chenr@tilt.FUN (Ray Chen) (03/18/85)
>When I first started to use VMS I thought all that Index Sequential stuff was >way over the top - but now I'm wiser and actually use IS files I find they >are very effective - but still amazingly complex to fully define. What I >find very impressive is that you DON'T NEED TO BOTHER about all the >complexity - DEC have a special editor (EDIT/FDL) which designs the file >organisation for you - you answer its questions about how many records you'll >have/where and what the keys are/do you expect records to be entered in >sequential order or not/etc. and it does the rest - even tells you how good >it thinks the result will be. It's the sort of programme which would be called >'AI' if written in LISP but as it's probably in BLISS ... > >Other file system developers please copy! Other file system developers please ignore. There's no reason why you can't have IS/VSAM/* files but keep them out of the kernel. Use a simple stream model and supply the routines and the above program as a user library and a user program. Ray Chen princeton!tilt!chenr
dlm@piggy.UUCP (Daryl Monge) (03/18/85)
Once and for all; RMS is NOT in the kernel. It is possible to do I/O directly to disk files without RMS, using the VMS equivalent of read/write. We used that technique once when we needed AST interrupts on I/O to many files.
guy@rlgvax.UUCP (Guy Harris) (03/19/85)
> Other file system developers please ignore. There's no reason why you can't > have IS/VSAM/* files but keep them out of the kernel. Use a simple stream > model and supply the routines and the above program as a user library and > a user program. Which is exactly what RSX-11M RMS does (although the file model that the kernel provides is an array of blocks, not a seekable stream of bytes). VMS does almost the same thing, only it puts RMS into executive mode (I'll bet you've wondered what executive and supervisor mode on the VAX were good for). I believe the OS access methods also run in user mode; my acquaintanceship with OS is old, but I think the model it provides of I/O devices is of something that you feed channel commands to - there's a system call (EXCP) to tell it to run a particular channel program. -- Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
jlg@lanl.ARPA (03/19/85)
> >When I first started to use VMS I thought all that Index Sequential stuff was > >way over the top - but now I'm wiser and actually use IS files I find they > >are very effective - but still amazingly complex to fully define. What I > >find very impressive is that you DON'T NEED TO BOTHER about all the > >complexity - DEC have a special editor (EDIT/FDL) which designs the file > >organisation for you - you answer its questions about how many records you'll > >have/where and what the keys are/do you expect records to be entered in > >sequential order or not/etc. and it does the rest - even tells you how good > >it thinks the result will be. It's the sort of programme which would be called > >'AI' if written in LISP but as it's probably in BLISS ... > > > >Other file system developers please copy! > > Other file system developers please ignore. There's no reason why you can't > have IS/VSAM/* files but keep them out of the kernel. Use a simple stream > model and supply the routines and the above program as a user library and > a user program. Hear, Hear! (Where, where :-) I am a file system developer. And I plan to include indexed files at a very high level - if at all. As I have pointed out several times in the past, this type of low level implementation is my main objection to VMS/RMS. The above note contains some of the reasons why. 1) the tool tells you how good it thinks the result will be - translation: the tool can't implement some data structures very efficiently since it has only one model of indexed files to translate into. 2) the built-in file tools are inadequate for database management so you require off-line tools to do part of the job (most of the job usually). Why not have the whole idea of indexed files removed from the system since only a woefully inadequate piece is there anyway. 3) this is not from the above article, but it is clear that users that don't need indexed files are paying for them involuntarily (and unnecessarily) since they are in the lowest level file handler. J. Giles
tihor@acf4.UUCP (Stephen Tihor) (03/20/85)
3) this is not from the above article, but it is clear that users that don't need indexed files are paying for them involuntarily (and unnecessarily) since they are in the lowest level file handler. J. Giles Sure they pay for it. It costs a couple of pages of physical memory. Not zero, but not a lot at current memory prices.
dww@stl.UUCP (David Wright) (03/21/85)
>>When I first started to use VMS I thought all that Index Sequential stuff was >>way over the top - but now I'm wiser and actually use IS files I find they >>are very effective - but still amazingly complex to fully define. What I >>find very impressive is that you DON'T NEED TO BOTHER about all the >>complexity - DEC have a special editor (EDIT/FDL) which designs the file >>organisation for you - you answer its questions about how many records you'll >>have/where and what the keys are/do you expect records to be entered in >>sequential order or not/etc. and it does the rest - even tells you how good >>it thinks the result will be. It's the sort of programme which would be >>called 'AI' if written in LISP but as it's probably in BLISS ... >> >>Other file system developers please copy! > >Other file system developers please ignore. There's no reason why you can't >have IS/VSAM/* files but keep them out of the kernel. Use a simple stream >model and supply the routines and the above program as a user library and >a user program. > > Ray Chen > princeton!tilt!chenr Yes yes please do keep the file system out of the kernel - why did you think I wanted it in there? Our own RT O/S work managed to keep it separate. I was referring in my original item to DEC VMS, where the file system is a (fairly) separate entity called RMS. Use of libraries for file operations are not always the answer though - they are for compact systems, but not for biggies like VMS. One important advantage of having IS etc. built in to the operating system (not into its kernel though) is that it encourages the language developers for that system to support the full set of facilities, including (e.g.) IS access. In VMS, IS access is almost as easy to use as sequential for most languages, even in Pascal and DCL (DEC's appology for a shell), which do not usually have such options without getting out the system library manual. But what you seem to have missed entirely is WHAT I want other designers to copy - which is that if you introduce a fundamentally complex thing like Index Sequential file structure, give the user tools to manipulate it without his/her having to be an expert. P.S. please don't lets argue about how RMS is too big and has far too much stuff in it; we all know that - especially all those file types!
bjorn@alberta.UUCP (Bjorn R. Bjornsson) (03/24/85)
> > 3) this is not from the above > article, but it is clear that users that don't need indexed files are > paying for them involuntarily (and unnecessarily) since they are in the > lowest level file handler. > > J. Giles > > Sure they pay for it. It costs a couple of pages of physical memory. Not zero, > but not a lot at current memory prices. How often does this have to be repeated: RMS/indexed files, et. al. are not in the lowest level VMS file handler. The real problem with RMS is the profusion of "file types". Since RMS is in the RTL (RunTime Library), which happens to be shared by all images running under VMS, the cost in memory is as follows: 1) If indexed files are being used: a few pages physical memory. 2) If no indexed files are used, the code will eventually be paged out, cost: a few disk blocks. I'm of the opinion that we could save a lot of grief in this newsgroup as well as others, if people who know absolutely nothing about VMS would cease their flaming about it's shortcomings. VMS does have shortcomings (as does UNIX), but that doesn't change the fact that imaginative fiction about VMS, appears with astounding regularity.
bjorn@alberta.UUCP (Bjorn R. Bjornsson) (03/25/85)
In a previous message I said: > 2) If no indexed files are used, the code will eventually be > paged out, cost: a few disk blocks. Apparently I'm not above some imaginative fiction myself. RMS being "pure" code never gets paged out, only in.
jlg@lanl.ARPA (03/25/85)
> 3) this is not from the above > article, but it is clear that users that don't need indexed files are > paying for them involuntarily (and unnecessarily) since they are in the > lowest level file handler. > > J. Giles > > Sure they pay for it. It costs a couple of pages of physical memory. Not zero, > but not a lot at current memory prices. On my desk I have a copy of the source code to the Fortran support library and to RMS (fiche thanks - or it wouldn't fit on my desk). Having traced through some of the labyrinthine logic of these bodies of code I can tell you that the price for features in RMS is HIGH. By the second or third dozenth check of various flags, you don't really care whether the I/O gets done or not. One benchmark (unformatted I/O through RMS and the same data through QIO calls) showed a factor of SIX difference in speed. Don't claim the cost is minor until you've compared the results! J. Giles
chenr@tilt.FUN (Ray Chen) (03/26/85)
Before any more RMS isn't in the kernel messages get posted, let me say, yes, I know. My brain was out to lunch when I posted that article. I just saw the words "file system developers" and immediately winced. I agree with you about the file specification/simulation program. If the access method requires a complicated file structure, a user-assistance program is a nice thing to have around. I just wish VMS's basic i/o was a little nicer. QIO's are gross. Ray Chen princeton!tilt!chenr