×
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.
Hi Kurt,
My question is this, other than trying to wrap up Scott's JDBCR4 into
appearing as native I/O... does OA offer any other benefit?
Not that I can see.. it'd pretty much makes it appear as native I/O. It
wouldn't accomplish anything else.
It'd carry some baggage, though...
1) You'd have to create a PF with the external definition of the remote
file in order to compile your program. (Though, it could be generated by
looking at the remote database -- but it'd have to be done before you
compiled your program, otherwise RPG would complain about being unable
to find the external definition of the file on your F-spec)
2) You wouldn't be able to use SQL abilities (such as joining, grouping,
totalling, etc) forcing you to write this in RPG code by hand.
3) If you didn't learn what's happening under the covers,
troubleshooting might be difficult. (Go ahead and ask your SQL Server
administrator why your CHAIN opcode didn't work, see what he says.)
So, you're losing a lot... and what is it gaining you? It looks like
native I/O. That's it. What good is that?
It's starting to sound like OA is a service program "under the
covers." To which I say: "why not use a service program?" This is
from the perspective of a non-vendor. I can see where a vendor could
put together something and offer it to shops as a programming tool.
Yes, that's what OA is... a service program under the covers. When you
do a CHAIN opcode, it calls a subprocedure and passes a slew of
parameters (describing the key values amongst other things) to the
procedure. When you do a WRITE opcode, it calls the subprocedure and
provides the contents of the record for the service program to "write".
That's all OA is.
midrange.com
