In article <[log in to unmask]>, Roy Brown
<[log in to unmask]> writes

(Apologies to those who have already seen this in comp.sys.hp.mpe
HP300-Listers won't have.
For some stupid reason, I thought News -> List was working now.
Silly me.)

>In article <[log in to unmask]>,
>Therm-O-Link <[log in to unmask]> writes
>>Well, thanks to all those who responded to my last inquiry about enabling
>>CIUPDATE via DBCONTROL, I am in the process of updating a program to make
>>use of CIUPDATE.  But now, I have some different types of questions.
>>
>>If I am reading down a chain and updating the values for that chain's
>>search item, what happens to the chain information?  For instance, this
>>program does a chained read by a certain value, and replaces the value for
>>that search item with zeroes.  Can I do:
>>
>>DBFIND
>>
>>DBGET (chain forward)
>>
>>DBUPDATE (with new value)
>>
>>Go back to DBGET until end of chain is reached
>>
>>Or will the program "lose its place" on the chain because of the changing
>>search item values?  If so, then I suppose I will have to save the value of
>>the next record on the chain and get that record by address, instead of by
>>chained read, so the processing logic would look like this:
>>
>>DBFIND
>>
>>DBGET (chain forward)
>>
>>Save next record address
>>
>>DBUPDATE (with new value)
>>
>>DBGET (by direct record address)
>>
>>Go back to the "Save" until there is no next record.
>>
>>
>>On a related note, if I am reading down chain A and changing values for
>>chain B's search item, what happens to the chain information?  Can I do
>>what I outlined above in the first logic example, or will I need to keep
>>track of the chain information in the program, as in the second example?
>>
>>As always, any and all help is appreciated.
>>
>The DBUPDATE will always leave the 'next record' entry pointing at the
>same place for the next DBGET, even if CIUPDATE is invoked by dint of
>key or sort item replacement.
>
>Consider it logically as a DBPUT to the new place in the chain followed
>by a DBDELETE in the old one, if it can't be a direct traditional
>DBUPDATE.
>
>So no, you don't have to do the thing you were worried about, for either
>scenario.
>
>However, you *do* need to allow for re-encountering the record you just
>'updated', if it got re-added further along the chain, in the direction
>of your processing.
>
>You must take care not to update it yet again, unless this really is
>valid. So if your sort key is 'xxxnnnnn', say, and your key-changing
>algorithm works by adding 100 to the nnnnn part, and your Mode is 5, you
>may wind up chasing records down the chain forever.
>
>Pretty unlikely example, sure, but *any* logic that adds to any field in
>the record, if combined with something that moves keys, may get executed
>more than once unless you safeguard against it.
>
>

--
Roy Brown               Phone : (01684) 291710     Fax : (01684) 291712
Affirm Ltd              Email : [log in to unmask]
The Great Barn, Mill St 'Have nothing on your systems that you do not
TEWKESBURY GL20 5SB (UK) know to be useful, or believe to be beautiful.'