To: Captain Greb <[log in to unmask]>
Let me try to clear a few things up ...
On 9/14/06, Captain Greb <[log in to unmask]> wrote:
> On Wed, 13 Sep 2006 14:57:44 -0700, Pete <[log in to unmask]> wrote
>
> It would be interesting to put together a mini PA-RISC interpreter for a
> PC
> and run some code through it. I'll bet you won't find a huge performance
>
> difference between the 64bit intel chips vs a 750mhz PA-RISC.
>
You have a point there, and it is a good solution to get-by for a
couple of years. I am personally not interested in that scenerio of
just helping MPE gracefully fade off into the sunset.
BTW, incase you don't know, 64bit only helps with large memory
applications in general, using the same tech with 32 bits.
> Anyway, did you read HP's "rules" of having MPE run on an
> interpreter/emulator? My understanding is that it has to run a stock
> version of MPE. That means it has to interpret the instruction set (all
> of
Not interested in an MPE interpreter/emulator! I thought that I made
that clear, I do not think it is economically feasible. What I am
talking about is writing intrinsics like FWRITE so that they are
identical from MPE user mode perspective, and internally use Linux
system calls.
> it, floating point and stuff they don't tell anybody about) and emulate t
> he
> hardware right down to the instructions talking to the disks. Let's say
> (I
> don't know) that MPE writes SCSI commands to port address 0xff200000 to
>
> talk to LDEV 1. Now how is the emulator going to translate output to/fro
> m
> that port that into an actual I/O to a SATA drive or even a SCSI drive
>
> attached to the PC? You also have to emulate all the PDC calls, even the
>
> undocumented ones.
>
I know all about that stuff, I used to hack MPE using a decompiler and
sent in a couple of patches in the apparent SPL from the decompilation
-- and that was before I got a hold of VEDecomp. It is actually
harder than you may think. That is my point!
> Another way to do the emulation is to create a program loader for hpux.
>
> The loader would need to handle the run time linking, which may or may no
> t
> be a huge issue. The main advantage to this is that the object code is
>
> being executed by the hardware.
>
Exactly my point! Use Linux to load the MPE binaries that have been
compiled into the native instruction set, say Intel x86, with MPE
intrinsic libraries that are internally Linux.
> >
> >Even if you overcome the emulation performance problems, you are still
> >having to compete with MS, Linux, AIX, HP-UX, Solaris, and zOS. Can
> >OpenMPE match the resources being used on these? Actually, all are
> >losing market share to MS and Linux. How do you expect to compete
> >against either of these OSs?
>
> This isn't a competition, its survival. And if you look at who's pushing
>
> for survial, its mostly the people who haven't accepted their fate.
>
Or, they see the value of MPE as a superior integrated database
development platform for custom inhouse developement. There was a
reason the platform survived for 30 years. I believe it was the
changes to HP's management that put MPE on a deadend road.
> >Which brings me back to my original idea. Use Linux as the chassis
> >and build a user mode MPE interior with all of the familiar controls,
> >layout, and easy-of-use design.
>
> /usr/bin/mpesh ;)
>
> >The key in a nutshell, is to build a
> >wall of MPE intrinsics separating user mode MPE on one side, and a
> >Linux platform on the other.
>
> Most of that has already been done for HP-UX.
>
> http://www.allegro.com/products/hp9000/intrinsix.html
This is great! Are they willing to GPL their work and assign the
copyright to OpenMPE, so we have some confidence in the future? Also,
they state on their web site:
"JCWs and session variables posed a particular problem. Unix does not
support the concept of putenv() actually affecting anything in the
parent's environment. Thus, there is no supported Unix method of
passing an environmental variable back to the caller. Rather than
invent a method (which opens the wormhole of job/session temporary
storage), we simply support JCW in PUTJCW, and that is settable only
within a process."
I suspect this might be true in HP-UX, but not of Linux which is the
future. This is the manual page for the 'putenv' Linux function:
----------------------------------------------------------------------------------------------------------
PUTENV(3) Linux Programmer's Manual PUTENV(3)
NAME
putenv - change or add an environment variable
SYNOPSIS
#include <stdlib.h>
int putenv(char *string);
DESCRIPTION
The putenv() function adds or changes the value of
environment variables. The argument string is of the form name=value.
If name does
not already exist in the environment, then string is added to
the environment. If name does exist, then the value of name in the
envi-
ronment is changed to value. The string pointed to by string
becomes part of the environment, so altering the string changes the
envi-
ronment.
RETURN VALUE
The putenv() function returns zero on success, or -1 if an error occurs.
ERRORS
ENOMEM Insufficient space to allocate new environment.
NOTES
The putenv() function is not required to be reentrant, and the
one in libc4, libc5 and glibc2.0 is not, but the glibc2.1 version is.
Description for libc4, libc5, glibc: If the argument string is
of the form name, and does not contain an '=' character, then the
variable
name is removed from the environment. If putenv() has to
allocate a new array environ, and the previous array was also
allocated by
putenv(), then it will be freed. In no case will the old
storage associated to the environment variable itself be freed.
The libc4 and libc5 and glibc 2.1.2 versions conform to SUSv2:
the pointer string given to putenv() is used. In particular, this
string
becomes part of the environment; changing it later will change
the environment. (Thus, it is an error is to call putenv() with an
auto-
matic variable as the argument, then return from the calling
function while string is still part of the environment.) However,
glibc
2.0-2.1.1 differs: a copy of the string is used. On the
one hand this causes a memory leak, and on the other hand it violates
SUSv2.
This has been fixed in glibc2.1.2.
The BSD4.4 version, like glibc 2.0, uses a copy.
SUSv2 removes the 'const' from the prototype, and so does glibc 2.1.3.
CONFORMING TO
SVID 3, POSIX, BSD 4.3
SEE ALSO
getenv(3), setenv(3), clearenv(3), unsetenv(3), environ(5)
GNU 1993-04-08 PUTENV(3)
----------------------------------------------------------------------------------------------------------
And here is an online link:
ttp://www.gnu.org/software/libc/manual/html_node/Environment-Access.html#index-environment-access-3079
In any case a GPLed version needs to be produced and all of the mixed
case intrinsics that Allegro produced needs to be upper case or hidden
from view. I really think it could be done easier, and simpler to
create an MPE user mode interface into Linux.
>
> Most image calls could easily be translated to sql:
> dbget,mode7 - select * from tablename where primarykeyfield='bah'
The idea of course is to be able to recompile a usermode program, and
have it just work!
> >Between 85% to 95% of MPE/iX can be
> >thrown away as not only unnecessary, but replaced by better components
> >of a Linux platform and with no ongoing support costs, with free
> >enhancements, and with free support of new server hardware and
> >peripherals.
>
> Amen!
>
> >In this scenario, you are not trying to beat Linux
> >(which even MS has failed miserably to squash for over 10 years), you
> >are joining Linux, and acquiring all of its resources by default. I
> >still haven't seen anything that says this idea won't work, nor have I
> >seen any other idea that is anywhere near as economically feasible.
> >If I am wrong on either account, please enlighten me.
>
> The whole concept of keeping MPE is flawed. Ask yourself what is so
> special about MPE that you can't live without. EDITOR? Image? Vplus?
>
> The 24x80 green screen?
I never used EDITOR, except the first few months when I didn't know
any better, who did? Image is great after the critical key update and
b-tree indexes were added. Vplus was excellent too! Block mode can
save a lot of interrupt processing and had a lot of functionality for
advanced "dumb" terminals that was not taken advantage of as the
common user terminal was the less functional cheap models. I did
suggest replacing Vplus with HTML output anyway as both character (for
dumb terminals or emulators) and graphic displays are supported.
Green screens are not part of MPE. MPE was character oreintated,
rather than graphic oreintated, for a substantial performance boost.
When you are talking about getting the numbers right and keeping
database data, you don't need graphics!
> Don't get me wrong, MPE was a great OS - 25 years ago. Today its time
>
> consuming and downright painful to do development on MPE vs something els
> e,
> whether it be MS or Linux.
That is a laugh! Have you tried to write C programs on all three?
You say you only do .NET or VB on MS? I'll still wager with
Powerhouse, I can beat you everytime producing simple apps, or with
OpenOffice producing a GUI frontend to a multitude of data sources.
> The only reason to stick with MPE is if you're a "homesteader". The main
>
> reason you'd be a homesteader is if you're a smaller company unwilling or
>
> unable to invest dollars in new software/hardware. They can continue on
>
> for a good 5 to 10 years with used hardware. Hopefully they know the sco
> re
> and they know they'll have to do something someday, but they can get by f
> or
> now. Any large company not thinking about getting off MPE in the next 3
> to
> 5 years has a problem with their business plan.
Its cheaper to by multiple brand new Linux servers than it is to buy
support for an HP3000 for a year (or at least it was the last time I
was managing an HP3000).
> Its almost 4am and I have to get up in a couple of hours.
> Good night.
>
> C.G.
> www.gresb4hp.com
> www.irs4hp.com
Hope you slept well!
- Pete
|
