HP3000-L Archives

April 1998, Week 3

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:
Sletten Kenneth W <[log in to unmask]>
Reply To:
Sletten Kenneth W <[log in to unmask]>
Date:
Tue, 21 Apr 1998 19:50:29 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (72 lines)
Yesterday Frank Nagy asked:

> What is the difference between FIND SET1.FIELD1 =
> SET2.FIELD2 and JOIN SET1.FIELD1 TO SET2.FIELD2?
> Does not work the later with SET1 = SET2?

Hmmm....  confess I've never really explored what might be
done now with the JOIN command.  We don't use that hardly
at all at our site (since we've got TRANSACT and INFORM),
but let me go try a couple things....   < short interlude >

Well, that was at least semi-interesting:   *IF* you want to
specify a particular value for the *same* FIELD in two different
datasets, then JOIN can certainly get you the "record pairs"
where this field has this same value.  But if you just want to
find all the records where the same field or two different fields
in two datasets are equal *regardless* of the value, don't think
you can do that...  If I'm wrong, I'd sure be interested to have
someone educate me.

Just for grins I also tried various combinations of same value
for FIELD1 and FIELD2 in two different datasets, but didn't
have a lot of luck;  I quit when once I managed to get 750,000
qualifying entries from two sets with capacities of 14,000 and
2,000, respectively..  like I said, I've hardly used QUERY JOIN.

In any case, even if JOIN can get you some results for certain
values for FIELD1 and FIELD2 or the same field, my take on
this enhancement has always been that it asks to be able to
find records where two fields in the same dataset or the same /
different fields in two datasets are equal;  *without* having to
specify a value.  There is a big difference between "equal to
one value" and "equal regardless of value"....

Frank goes on to ask a question on another subject:

> What is the trick of addressing by number which extends
> the Image datasets beyond Terabytes?

From my "What happened @ IPROF-98" message awhile
ago:

<<
Currently IMAGE keeps track of individual records using an
"EntryByName" scheme:  24 bits for the block number and
eight bits for the slot number.  So max number of blocks that
are currently possible is  8,388,607.  Current BLOCKMAX is
5,120 Bytes.  Result:  Max dataset size is currently ~40GB.

Three possible "size mitigation" avenues were explored:
(1)  Use the sign bit of the record name.  Max size = 80GB.
(2)  Enlarge the block size.  Max size = 272GB.
(3)  Use EntryByNumber instead of EntryByName.
      Max size = 10TB  (yes: that's ** 10 TERABYTES ** !!).
>>

I guess in the above I could have added:

Going to "EntryByNumber" allows use of 31 bits to "count"
IMAGE blocks:   2^31 = 2,147,483,648 blocks;  which is
about 250 times as much as now....  oops...  that might
be 2^31-1...  Anyway, 2G blocks times 5K bytes per block
equals 10 Terabytes....

Now if you are talking about the internal details of just how
that will work at or even below the IMAGE intrinsic level....
well, stay tuned....  I'm sure we'll get more details as the
design gets further along...

:-)
Ken Sletten

ATOM RSS1 RSS2