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

We're just going to have to agree to disagree Dieter.

Suppose I want to use a web service and use an OA handler to enable CHAIN etc. to retrieve data via conventional RPG opcodes. I don't need to write a handler to deal with everything ... just the operations I am going to use. As long as I protect the user by having the handler error out any attempts at usage that is not supported by the handler then I don't see the problem.

You appear to be looking at OA simply from the perspective of enabling database modernization. I also look at it from that perspective but in addition as a vehicle for enabling the use of conventional RPG operations by folks who don't know (or indeed need to know) all the nuances of using web services or whatever.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Jan 16, 2019, at 9:40 AM, D*B <dieter.bender@xxxxxxxxxxxx> wrote:

<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
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com