Ted Ashton <[log in to unmask]> wrote:

>  2) MPE/iX machines are not as tied to the blocksize as MPE/V machines, as
>     they can read large chunks of "real estate" consisting of many blocks
>(and
>     I got the impression from what was said that the chunks didn't
>necessarily
>     have to include integer numbers of blocks--is that true?).

I don't believe IMAGE accesses *partial* blocks on disc :-)

Seriously, though, if your blocking factor is really bad (for instance, a
BF of 1 and a MediaEntry length of 20 or so and a capacity greater than a
trivially small number) you will be wasting a great deal of each block.
Whether you read one block at a time (on CISC machines) or several blocks
at a time (on RISC machines) doesn't really matter in this case: You are
carrying a lot of "undefined bits" because IMAGE still rounds up its blocks
to be multiples of 128 16-bit words (or 64 32-bit words).  So, you want to
fill each block as much as possible, under any hardware architecture.


>...  Still, good
>     blocking factors, resulting in efficient use of disc space will increase
>     performance, as they make the "chunk reading" more effective--reading
>more
>     useful data at a time.

Correct.  In other words, don't be sloppy with your blocking factors just
because you are no longer on "Classic" RISC machines.



>  3) *WARNING* This is worth noting, particularly by those who use integer
>keys
>     or have large master datasets!
>     In the first release of MDX (which is supposed to be out on PP5, I
>think),
>     Image will now expect *MASTER* dataset sizes (when enabled for MDX) to be
>     a multiple of the blocking factor and DBSCHEMA will silently round them
>     up.  This means that the primary address calculation for integer keys and
>     the hashing for non-integer keys will be affected and that the DBA
>will be
>     unable to exactly specify what the dataset size will be.  Alfredo, could
>     you say more on this subject, please?  Is there anything Adager can do to
>     get around it, or do we need to just be aware and decide to use or
>not use
>     MDX depending on how we would be affected?

My understanding is that HP is working on a future version of MDX that will
NOT force an MDX-enabled master to have a capacity which is a multiple of
its blocking factor.  (The current MDX release of IMAGE imposes this
requirement.)

I have been thinking about possible work-arounds for this issue for about 4
months.  After our early-morning session a couple of days ago in San Diego,
I came up with an Adager solution that allows you to enable a master
dataset for MDX -- under the CURRENT IMAGE release -- even when its
capacity is NOT a multiple of its BF, provided a little easy-to-meet
condition is met.  (There will be *rare* cases where this easy-to-meet
condition can not be met.)

This Adager solution applies only to existing master datasets that you want
to enable for MDX on the fly.  If you create a new MDX dataset from scratch
via DBSCHEMA and DBUTIL, IMAGE *will* round up its capacity (if necessary)
to be a multiple of the dataset's BF.

If you remember, there was a friend of mine (who happens to be working for
a competitor) at that session, so I am reluctant to give away -- tonight --
the result of my months-long incubation, which just happened to "hatch"
after my brain had been stimulated by our nice discussions in San Diego.  I
will provide more details later, as soon as I finish applying the necessary
remodeling touches to my current algorithm...  I hope you will understand
that this is only fair :-)



>And one point which was in one of the supporting tangents but which may not
>itself have been exactly on topic ;-)
>
>  4) Alfredo is home-schooling his kids and is teaching them about math using
>     sliderules which they are constructing themselves.  YES!!!!  :-)

The slide rules are just this week's topic.  There are many other topics :-)

"Alfredo is home-schooling his kids" sounds like I am doing all the work.
My wife is really doing most of the work (and we have had a wonderful young
couple helping us during the last two years, as well as several
"specialist" teachers for languages, science, etc.).  The kids are avid
readers themselves, and that helps a lot.  I just do the fun part :-)



>> Just for the record (and for the benefit of those people who put a great
>> deal of importance on evaluation forms), let me stress that the topic of
>> our little session yesterday morning was "The HP3000 and IMAGE are an
>> unbeatable combination".
>
>Is this where I don't mention that the title was "IMAGE/SQL Performance"? :-)
>Or was that your suprise?  Speaking of which, I seem to have made it all the
>way through the conference without identifying what that was--could you make
>up for my blindness?


At first, I thought it was *my* blindness.  For the minor technical
details, you might want to check a recent posting of mine (Fri, 7 Aug 1998)
with the subject "Re: Big Adager News?" :-)



 _______________
|               |
|               |
|            r  |  Alfredo                     mailto:[log in to unmask]
|          e    |                                  http://www.adager.com
|        g      |  F. Alfredo Rego                       +1 208 726-9100
|      a        |  Manager, R & D Labs               Fax +1 208 726-2822
|    d          |  Adager Corporation
|  A            |  Sun Valley, Idaho 83353-3000                   U.S.A.
|               |
|_______________|