Guy Smith and Jeff Lindberg quite reasonably argued the opposite point of
view than I offered a few days ago concerning POSIX. They are not only
excited about the possibilities of running "industry-standard" software
through the use POSIX, but see POSIX as the salvation of the HP3000 -- not
its demise.
 
However, I remain unconvinced and still strongly believe that the road to
hell is generally paved, brick-by-brick, with good intentions. While I used
the term "bastardization" and Jeff & Guy used the far more polite phrase
"least common denominator," I'm not sure that there will be all that much
difference in the end in practical effect.
 
GOOD INTENTIONS
 
I wholly agree that POSIX is currently serving a very valuable purpose in
many shops as political cover, but I also think perhaps that is all that it
should ever do. But political cover is not, of course, why POSIX was
developed for the HP3000.
 
HP's underlying line of thought for putting POSIX on the HP3000 was
straightforward: "If we can't demonstrate the existence of "world-class"
software packages on the HP3000, then we're not going to be able to sell
HP3000's into the very large accounts. These are the only agencies that we
can afford to talk to any more, and if we can't provide them with what they
want, we're going to lose out each and every time we go out to close a sale.
We obviously must to do everything that we can to facilitate the migration of
these "world-class" software packages onto the HP3000."
 
But the fundamental question now becomes: What have you accomplished when
you've created an environment that is UNIX-like, but not UNIX? Nothing that
can do any of us any good on the long term. If you change any environment in
some fundamental manner, the consequences may be unintended -- but they are
not unpredictable.
 
POSIX is a set of guidelines set out by committee, with no rules of
enforcement nor even a particularly deep sense of commitment, and of which
the HP3000 is only approximately 85% compliant. And the same is true for all
of the emerging POSIX-compliant box manufacturers -- although they are not
compliant to the same 85% of the standards. Some (potentially significant)
porting effort will seemingly always be necessary to move any standard
UNIX-based process onto any specific POSIX-compliant platform. At the moment,
HP substantially subsidizes much of the porting effort required to move some
of the larger packages onto the HP3000, just has they have significantly
underwritten the migration of Oracle onto the HP3000.
 
The effect of inviting these packages onto the HP3000 is much like inviting a
pack of parasitic vandals into your house. They will not only suck the life
out of the HP3000, they'll burn the house down when they leave. An externally
immigrating software vendor will -- by his very nature -- view a
POSIX-compliant HP3000 as nothing more than a poor implementation of UNIX. He
doesn't give a hoot in hell about the HP3000, MPE, the IMAGE database, or its
transaction manager. UNIX is what the developer developed his software to run
on. UNIX is what he expects. He will use no more of the attributes of the
HP3000 in his software implementation than he is absolutely forced to.
Indeed, he will inevitably bring his own database and his own transaction
managers to the HP3000. He is evolutionarily and economically bound to do
this; he has absolutely no desire to substantially modify his software to
adapt it the HP3000. To do so would be completely counterproductive to his
larger goals and his larger audiences.
 
And because an almost-UNIX-like HP3000 will always be viewed as a minor --
and therefore very troublesome -- market for any UNIX-based vendor, several
aspects of his intensity of commitment and support will be inevitable: (i)
the stepchild will always be updated last, receive the least attention, and
be the first to be abandoned. No incentive exists for the primary effort to
be expended first on the "odd" implementations, especially if the market
proves disappointing. And, (ii) because of the inescapable dissatisfaction
that will be expressed by both the vendor's internal development staff and
his "odd" customers, he will, surely as the sun sets, incessantly harangue
his HP3000 customers to get with it and move onto a "real" UNIX box.
 
Surprisingly, the closer the HP3000 becomes the nearly perfect (but-no-cigar)
POSIX-compliant box, the more intense this pressure will become. The reason
is simple. HP says the software ought to work. You think it ought to work.
And the vendor says it will work. But no emulation of anything has ever
worked as well as the real thing and there's going to be a lot of
disappointment in the process. And what cure will the vendor recommend?
Abandon the damn HP3000,  move onto a "standard" platform and let's do it
right this time.
 
In this situation, the vendor, the user, and HP itself will no longer see the
HP3000 as a well differentiated product that contains great intrinsic value
in its own right. It has now become nothing more than a defective
implementation of UNIX in each of their eyes.
 
But what would happen if HP gets does get it dead right, where no porting
effort is required at all? It is in this circumstance that you can be
absolutely guaranteed that the software vendor will use none of the HP3000's
advantages. After all, the vendor must do nothing to modify his software. All
that he's going to use now is the HP3000's processor and memory. The correct
question now becomes: "What do you call an HP3000 that uses none of the
attributes of the HP3000?" I  don't know, but I don't think that you will
call it an HP3000 for long. The vendor won't think of it as an HP3000. It's
now a generic UNIX box. And the user will come to think of it more and more
that way, too. But an HP3000 is never going to be as cheap as a generic UNIX
platform and, inevitably, economic pressure will develop to see it as an
increasingly disposable item as time goes by -- because what value is it
adding in these circumstances?
 
If the HP3000 is going to survive and prosper, this is not going to be the
path.
 
TRULY PORTABLE SOFTWARE &
THE TRAGEDY OF THE COMMONS
 
While Guy argued for the advantages of the evolution of standard computer
languages, I have severe reservations. Much of my incredulity stems from the
simple fact that I am simply getting old -- and I have persevered through any
number of other standards committees and events that were going to
"fundamentally transform the world of computing." Twenty years ago, Pascal
was one of them.
 
Almost no one now remembers the underlying motivations of the development of
Pascal, but its original intentions were precisely those of POSIX. While
Pascal introduced a few nice features, such as structured programming, its
fundamental reason-of-being was to produce a language that was absolutely
portable, machine to machine, across all platforms.
 
Pascal was developed in the early 1970's, during a time when a plethora of
microprocessors, minicomputers and mainframes were first coming to  market --
and there was no clear winner at the time. Intel was a much smaller company
then than was Fairchild Semiconductor (the inventor of the integrated
circuit, and which is now extinct). And as with any new incursion into a new
technological capability, the rate of evolution and the production of
competing products was extremely rapid.
 
What Pascal was going to bring to the table was an absolutely common,
standard high-level language that was guaranteed to be completely portable
across all platforms. The way that this was to be accomplished was that the
high-level compiler was never to be written to work against any specific
target processor, but rather against a hypothetical, nearly ideal processor
which executed "P-code". Pascal was intended to be a two-step compiler. The
first step was the emission of the universal P-code, followed by any one of a
number of CPU-specific optimizing object-code translators to translate P-code
into the best possible sequence of opcodes for its target processor.
 
In this model of portability, a new P-code translator/optimizer would be
written for each new target processor as soon as it rolled off the assembly
line, but the high-level compiler would never be touched. And because the
high-level language aspect of Pascal remained unmodified, we could all be
absolutely guaranteed of complete portability -- without compromise, and with
full assurance of its compatability and optimization to each and every
processor.
 
But the first time someone wrote a Pascal compiler that skipped the P-code
step and went instead directly against the target processor, portability went
out the window and Pascal become nothing more than another variant of FORTRAN
or BASIC -- comprised of many variations itself, each optimized to take
advantage of some specific set of conditions for each different system for
which it was written.
 
All evolutionary pressure is for this simple pattern to be repeated again and
again. The individual vendor gains nothing by conforming to the standards set
out for the masses. In evolutionary ecology, the process is called the
"tragedy of the commons." At HP, it's called a "circular firing squad." But
it's the same thing. No manufacturer wants a level playing field, no matter
how much lip service he gives the idea, unless he can significantly tilt the
field in his direction. The vendor obtains his advantage by making his
products work better, more efficiently and more appropriately on whatever
platform he chooses to specialize. While the vendor may speak highly of the
ideals of portability and universal standards, he privately works to extract
every possible advantage out of his available technologies.
 
For POSIX to succeed it will require that a great number of highly
competitive organizations work to a common standard and adhere to it
religiously, without modification or compromise. It will also require that no
software vendor write his code so that it will not take advantage of the
specific nature(s) of any specific operating system. I see no hope that
either condition will ever be met.
 
COMMITMENT ALWAYS WINS
 
This is a very dangerous game that HP is playing. While all attempts at
standardization have either outrightly failed or exhibited only very modest
success in the past -- and I give POSIX only a very slight chance of being
marginally successful -- it does offer the very significant opportunity to
corrupt and complexify the HP3000 to the point that its open market value
will be made nil.
 
How do you corrupt -- and eventually kill -- such a strong contender as the
HP3000? One innocent step at a time, in exactly the manner that Richard
Gambrell (quite innocently) proposed: begin considering (and later requiring)
the POSIX shell(s) to be part of the fundamental operating system structure
of the HP3000 to the point that POSIX eventually becomes hierarchical over
MPE -- one step at a time, beginning with perhaps first with a
POSIX-implemented date and time functionality.
 
I have absolutely no complaint about common data interchange languages, such
as SQL or TCP/IP, being well developed on the HP3000, but the HP3000 must
remain an island of consistency and integrity if it is to survive.
Simplicity, ease-of-operation, reliability, and robustness will win out in
the end -- if given a chance and some real commitment from HP.
 
Wirt Atmar