[Info-vax] RMS and SSIO (again)

[Greg Tinkler]

On Sunday, 9 January 2022 at 4:12:43 am UTC+11, Vitaly Pustovetov wrote:
Hi Vitaly

> We don't have to assume anything about the current interface of SSIO. Because it is already define. 
It is not in any 'released' documentation, possibly part of FT and therefore subject to change...

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

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.  NB in this case the correct solution was FIX CRTL to use RMS correctly.

My point is lets use this change to benefit lots of requirements for VMS, not just Postgresql.  Part of that would be to code pread/pwrite in CRTL to use this interface, and have the byte update XFC/SSIO API visible to all code that uses  ACP/XPQ.

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

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.  If it does not work that way then a lot of things will break.  If it does work that way, and we have a reasonable expectation that it does, then implicitly SSIO will work across a cluster subject to the application code coordinating the access to the data to avoid those issues that are outside XFC's control, aka serializing data access probably using LCK$...

Back to my main point, RMS buffer can go.  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.

gt