Re: AS/400 and DB2 vs. Unix and Oracle

In article <4e4dcj$7qm_at_lehi.kuentos.guam.net>, crobato_at_kuentos.guam.net writes:
|> In <4e3ac8$117a_at_locutus.rchland.ibm.com>, brutman_at_bruteforce.rchland.ibm.com (Michael Brutman) writes:

[snip]
|> On the OS/400 structure, it appears to me that much of what OS/400 appears
|> to be for the user and the programs are very high level, while the Machine
|> Interface or MI seems to provide only rudimentary hardware functions, much like
|> a kernel does. I can be wrong, just stating an opinion.
|>

It's not far off, just a tad overstated, at least from where I sit.

I didn't look at what the web page says, but the microkernels I know of (those from Carnegie Mellon or the later versions of it from Open Software Foundation) are relatively small, containing maybe 100,000 lines of code or less, plus other servers that might be called "midware" that run in problem state that might run in the kernel elsewhere. For instance, in the OSF microkernel, the "default pager" and the "name server" run in problem state. In AS/400, equivalent parts of the code are part of the kernel.

The "licensed internal code" that creates the MI (Machine Interface) is upwards of a couple of million lines of code, but a lot of that is I/O support, of which we have a generous amount. So, the part of the machine that runs the pager and dispatcher and so on, are not quite that big. But, there is perhaps a million lines of you-couldn't-possibly-subset it code in there.

Along with the I/O code, there is a substantial fraction of the DB2 support "under" the MI, too.

Even if you throw out all I/O and all data base related stuff, what you are left with is probably comparable, in size, to a Unix kernel, which is much bigger than at least the OSF / Carnegie Mellon Microkernel; indeed, the latter was done, in part, to show just how much stuff you could throw _out_ of a standard Unix kernel.

Still, one man's micro is another man's huge. OS/400 and all its licensed programs makes even a million lines or two seem small; in that since one might argue it is "micro". But, at least in terms of the academic literature on microkernels, today's AS/400 below-MI code is not really a microkernel.

|> As for being object oriented, everything OO seems to imply that you have
|> a prexisting supply of base classes of objects. New objects are then created
|> from these base classes, using inheritance. But isn't that how users,
|> printers, display terminals and other stuff, created and configured inside
|> OS/400? Such as creating a new printer configuration from *PRT class, etc?
|> Or the way every object created by the user inherits that user's security class,
|> even for just a simple file?
|>

You must understand that our notions of object-oriented precede either Smalltalk or C++ by about a decade and more. Therefore, you should not expect a one-to-one correspondence between what one sees in today's OO languages and how AS/400 is constructed. We were _really_ on the leading edge of objects; we had them before anyone really had time to dream up many of today's critical ideas.

In spite of this, the object structure of AS/400 and OS/400 is not that far off of what developed. It is easy to show we have something like "inheritance" going on. For instance, both a data base file and a spool file inherit from the basic "below MI" data base object; they just use them differently. There is a notion of "object subtype" that enables one to see the "object hierarchy" between the machine level objects and the various versions created by XPF (and, before that, CPF) to run the system. It directly provides the "is-a" notion.

I am not as expert on the above-MI work, but certainly, one sees many echoes of a class definition/meta-data, especially in the data base area.

You could draw nice Bootch-type or other OO style diagrams for every existing XPF object, though it might be a little odd at first in that the XPF part, being the "leaf" object, would tend to be drawn below the base microcode "below MI" object, so the pictures would be upside-down compared to most literature about AS/400, either in or outside of IBM, that show our objects. Once you get over this issue, which is really just a graphical art thing, it all falls out pretty nicely.

The major thing we didn't anticipate was polymorphism. Our "methods" tend to say "delete data base" and not "delete".

I don't know how or whether more of this structure will be made visible to the user. Or, for that matter, how aggressively a C++ coder could "wrapper" the existing System API set in a way that corresponded closely to the actual object structure. But, at a "here's how it looks" level, you could draw a very recognizable picture of the system using any of the object-oriented documentation protocols and see readily where we anticipated the late 80's revolution and where we didn't back in the '70s when all this was invented.

-- 
   Larry W. Loen        |  Science is often the act of trading
                        |  comforting myths for exciting ideas

   email to:  lwloen_at_rchland.vnet.ibm.com