[Info-vax] OpenVMS async I/O, fast vs. slow

[Arne Vajhøj]

On 11/7/2023 12:27 PM, Jake Hamby (Solid State Jake) wrote:
> I made a bigger mistake in my earlier post, which I'm surprised no
> one seems to have caught. I wrongly stated that the RMS file block
> services allowed you to read/write starting from any position, but in
> fact you have to read/write starting from a 512-byte block boundary,
> the same as for $QIO and $IO_PERFORM. You can read less than a full
> block, so that's how the ends of files are handled (it's not like
> CP/M where everything gets rounded up and you lose the real file size
> or anything like that).

Depends on where you are measuring.

:-)

application---(API X)---RMS---(API Y)---VMS

API X starts at block boundaries for $READ and $WRITE but on
byte boundaries for $GET and $PUT.

API Y starts at block boundaries for $QIO(W).

So RMS $GET and $PUT translate from starting at byte boundary to
start at block boundary, which means a buffer.

As you note then $IO_PERFORM(W) start at block boundary just like $QIO(W).

When SSIO (I cannot remember the system service name right now)
becomes available it will allow start at byte boundaries.

> With that additional info, I now believe the C RTL is going through
> RMS primarily in order to handle all the different VMS record formats

In general that is what RMS provide.

The RM in RMS stands for record management, so it manage
records on top of the basic file blocks. That covers
understanding the record formats and locking.

I believe most language RTL use $GET and $PUT to let
RMS do all the record format handling.

C RTL is a little different I believe. fgets/fputs do records
but fread/fwrite do blocks. And then there is the difference between
ctx=rec and ctx=stm. I don't know when it use $GET/$PUT and when
it use $READ/$WRITE and does its own record handling.

Arne