[Info-vax] RMS - Wish list

[Stephen Hoffman]

On 2021-10-16 03:01:44 +0000, Greg Tinkler said:

> 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.


You're not going to abstract a stream through a punched-card database 
and back to a stream, and have a reasonable and workable solution.

No one would ever demand to have a stream of data routed through a 
SQLite database and back to a stream of data.

But here we are.

The XQP, yes, that can and does get to play here, as the user data 
managed by XQP is not tied to the punched-card constructs.

Want stream access? RMS isn't involved. At all. Best case, stream 
access blocks new RMS access, and an RMS open blocks any stream access 
attempts.

>>> 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.

Support for directly accessing RMS locking is unlikely.

> DCL support to read/write a byte range in a file, aka UDF files.

The current DCL 32-bit integer limits gets you tiny files when 
specifying byte addresses in files.

Yeah, somebody is going to suggest block and byte references.  Fun times, that.

The lack of 64-bit support in DCL will also soon collide with the 
64-bit LBN work underway at VSI, too.

> Add timeout to the PIPE driver, should have it anyway.

I'd like COPY /SFTP and ilk, and the ability to open SSL/TLS-protected 
connections akin to what DCL has had with DECnet for aeons. With that, 
I care rather less about local pipes.

> Remove <> as a directory limiter, unless quoted, so we can have pipeless pipes.

Angle brackets for directory delimiters isn't going away with the 
prevalence of ODS-2 and ODS-5 file system. What an extension to those 
or replacement file system might bring?

> 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!

RMS internals are RMS internals.

Wasting a few bytes with a file or logical or resource name prefix is 
traditional on OpenVMS, too; app-specific namespaces, not so much.

> And can we please get VMS to be 64 based as the default before we need 
> to make 128 bit based...

OpenVMS has barely gotten to 64 bits, and not at all cleanly. Issues 
involving the 65th (virtual or physical) addressing bit aren't even in 
the realm of discussion for any mainstream operating systems.

Getting DCL to 64 bits would be nice, and "NuDCL", "DCL2", and 
modifications to DCL have been discussed before. Wholesale replacement 
is a whole lot easier. PowerShell, bash, and zsh have all been 
suggested, as have some others.

> 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...

By all appearances, VSI is understaffed for the port and related work, 
and for what they have on their schedule after the V9.2-1 production 
release.  Not that adding staff at this juncture would likely 
appreciably speed the release of the port.







-- 
Pure Personal Opinion | HoffmanLabs LLC