In message <[log in to unmask]>, Eben Yong
<[log in to unmask]> writes
>On Thu, 13 Nov 2003 00:29:45 +0000, Roy Brown
><[log in to unmask]> wrote:
>
>>Lots of snips - intriguing problem, though.
>>
>>How do you lock now, BTW? If you are not row-level (record) locking, or
>>set locking already you must be database locking. Seems a bit horrible
>>on a big, well-used database or set of bases.
>
>Currently, our existing custom apps do not "mess" with the vendor DB in a
>way that requires explicit locking.  We have many QUICK screens that
>handle the required locking mechanisms without explicit programmer
>knowledge, per se, of locking requirements.

OK, but if you don't know how that locking is actually being done, you
may have problems in choosing the correct locking strategy for a
high-usage COBOL program that has to work when they are working.

(Mind you, this may imply nothing much more than reading up the
technical background of how QUICK implements locking).

>>But one question intrigues me (and may either be the germ of a solution
>>to the do-it-during-OLTP problem, or its death knell, no matter how
>>fancy the locking you used was)
>>
>>"During OLTP, if you were updating at the same time, and even if you
>>could solve the half-updated problem in some way: how would the users
>>know whether to use the old key or the new key for a given member?"

>This boils down to training.  We will be creating a cross-reference table
>that users can use to look up the "old" key and find the "new" key.  Then,
>they would use the "new" key to look up the member's information.

OK, then maybe you could use this X-Ref to solve the 'half-updated'
problem. Load the X-Ref with the old keys on both sides, and have your
users start using it straightaway. Then as your update program runs, it
first finds the old key in the X-Ref, sets the new key to something
which signifies 'Come Back Later', updates all the old key records to
the new key, and finally writes the new key into the X-Ref.

That way, the worst the users will find is a set of records temporarily
unavailable to them; they won't have an incomplete set returned to them
undetected.

It does mean training the users not to do 'look for the old, and only
use the X-Ref if it isn't found'; but they would pretty soon find that
the slower strategy even if you did all your updates out of hours.
--
Roy Brown        'Have nothing in your houses that you do not know to be
Kelmscott Ltd     useful, or believe to be beautiful'  William Morris

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *