RE: Open Access for RPG

[Mike Cunningham <mike.cunningham@xxxxxxx>]

I could see an issue with trying to write the handler to deal with a SETLL/READE I/O logic from a typical native IO RPG app. The easy way would be to do nothing with the SETLL (unless there was a result indicator) and then issue a SELECT WHERE TOP 1 sql command for the first READE command and on the next READE a SELECT ??? (not an n SQL expert on how you might get the 2 record). Which could be inefficient depending on the number of rows to get and hardware. Might get tricky to try and use the handler to transfer the read loop into a single SQL command to get a result set and then pass back one record at a time to the RPG app.  

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Jon Paris
Sent: Thursday, July 22, 2010 9:57 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Open Access for RPG

Sorry Charles - I have to completely disagree with you here.

Unless you are performing set updates - not that common - most  
business applications still process a retrieved set a row at a time.  
Whether that be by retrieving the entire set as an array and then  
walking through it, or by using a cursor, or ...

Why can the OAR handler not retrieve the set and then hand it back a  
row at a time in response to read requests?

I know it will happen becuase the IBM Lab Services team already do  
this with SPECIAL files as part of their database modernization  
approach. OAR handlers are a natural and much simpler extension of  
that process.


Jon Paris

www.Partner400.com
www.SystemiDeveloper.com



On Jul 22, 2010, at 9:30 AM, rpg400-l-request@xxxxxxxxxxxx wrote:

> While you could certainly do it, I doubt it would be a good idea.
>
> The problem is that ROA is designed for RLA and you'd probably need to
> use SQL in the handler to access the remote DB.  While SQL can
> certainly return 1 record at a time, it wouldn't be very efficient.