Re: Writing an Open Access handle that will either read/write to the Db2 file or make a REST call

<Jon>
What I have done is to have the OA handler cache the current record as part of the state info. Any subsequent I/O related to that record is retrieved from that cache. A lot of the time (as in OP's case) a handler is required for specific purposes and is best done by not trying to boil the ocean but rather designing for the task at hand. If you need to go further and create a generic handler that is a different animal and does indeed present a great many additional challenges. But it has been done by several people. Lab Services have an OA "product" that they offer as part of a service engagement that completely handles all RLA aspects and maps down to SQL. Dan Cruikshank has described the process and right now we're trying to find where IBM have hidden the source code.
</Jon>
caching last read record might help for chain/update, but is not sufficient for going on with reade, readpe ...
once replacing a f punching card with an OA handler, you would have to provide all I/O operations by your handler and that's the real problem, I'm talking about.
Providing some logic for "specials purposes" I would not recommend OA handlers, because the resulting code is not readable and maintenance is difficult and error prone.

what really would be needed is an open source solution for replacing RLA by SQL with minimized effort.

<Dieter>
Some additional remarks: First heared of OA, my idee was to have a generic OA handler translating all rla operations to SQL, with the final goal to enable existing RLA programms to use true SQL indexes. This would decouple RLA programms from the database without major changes, opening up the possibility for redesign steps of the database.
</Dieter>

<Jon>
See above. IBM normally do it as part of a database modernization for exactly the reasons you describe.
</Jon>
I've never seen this at any customers site!!!

What I've seen sold as "modernization" is:
- replacing dds by sql ddl for physical files
- adding autoincrement primary keys and some automatic timestamps and user fields
- adding some not needed indexes
- adding the (altered) dds logicals. needed for the rla programms to work
benefits: none!
costs: lots of money
new problems:
- more complexity
- referential problems (delete / insert cached record creates duplicate records!!!)
- no decoupling effect

The next, more importent step to replace rla by SQL to a true view layer to decouple is never done!!!

Dieter