Wow! Shaking my head.
Pete, you have delusions of grander. Give it up. Its
not gonna happen. Its not realistic.
--- Pete <[log in to unmask]> wrote:
> 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
>
-----------------------------------------------------------------------------------------------------------------------------------
Seeking PERMANENT employment within a shop that has any of the following: HP3000, Macola, Jobscope, MS SQL in the states of: OH, TN, GA, NC, SC, FL.
Titles of:
Senior P/A, S/A
MS SQL Admin.
IT Director, Manager, project leader
OR >>>> HP3000 Contract/Consulting anywhere in US.
Can you help me out?
419-651-6704 or [log in to unmask]
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
|
