Re: Open Access for RPG

[Vern Hamberg <vhamberg@xxxxxxxxxxx>]

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
>