[Info-vax] RMS and SSIO (again)

Greg Tinkler tinklerg at gmail.com
Wed Jan 12 17:31:32 EST 2022


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

> > Also after 17 years and it still not working don't you think it is time to move on, and just fix CRTL. NB I have also stated that RMS should be fixed but until then the work around I have suggested to a good fit.
> Current status - SSIO works well and is in the field test phase. It's simple, fast, and fixes the problem for everyone, not just CRTL users.
Apparently so, but no one has refuted that SSIO is NOT cluster safe, whereas the CRTL/RMS change is.

> The options for fixing this problem in CRTL that I know are complex and slow. Maybe your hack is quick and easy, I haven't looked at it carefully yet.
This is where we disagree,  complex no, actually will probably simplify the code.  If the changes to RMS are also done then even less complexity for CRTL.

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
- 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.
- fix $FIND so it will work with UDF files, so that $UPDATE can work without having the read data
- use the $ SET RMS values to directly impact XFC, block size/buffer/...
- and the list goes on, and has been around for decades

So Vitaly, do you work in the VSI/RMS space?

gt



More information about the Info-vax mailing list