Re: Adoption of RPG OA (Summary)

Hi Joe,


<snip>
But why OA rather than, for example, a read trigger? As I said, I'm
just gathering opinions. And just to be a little bit of a devil's
advocate, shouldn't every RPG programmer also know how to program a CALL?

</snip>

Simply because the retrieval of geo-code data from google is a basic request/response mechanism that provides output information for a given input. The output is well-defined and is in a constant format. This seemed similar to populating a record format for a given key value during a chain. We coded it to see if it worked - it did with minimum effort.


For retrieving this information (on demand) you could write code like this:

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;

It seems clear and self-evident what is occurring here - even if the manner of the retrieval is not obvious. I can't see a read trigger providing this level of simplicity.

This code "could" still work if a read trigger was placed on addressFile. In that case the geocode info could be retrieved (and stored in geoCodeFile) for each read of the file. The problem is that the info may not be needed, or even allowed to be stored permenantly, or may be volatile. It is not until the chain on geoCodeFile that it is evident that the data is required so why store it on the read of addressFile?

If the data is stored in a service program instead of a DB table there is still the overhead of retrieving the data when it may not be required. This doesn't cover the fact that a separate mechanism is now required to retrieve this information into the program. It must also be understood that there is now an intimate relationship between the addressFile and the service program - you must read addressFile before retrieving the geocode info from the service program or the data will be old - probably from a previous read of the file. This is not the case with the OA geoCodeFile as it will still retrieve the correct data from Google as long as you have the key.

I hope this makes sense.

Cheers

Larry Ducie