Jeff Kell and Michael Gueterman both write in reply essentially the same
message:

> [Wirt's eloquent diatribe deleted for brevity, with apologies to those
>   who may receive this out of chronological sequence and left wondering
>   what I'm talking about]

>  Tier pricing [in specific regard to compilers] made some sense when there
>  was only one alternative - the
>  flat-rate unlimited user license.  It offered incentives to the smaller
>  shops with smaller CPUs.  But that is almost 20-year-old thinking, and
>  as I said originally, is an archaic principle.

My lengthy diatribe was edited substantially by me before I sent it to the
list. The version that appeared was only half as long as I originally wrote
it. It was in one of the sections that I deleted that I raised precisely the
same point that Jeff and Michael are concerned about. My response may have
been a little less clear because of those deletions, however.

Each class of software product is clearly used in a different environment and
to a different purpose, and warrants a different pricing consideration. A
batch-oriented report writer obviously must be used on the production
machine, just as a database maintenance/therapy tool must be. There are no
physical alternatives. The question then becomes how to best and most fairly
price these kinds of products.

But compilers are intrinsically different. They don't need to be run on the
production machines. Indeed, there are even some fundamental reasons
associated with safety not to perform development on the primary system. But
the current, overwhelming reason for not running the compilers on the primary
machine are exactly the reasons that Jeff and Michael state: the exorbitant
costs of upgrades for compilers when priced on a "user-based/CPU horsepower"
tier pricing.

It might be possible to get HP to change there pricing structure in regards
to such products. However, I have long ago given up tilting at windmills --
especially when there is an easy alternative. There exists a perfectly legal
and honorable way around the problem of high compiler costs on the large,
primary systems: obtain a small development machine and run it in parallel to
the primary system. Series 917's (if you can get someone to sell you a
machine in that configuration nowadays) can be obtained for about $6,000 --
and it's a hot little box when used as a 1- or 2-person development device.

The costs associated with purchasing all of the software upgrades for the
various compilers for just one upgrade phase may well be substantially above
the price of buying the 917. Further, and even more pleasantly yet,
"downgrading" to a 917 may actually represent a significant improvement in
compilation times due to the lack of system resource contentions that you
must endure on a big box.

Clearly, there may be some inconvenience associated with running two machines
and having to move the compiled executable code from one device to the other,
but ideally, that movement would be rather rare and would occur only after
you've extensively tested and certified the validity of the code on the
development machine. But the obvious advantage of running a small machine --
under the present pricing environment -- is that executable code is
unmonitored (and almost certainly always will be) and will run on any size
HP3000, once compiled.

This is the tack that virtually every vendor/developer uses. And there is a
certain degree of pleasantness being able to use an HP3000 as a PC.

>  HP3000 software vendors should focus on support revenue, and deliver on
>  that revenue (unlike HP's Roseville black hole).  Expand and adapt and
>  you have customers for life.  Don't run them off with exorbitant costs
>  for hardware upgrades, they're already hooked.  I sincerely hope that
>  (upgrade cost) isn't a "premeditated" source of significant revenue.

The only products that don't need support are the ones that never get used.
The greatest compliment any software vendor can receive is to have someone
say that his product has become fundamentally critical to the success of
their enterprise. But that doesn't happen just because of their ownership of
the product. Extensive support is almost always the reason that the user has
gotten to that state of satisfication and reliance on the software
manufacturer's product.

Wirt Atmar