I think this whole CIUPDATE bit is cart before horse.  Instead of changing
its setting, fix DBUPDATE to optionally use DBPUT-style smarts* wrt
comparing records.  After that, CIUPDATE means do it tighter than
DBDELETE/DBPUT, and the default really should be ON.

Even better, to heck with CIUPDATE; just really fix DBUPDATE to be smart.
That covers the "Which direction to go" item, too.

also, no need to bug Fred or Stan: DBPUT pretty obviously takes SORTITEM to
mean "compare the records BEGINNING at SORTITEM" as opposed to "tack the
record on the end of the chain".  simple sweet powerful!

Tracy Pierce

> -----Original Message-----
> From: F. Alfredo Rego [mailto:[log in to unmask]]
> Sent: Thursday, January 30, 2003 3:52 PM
> To: [log in to unmask]
> Subject: Re: SIGIMAGE Update: HP R&D Lab still open
>
>
> At 10:43 PM +0000 1/30/03, 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.
>
>
> I agree.  Perhaps Wirt and Olav can fine-tune their position:
>
>     If the CIUPDATE flag is set to on, then the behavior of
>     CIUPDATE should be exactly like a DBDELETE/DBPUT of the entry
>     for each path (IF ANY) whose extended sort field has changed.
>
>     In other words, don't waste any time fooling around with paths
>     that don't need fooling around.
>
>    _______________
>   |               |
>   |               |
>   |            r  |  Alfredo                     [log in to unmask]
>   |          e    |                           http://www.adager.com
>   |        g      |  F. Alfredo Rego
>   |      a        |  Manager, R & D Labs
>   |    d          |  Adager Corporation
>   |  A            |  Sun Valley, Idaho 83353-3000            U.S.A.
>   |               |
>   |_______________|
>
> * 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 *