[Info-vax] RMS and SSIO (again)
Greg Tinkler
tinklerg at gmail.com
Sun Jan 9 21:57:28 EST 2022
Arne
frankly I am not surprised that the offshore VMS group could fix it, I am surprised the the back in the 80/90's the CRTL folk did not talk with the RMS group and have a good solution in place to start with. But then C IO was a very low priority, you either did RMS or your own $QIO. Now with open source it is a very different ball game.
SSIO is not and was never a well designed solution. It looks more like a *nix persons view of how VMS should work.
Once XFC can be properly used for buffer sharing across the cluster, and RMS can use it, then maybe, but why not then just use RMS. The main question re XFC is the focus disk io buffering or file caching. If it is disk IO then it should probably use the device's 'cluster size' as the buffer size, if it is file buffering then it should be MBC/Bucket size. Using some 'fixed' value that does not match either of these will/does cause issues...
The SYS$MODIFY's function is what you just described, after an open, get RMS to pretend that the file is of a different format. And no it is not just 20 lines, that was the few line to help those that don't understand VMS/RMS what is possible. Careful code design would allow the initial open to use UDF so you don't need to do it each IO.
"There is no need for all of that. It can be done other ways."
Well if that is the case then please put your code up... and clearly you don't think SSIO is a good solution either. 8-))
gt
More information about the Info-vax
mailing list