from a lowly application programmer who's never _really_ looked under the
hood,

iirc we were recently told the 3rd party stuff is 3 items:

1) some unix stuff
2) more unix stuff
3) MBFoster's ODBC

No disrespect intended, Birket, but frankly I was quite surprised to hear
that there's an HP-paid 3rd-party license fee for #3, as the ODBC product
supplied is, at least in our perception, a teaser, designed to show you how
cool ODBC can be, but to really use it effectively you need to buy a REAL
ODBC product, conveniently available from of course MBFoster and now
Minisoft (others?).

re the 1st two, IF the emulator were software designed to run atop linux,
all ux stuff could be just left out of OpenMPE, and ux calls could be as
simply invoked as is MPE's HPCICOMMAND.  Voila, no 3rd party fees.

Granted that's a huge IF, and quite contrary to the hardware emulation
touted by the OS experts here, but if MPE emulation amounted to intrinsics
written to run atop Linux, that OS's continuously improved features would be
pretty durn near.

Gavin et al are apparently concerned with automagically supporting
anything/everything anyone's ever done with MPE, no compilation required,
and that sounds like a a really clean approach, probably a lot simpler and
surer-footed than a complete rewrite of each chunk of MPE.  But that amounts
to a project that can't well be shared, and I'm not seeing any economically
viable scenarios for it.

Written atop Linux, many pieces of MPE would be just plain unnecessary, and
the really hard part, mapping the file system onto free-range disk INVALID
KEYWORD oops disc, becomes a (less secure of course) community-shared design
project which can start right now.

Me, I don't care if I have to minor-mod and recompile my code to run on the
new OS  ("emulator", which contains my familiar listf, fixedlength records,
etc), as long as I can operate vs Image and KSAM etc using (new versions of)
familiarly called intrinsics, I really don't care what's underneath.  I
probably can't expect true e3k performance, but since I'll be throwing
multiple GHz CPUs at the problem, disk IO is once again the bottleneck, big
deal.  And I won't be wasting my time trying to get CSY to add features:
check out the appropriate code, make it work, submit to OpenMPE for
inclusion.

Based on past models of emulation (Visicalc commands work in every
spreadsheet there is), there shouldn't be any real problem using names like
FOPEN, so skip those court battles, and don't even call OpenMPE an emulator:
it's a new product designed to work as but better than the original.

Seems to me this is the only way MPE could ever become OpenMPE anyway, and
Open seems to be the only way this will ever fly economically.  It also fits
the tried-and-true KISS and StepwiseRefinement theories we all know and
respect if not love.

OK, shoot me down folks!

Tracy Pierce

> -----Original Message-----
> From: Tom Brandt [mailto:[log in to unmask]]
> Sent: Friday, December 13, 2002 4:40 AM
> To: [log in to unmask]
> Subject: Re: MPE Licensing
>
>
> At 05:14 AM 12/13/2002 -0500, John Dunlop wrote:
> >Jeff Vance wrote :
> >
> > > Finally, if you wish to continue using your e3000 AND you wish to
> > > start using MPE on an emulator then you will need to purchase a
> > > new MPE license.
> >
> >Is it just me that feels rankled that hp (not HP) expects to
> continue to
> >extract revenue from an installed base that they have abandoned.
> >In my somwhat naive mind (in my dreams), a "goodwill" gesture from hp
> >towards the previously loyal installed base could take the
> form of one or
> >all of the following :
> >
> >1. Release the MPE source code (e.g. to open source or
> reputable custodian).
> >2. Uncripple ALL hp3000s.
> >3. Waive any license fees for new or transferring of
> existing licenses.
> >4. Not charge a fee for using an Emulator.
> >5. Allow 9000s to be converted to run MPE.
>
> What do you propose for the parts of MPE that are licensed
> from third parties?
>
>
> --------------------------------
> Tom Brandt
> Northtech Systems, Inc.
> 130 S. 1st Street, Suite 220
> Ann Arbor, MI 48104-1343
> http://www.northtech.com/
>