In article <[log in to unmask]>, Roy Brown
<[log in to unmask]> writes
>
>Lots of snips - intriguing problem, though.
>
<SNIP>
>
>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?"


To quote Roy of old :-), have you thought about lowering the water
rather than raising the bridge?

You may undoubtedly be correct that over a 48 hour period you don't have
time to process all the databases and datasets and update all the key
(and non key?) entries using a conventional program calling image
get/delete/put update even with CIUPDATE turned on. This is going to be
some real heavy processing for Image.

So why not evaluate a different approach.

Unload the databases to flat files, write a program, or perhaps even use
some of the shell commands (ugh!) to update the values in the flat
files, and then just erase the database and reload it from the flat
files. That way you are down to a very fast unload process, x time to
process the flat files, and a single dput for every record to go back.

The advantage of this approach, is that you can practice and practice,
and do timing runs and work out how to get it all within your 48 hours.
And even when it comes to the big bang, the only point of no return is
at the dberase/reload point. Up to that point nothing in the live system
has been touched. In fact you could even extend the failure point (i.e
run out of time) even further. Instead of erasing the databases build
new ones to load with the converted data, and just do a dbpurge rename
at the final point when everything is complete.
--
Alan Yeo
[log in to unmask]    Just because you're paranoid
Phone +44 1684 291710   it doesn't mean someone isn't!.
Fax   +44 1684 291712

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