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

Hi Scott,

Just some thoughts about this -- how about a handler for HTTPAI? Pass
the URL as a key and get back the website as a record on a CHAIN?

I haven't done any SOAP or REST stuff, but how about stuffing all that
in a handler?

Maybe your FTP api?

How about your Excel service program? OPEN the spreadsheet, READ
through the rows, CHAIN to a specific row, WRITE a row?

It's great to know a lot of new stuff, but even after I know it, I'm
always trying to find ways to encapsulate it so I don't have to
constantly deal with the details. That's why we write procedures,
service programs, etc. If there's another way to reduce the complexity
of a program so the business logic is clearer, I'm all for it.

--
*Peter Dow* /
Dow Software Services, Inc.
909 793-9050
pdow@xxxxxxxxxxxxxxx<mailto:pdow@xxxxxxxxxxxxxxx> /

On 2/2/2012 3:29 PM, Scott Klement wrote:

Hi Vern,

An obvious possibility for me is remote databases. You have put together
great material on using JDBC - your service program could be the core of
a nice handler - just as I've done that with our RPG2SQL product.

I approach this with a similar stance as UI modernization. Shouldn't we
be using SQL to access remote databases instead of native record-level
I/O?! Wouldn't that be better.

Sure, you could say that there are lots of existing programs out there
using native I/O and maybe users want to have them work with SQL Server
or Oracle or something without rewriting the code. Okay, I can see that
-- but, again, that's a quick-fix, not the ultimate goal. The ultimate
goal should be to use SQL.

Dieter Bender has already written an ARD driver for JDBC so you can use
the dynamic embedded SQL operations (EXEC SQL) for accessing other
databases like SQL Server, Oracle, MySQL, etc. Isn't that a better
solution than OA?

At least "normal" native I/O, has a minor performance advantage over
SQL. With an OA driver to a JDBC connection, it'd be the opposite, the
direct SQL would actually be faster than the OA calls (which would use
SQL under the covers, but wouldn't be able to do set-based processing.)

Not to mention that the handler would be really tough to write. As you
mentioned, a CHAIN would be easy. So would a WRITE opcode. But what
about SETLL or READE? What SQL statements would you translate those to?
How about UPDATE? The native I/O UPDATE updates a record that's
already loaded in memory and locked for the program's use. How on earth
would you do that in JDBC?

For stuff like CSV files, I think it makes sense, though. But, there
aren't a lot of areas where I think it fits.