• 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 08:41:10 +0100
  • Arc-authentication-results: i=1; mx.google.com; spf=neutral (google.com: 212.227.126.130 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=QC3ZKijQvMx1PqTgSCaJb3gfS8PM9hAkcZDjfU7Htts=; b=OKRCxZ8HLTfkaKQRTKlubmBM5rS/QbGijtbMWR65sJol430INElpKfuaosumCQzOsp 1pMemzvVoMCw+jCd9N0wl6gBanPlXzK0omEm8iWRsH5PtV9yOcu/pqZeCBvbjHSStWVp TBSBOkIejRJd8Y5xHCgqYIyMiUlfhGjEAP/K3BhFxGRU3j6yiEKIXPwo28OIUw20tQQI Ewz8Viugw4/OGVpATiIVRcQ8QW30qYHw264bnWOZKsY3LJE8i9Yy5dcbxcktv3C9EKSx VRUMeTI5awH4QeIFY2j6KKmvwtdMQcf6YZ9gIOkGSkXXbpREv7zGed4BxnWsajN7+USo SZ6Q==
  • Arc-seal: i=1; a=rsa-sha256; t=1547624459; cv=none; d=google.com; s=arc-20160816; b=ap16MsM0QR6GVO44/CTUyG+dIeJxgCLirtuaej9YDpozv6Ez9/ykIsmITXR2B8+lo/ aPBKSeUt4yKbH/KLwkOhURNW6FfZNyGGNY3F97D+v1cedFLANufiyyLOqzBY6CgVeQMF kYb0E3zkbDqZuMIowZ1nq3lqPw8GTWu6UpU7LxymKaUVLV6DVlH3924+Y3tpyG7p6G3q RHxBj4MNl9h3SHpzBRA3GnzAJQ5NMOBTz0rGJEjar2ZAPVyM+sBfdvLXuqKA1OUuiQsI ZRimQ9esyxDLjwuXbQrRwEHyuh76C9mdMPKB4rWS/4PMPlojKNBPBo4ZpAdbujT4vdEf t3xw==
  • 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>

<Jon>
And if I were mapping to a DB2 table and needed to do read next type operations that would matter to me - but I'm having trouble seeing why it matters when I'm changing the UPDATE in the RPG to and SQL update on another system. Normally doing that I'd be using some kind of handle/cursor/whatever to keep track of the connection anyway and if that is stored in the state info then I'm golden.
</Jon>

chain and insert are trivial. For update and delete it might depend, because rla is using positioned updates. the best way to keep track of the position I see, is a SQL cursor, but you can't create dynamicly cursor instances with embedded sql, so you would end up with SQL CLI or use bind by copy.

<Charles>

Can't you handle all the state info you'd need by passing it a pointer back
to it in the stateInfo subfield?

The only issue I see at this time (other than having to do a handler for
each logical) is that if PGMA calls PGMB and both use the handler, and I
don't need to hit the web service...then I might have to pay for extra I/Os
to reposition the local table.

I suppose a bound by copy handler wouldn't have that problem. Didn't
realize that was a possibility.

Charles
</Charles>

For your requirement, making virtual nothing or call some other function (might be REST or something else is all the same to me) we have two problems to solve:
- doing virtual nothing:
the handler would have the same logic, use the same file specification etc. simply doing what the programm would have done itself, giving back the same data. Using bind by copy this should be a technical one to one solution. Not without effort, as all examples I've seen stay in the trivial area. I don't see additional I/O needed, you should forget to worry about this, one REST call will dominate hundreds of native I/O operations!!!
Maybe another aproach might be easier (and so better!!!). If the programm would know what to do, I would think about to switch between two diffrent implementations, one using the original f spec, another using OA. (or maybe something else???)
- calling some other function: Problems will come up, if you would have to emulate ISAM access methods, especialy the positioning logic with reading forwards and back. The called functions would need to translate this to SQL logic!!! Another problem could be share and OVRDBF, this should be evaluated very carefull. (sometimes I was told: we don't use ... and first evaluation brought up, that they didn't have all sources of their programms...)

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

This thread ...

Follow-Ups:

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

This mailing list archive is Copyright 1997-2019 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].