From Wirt's recent posting....

<snip>

> If I understand what David is writing, the action of a
DBGET-DBDELETE-DBPUT
> sequence will replace the entry with its extended sort entries intact,
> whereas a simple change of a "critical item" value when CIUPDATE is ON
does
> not follow through and re-sort the chain based on extended sort
information.

I'm pretty sure that is what it does.

> While this is one of those "feature" vs. "bug" items -- as Bruce notes, it
> would be far better if IMAGE were consistent in its behavior -- having
> CIUPDATE be ON should not affect any program that is already performing
the
> DBGET-DBDELETE-DBPUT sequence in order to obtain extended sorts. Indeed,
the
> code would never be called.
Almost, but for years my standard way of writing update applications so they
won't break if we add a search or sort key, has been

UPDATE
IF IT FAILED WITH THE STATUS-CODE FOR CRITICAL ITEM
     DELETE
     PUT
ENDIF
IF ANY OTHER FAILURE, MASS HYSTERIA

If ciupdate magically changed from 'allowed' to 'on', these programs would
cheerfully corrupt my data bases when an extended sort key changed.

> I would certainly vote to have CIUPDATE changed so that it honors extended
> sorts,  <snip>.
Me too!!! But what I have really wanted for years is the ability to specify
extended sort keys in the schema, instead of having to put them right after
the official sort key.  Syntax might be like:
KEY-FIELD-NAME (MASTER-NAME (SORT-FIELD-NAME, EXTENDED-1, EXTENDED-2))


Question:  how would everyone like HP to implement a ciupdate-default-on
scheme?  By JUST changing dbutil's default, or also changing the status of
current data-bases?  How many of you even run dbutil how often?  (100% of my
databases are created by jobs that run dbutil and specify 'set xxxdb
ciupdate = allowed', so I'm safe if ALL HP does is change the dbutil's
default).

Sorry to go on at such length, but I just wanted to make the point that
ciupdate, as currently implemented, is NOT guaranteed harmless.

<snip>

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