HP3000-L Archives

January 2003, Week 4

HP3000-L@RAVEN.UTC.EDU
Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
Re: SIGIMAGE Update: HP R&D Lab still open
From:
[log in to unmask]
Reply To:
[log in to unmask]
Date:
Tue, 28 Jan 2003 11:35:07 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (61 lines) 
There's clearly some misunderstanding of KSletton's specific request to
address this topic via the HP3000-L (as opposed to OPENMPE, which has an
allegedly differnet focus than those of us interested in MPE, but...

Maybe there's some misunderstanding of CIUPDATE?  (and maybe it's me ;-)
AFAIK,

Whether CIUPDATE's on or not, if you have >1 details with equivalent sort
items, the rest of the record counts in the sort at DBPUT time.  If you
update non-critical fields to the right of these sort items, you can screw
up the sequence of the sorted path.

I'd venture a SWAG that relying blindly on CIUPDATE to simply "keep things
right" is where pipple go wrong; I'd be willing to guess that all
CIUPDATE=ON does is a slightly enhanced DBUPDATE, amounting to "if
criticalitem changed, DBDELETE/DBPUT, else just DBUPDATE.

If it's any worse than that, something's really _broken_; if that's all it
is, it's just an oversight by CIUPDATE's creators.  Either way OFF is
probably safer, but not much; DELETE/PUT is the only way to be certain.  So
that "correct-direction search at DBPUT time" would be a worthwhile thing.

Tracy Pierce








> -----Original Message-----
> From: Bruce Collins [mailto:[log in to unmask]]
> Sent: Tuesday, January 28, 2003 11:10 AM
> To: [log in to unmask]
> Subject: Re: SIGIMAGE Update: HP R&D Lab still open
>
>
> David Powell writes...
> > CIUPDATE can leave a chain NOT in order by extended sort
> keys, in an order
> > that cannot be 'achieved' with dbdelete & dbput.
>
> If this is the case, (and I have no reason to doubt it) then
> maybe this
> should be added to the list of  "last call low / medium
> effort, low risk
> enhancements" that should be requested from the lab, in
> addition to Wirt's
> original request to make CIUPDATE =ON the default.
>
>
> Bruce Collins
>
> * 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 *

ATOM RSS1 RSS2