Roy:

Granted, the overhead for IMAGE to process a given DBDELETE/DBPUT with 12 chains of
which 2 are sorted might be slightly longer than your method of CIUPDATE.  But your
method will be prone to more errors in the coding phase and require the execution
of an excessive amount of logic in the core of IMAGE code.  The only issue with the
time factor is if somebody plans to do a CIUPDATE on millions of records, otherwise
it should only be needed occasionally and time will become negligible.

We know that DBDELETE works all the time, we also know that DBPUT works all the
time. But CIUPDATE requires alot of variable conditions which need to be addressed
each and every time and must be exactly right before it works.  The question is,
can this be done and perfected before EOL for MPE and/or EOL for IMAGE.

Olav.

Roy Brown wrote:

> In message <[log in to unmask]>, Wirt Atmar
> <[log in to unmask]> writes
> >Olav writes:
> >
> >> I would suggest that if CIUPDATE flag is set to on, then the behavior of the
> >>  CIUPDATE should be exactly like a DBDELETE/DBPUT of the record.
> >
> >That is exactly the position that I am advocating too.
>
> Are you sure? As you kindly informed me, Wirt, the CIUPDATE UPDATE is
> significantly more efficient than DBDELETE/DBPUT.
>
> Let's take the example of a record in a dataset which is in twelve
> chains, of which two are sorted. And along comes a change which alters
> one of these sort items, the one nearest the top of the record.
>
> The CIUPDATE modifies the record, and alters the pointers in one chain.
> Job done. The record does not move in any of the other chains.
>
> But if you used DBDELETE/DBPUT, the code would have to delete the
> record, relink twelve chains, add the new record, link it onto the end
> of ten chains and make two backwards chain reads to position it in each
> of the remaining two chains.
>
> I'll advocate that the CIUPDATE 'should, for any chain in which a Search
> Item, Sort Item or Extended Sort Item changes such that the record has
> to be repositioned in that chain, handle the chain exactly like a
> DBDELETE/DBPUT would. And leave any other chains containing the record
> strictly alone'.
>
> Longer to describe, but it doesn't throw away any of the efficiency of
> CIUPDATE beyond that minimum needed to respect extended sort fields.
>
> --
> Roy Brown        'Have nothing in your houses that you do not know to be
> Kelmscott Ltd     useful, or believe to be beautiful'  Wm Morris
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

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