Sometimes, Nathan, sometimes it seems you don't really get what OAR is
about - I suppose you might call it an interface - depends on what you mean
by that term.
I call it an interface because the handler has a name, keyword parameters,
and a parameter data-structure is passed each time the handler is called by
an I/O operation; similar to procedure interfaces.
The parameters the handler will receive are defined by OAR - I suppose that
would be the interface.
Yes.
The OAR whatever and handler don't solve anything on their own. One of the
things you receive in the main handler parameter is which operation was
requested - and you write code to process that as desired. The CODE in the
handler is what solves the problem, not OAR itself.
Yes, I agree with that. You're also admitting that the handler may solve a
problem, say a problem with field-proc encryption which a programmer who
may be using RLA opcodes may know nothing about, which IBM's default DB I/O
procedures may not be designed to handle.
I'm probably missing the point somewhere. You mention something you call
SQL IO - I'm not sure what that means, either.
I say SQL I/O when referring to SQL SELECT, INSERT, UPDATE, DELETE, etc.
SQL Statements which cause the SQL Query Engine to call DB I/O procedures
under the covers (which are listed in the JOB's call stack).
For me, SQL is the technology used to carry out the IO requests made in the
RPG program.
I'm not sure if you worded that the way you intended. You're not saying
that SQL is the technology that carries out RLA requests, right?
I think of SQL as language statements and elements. The runtime engine
(SQE) makes decisions about how to process statements, perform DB I/O, and
return results.
I think I understand RPG open-access much better than you give me credit,
including a good understanding of the mainstream OA handlers which are used
to supplement display files.
As an Amazon Associate we earn from qualifying purchases.