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

Scott

I have gone through much of what you say here, and agree that there are limits. I have found a few acceptable - to me - ways to make it OK, however. IBM have provided a database migration tool that does very well for Oracle and SQL Server and maybe mySQL - it takes a little tweaking, but the result can be very useful. It's what I suggest to people that'd use our handler. You will have to deal with mapping of field names to those in the RDBS. Very doable, of course.

You can have other than PFs - LFs do fine, as do views. Someday I may add the ability to use JOIN LFs - of course, you'd be limited to what those can do, in the matter of joining. If you had a view, maybe you'd extract THAT statement and there you are.

I generally position our handler as a way to more easily use our product - especially for those who may never have called a procedure - which they have to do a lot of with our product - and with your JDBCR4, too, as I recall. The OAR stuff greases the skids, gets people going sooner to be productive. Now things can get interesting rather quickly, and then they'd go to doing the procedure calls.

So what do you gain? Maybe a smoother transition to newer technology, maybe making something even possible to shops with limited personnel resources.

Oh - and consider WRITing a CREATE TABLE statement to and Oracle server! This is the kind of reframing of what the opcodes can do that this new feature can enable.

Regards
Vern

On 2/2/2012 5:37 PM, Scott Klement wrote:

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.