[Info-vax] CRTL and RMS vs SSIO

[Greg Tinkler]

I notice that SSIO (beta) in included in an up coming V9.1 field test.  So I read up on the issues it is trying to solve.

One concerning thing was to have CRTL (via SSIO) access directly to XFC.  From an architectural point of view this is wrong at so many levels, but if that is what needs to happen then open it up so RMS and other code bases can use it.

The main reason stated was the need to do byte offset/count IO’s.  Well lets solve that first, change RMS by adding SYS$READB and SYS$WRITEB.   These would be useful to all code using RMS.  
SYS$READB read from byte offset for count, return latest data from that byte range.
SYS$WRITEB write  from byte offset for count, update latest copy of underlying blocks.

SYS$WRITEB needs to use latest copy of data, and could use the new SSIO interface to XFC but RMS has it's own methods for this. 
It may seem like a big ask getting all the latest blocks, but if you think about it it only needs to re-read the last and first block if it does not already have the latest copy.  Also no need if the offset starts at the beginning of a block, and it fills the last block.

By having these as part of RMS we want to ensure the blocks/buffers are coordinated so any other user of RMS will see the changes, and we get their changes.

This seems to be at the core of the CRTL issue, it does NOT use RMS, nor does it synchronize its blocks/buffers, leading to the lost update problem.

So with this ‘simple’ addition the CRTL should be altered to us RMS for all file IO.

An extra that could be added, if the file is RFM=fixed, and the C code uses it that way with the same record length then use the SYS$GET/SYS$PUT so it will play nicely with an RMS access to those files.

Anyway just my 2 cent worth.

gt down under