Gavin wrote :

> One of the first laws
> of Unix is
> that everything is just a stream of bytes, and everything in
> the system
> orbits around that idea.  As soon as you introduce MPE-style
> files, you'll
> find that nothing in the Unix world will know how to deal
> with them in all
> cases (no matter how clever your file system is, and I can
> think of a lot of
> really clever ideas in this area).

It's been my understanding, since the good ole' days of 5.0, that the byte
stream file type had been implemented within the MPE/iX File system.
Therefore, we now have the following record types : Fixed, Variable,
undefined, and byte-stream, which is basically there for Posix' sake. So
this issue may not be such a big problem as Gavin suggested.

Unless I'm seriously mistaken about MPE file types.

> This is one of the failings of MPE, that files have such a
> complex interface
> that it is very hard to write general purpose programs
> without a huge amount
> of conditional code to handle all possible cases.

From what I remember of the MPE source, this is seriously true !!! But it's
handled by OS code, so it's not such a big deal for app code. An app would
call HPFOPEN, either directly by intrics call or by some compiler-specific
OPEN (or similar) verb, and that would do the job of interfacing the complex
inner layers of MPE.

> Also you can expect the Unix/Linux world to think that the
> whole idea is
> just one massive perversion, so any hope of getting an MPE
> file system into
> the Linux kernel, say, will have an uphill battle at best.

That's why I'm highly doubtful that an "MPE-within-Linux" initiative can
succeed. I'd rather try an "MPE-above-Linux" initiative, i.e. implement the
MPE file system (incl. file equations) and the MPE CI features (scripting
language, UDCs, variables, job control stuff) as outer layers.

Other posts have raised the issue of XM (Transaction Manager). XM may easily
be the most interesting internal feature of MPE (internal, because most
users are not even aware it exists, interesting because it's the best
differentiator MPE has for stability's sake).

XM in itself is a very complex piece of code. In fact, it requires changes
to file system (it uses reserved files with names beginning with "$", and
which are not user-viewable). It also has hooks to memory manager (the XM
journal is a memory-resident data structure). And it has its own recovery
processes, that are invoked at startup time (the APR - Aggregate Parallel
Recovery - processes). There are also the famous checkpoints (pin 11,
xm_checkpoint) and other pieces of code. That means that, if we are serious
about "emulating" MPE on anything else, we must take great care of the XM
code and features. That is, we must consider not only XM itself, but all of
its dependencies.

Another choice would be to have some partial MPE emulation, without XM. But
I do not see the point in spending time, money and other resources on some
project that works not nearly as reliably as HP-UX (11.0 has JFS 3.3) and
far less reliably as good ole' MPE itself.

My point is that XM is so deep embedded inside Core MPE that it probably
can't be taken out. Unless, that is, we rewrite everything.

Just my 2 cents ...

Christian "I want my MPE, and my XM too" Lheureux

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