In message <002b01c2c7c6$76f45010$090101c0@PCC>, David Powell
<[log in to unmask]> writes
>----- Original Message -----
>From: "Roy Brown" <[log in to unmask]>
>To: <[log in to unmask]>
>Sent: Tuesday, January 28, 2003 9:09 PM
>Subject: Re: [HP3000-L] SIGIMAGE Update: HP R&D Lab still open

><snip>

>> But I reckon that any DBUPDATE, as per his example, can fritz the
>> extended key sequence all on its own, if the extended area is changed,
>> but no critical items are.

>Roy has caught me on this.  A moment's dinking in Query with
>'ciupdate=disallowed' verifies that its update command will put extended
>sort keys out of order (does anyone know if this has always been true?? or
>did dbupdate 20 years ago refuse to change extended sort keys).

I have 'always known' it to be true, where 'always known' is on an MPE
in roman numerals.....

And like many of the things I have 'always known' which I imagine were
word-of-mouth arcana handed down by HP Systems Engineers, or the *real*
pioneers on this list, it is openly documented in the manual:

TurboIMAGE/XL Database Management System Reference Manual
HP e3000 MPE/iX Computer Systems
-------------------------------------------------------------------------
-------
Edition 8 HP Part Number:30391-90012
E0701 U.S.A. July 2001
2       Database Structure and Protection
        Data Set Types and Relationships

If you depend on extended sort fields to sort a chain, do not call
DBUPDATE to modify any of the values in the extended sort fields because
the chain will not be automatically resorted according to the new
extended sort data values. Instead, call DBDELETE and DBPUT to re-enter
the records with modified values. DBUPDATE only recognizes extended sort
items when the actual search or sort item is changed.

The last sentence must have come in with CIUPDATE. But as for the rest
of it, I don't know if anyone can look this up in an MPE/III, IV or V
Image manual, but I bet it's there.

> There are
>application-specific reasons why this hasn't messed us up here.  The problem
>when ciupdate was shiny & new and I used it for the very first time must
>have come from I put it into a program that had previously done a delete&put
>for all 'updates'.

Yes; CIUPDATE allowed you, for the first time, to experience this
inherent limitation in DBUPDATE :-)

>> The only way round this would be if the program had code to check if the
>> extended area was changed, and always forced a DBDELETE/DBPUT if so. But
>> if this was the case, it would never fall into a CIUPDATE in these
>> circumstances....

>Which some of our programs do.

Searching the TurboImage manual while reading up on this topic produces
some other interesting side issues:

'On unsorted chains, DBUPDATE will leave the record in situ in the
chain, but DBDELETE/DBPUT will move it to the end of the chain'.

Later the manual says that 'a CIUPDATE DBUPDATE is like a
DBDELETE/DBPUT'. (But this is of course only true on chains which have
to be broken and remade).

'CIUPDATE is not 'On' by default because of (unspecified) security
issues, and because of compatibility issues'.

'If you are processing a chain, and do a CIUPDATE update on an entry,
you may encounter it again, further down the chain'. You need to ensure
that you have considered this in your design.

(Which is why Wirt's ideal of having DBUPDATE do a 'limited CIUPDATE' to
honour extended sort fields, without any option to switch this off, must
probably remain an ideal. It would break backward compatibility in
Image. Which was the same consideration that led to CIUPDATE not being
ON by default).

Switchable would be OK, though.


Thinking of DBDELETE/DBPUT though, that could lead to the 'double
encounter' problem. Or worse, if the Current Record pointer migrated to
the end of the chain on the DBDELETE/DBPUT, the records in between could
be skipped.

So you'd either have to do the DBPUT first, and ensure your dataset had
the leeway for one extra record at least, or you'd have to ensure you
captured the 'Next Record' pointer before the Delete and Put, and then
read that record direct. That's what I've always done.

I think you could have the same considerations with a CIUPDATE too,
which is why you don't want one unexpectedly working for you. And while
an update that works with CIUPDATE, but would have failed without it is
one thing, a 'stealth' CIUPDATE from a DBUPDATE which has suddenly
started respecting extended sort fields is quite another....



--
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 *