Re: Adoption of RPG OA (Summary)

Joe

Allow me to jump in here again. You ask why the chain is better than a call. I'll suggest, it's not - they amount to much the same thing. In fact, the code in the handler will probably be the call you presented here. OAR can conceal very complex code - this example doesn't show that, but the handler I've written could show that - consider all that happens in an OPEN - doing the same thing in C is a lot of function usage, where RPG does a lot for us. Now the code using either the JDBC stuff Scott has written or our RPG2SQL Integrator uses a lot of functions and keeps a lot of state info that the RPG programmer has never had to worry about much, if at all.

One of the responses I heard to OAR was, why would we want to do that? We know how to do function calls already. This was from an ISV. My response to that is, an ISV is probably not the market for an OAR handler - they would likely CREATE the handler using their product or expertise with APIs. The market is more likely a traditional RPG shop - some will castigate me for using that word! Fine!

This might be a matter of opinion, or it might be a matter of time and skillsets. And maybe a matter of familiarity. All of us who now think it's a piece of cake to work with system APIs, well, this person can attest to the trepidation and uncoordinated feeling he had the first time - why does this sound like a first date?? Yikes! It takes time to get used to something that different. OAR could enable adoption of new technology more quickly, and that still seems a good thing to me. In fact, the concept of "the programmer has to do everything" (not your statement, of course - am rambling a bit here) is kind of the old way of thinking - OAR brings us to a place where we are given tools that someone else - a local expert perhaps - and that we can use very simply in our code. So OAR is not about one developer doing it all.

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.

If you've used SPECIAL files - I haven't - then OAR is the same kind of thing, with more power and flexibility. Those were an acceptable part of RPG for years.

Anyhow, there I go again! Later, man!
Vern

On 3/20/2011 5:07 PM, Joe Pluta wrote:

On 3/20/2011 4:56 PM, Larry Ducie wrote:

Hi Joe,


setll (key1) addressFile;
reade (key1) addressFile;
dow not %eof(addressFile);

if someCriteria = true;
chain (key2) geoCodeFile;
if %found(geoCodeFile);
// do something with the long and lat...
endif;
endif;

reade (key1) addressFile;

enddo;

Thanks, Larry! I think I get your point. But why is the above better
than this:

setll (key1) addressFile;
reade (key1) addressFile;
dow not %eof(addressFile);

if someCriteria = true;
getGeoCode( key2: dsGeoCode: rc);
if rc = OK;
// do something with the long and lat...
endif;
endif;

reade (key1) addressFile;

enddo;


Why is the chain better than the call? The more I see this, the more I
have a problem with usurping a known opcode. Prior to this, READ/CHAIN
was getting data from a database. Now I'm not really sure what it's doing.

Anyway, enough on this particular topic. Either way works, and they're
both doing essentially the same thing. I think it really is opinion at
this point.

Joe