Re: Database I/O Modernization

Dieter,

On Sat, Sep 16, 2017 at 12:30 AM, D*B <dieter.bender@xxxxxxxxxxxx> wrote:

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!

I had already formed a negative opinion about the I/O server that I
referenced in my original post, prior to my posting the source code. I felt
that the particular procedure interface, which consisted of 3 parameters,
was regressive. It was an anti-pattern. It might have some appeal on the
surface. It might work in a limited context. But it wouldn't work in a
broader context.

It's severely constrained by the procedural interface that's exported. I
didn't share my opinion right up front because I didn't want to bias
anyone, and I wanted to vet my own findings against the findings of others.

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 programs need
recompile after changes to the table.
- your initial draft is just producing overhead, without doing anything
better.

I appreciated and valued your points shared in this discussion. Not because
RLA itself is regressive, but that the interface surrounding it in that
service program is regressive.

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.

I've been using SQL views, paired with an RPG wrapper around SQL CLI in
most of our applications for about the past 15 years.

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 access to a table
into one SRVPGM using RLA.

The problem with that service program had little to do with RLA, and more
to do with the constrained interface that wrapped the 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 programs or more.

Let's put changes to database record formats in proper perspective. Any
major changes to record formats will trigger an assessment of the impact on
programs. You'll have to make that assessment whether you use SQL or RLA.
That and actual code changes will take the most time. Recompiling and
testing programs in order to remove file level checks is less of a factor.
The actual recompile can be automated.

The frustrating part of this discussing for me is the myopic view that all
I/O must be SQL, and the equally myopic and opposite view that all I/O must
be RLA. Use the best tool for the job.