On Fri, 21 Sep 2012 08:20:38 -0700 Edward Jaffe <[email protected]> wrote:
:>On 9/21/2012 5:01 AM, Peter Relson wrote: :>> Of course Binyamin is right. Since the "runner" can get interrupted, then :>> the runner needs to run within a transaction too. (Getting interrupted :>> includes the z/OS LPAR getting interrupted by LPAR processing, which :>> covers even the disabled PSW case) :>There are existing search/update models in which the "runner" performs its :>search using only block-concurrent instructions (such as L) without :>serialization and then checks later whether a retry is needed. A good example is :>IEANTRT. That code is FAST because the "retrieve" function never serializes :>against the "update" function. Wonder how the delete works. Perhaps it leaves the storage orphaned? Otherwise the scan, if interrupted, could be left with a link pointer to nowhere. -- Binyamin Dissen <[email protected]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies.
