The previous email got away from me before I was finished assembling it all.
My apologies. Here is the complete response:
John writes:
> At 2002-10-01 03:01 PM, Mark Klein wrote:
> >On 1 Oct 2002 at 13:35, [log in to unmask] wrote:
> >
> > > In complete disagreement with Mark's assessment, I would back all of
> > > the POSIX stuff out of MPE. POSIX really is not much more than a poor
> > > imitation of UNIX. Given that Linux is freely available, it doesn't
> > > even belong on MPE. It is nothing other than an unnecessary and
> > > generally unuseful complexification of MPE.
> >
> >More water under the bridge. Without it, MPE would've died in the mid
> >90's. As far as pulling it out - it is too tightly integrated with
> >the kernel today as to make that darn near impossible.
>
> I agree with Mark. Without the POSIX shell and all of its utilities, all
> of the ports of Unix/Linux packages, etc., MPE would have died some years
> ago, and I for one would not have been able to get an HP 3000 installed at
> this site. POSIX was not a mistake. If anything, it came along too late
> and wasn't complete enough.
That's very much the point. POSIX, by its very nature, could never be
complete enough. It always will/would have had a "day late, dollar short"
nature to it. It could never be as good as the real UNIX, thus it would
always have appeared to be a weak sister, a pale imitation of the real thing.
The great evolutionary advantage would have lain in having integrated MPE
with a real UNIX in some significant manner. Five or so years ago, CSY
actively investigated doing exactly that in a project they called MOST
(multiple operating systems technology). I was quite excited about the
prospects of MOST for exactly the same reasons I state now: it would have
allowed POSIX to have been backed out of MPE (or at least abandoned in place
so that it was no longer reachable) while allowing communications with a
no-porting-required, guaranteed-to-be-correct, guaranteed-to-be-up-to-date
version of UNIX (or Linux).
Harry Sterling killed the MOST project because he couldn't see the value in
the proposition. Why try and run two operating systems in the same box at the
same time when you could just put two boxes next to each other and do the
same thing?
Although I didn't agree with Harry at the time, I do now. Given FTP and
REXEC-like capabilities, there's nothing that couldn't be done easier on an
MPE-UNIX/MPE-Linux two-box solution than on one burdened with POSIX -- and
we've been doing that here now for a fair number of years. Rather than
re-type all of that history again, I'll just cut and paste the following from
one of our web pages:
=======================================
Pictured above is a third small HP3000 that we run, another 918. However
that's not the device of interest in this picture. Rather the machine of
importance is the small $400 e-machine PC in the center of the image.
Adobe Acrobat Distiller is the program that converts PostScript files into
the PDF format that's become very popular on the web. Beginning about five
years ago, for a period of two years, I spoke to everyone I could at HP and
Adobe about porting Distiller over onto the HP3000, but I was able to make
absolutely no headway with anyone. No one was interested. Even more
frustrating, because POSIX is not UNIX, the UNIX version of the Acrobat
distiller would not run on the HP3000 as it was, even though it was certified
for HP-UX.
One day, in an epiphany not unlike Saul's conversion on the road to Damascus,
it simply dawned on me that I didn't need to keep beating my head on the
wall. Rather, I could purchase the very inexpensive Windows-based version of
Acrobat and FTP my files from the HP3000 down into a PC. The process worked
so well that I have now become a very enthusiastic advocate of not porting
material onto the HP3000 directly. Rather I now argue that it's best to run
the programs on the platform for which they were designed and control them
from the HP3000. Indeed, doing this insulates and protects the HP3000 in two
ways: one is from random software bugs, the second is from obsolescence.
In the arrangement we now use, a standard, simple HP3000 job runs our
QueryCalc reports and prints their PostScript output to MPE flat files. As a
second step in the jobs, the ASCII flat files are FTP'ed down into the
e-machine, into an Acrobat "watched" folder, adding the file extension ".ps"
onto the file as an intrinsic part of the transfer. The PC is set up so that
when a ".ps" file appears in the watch folder, Acrobat automatically converts
it into PDF, moving it to a pre-specified output folder. Although the
distillation process generally takes less than a second, we have our HP3000
jobs wait 10 seconds before they retrieve the newly-converted PDF files and
move them back onto the HP3000. Once the new files are back on the HP3000,
they're FTP'ed to a third server, our webserver in Minneapolis, MN, inside
the same job. It's all surprisingly very simple, very straightforward and
very efficiently done.
Because virtually any process on a Linux/UNIX or Windows machine can be
controlled in this manner, there's essentially no reason to port anything to
the HP3000 nowadays. But just as importantly, this simple observation makes
the current version of MPE nearly obsolescence-proof. Even more than SCSI,
FTP and telnet, because they are now nearly ubiquituous 30-year-old
standards, are going to look the same in 25 years as they do now. They cannot
be changed.
Hardware ages, but software doesn't. It is essentially immortal. But can you
run 25-year-old software 25 years from now, especially if no one is
"maintaining" it? What does maintenance mean? To a great degree, it means
keeping up with the evolving standards, not fixing bugs. But what would you
really want to change on your HP3000? Your code works now. It will work just
as well a quarter-century from now.
The little Linux box in the topmost picture is set to dial back to Red Hat
every evening, check for updates, and apply them automatically, if need be.
Doing this is necessary at the moment because of the rapid evolution
attendent to trying to make Linux a mission-critical operating system, and it
will be that way for the next five years or so. But there's virtually nothing
that really needs to be fixed on the HP3000 that sits next to the Linux box.
MPE code has proven itself to be extremely reliable at tens of thousands of
sites over decades of use. And although the total sum of all of the equipment
in the upper image came to less than $2000, there is sufficient computing
power on the table to run a $50 million/year business easily.
All software contains bugs, and on the last day that HP corrects whatever
bugs it finds in MPE, if no emulator and no Open MPE should come to pass,
those defects that exist in the code on that day will remain there forever.
But in many ways, operating under these conditions is more stable and more
predictable than when code is still actively being modified. You rapidly
learn where the remaining pitfalls are and you simply work around them.
The real trick to operating obsoleted hardware and an O/S is to buy multiple
spare equipment. This equipment is going to become startlingly cheap in the
next few years, so keep your eyes open for it. In your free time, configure
these spare systems to be identical to your production boxes. In this manner,
if your primary systems should fail, you can actually swap out a spare system
faster than you can call for assistance and certainly be back on line before
the repair people arrive, if you need them. Doing this also allows you to
find out what's wrong with the failed system at a leisurely pace and get it
back up and running on a schedule that's far more appropriate to the task
than one dictated by panic.
As I mentioned at the beginning of this note, I do not believe that staying
on the HP3000 indefinitely to be a particularly risky strategy. If your code
and business procedures work well today, they will work just as well
tomorrow, a week from today, or twenty years from now. In great contrast,
migration may be the riskiest thing you can do.
Over the years, we've had a great many customers move off of the HP3000 and
we've been very interested in hearing about their successes and their
failures. The former users who have had their companies bought out by a
larger organization have had the greatest success. The larger organization
dictates what kind of computer system they're going to use, and in this
situation, the HP3000 often loses. Nonetheless, our former customers
generally have to do no more than have their terminals changed out and learn
the new business rules as they connect to the central server at company
headquarters.
In this company-purchase environment, everything has been relatively well
smoothed out in advance by the purchasing organization, optimizing their
procedures over a period of years, if not decades. But the same hasn't been
true of our customers who have "migrated" off of the HP3000 onto some other
platform, based on their own volition. Their costs of migration have
universally been far higher than anyone originally estimated, as have the
times involved. Indeed, the migration efforts were so difficult that a few of
our former customers have outrightly failed during the process and many
others were put at high risk. There's no single day in the life of a company
when the computer system, no matter how it's architected, that it can't
operate and fulfill its business purpose, and it's this simple necessity that
makes migration so extremely difficult.
If your choices boil down to choosing between a "migration" process, which
may cost millions of dollars, and which may well put the company at risk, and
doing nothing, other than purchasing a number of very inexpensive spares,
staying put may well be the least risky thing you could ever do.
--http://aics-research.com/planb.html
=======================================
Wirt Atmar
|
