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.
OAR says you have a keyword, "HANDLER", and if that keyword is set for a
given file, then every time an IO operation is requested for that file,
the RPG runtime goes to the program or service program specified in the
HANDLER keyword.
The parameters the handler will receive are defined by OAR - I suppose
that would be the interface.
As the manual says, OAR is the linkage between a standard RPG program
and a handler that will "handle" the several native IO requests in that
program. OAR is part of the RPG runtime.
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.
I'm probably missing the point somewhere. You mention something you call
SQL IO - I'm not sure what that means, either. For me, SQL is the
technology used to carry out the IO requests made in the RPG program. It
gets input from the database component of the system and delivers output
to that component.
Every IO opcode in RPG can be seen as a parameter to a call to the
database engine - things like DBGETM (get multiple), etc. A handler gets
buffers and names and states - it has to get the same results, in this
case, as standard native IO. It doesn't matter HOW - SQL is just one way
to do it - you could do this with counting on your fingers, if you had
an API to call to do that.
Someone said they did not need to use OAR for stuff - they already knew
how to use APIs for that - and that is true - an OAR handler is a kind
of traffic cop for calling APIs or whatever to carry out requests for
data operations.
Enough rambling - must go to play keyboard in pit for Little Mermaid -
I'm a harp - I'm steel drums - I'm a tambourine - I'm an average string
section - where in the world is Carmen San Diegp?
See you later
Vern
On 7/29/2016 3:47 PM, Nathan Andelin wrote:
Thanks again, Vern.
The "problem" referenced in the article appears to be specific to
Townsend's framework. So maybe I'll just have to get over the ambiguity. I
suspect that the OAR interface and handler were the key to solving the
problem rather than SQL I/O per se.
If anyone wants to chime in on OAR as a wrapper around SQL, that's an
interesting topic too.
On Fri, Jul 29, 2016 at 2:27 PM, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
wrote:
You'll have to read the article again - there is a brief mention of the
problem.there, as I recall.
There is also an earlier article at IT Jungle that doesn't include any
mention of yours truly - sort of my preference here! There is a link to
this article in 2 places in the one you refer to here.
There was also a press release - here is the link from the Townsend
Security site -
http://townsendsecurity.com/news/townsend-security-announces-major-step-forward-with-FIELDPROC
Beyond that, I'm not at liberty to say - you could contact Patrick if you
want to ask more.
Cheers
Vern
midrange.com
