×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On Sat, Oct 14, 2017 at 5:07 AM, Jay Vaughn <jeffersonvaughn@xxxxxxxxx>
wrote:
I'm a little confused on one final piece of dissecting the fetched row out
to return back to the database manager.
Just a point of clarification in regard to returning "back to the database
manager". It's a little confusing to assert that you are returning data
back to the database manager. Your ROA handler is actually a substitute for
the database manager. The RPG program is bypassing the database manager,
and invoking your ROA handler instead.
The term "database manager" is quite vague. RPG RLA opcodes normally invoke
procedures in the QRNXIO service program. Adding the "handler" keyword to
the "f" spec causes the RPG program to bind to your ROA handler instead.
I gather that you mean mapping data from the SQL cursor to the record
buffer of the RPG program that invokes your ROA handler. The address of the
record buffer is passed to your ROA handler in the "inputbuffer" subfield
of the QrnOpenAccess_T data structure.
And if you really think I'm reinventing the wheel, please produce the wheel
for me and I'll use the wheel as-is. But so far in my journey, NOBODY has
produced the wheel for me. But I do agree, if it's generic to any file, how
come it's not floating around somewhere. My conclusion is that Vern has
written the only one and it's a very proprietary piece to Townsend's
encryption product.
You've evidently done more research into the ROA handler licensed by
Townsend than I have. The IT Jungle article implied that the ROA handler
might be licensed separately from Townsend's encryption product.
midrange.com
