Jim Phillips recently wrote, being worried about the state of MPE:
> I certainly hope that there is (lots) more going on behind the scenes than
I
> am privy to. That is my hope for OpenMPE.
Another person wrote me privately:
===========================================
"The OpenMPE list has made no proposal. The vendor community has made
no proposal. Winston, Dave and Jeff have all expressed a solid desire to give
MPE a good home and I expect that any "licensing fee" would be nominal. But
they cannot, in good conscience, hand MPE over to the seething masses if they
have any desire for MPE to survive.
"If we want that sort of announcement from CSY we must (and I'm feeling
exceedingly urgent about this) organize the entity we want them to hand MPE to
and we must make that happen NOW. If we want to hand it to Beechglen or
Allegro or whatever, fine, but we have to have a real business model and an
extant entity with one official representative who can sit down at at table
with Winston and make actual decisions."
===========================================
I've now spoken at length with about 30 customers and vendors now about this
subject, each conversation lasting between 30 minutes and two hours, and I
believe that there is a consensus building on a way forward to not only save
MPE but to expand its use, as well.
What I'm going to write here are primarily my ideas on a way that we can make
this work, thus they should not be considered to be cast in stone.
Let me say at the outset that I am wholly opposed to MPE being owned by any
single vendor or company. Rather, I think that the only stable way to keep
MPE alive over the long-term is to have it owned by its users, just as United
Airlines is an employee-owned organization, or a credit union is member-owned
or a mutual assurance company is insuree-owned. Not only do such
organizations tend to be more stable, they also tend to be more
user-responsive, and thus in the long-run tend to prosper better. Credit
unions are as good as an example as any. Because they are inherently
member-oriented, they cannot easily do anything to harm their members. As a
result, most are thriving and have an excess of cash on hand. Banks, to the
contrary, because they work primarily for their shareholders, have taken on
the taint of mean-spiritedness and have become reknown for poor service, and
are not nearly faring as well.
Let me also say that when I speak of Open MPE, I don't mean open source in
the manner of Linux. The great majority of MPE users have no need to have
MPE's source on hand. Rather I see the real value in having MPE safely in the
hands of a "New CSY", completely independent of HP, financed by the user
community itself, although it may be composed of some to many of the people
who now work for HP's CSY. For lack of a better term, I'll call this new
organization NCSY, but I'm sure a much better name can be chosen later
(personally, I've always favored "Santa Fe", simply because it means the
"Holy Faith").
Finally, let me say that in the model that I believe will work best, MPE will
be distributed without license. Anyone would either be able to download MPE
from a server at no cost or order an installation CD for $100 and install it
on as many machines as they care to. All documentation would be on the web,
essentially as it is now. But if you wanted to be able to ask questions, your
support costs would be perhaps $1000/year. For that payment, one designated
person in your organization would be allowed to call in for support. While
you would be free to put MPE on as many systems as you care to, support would
be $1K/person per year.
However, when you pay support, you would be paying more than just for
support. Your yearly payments would also be your partnership dues in a
limited-liability company. You would be a full voting partner of the
organization. [While a domestic co-operative would be a simpler construct,
domestic co-operatives and US S-corporations are prohibited from having
foreign member-owners, thus an LLC is the only practical alternative.
Nonetheless, the LLC can be organized to be a cooperative in every manner but
name.] All of the finances of the LLC would be publicly posted on a web page,
including all income, the list of members, and all expenses, including all
salaries. Every nickel would be open and available for inspection by anyone,
at any time. The intention of the NCSY is not to generate massive profits for
its owners but rather to provide a very stable operating base for MPE and its
follow-on improvements.
MPE would be ported to the Intel platform, perhaps initially to 32-bit and
only later as 64-bit. But the "port" wouldn't be accomplished by
recompilation of the massive amount of code that represents MPE, in all of
its various languages, but rather through the construction of a PA-RISC
emulator/translator layer that would perhaps operate on top of the Linux
kernel. Such a design would *not* be able to obtain all of the performance
that native code could achieve, but it would be by far the simplest and most
reliable method to move MPE to Intel. [This, btw, is why God made 2GHz
processors.] Indeed, this is the only practicable way to get MPE onto an
Intel platform in less than a year.
MPE development would continue on PA-RISC machinery, just as it is now.
Indeed, it may be that all MPE development will continue to be done only on
PA-RISC for the next 25 years. But simultaneous with that HP's proposed
development in their current two-year roadmap, an emulator/translator would
be also developed, outside of HP, essentially beginning now. The immediate
advantage of working on a translator/emulator is that HP/CSY can
independently continue to improve MPE over the next two years while the
emulator/translator is being developed. At any point in the future, the
then-current version of the MPE object code could be moved over and run under
the the emulator.
TECHNICAL DETAILS
Undoubtedly, the simplest and most robust implementation of MPE on
inexpensive Dell-like servers would be to have MPE reside on top of the Linux
kernal, in a manner something like this:
deep
philosophical
firewall
.
MPE apps . Linux apps
| . |
| . |
MPE O/S <- . -> Linux O/S
| .\ |
| . \ |
|_____________\_________|
| \
Linux kernal \ file sharing would be
accomplished through
file equations/links
Although the intial effort would be aimed wholly at getting MPE to launch off
of the Linux kernel and have Linux do no more, the ultimate goal would be to
have both operating systems, Linux and MPE, executing simultaneously, either
on separate processors or alternating on one, with the Linux O/S being
subordinate to MPE.
In this architecture, POSIX could be backed out of MPE. The porting effort
necessary for POSIX-based applications has always been misguided, in my
opinion. It leaves MPE a day late and a dollar short. With Linux running as a
parallel process, there is absolutely no reason to maintain a weaker version
of POSIX as an intrinsic part of MPE. In this design, whatever processes come
to Linux would be immediately available to MPE as well. Implementations of
Telnet and FTP would remain in MPE, but all other internet services could be
pushed over onto Linux.
A great portion of the internal costs of the maintenance of any O/S center
around the constant evolution of hardware. For the foreseeable future, Linux
is gaining access to these new hardware designs as fast as any operating
system ever has in history. The great trick will be to "virtualize" MPE's I/O
structure, connecting to Linux kernal code so that little or no code changes
will be necessary in MPE in order for it to connect to the evolving
Linux-based disc/bus/etc. drivers.
SERVICE & SUPPORT
While some mainframe operating systems have been emulated on Intel PCs as
"programmers' toys," more out of nostalgia than anything else, the intention
of Open MPE would be anything but frivolous. Rather, it would be to generate
a completely serious, fully-functional and highly competitve environment for
application development. While such development may not aim at the
"enterprise-level" customer for several to many years into the future, the
HP3000's traditional users have been among $5 to $50 million/year gross
revenue companies or as departmental computers in larger companies. In that,
nothing will change.
Ultimately, all technologies eventually become simple and reliable, requiring
no mechanics constantly hovering over the machinery to keep it operational.
It happened with color television sets. It happened with xerox machines. And
it will happen with commercial computing platforms, too. In that regard, the
HP3000 is today more like what all computers must become in the future than
any other competing platform currently manufactured. The HP3000's inherent
simplicity and reliability are of fundamental importance for two reasons: (i)
these attributes dramatically increase the user organization's productivity
and information flow, and (ii) they greatly decrease its costs of operation.
A license-free MPE, coupled with very low-cost hardware, offers several
distinct advantages. One is the adoption of an Army-like method of hardware
repair. The Army designates three levels of repair: field, depot, and
factory. At the field level, if your radar van breaks down, you simply drive
up another one and return the defective one to the depot, where major
components are unscrewed, unplugged and replaced. It's only at the factory
level that individual resistors and IC's are replaced, and there not so much
to repair the units for return to service but to understand the nature of the
failures that are being experienced.
The newest Dell server I bought (128MB of ECC RAM, 20GB of disc, 900MHz
Celeron processor) was $448, which is less expensive than I've paid in the
past for some HP cabling. At these prices, you don't bother repairing the
units. You simply replace them, just as you do nowadays with color
televisions and xerox machines.
But inexpensive hardware should not be confused with unreliable hardware.
Indeed, we've seen no difference in overall reliability of our Dell servers
as compared to our HP3000s. The new CSY would undoubtedly recommend and
certify certain hardware configurations, but if the virtualization of the MPE
emulation is done well enough, the rules could become nothing more than, "If
Linux runs on it, so will MPE."
The great second advantage of very low cost hardware and free licensing is
that it will get MPE back into schools, not only universities but also
high-schools and trade schools as well. Guy Paul recently wrote:
> I believe the Nov 14th announcement made a point that no one has
> elaborated on - That finding new talent to support the MPE environment
> is becoming increasingly harder to find.
>
> All the folks I work with and probably most of you on the list are over
> 40 like me. When was the last time you saw a new hire come fresh out of
> college? NT, UN*X and Linux are all that's used at most university's with
> MPE being the rare case.
Price is the singular entry barrier to getting something used and taught in a
school environment. A true commercial operating system of MPE's quality,
available at virtually no cost, would be a tremendous motivator to having MPE
rigorously taught again in university environments, especially if it has an
active development organization behind it.
Keeping costs significantly above the norm, as MPE has been over the last
decade, has caused an ever-increasing downward spiral in use and users.
Keeping costs below the norm and maintaining a quality much better than
expected should very pronouncedly promote quite the opposite response.
GETTING THERE FROM HERE
MPE will die in two years, thus we have that much time to prepare a "New,
Independent CSY". We also have that much time to create a working
implementation of MPE on the Intel platform.
At the moment, of course, there is no such organization. The situation is
equivalent to the current government of Afghanistan, simply a bunch of tribal
leaders, warlords and cheiftans roaming around rather aimlessly in the
desert, each who have their own ideas about how we can get from here to a
fully functioning, parliamentarian, democratic central government.
Nevertheless, even in this situation, something has to be soon done. I spoke
with Steve Cooper, president of Allegro Consultants, for about an hour a week
ago. Allegro is the natural group to begin attempting to create an emulation
of PA-RISC MPE on Intel. They understand the PA-RISC architecture intimately,
have taught MPE internals classes to HP people, and have written a number of
MPE's routines in the past. My conversation with Steve was encouraging. Steve
was, as I am too, absolutely certain that MPE can be emulated on Intel, but
it won't necessarily be an inexpensive process.
Steve was less sure whether the money could be raised to accomplish this. As
I told Steve a week ago, I'm sure that it can. Verifying that statement of
mine has been the essence of many of the conversations I've had recently and
I'm now more sure that a minimum amount (perhaps $2 million/year) can be
raised.
To do this, I suggested that we, AICS Research, start collecting names,
addresses and emails of current users would be willing in the near-term
future to contribute one to two thousand dollars per year to what will
eventually evolve into a new independent CSY.
AICS has mass email capabilities and we can easily build new IMAGE-based
applications. Moreover, the two processes can be linked together quite easily
so that automatically generated emails can be produced with virtually no
effort. I spoke with the people here and everyone agreed that typing in two
to three thousand names would be no trouble for them and that they would be
pleased to do that.
In this intitial -- and temporary -- scenario, AICS would administer the
money, paying Allegro as necessary. All income, all payments, indeed
everything financial would be placed on the web for constant inspection by
everyone.
WHAT DO YOU NEED TO DO NOW?
The first step, if you are interested in seeing MPE continue on for the far
foreseeable future, is for you to simply send us:
A contact name
Your company
Physical mailing address
City, State, Zip
email address
If an insufficient number of people respond, there's little or no reason to
progress to the second step. But if the response is sufficient, you should
expect an invoice sometime in the near future, somewhere between $1000 to
$2500, dependent on the number of organizations that sign up. Even then, you
would not be obligated to pay the invoice if you either have changed your
mind or see no hope of MPE surviving.
WHAT WOULD YOU GET FOR THE FIRST TWO YEARS PAYMENT?
Almost nothing.
The collected monies would all be spent in moving MPE over to an Intel base.
There would be no support during this period, just periodic updates as to
progress.
WHY WOULD ANYONE PARTICIPATE IN THIS PROCESS?
It is my estimation that about 10,000 HP3000 sites now pay support to HP.
That number could be high or low, but I will simply assume that it is correct
for the moment. In my discussions with a great number of you, the lowest
annual support fees that I've run across -- for those of you who pay support
-- is $10K/year. Most sites pay two or three times that amount.
Given HP's announcement, I expect that 80% of the current HP3000 customers
will leave the platform. Nonetheless, that leaves approximately 2,000 sites
that will have a very strong vested interest in seeing MPE survive. These are
the sites that are running either home-grown code or orphaned code or those
who simply know what they have and do not want to change.
For the vast majority of these remaining organizations, migration is not an
option. The costs would be simply prohibitive: $100,000, $250,000 or a
million dollars. A complete restart would be easier. Their only option is to
stay on MPE until the last PA-RISC machine dies, all the while looking for
another application -- on any platform -- that comes close to what they have
now -- or Open MPE becomes a reality.
Paying $1000 a year for the first two years of development, all the while
continuing to pay their HP support costs, would be the cheapest, most
cost-effective insurance that they could possibly buy.
WILL HP COOPERATE?
This is the final question, and the most important. In this model, the source
is not being given out to everyone, willy-nilly. Allegro, I'm sure, will be
pleased to sign a dozen overlapping non-disclosure agreements concerning the
safety of the source code. They do that now on a regular basis as a standard
part of their business. It isn't being able to see the source code that is
important in this model. It's simply critical that the user community knows
soon that someone competent is diligently working on their behalf.
But this model is also in HP's interest. The level of user anger that exists
over this decision is deeper than CSY believes it to be. I do not consider
class-action lawsuits to be out of the question. However, if after one or two
years' worth of effort by Allegro, and possibly others, yields nothing, much
of the anger towards HP will be blunted. Quite to contrary, if HP/CSY
actively and generously aids in the development of an Intel-based emulator,
the amount of goodwill that that act will generate will go a long ways in
repairing the deep rift that now exists.
Will HP cooperate? I believe so. I spoke with one of the senior management
people at CSY at some length a week or so ago. In regard to Open MPE, he
said, "Why do people automatically assume that we won't cooperate. Why would
we want to do any harm to MPE?"
Based on that statement, I think everything else is eminently feasible.
Wirt Atmar
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
