[Info-vax] RMS and SSIO (again)

[Hein RMS van den Heuvel]

On Wednesday, January 12, 2022 at 5:31:33 PM UTC-5, tink... at gmail.com wrote:
> > One of the people who created SSIO now has been working on RMS since 1975 (member of the initial VMS design team :) 
> > Another example is Ruth Goldenberg, she came up with part of the SSIO design.
> Good to know, pity they did not see this solution. But to restate what I said before, byte to XFC is a good thing particularly if it integrated into RMS, i.e. have XFC do the buffering for RMS.

There needs to be a 'system' buffer, not a 'process' buffer. 
For robustness that buffer is probably  best on top of XFC, not inside.

You have been focussing on random updates. nice of database, irrelevant for typical usage today.
I think the more important problem to solve is shared appends and eof handling ( tail -f )


> What changes would I like to RMS, particularly with regards tp XFC. 
> - change $READ/$WRITE to use the MBC/Bucket buffers that RMS has, which would be XFC 

READ/WRITE does NOT use (RMS) buffers. The user provide record (UBF on read, RBF on write)

> - change $READ/WRITE so they use byte offset. NB this is possible without change the RAB, just by adding a ROP (byteoffset) and using all the space available for RFA, i.e. RAB$Q_RFA. 

The current RFA already has a (32bit) block and (16 bit) byte offset. 
I suppose you could add RAC=RFA and make $READ/$WRITE use the RFA fields, not the BKT.

> - fix $FIND so it will work with UDF files, so that $UPDATE can work without having the read data 

$FIND has to read the data into the rms process buffer also. 
It just does not move it to a user provided record buffer - a minor step in the scheme of things.
The biggest special thing about $FIND vs $GET is that $FIND only impacts the current record, not the next.
That is useful for updates. A program could be doing GET GET GET (all next 'blobs') then see some special data and decide to need a FIND and UPDATE for a random record before doing the next GET to continue reading a sequence. I find using two rabs for that more clear, more robust.


Hein.