Re: Adoption of RPG OA (Summary)

I hear you, Joe, and I think I understand your point of view. You are not at this time a candidate for using OA. That's cool - not everyone will be, and not everyone should be.

Your point about performance or response time is a valid one. Connecting to an RDBMS on a system across the country is just not going to perform as well as local access. The creator of a handler will need to let consumers know this. But remote SQL can have some latency, too.

As to side effects - actually, the RPG engine is protecting you pretty well there, I believe. All the handler does is set some values that the RPG engine uses. This is things like the equal indicator, the found indicator, the 3 file feedback areas, the RPG status, and input and output field data. If some of them are not set right, you get a standard RPG error. The rest, if it works not as expected - and that, to me, means, as RPG always has, then it's a bug, and one must get with the provider of the handler.

Now having said that, this IS a new thing to maybe fight with. I have done all I could to make my handler behave as expected. I've done nothing on the side, to existing objects or data. THAT would be on the level of a virus or trojan horse, IMO.

So some of this is a matter of trust - of a vendor, of your expert in web services or IFS, whatever.

One new thing to realize is, the actual physical object needs to exist only at compile time - it is never touched (unless your handler needs to) at run-time. Now a DISK handler may probably want that actual table around - I take advantage of system information of this kind of thing.

You mention complicating things - from one side, yes, it does. From another side, no, it actually simplifies life. At least, it looks that way to me.

Nothing to prove, but if you ever want to see my (that is, RJS Software's) handler at work with SQL Server or Oracle, gimme a shout. I like showing it to anyone!!

Luddite? Nah!! You already know how to use a different approach, a different paradigm, and you're very comfortable with it. No reason to go to what is basically a very thin, almost embarrassingly transparent wrapper around what you know how to do. For you, this emperor has no clothes. For others, who don't have X-ray vision, it could be a good approach.

The main obstacles are still the pricing and licensing issues - the latter is the main problem in my view. IBM has to help us here, in order for this to have a good chance, seems to me.

Cheers
Vern

On 3/20/2011 6:18 PM, Joe Pluta wrote:

On 3/20/2011 5:49 PM, Vern Hamberg wrote:

I guess I would not consider the use of OAR to be usurping an opcode. It
does "redirect" what RPG does (or extends what RPG CAN do) when an
opcode is specified. You also say you don't know what it is doing. I
suggest we don't really know now what native IO is doing, either - RPG
calls data management routines for each opcode. Now, if a handler is
specifed, THAT is called instead of DM routines. We trust DM, we can
learn to trust a different black box. We've learned to trust the
blackbox that is SQL without really knowing all that it is doing.

A lot of your points are fine, but I just don't agree with this one. I
know EXACTLY what a CHAIN is doing - it's getting a set of fields from
the database. I know what it's doing, and I also know (roughly) how
long it's going to take. Perhaps most importantly I know that there are
zero side effects.

Once you start adding triggers and handlers and all that, it does indeed
turn into a black box. And what worked one day may suddenly stop
working because somebody touched the handler program. Whereas yesterday
I was just reading a file and perhaps doing a little formatting, now I
may be calling an external program - and adding all the overhead that
ensues.

Take it for what it's worth. Call me a Luddite, but I just see OA as
potentially complicating one of the things in programming that is the
least complicated: a CHAIN to a database file. Personally, I don't need
a way to make a CHAIN act like a CALL when I have a perfectly good CALL
to do it for me.

Joe