[Info-vax] RMS and SSIO (again)

[Hein RMS van den Heuvel]

On Saturday, January 8, 2022 at 7:07:58 PM UTC-5, tink... at gmail.com wrote:

> If you look at the parameters they are almost $QIO so why not change it so they are. 

QIO is a generic interface, this a specific one.
It's called progress without being disruptive, still giving a familiar touch and feel.
Switch to all 64 bit, ditch the crud.  
IO$_READVBLK orred with modifier bits? Yuck!
Almost too bad they kept the 'channel' instead of a generic (more) opaque 'handle'. 
Almost because  but I do love my SDA> SHOW PROC/CHAN and such.

> One if the things that a lot of users of VMS have liked years is the focus on quality engineering looking at the whole OpenVMS environment, and not a knee jerk response to some particular issue. 

Steam IO  a knee-jerk reaction? Ha! It's been looked at, worked on for 20+ years.

> NB in this case the correct solution was FIX CRTL to use RMS correctly. 

Nonsense. The C-RTL folks didn't live/work in a vacuum. They know/knew how to use RMS, they know about the FAB$C_UDF hackery.
They know (and implemented) how NOT to use (buffered) RMS and switch to SYS$READ/SYS$WRITE  to avoid excessive going in an out of EXEC mode with all the probing for simple actions.

> > p.s. About cluster support - "SSIO V1 has minimum cluster support".
> Yup, it does not define what 'minimum cluster support' is. For more minimum cluster support means it supports cluster, end of, i.e. it either supports cluster, 
> which if it uses XFC it must, or it is some other interface maybe hacking XFC which we don't want. 

You mistakenly believe that XFC usefully supports clusters. It doesn't. It merely coexists peacefully.
All the XFC caches for a file on one node are invalidated when a change, any change, anywhere is made for that file on an other node.

> XFC by it's very nature coordinates the updating of 'buffers' (MBC's) for all files in the cluster across all systems in that cluster. 

Noop.

> If it does not work that way then a lot of things will break. 

Correct. The XFC knows just enough to walk away before it breaks.

> If it does work that way, and we have a reasonable expectation that it does,

Noop.

> Back to my main point, RMS buffer can go. 

Now there you are correct. 

The whole goal of stream IO should  be to get rid of protected process buffers and use shared system buffers like Linux does.

> We can now use XFC to do the local/global buffering, NB XFC may need some tweaking so it will use bucket size, and number of buffers as set by $ SET RMS/BUFF... which it sort of does now anyway. 

I disagree. Let RMS keep doing the global buffers, relative files, indexed files, bucket size
Just solve the shared sequential file problems.

fwiw, I don't see how the XFC 'sort of does' take MBC, MBF, BKS into consideration. It doesn't. It just divides a file up in 8KB (or was it 16) cache lines with zero consideration for actual usage. In fact the default for indexed and relative file causes maximum overhead due to the prologue block(s) in those files as well as the typically 'odd' cluster sizes.
Even if you make the bucket size a nice multipel of fraction of a cache line, you'll start off  with the odd bucket and there will need an extra cache line all the time.
I did extensive experiments with this back in the day (Mark Hopkins!) .
If you tweak an Indexed file just so - over and beyond normal tweaking - you can get a few percent improvement - reducing CPU and IO.
(make cluster size a multiple of 16, make bucket size a multiple or divisible fraction of 16, make the data NOT be in AREA 0 which has the prologue)

Cheers,
Hein