This is a reply both to "os400" and to James Graves. I need to preface it by saying that these are thoughts written in haste, that they are opinions only, and that they may change with reflection and discussion.
Very little has been published about the AS/400 system and it's operating system OS/400. Perhaps the best source is a book by Frank Soltis entitled "Inside the AS/400" (ISBN: 1882419669). Note, however, that this book focuses primarily on the architecture of the machine, rather than on the software system that surrounds it.
Within IBM, feelings about the AS/400 line are definitely mixed. On the one hand, it's clearly a successful system and people continue to suport it. A lot of Europe is running on AS/400 systems, and in many respects it is a system that is easier to use and work with than other midrange systems -- particularly from a software perspective. On the other, tha AS/400 is very different from anything else on the planet, and the division that handles it does an extremely poor job of interacting with the rest of the world. The result throughout IBM, and more broadly in the industry, is pretty much what you would expect: understanding of the AS/400 is very limited. It's an architecture with a LOT of firsts:
+ First serious production use of dynamic translation as part of an
architecture
+ First (and only) capability system to achieve widespread use
+ First OS architecture to successfully preserve binary compatibility across
a transition of the underlying architecture
+ Arguably the most compatible transition from 32-bit to 64-bit system.
Recently, the AS/400 architecture managed to eliminate the need for a custom microprocessor by integrating certain instructions into the 604 chip and altering the "horizontal microcode". Enhancements of course continue (as you would expect), and I probably shouldn't comment on where they are going from here.
On the other hand, there are some negative things about OS/400. The "Principles of Operation" for the machine is depressingly large -- easily five times the size of the S/390 ESA PrincOps, which is itself about five times too large for comfort. A lot of the bulk stems from the hybrid use of code translation as part of the architecture definition. There is some reason to think that the architectural complexity of the machine may have gotten out of hand.
There are some definite similarities. Both machines, after a fashion, provide persistence. Both are "object systems".
> I believe nobody can duplicate such thought [as OS/4000]
> in Intel-PC world easily.
I think you are right, but fortunately that is not the goal.
EROS is about 6 orders of magnitude simpler (so far, anyway). Some of the people who worked on the AS/400 early on have looked at EROS and said things to the effect of "this is where we would have gone if we had been able to see how to get there."
So basically, I feel that we have a system with all of the potential strengths of the AS/400 with few of the weaknesses. Of course, that's easy with a system that is so young. When we hit the age of OS/400, we'll have to see where we are.
That said, there are major differences as well. OS/400 is basically an ACL system stuck on top of a capability kernel. I'm inclined to think this is an unfortunate thing, though for practical usage the jury is still out.
So in summary, I would not say that EROS is conceived as a replacement for OS/400. It is definitely a potential competitor, and I think it lets us bring much of the OS/400 world to commodity computers, which continues to elude the OS/400 group (so far). I do think, though, that there is a pool of programming talent for OS/400 that will migrate readily to EROS.
Jonathan