Re: AW: Open Access to be generally available as part of the RPG compiler

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.