Mike Berkowitz writes:
> I agree also that CIUPDATE=ON should be default, however I disagree
> with the statement that b-trees should be on by default. First, some
> master keys by their content do not lend themselves to partial key or
> range lookup as a practical basis. Second, why must all users increase
> their disc space usage and back up times if they don't need to. Last and
> most important, those of us that have purchased Omnidex or Superdex
> really don't need them at all. These products are much superior to
> b-trees since they don't require an index to be on an Image key/search
> item.
Steve Dirickson gave one reason for having b-trees ON as the default, a reason
that I have no argument with. However, the primary reason that I believe that
b-trees should be the default condition is because a great number of HP3000s
are not run as "large" systems, with a well-trained data processing staff on-
site, but by ordinary business people. Indeed, you can essentially measure the
success of any product by its capacity NOT to require gurus on staff or on-
site.
A great number of our customers who started on Micros are now running 987s,
with no increase in staff (they still operate their machines with no one who
is a "technical" data processing type. As often as not the current "system
manager" started his or her career with the company as a mail clerk). They
moved from a Micro to a 987 only because their businesses became a sufficient
success that the cost became easily justified. People such as these tend to
extract every nickle's worth of behavior out of their machines before they
spend another dime. But it is one of the extraordinary attributes of the
HP3000 that a non-technical organization (which almost every real business is)
can, on a moment's notice, migrate to a larger machine without having to do
all that much more than a store and restore operation.
It is precisely situations such as these that having the most useful
configuration be the default provides the greatest value to us all -- because
these people represent the future of commercial computing. I've become
extremely impressed with our mail-clerk/accountant/company CEO "system
managers." These people will learn anything and do anything to make their use
of the HP3000 a success. But there is absolutely no reason to make the use of
an HP3000 any more complicated than it need be, and certainly not any more
complicated than driving a car. An automobile designed the same way most
computers currently are would have interior cabin configuration switches for
rates of emission gas recirculation rates based on current altitude,
temperature and barometric pressure -- and a guru riding along in the back
seat to adjust these and all the other switches.
James Trudeau recently seemed quite disappointed that I drive a 1988 Chevrolet
Corsica. However, I doubt that he knows that in my younger days I was on a
racing team that nationally campaigned first a series of single-A (normally
aspirated, nitromethane fueled) rail dragsters that were eventually upgraded
to double-A [turbocharged (overpressured)], two-speed automatic transmission
dragsters. Between each run, the engines were removed, completely broken down,
inspected and burnt or worn parts (such as pistons, valves, and injectors)
replaced, reassembled and reoptimized for current weather and track
conditions, all within an hour. Exhaust manifolds were sometimes changed out
simply to reestablish a proper standing wave ratio in the pipes so as to
minimize the acoustic impedance mismatch between the gas escaping the
cylinders and the existing atmospheric conditions. It was enormous fun -- to
the point of being physiologically addictive to the noise and the intense
competition. But now, twenty years later, I've gotten old. I now make my wife
go to the gas station to keep the gas and oil levels proper in the car. And to
keep the windshield clean. In fact, I hardly even drive anywhere any more. But
when I do, all I want now out of life is to be able to put the key into the
car and drive to the store without incident, with 100% reliability.
Our business customers feel very much the same way about their HP3000s.
The reason business users don't go to HP3000 user group meetings is the same
reason that most of us don't go to Society of Automotive Engineers meetings.
While we would sit there and listen intently to someone going on for an hour
about the changes in electrical capacitance that occur in a compressing
cyclinder and his estimates and his equations demonstrating the minimal,
optimal number of joules that must be pumped into an electrical spark to
provide a maximally effective and completely progressive explosive burning of
the fuel/air mixture, in the end, it wouldn't have any impact at all on the
way we drive. And we wouldn't go back to the next meeting.
Gurus, mechanical, electrical or DP, can always "tune" their systems any which
way they like -- but ultimately, all commercially successful machines have
always been put together in a manner so that most people don't even have to
think about them. Having b-trees be present and ON is part and parcel of such
a design.
> WRT to the recurring "too much disk space" excuse: can someone please
> provide some real-world numbers on what native TurboIMAGE SSI does in
> this area? Instinctively, the argument feels bogus, because of the
> tremendous "compression factor" achieved by putting the index on the
> master set, but I would really appreciate it if someone with hard numbers
> would share them.
I do very much agree with Steve on this point. My estimates for most real-
world databases is that they will not increase by much more than 5%. Ours
certainly haven't. If true, then backups and disc space utilizations will
hardly be affected.
Once b-trees become common in the installed base, we'll certainly know for
sure.
Wirt Atmar
|
