Re: Database I/O Modernization

<Nathan>
I'm just saying that there are valid use cases for SQL, and that there just as valid
use cases for RLA. Pick the right tool for the job.
</Nathan>

May I remind you of the starting point of the discussion: You introduced a SRVPGM to externalize RLA I/O. In this SRVPGM you've used RLA, expecting you are using the right tool for the job, I suppose!
In some of my postings I pointed out (and Charles had some other valid arguments), that RLA is not the right tool for this job!!! Here are only some of the arguments:
- lousy performance for read only (because your implementation lost blocking), SQL would have performed by far better!!!
- the implementation doesn't meet the requirements, (the share problematic)
- tight coupling, as your implementation and all referencing programms need recompile after changes to the table.
- your initial draft is just producing overhead, without doing anything better.
These problems are not solvable with RLA, even embedded SQL would not be sufficient, to solve the share problematic SQL CLI would be the way to go. What we are seeing here, is a typical problem of RLA usage. If we limit the tools to RLA, we would end up in spreading around RLA access all over the application, because its not possible to centralize acces to a table into one SRVPGM using RLA. And then we would have exactly that problem, you were trying to solve by externalizing Database access to a SRVPGM - changes in Database Design has impact to hundreds of programms or more.

D*B