Re: Database I/O Modernization

this design won't work for programs, making updates without commit.

It appears that you might agree that setting up commitment control is
typically very disruptive to legacy applications. It's arguably not needed
for single-record updates as implemented in I/O servers, but rather
designed to ensure the integrity of multi-update transactions.

Creating your SRVPGM with named Activation group would not run at all with
commitment control in existing applications.

Existing applications would be forced to implement commitment boundaries,
commits, and rollbacks.

It's the strange design with RLA, causing most of your problems and your
wrapper design with parm Action has more performance influence than the
single call to make an I/O operation happen.

That was confirmed by the benchmark programs I ran.

Your "Benchmark" is just telling nothing.

Well, it is measuring READ performance, which is more than nothing.

Real world programs don't make I/O to do nothing and even slowing down an
I/O operation from one millisecond to 5 milliseconds would only make a
difference in processes making millions of reads (or writes)

I understand that READ performance would be inadequate if considered alone.

and then SQL would outperform rla anyway, if it is used as it should.

That's another subject.

To be clear, these are not my I/O servers, nor am I advocating for them.
I'm accumulating my thoughts at the following link, which also shows the
benchmark code:

https://rd.radile.com/rdweb/info2/ibmiapp02.html