• Subject: Re: Writing an Open Access handle that will either read/write to the Db2 file or make a REST call
  • From: "D*B" <dieter.bender@xxxxxxxxxxxx>
  • Date: Wed, 16 Jan 2019 15:40:27 +0100
  • Arc-authentication-results: i=1; mx.google.com; spf=neutral (google.com: is neither permitted nor denied by best guess record for domain of dieter.bender@xxxxxxxxxxxx) smtp.mailfrom=dieter.bender@xxxxxxxxxxxx
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=importance:content-transfer-encoding:mime-version:date:subject:to :from:message-id; bh=xBA8Hx4mttnwVka7g0t8L3qAJvQsmhYQr2bCSZJ45JM=; b=CuOXZ+lkpK3a+mQHRAT5G7CSE650anyELyMSmVr59I6wl3vnSsktgvPD10FQ6Fyp1d XG1XMWkgShYm7HzJp8kfwhaGogJpwXikFx/mR1dpztz5sz9OGKYik6h/TOUL4D+EFf91 VgV+LkLdjiXiDTfI8xZmwxrI+u1XXkOBr8ZRH3Zbo0pcgqRzVmXRC+wf83e/EsjBZGj0 oWwG86tAgDx49/SUeO06UeZ+wvZ3aeuBFd/MwFLEy6A7FHxWPwppEplOncDRFPxO/yPQ H5jylnccV3ATN54UwWbcCO2p4QnaeXBlVnelqcK0L1AQEGHTrKk6gt8lAJ7SX9kiyw8t nd2w==
  • Arc-seal: i=1; a=rsa-sha256; t=1547649615; cv=none; d=google.com; s=arc-20160816; b=jga7183MhpuBExkAaVyo2Vh2SJd0YUkmCmDG/CAj/EadhlWbPCrqlTIumwqfA8jyRy iTObF1iS5CsHvoQ+fjUkE2HRGk9KcDXv+DowhryTqaKYLESchqFCnoqdrpY+cY+QFpJ5 GjVAKWGDEJ6UmxvofETSuA2Rv0u7uBpKCUn9MDFiagSTr0AWUlmp+xNExvDQZJs58gmg MzoDCwtHsQdSZyG/EEklRSdCAgLB0Hkv/GddoqL0qSiheR9SOIxa+PAZuo+/2yBtPYqa 3nyGXE1ZV5Y/3k/5Lc6DHdmBdmpI5mLOKpq42xPc+hpn0jje6thZTkEUGzadXv2k5+by gj8w==
  • List-archive: <https://archive.midrange.com/rpg400-l/>
  • List-help: <mailto:rpg400-l-request@lists.midrange.com?subject=help>
  • List-id: "RPG programming on the IBM i \(AS/400 and iSeries\)" <rpg400-l.lists.midrange.com>
  • List-post: <mailto:rpg400-l@lists.midrange.com>
  • List-subscribe: <https://lists.midrange.com/mailman/listinfo/rpg400-l>, <mailto:rpg400-l-request@lists.midrange.com?subject=subscribe>
  • List-unsubscribe: <https://lists.midrange.com/mailman/options/rpg400-l>, <mailto:rpg400-l-request@lists.midrange.com?subject=unsubscribe>

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.
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.

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.

See above. IBM normally do it as part of a database modernization for exactly the reasons you describe.
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!!!


This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].