At 08:39 AM 1/2/2007, Ray Shahan wrote:
>Hmm, thanks Deny.  I get it that I4 and R4 aren't really good choices
>for keys, but I don't see (from the manual) just what is happening (note
>that I did state I suck at math/algorithms).  It may suffice to just
>know that an R4 is a bad key choice (but I'd still like to know why).

The value doesn't hash at all, so if it contains "100" then it will 
physically go to spot 100, and if you have a lot of repeating integer 
values, then you are gonna end up with a freaking long synonym 
chain.  We use to use J2 integer keys in Omnidex'd databases because 
you could let it assign the value and have it re-use deleted entries, 
so everything was nice and fast and packed.


>My co-worker also saw from the manual that we just need to make the
>capacity of the auto larger than the value that caused the synonym chain
>to fill up, so we're setting about finding the largest current value in
>the set of key values because the key value is a dollar amount, and that
>may mean the set cap could be required to be a huge number...we'll look
>at this and other alternatives.

a dollar value is the key?  An R4 can contain a massive value, much 
larger than an I4 if I recall correctly, it was HP's version of an 
IEEE REAL value before they made the actual REAL E type.  I think I 
solved this at one place converting it to a Z type because they were 
using a J2 to hold a date key and had terrible chains, the Z solved 
the performance problem and was easy because it was a SPEEDWARE shop.


>You stated <<<<Also, I think you are misinterpreting what you are
>seeing.  First of all, there is no "dataset's synonym path".  The
>synonym chain is a double-linked list connecting all the entries that
>want to occupy the same position. Since the synonym chain counter is a
>16 bit value, the maximum number of synonyms that can exist for any
>single primary location is 65,536.  You have a key value to which all
>your entries calculate and the chain has popped.>>>>>>
>
>Please excuse my poor choice of wording, but yes, I do underatnd what
>happened (the DBEXPLAIN was very explicit about the error  8-)).  Also,
>the synonym chain filled up at 32,768, but no matter, it's full, and we
>need to make the set cap larger, but we're going to see just how much
>larger, so we can review alternatives.
>
>Thanks for your help, Denys.
>
>
>Raymond Shahan
>Computer Programmer
>  REPUBLIC TITLE OF TEXAS, INC.
>   2701 W Plano Parkway
>Plano, TX 75075
>
>
>direct 214.556.0202
>main 972.578.8611
>fax 972.424.5621
>  www.republictitle.com
>[log in to unmask]
>
>
>-----Original Message-----
>From: Denys Beauchemin [mailto:[log in to unmask]]
>Sent: Tuesday, January 02, 2007 9:49 AM
>To: Ray Shahan; [log in to unmask]
>Subject: RE: [HP3000-L] Full synonym chain (really ugly)
>
>The R4 (and I4) are not hashing-type keys.  For all intents and purposes
>the
>key value (or parts of it) dictate the placement of the record in the
>dataset.  Unless you can change your key to a hashing type key (an X
>value),
>your only method of controlling the formation of synonyms is by
>adjusting
>the capacity.
>
>In order to do this effectively, you need to provide some further bits
>of
>information:
>
>1- What is the current capacity?
>2- What is the lowest key value?
>3- What is the highest key value?
>
>Also, I think you are misinterpreting what you are seeing.  First of
>all,
>there is no "dataset's synonym path".  The synonym chain is a
>double-linked
>list connecting all the entries that want to occupy the same position.
>Since the synonym chain counter is a 16 bit value, the maximum number of
>synonyms that can exist for any single primary location is 65,536.  You
>have
>a key value to which all your entries calculate and the chain has
>popped.
>
>This can easily be remedied (temporarily) with a capacity change, but
>the
>capacity must be judiciously chosen, hence the questions at the
>beginning of
>the message.
>
>Denys
>
>-----Original Message-----
>From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On
>Behalf
>Of Ray Shahan
>Sent: Tuesday, January 02, 2007 9:25 AM
>To: [log in to unmask]
>Subject: [HP3000-L] Full synonym chain (really ugly)
>
>Hi all,
>
>
>
>             Last Friday eve (as luck would have it), we had a DB lock up
>because an Auto Master synonym chain filled up.   We did a verify of the
>set's synonym path (on a copy of the DB), and just about every entry had
>lots of secondaries - (only about 2% of the entries did not have a
>secondary).  The particular data value that finally filled up its
>synonym chain is:  41378.25
>
>
>
>             After reading the IMAGE manual trying to determine what's
>wrong, we can see that it may be a problem with the R4 data type for our
>key value?   I'm not a math wiz, and have never used real numbers data
>types as keys before (heck, I don't ever recall using real number data
>types for anything in IMAGE).
>
>
>
>1) My questions are why does the R4 data type end up with so many
>synonyms?
>
>
>
>2) Would the same problem exist if the data type was an I4?
>
>
>
>
>
>
>
>TIA, and Happy New Year!
>
>
>
>   <http://www.republictitle.com/>
>
>Raymond Shahan
>
>Computer Programmer
>  REPUBLIC TITLE OF TEXAS, INC. <http://www.republictitle.com/>
>   2701 W Plano Parkway
><http://maps.yahoo.com/maps_result?addr=2701+w+plano+parkway&csz=75075&c
>ountry=us&new=1&name=&qty=>
>Plano, TX 75075
>
>
>
>
>direct 214.556.0202
>main 972.578.8611
>fax 972.424.5621
>
>  www.republictitle.com <http://www.republictitle.com/>
>
>[log in to unmask]
>
>
>
>
>
>
>* 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 *


Regards,

Shawn Gordon
President
theKompany.com
www.thekompany.com
www.mindawn.com
949-713-3276

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