Re: Open Access for RPG

Joe

I think we're probably close on these things. I don't think it makes much sense to use CHAIN to do a CALL. We have this product that can work with remote databases, and some of the functions are not even close to IO opcodes like CHAIN. They set environment stuff. Those should probably still be done with procedure calls. But that's not how I see using this functionality. There are things that can be handled in a "native I/O" kind of way - the handler doesn't have to handle everything that RPG can do - you can limit it to what makes sense. Like working with data queues. You won't do a READC there!

Anyhow, we shall see how this works out. And I do see this as similar to how things must happen - there are database programs that end up processing the various opcodes now - those are, in some sense, CALLs under the covers. Close enough, at any rate, for me to make the comparison and be comfortable with what is kind of a rerouting of the process.

Later
Vern

On 7/27/2010 7:25 PM, Joe Pluta wrote:

Joe

I hear your points. I want to focus on 2 that seem self-contradictory,
of course, not casting aspersions your way! :-)

You say to write "...callable code..." - as far as I can see, and I have
and am working with it now, that is essentially what an OA handler is,
it's just called by the RPG runtime engine. So when you say "It does
almost nothing that a CALL can't do." you are exactly right. That
doesn't make it a bad thing, IMO. Again, many of us on this list are not
the target - vendors such as we are and consultants such as you know how
to do lots of things the average Joe-Six-Pack developer doesn't, and
might be constrained by budget and politics and time from learning all
we have.

Nothing contradictory about it. Using the syntax of a CHAIN to perform
a generic CALL is simply a bad idea. I'd rather teach people how to do
calls directly from the start rather than try to shoehorn them into the
SETLL/READE functionality available to OAR (or RPG-OA).

As I said, I can see a very narrow set of circumstances where OAR is a
good idea. Most of these center on talking to data repositories that
don't fit the relational model, with XML being the primary case although
I suppose in certain circumstances an Excel spreadsheet might also be
applicable. Anything outside that, though, you're either stretching the
analogy, or else perfectly good tools already exist (e.g., ODBC).

But that's my own opinion. I've done enough cross-platform development
that I'm comfortable with my own assessment of this particular
technology; I'll let you guys debate the pros and cons of an extra-price
module that lets you do calls in a cool new way. It may be a good fit
for some people. I've seen worse technological directions advocated
(often right here).

No, my bugaboo is the elitist mentality that pervades this list more and
more that somehow RPG programmers are stupid and stubborn and can't
learn anything, when in reality the truth is usually just the opposite.
RPG programmers would love to learn new technology, if it really
provided them some benefit. They've been sold bills of goods on
everything ranging from Java to SQL to SOAP to PHP, every one being
touted as absolutely essential to their business and each one being
ultimately more useless than the last (and I'm not saying the
technologies are useless in and of themselves, but that most of them
don't fit most real world shops, not without some serious costs).
Meanwhile, their horrible 20-plus-year-old hybrid RPG II/III/IV systems
are running their businesses and keeping their kids in college. And the
folks on this list are telling them they're too dumb to learn anything
just because they've stopped drinking the "latest shiny toy" koolaid.

What's needed? I could tell you but I'd have to kill you<smile>.
Seriously, though, there are things needed. I could make a list of
about a half dozen practical things, any 2-3 of which would fit most
midrange shops. The trick to make a sale to management is to make sure
that at least one thing provides an immediate visible benefit to the
company (outside of IT!) while the others provide measurable benefits in
the short- and medium-term.

Anyway, this is more than I intended. I just to make sure at least one
person on this list isn't yammering about how old RPG programmers can't
learn new technologies. They can, they just prefer one that actually
make business sense.

Joe