[Info-vax] RMS - Wish list

[Greg Tinkler]

re $GET, sorry yup you are correct you can use $GET to get an arbitrary range of yes from a UDF file, but you cannot you $UPDATE.
%RMS-F-CUR, no current record (operation not preceded by $GET/$FIND), even if you do a $FIND or $GET before.
FYI $PUT is good to append to the file.

So I see this inconsistency as a bug...

re stream file, interesting thought stream/meme...  
Originally the term was probably from using punched tapes, remember them.  What we now focus on is addressable data, call it a record, or an object or a what ever but it is not stream.  In fact even punched cards are more stream than record based, at least that is my memory of them.

Even the example given for SSIO was a block of bytes, i.e. a record, needing to be updated somewhere on a disk block(s).  That is NOT stream access.
>> SSIO seeks to avoid the latent file corruptions that arise with sharing
>> stream files within the current implementation of C and RMS: 
Yes, it is the CRTL implementation, not RMS.  RMS has its limitations hence the wish list.

And to add the wish list, 
A higher level lock API for RMS so we can change the file lock, record lock, block/buffer lock on the fly.  Needs some documentation on the resource named used by RMS.
DCL support to read/write a byte range in a file, aka UDF files.
Add timeout to the PIPE driver, should have it anyway.
Remove <> as a directory limiter, unless quoted, so we can have pipeless pipes.
Add resource name spaces to System locks so RMS etc can have its own area, and not have to waste x bytes with a prefix to the resource name.  NB the is space in the lock block to do this!
And can we please get VMS to be 64 based as the default before we need to make 128 bit based...
Sorry the last one is something I have argued with the VMS group for a long time,  well a long time ago, pre-alpha release.
NB I do like the sign extended pointers...

All good thoughts and ideas.
gt