[Info-vax] CRTL and RMS vs SSIO

[Arne Vajhøj]

On 10/5/2021 10:06 PM, Greg Tinkler wrote:
> 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.

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

To be honest then I think the safest way to implement this is
to put lots of restrictions on when it is doable.

Examples:
* No cluster support (announcement already states that!)
* Only FIX 512, STMLF and UDF are supported
* no mixing with traditional RMS calls

Some applications coming over from *nix most known PostgreSQL needs
this. But trying to cover all types of cases would be a lot of
work.

Arne