So up and out this morning to take in "IMAGE/SQL and TPI" by Gerry Johnson.
Mostly I learned that keyworded indexes are not provided to Allbase in an attach
but that other third-party indexes are.  Also, that it is wise to use "update
statistics" in isql when making any DBE changes as that is a big help to the
optimizer.

Next to the MPE Performance Panel with Bill "It Depends" Lancaster moderating.
6.5 performance did come up.  There appear to be three problems.  First, there
are some specific situations, mostly having to do with heavy I/O on small boxes
that has some significant slowdown.  Second, if your box is on the edge of
disaster anyway, 6.5 might push it over the edge.  I think that the number given
was "no less than 128M of memory".  Last, there was a problem introduced in
6.5PP1 which had a significant performance impact on SORT and there is a patch
soon to be out which we'll want to put on top of PP1.  The patch number was
given, but I didn't get it down.  I think that Neil Armstrong had it, perhaps
he could give it here.

There was quite some talk about number of spindles as well.  The upshot being
what seemed general agreement that a usage of about 4 or 4.5G per drive is
about right and that more than that can degrade performance.  It was recommended
to go ahead and buy whatever you can get (4.5s can be hard to find) and just
configure it to only use 4.5G-worth of the drive.  Steve Macsisak gave some
numbers which perhaps someone else has jotted down.  My vague recollections are
that on a given drive, you want to be using it at no more that 50% of it's rated
average throughput for decent response and 25% for excellent performance and that
when I/O rose above that, more spindles was a good move.

Then off to the Ballroom of a live link to New York and the rollout of Superdome.
Once again, a presentation completely innocent of MPE references.  Sigh.  I was
pretty comfortable with that, as Superdome *is* a shot at the high-end UN*X
market, until Carly said that what was important was open industry standards and
proceeded to list of Windows, HP-UX and Linux as their three *non-proprietary*
OSes.  I mentioned a disappointment that MPE wasn't to go on Superdome at the
3000-L lunch and there was general agreement around the table that MPE doesn't
*need* Superdome to accomplish the same amount that HP-UX will be accomplishing
on it.

I spent an hour each side of lunch wandering the Expo and, to my surprise,
getting a solution or two ;-), and then off to Alfredo's talk.  It was entitled
"IMAGE/SQL Database Foundations" and was filled with all kinds of wonderful
things.  An Alfredo talk is a wonderful thing and this one was no disappointment.
Probably the best line of the talk was when he was talking about not having
access to a private 747 as the President does and someone in the crowd
recommended using Carly's jet instead.  Alfredo replied that he didn't think
that that would be much help as it evidently couldn't get from Philadelphia to
New York :-).

I finished my HPWorld day with the IMAGE and HP SQL Roundtable with Ken Paul
leading out.  Jon Bale, bless his heart, has had to hold the fort as the only
HP database person in attendance.  They had arranged for two other DB folks to
be there, but the one from Bangalore evidently had visa troubles and the one
stateside was called away due to some other emergency, so he's standing alone,
and doing a fine job of it.

Ken Sletten, absent though he was, managed to ask if Oracle's moving off the box
would result in any more resources going toward IMAGE and Allbase work.  The
short answer is no.  The long answer is that that change really doesn't free up a
whole lot of resources at HP, as there weren't many being used by that program
recently.  The question came up of including the 9th module of Allbase with
IMAGE/SQL.  Dave Wilde had already answered that pretty well at SIGIMAGE--we need
to get paid sometime.  They can't just give Allbase away.  And I think that
that's fair.

The DSEM and Prefetch options came up.  It is, if I've understood correctly,
Ken Paul's considered opinion that enabling a database for DSem and Dumping is
a safe and intelligent thing to do across the board, but that there are
situations, particularly those high memory pressure, where enabling Prefetch can
actually decrease performance, so that should be done as needed.  Prefetch
basically gets all the information needed for the DBUPDATE (or whatever) into
memory prior to locking the semaphore so that the actual semaphore lock time is
as short as possible.  Under high memory pressure, some of that stuff can get
flushed to disc and has to be regotten while the semaphore is locked, thus *not*
shortening the lock time and requiring double I/O.  Not pretty.   Also, this
flag is obviously not going to help at all in single-user updating, as shortening
the lock time doesn't matter.  That said, for OLTP when memory is available,
Prefetch may well speed things along.

Well, that's about all I'm remembering after this long a day.  Oh, yeah, one
more big thing.  I finally met the famous Wirt Atmar and proceded to tell him
that I'd be at his talk tomorrow (it's really on Thursday, which I knew, but,
well, uh, that's where the title of this message came from :-).  Actually, it's
been good to add to the list of known faces: Joseph Rosenblatt, Lane Rollins,
Tom Brandt, Mark and Julie Bixby, and numerous others.  And now, before I
blither much more, I'll wrap this up and head for bed.

Ted
--
Ted Ashton ([log in to unmask]), Info Sys, Southern Adventist University
          ==========================================================
To Thales the primary question was not what do we know, but how do we know it.
                                       -- Aristotle (ca 330 BC)
          ==========================================================
         Deep thoughts to be found at http://www.southern.edu/~ashted