HP3000-L Archives

March 2002, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Gavin Scott <[log in to unmask]>
Reply To:
Gavin Scott <[log in to unmask]>
Date:
Sun, 17 Mar 2002 19:07:39 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (111 lines)
Wirt writes:
> Roy writes:
> > Not if the emulator enables us to define our own HP Susan
> > # and CPU Name values :-)

This is one of the issues that will need to be addressed for any MPE
"future", either emulation or some sort of "Open MPE".

A number of people have expressed concern about license transfer costs
if MPE is ported to another platform or an emulation environment, but
there is really nothing new here.  Any such "new" MPE platform will have
precisely the same licensing issues as if it were simply a new HPe3000
model from HP.  If, say, I sell you an emulator with a bundled MPE
license then it would look the same to you as if you simply bought a new
"real" machine from HP.  You'll have to deal with the license transfer
issues any time you move to a new "box", whether it is a "real" HPe3000
or something else.

A truly "open source" emulator would, of course, eliminate the usability
of the HPSUSAN and HPCPUNAME values for software license enforcement.
This is one of the reasons why HP might specifically choose to support
or "enable" a commercial emulator product, as HP could license MPE to
the vendor of that emulator with the stipulation that the
HPSUSAN/HPCPUNAME values would continue to be controlled.

It is also important to remember that each independent software vendor
is free to decide which "models" of HPe3000 they will "support" and to
which ones they will permit license transfers.  If an emulator is both
sufficiently reliable and correct in its operation and it provides the
same license protection mechanisms as a "real" HPe3000, then I think
most ISVs will be happy to take your money to run their software on this
new model of HPe3000.  If, however, it either doesn't work right
(increasing support headaches) or will result in a perceived likelihood
of rampant piracy, then few ISVs may support it.

> The most likely emulator model that will develop will be done
> commercially, probably developed by Allegro, probably written
> by Gavin Scott, with charges for the emulator possibly something
> along the lines of total database usage less than 2.5 GB: free,
> other than distribution costs (ca. $150); 25 GB total usage,
> possibly $5000; 250 GB and up, possibly $25,000.

While my current numbers are somewhat different than Wirt's numbers,
this is, in fact, the model that we're currently investigating.  My own
desire is to be able to provide a "Personal MPE" license and emulator
that would be available for a small enough price that it would not be an
impediment to anyone who wanted to do development/support for (or even
just play with) MPE.  This "personal" version would be limited in some
way (total usable disk space, memory, or something like that) so as to
not cannibalize sales of the "production" version.

As far as pricing goes, the goal is to make everyone as happy as humanly
possible.  Of course we (and anyone else doing such a product) have to
make enough income from it to justify doing this project rather than
something else, and having a profitable product results in a strong
product with a healthy future that continues to get continuing
investment.

From the customer's point of view, there is some "value" to being able
to run MPE in this environment, and our goal would be to charge some
amount of money for the product that is less than the value you get from
it (hopefully significantly less), so it ends up being a win for
everyone.

Of course we can't charge you thousands of dollars for an emulator that
runs at 1% of the speed of a 918, so again the price will be dependent
on the value we are able to deliver.

It will sound self-serving but, honestly, you want me (or whomever is
providing your emulator or other MPE "future") to make a lot of money
doing it.  HP canceled the 3000 because it was no longer worth their
while to keep at it.  Fortunately I (and most of the rest of the non-HP
MPE world) can be quite happy with a very tiny fraction of what it takes
to keep HP's interest :-)  The HPe3000 is a "business" computer and if
it is going to survive into the future for that fraction of the user
community which, for one reason or another, needs/wants to stay on MPE
longer than HP is going to support it, then it's going to have to be a
viable "business" for those who make it happen, and the better a
business it is, the better it will be for *everyone* involved.

As far as the issues which have been raised about "ownership" of
an/"the" emulator, of course we understand that people will only
purchase and use an emulator if it provides a better future than, say,
keeping a closet full of obsolete 3000 hardware.  One of the issues with
any product you are going to use as a critical component in your
business is: what is the viability of the company providing that
product, and what happens if that company goes away or stops supporting
it.  My current thought is that we would arrange licensing for the
emulator that says that if we stop maintaining it then the source code
is released at least to our customers and quite possibly the whole thing
becomes completely "open source" if the HP and ISV licensing issues can
be worked out so that this is possible.

> The primary advantage that the emulator offers, besides the obvious
> significant reduction in hardware costs, is [...]

In my opinion, the primary advantages of running standard unmodified MPE
under an emulator on Intel processor systems include the potential to
save money by enabling you to use "commodity" hardware, but the biggest
advantage is that unlike the "closet full of old 3000 hardware" the
emulator is a dynamic entity, capable of continuously adapting to
changes in the computing landscape, supporting new systems hardware and
peripherals, and providing most of the things that you would get from a
true "open MPE" without the horrendous cost of replicating the entire
CSY development lab.

G.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2