I wrote...
> > But, even if we did offer MPE source to the public, how easy
> > do you think it would be to make a change in MPE and verify
> > that the change is correct and does not have any negative
> > side effects?

Chuck replied:

> Um Jeff, you do know that some of us are actually programmers
> that do have some small idea of what is involved in maintaining
> and enhancing old code?

I do realize this. In fact I have great respect for the talent
in this 3000 community.  Nonetheless, MPE is big with 10s of millions
of lines of code. It is written in several languages (CM Modal,
NM Modcal, SPL, SPL II, PSPL, C, assembly), it has a very complex
build environment -- make that 2 or 3 build environments since
not all parts of MPE use the same build engine, and it is a
challenge to do full fledged system regression testing. So, my
comment was aimed at those hurdles and not a statement of the
abilities of this group.

> The repeated statements made by you and others at CSY have
> led me to expect
> a mass of undocumented hacks and quick fixes that will be no
> small challenge to work with.

Some internal documentation is incomplete, out of date, missing, and
sometimes right on the mark!  Depends on who wrote the code, mostly.
There are probably not very many "quick fixes" as it takes us some
time to test the code.  But, to be sure there are fixes that are
not aesthetic.

> Which is why I think rolling back to a version before the
> large number of appeasement changes might provide the most
> stable code base.

There is a lot of CM code still in MPE and that code comes from V/E.
And that code is not stellar!  Rolling out POSIX (or name your
poison) will not significantly make MPE easier to understand and
modify.

Just my opinion,
 Jeff