Earlier I wrote that the first two words are used in hashing, that was
incorrect. I was wondering how IMAGE dealt with something like an X4 or
smaller and upon reading the manual a bit :-) more, I see that IMAGE uses
the rightmost 32 bits, padding with binary zeroes on the left as needed to
get 32 bits. Your number 41378.75 is not magical; it's simply the first one
of many that had 32 bits on the right filled with 0s. Sorry for the
confusion.
So, they used a signed integer for the synonym chain counter. Maybe they
thought you could have a negative value in that counter.
The problem you have is with the internal representation of the data. Since
you mention that you have dollar amounts in R4, the application might be in
BASIC/V. This language only gives you 16 bit integers, 32-bit (R2) and
64-bit (R4) reals and characters strings to work with. (I am ignoring the
complex type.)
The R2 has an accuracy of 6.9 digits and the R4 has an accuracy of 16.5
digits. So for dollar amounts greater than say $9,999.99 you need to use
R4s.
The data in the R4 representation is made up as follows:
0:1: Sign
1:9: Exponent
10:53: Mantissa
The numbers are represented by a decimal digit made up of a BCD nibble,
which is 4 bits long.
As Rene reminded us, only the first two words are used in the modulo
operation to come up with a primary record number for the record.
As we can quickly see, the first 32 bits would be made up of the sign, the
exponent and 22 bits of the mantissa, which would make up 5 whole digits and
half of a sixth. These 5.5 digits are the most significant digits in the
number. In your case, that is 413780; the .25 are on the third word and
beyond.
So, big deal you say. How do I fix this? Well, changing the data type is
the solution. IMAGE does not care what you put in the various fields. So,
if you wanted to use hashing, where IMAGE uses all 64 bits for address
calculation, you could simply redefine the data item as an X8 and let
whatever tool you use to do the trick recalculate all the record based on
hashing instead of just modulo. Your programs would not know the difference
as long as they are not interrogating IMAGE with DBINFO to find out what
type of data is ostensibly in the field. In other words, let's say you are
using BASIC; if you do a DBGET of the item using a REAL buffer to receive
the data, it will go right in there and be usable by the program as is.
This will defeat Query and other similar programs to which you cannot apply
a dictionary of some type. These programs will interrogate IMAGE and get
told the data is X and they will expect that and be surprised.
On further thought, I would probably change it from R4 to P16. That will
still hash.
Denys
-----Original Message-----
From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On Behalf
Of Ray Shahan
Sent: Tuesday, January 02, 2007 10:39 AM
To: [log in to unmask]
Subject: Re: [HP3000-L] Full synonym chain (really ugly)
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).
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.
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 *
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
