WirtAtmar wrote:

> 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], two-speed
> automatic transmission dragsters.

Wirt never ceases to amaze me :-)  Were you driving (increase surprise
level considerably) or tuning the engine (expected answer)? :-)  I
guess we all have our wild-haired past, 15 years ago I could be found
in a Chattanooga nightclub playing keyboards in a rock band singing Pink
Floyd... but I had one of the first Digital Sampling Synthesizers on the
market, with a whopping 512K of RAM and a SS-SD 3.5" floppy.

> 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.

Not unlike early experiences with the 3000, when you optimized code to
extreme levels; I recall converting our SPL screen I/O routines into
some very tight code, in many cases long streams of ASSEMBLE code.  The
days when you used segment numbers on your Cobol sections and kept your
initialization/termination code away from the meat of the code so that
it wouldn't waste memory being in the same segment as the main code.
You wouldn't think of doing such today, but to get 64 users on a Series
III you had to at the time (and yes, we had 64 users on a Series III,
when everything you read said it was impossible).

> 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.

Putting this in proper perspective, YOU didn't design your current car
and don't care to find out the details of what makes it tick.  YOU
aren't concerned about making a quarter mile in (guessing for the time
period) under six seconds.  You ARE only concerned about driving to the
store.  There is a big difference.  Performance and objectives.

You could probably have done the disassembly/reassembly/tuning of your
rail dragster and know every intimate detail of what you were doing
because it was YOUR rail and YOUR specifications.  You could look at it
and know exactly what was wrong and how to fix it, and how to get the
most out of it when you wanted it.

> Our business customers feel very much the same way about their
> HP3000s.

This may be true of much of the customer base, but I would argue exactly
the opposite from my perspective.  Many of us don't want to "go to the
store without incident", but rather we want to make that quarter-mile in
under five seconds, preferably under four, three would be just fine :-)
The "1988 Corsica" is more like the Unix box - everybody has one, most
anybody can fix one, and yes, it will get you to the store and back most
of the time.  And I would challenge you to disassemble/reassemble one,
with bonus points for a 90's model.  Care to take it to the track?

The 3000 is special, but not necessarily because it is a "no-brainer".
It is a superior performance machine with low maintenance cost.

> 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 cylinder 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.

Certainly not - that is for HP, vendors, developers, and power users.
On this point I would concur, the typical 3000 user doesn't care for
details.  If you buy a Porsche 911 Targa you could care less why it goes
so fast, it just works.  You attend users groups for one of two reasons:
something is broken/missing, or you want to keep abreast of improvements
that you may have overlooked.  Similarly, you don't go to a car dealer
unless your car is broken or you want a new one (Saturn parties and BBQs
excluded :-) ).

> > 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.

This was a hot item at IPROF95 (yes, this goes back that far).  Perhaps
it is due to us old timers who remember when 20Mb of disc cost $20K, but
it was somehow intrinsically incorrect to the majority of those present
that the b-tree indexes were automagically generated by default.  The
discussion then diverted into "If you enable b-trees, do we generate
indexes for all datasets" then "Should we allow sets to be individually
enabled for indexing" and so forth; thus the current "solution".

I am still personally undecided on the issue, but biased toward the
current offering.  While enabling b-trees can make random queries much
more efficient (Wirt has elaborated previously), they do nothing for
existing applications which were developed without b-tree availability.
In the latter case, yes, you would waste some disc space for the indexes
that would be completely ignored by the application.

On a larger scale, we should consider HP's stance with respect to
b-trees.  For example, if a master dataset has a b-tree index, could
DBGET take advantage of that fact and retrieve the record via the index
rather than hashing the key and potentially chasing down synonym chains?
If Image itself took advantage of the b-trees, I would have no problem
with having b-trees built by default.  As it currently stands, no such
optimization is in place (as I understand) so b-trees remain a foreign
entity which you must explicitly take the incentive to exploit.

I want a poster of Wirt hopping out of the cage of a bored and stroked
supercharged 429 Mopar hemi powered rail dragster, pipes still spouting
flame, with the "MPE users kick butt" logo :-)  Leave the Corsica out of
the picture.

Jeff Kell <[log in to unmask]>