HP3000-L Archives

September 1997, Week 1

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:
From:
Steve Dirickson b894 WestWin <[log in to unmask]>
Reply To:
Steve Dirickson b894 WestWin <[log in to unmask]>
Date:
Fri, 5 Sep 1997 16:35:00 P
Content-Type:
text/plain
Parts/Attachments:
text/plain (26 lines)
<<Are there any situations, especially when dealing with datasets with a
large number of puts, deletes, (and the occasional Detpack), that the
'LIFO' order of a detail chain cannot be relied upon?  I have always
thought of this as a general rule, but I haven't had the 'faith' to rely
on it and code based on that logic.  Is my lack of faith prudent or
sinful?>>


Unless the path uses a sort item that is "guaranteed" to be
always-increasing for later records, like a date/time stamp or
free-running counter, the integrity of the chronological sequence is less
than that of our President. Without a sort item, update activity alone
will trash the sequence fairly quickly. A reload/repack will do so much
more thoroughly. If you want to be sure that you can traverse the chain
in chronological order of record creation, always use a sort item.

To answer the obvious follow-on question, no, it doesn't "cost" much at
all to use such a sort item. When IMAGE needs to add a new record onto a
sorted chain, it starts at the end of the chain and works backward in
sorted order until it finds the appropriate place for the new record.
Since the sort item is an always-increasing value, the first place IMAGE
looks is the place where the new record needs to go, i.e. the end of the
sorted sequence.

Steve

ATOM RSS1 RSS2