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

In article <4e21hj$21m_at_lehi.kuentos.guam.net>, crobato_at_kuentos.guam.net writes:
|> In <DLJywz.HBr_at_eskimo.com>, salvo_at_eskimo.com(Marc Salvatori) writes:
|> >In <4dcacb$co1_at_lehi.kuentos.guam.net> Christopher Robato wrote:
|> >> You should see how progressive OS/400 is. How about an object oriented
|> >> design and architecture, with microkernel.
|> >
|> >OS/400, an object-"based" kernel, I can understand. But object-oriented?
|> >Hmmmm. Please expand on your thoughts here. An object-oriented kernel
|> >should allow you to add modules without the need to re-IPL, let alone
|> >reconstruct the kernel package.
|> >
|>
|> First of all, the word "kernel" does not exist in the AS/400 language. I'm sure
|> there should be such a thing called a kernel deep inside the AS/400, and the
|> thing I know closest to that would be the Machine Interface. So it's really
|> hard to say where the kernel ends or begins. The only time the term kernel is
|> used, is with the current IBM Workplace microkernel version used on the
|> RISC AS/400s (OS/400 v3.6 and above).

Correction - v3r6 (RISC) is not using a microkernel. When I think hear the word microkernel, I think of something like Mach which provides the bare minimum and relies on higher layers to define & present the operating system. AS/400s might use a microkernel some day, but our current implementations do not.

Regarding an object-oriented kernel: the ability to add modules without needing to re-IPL has nothing to do with being object-oriented. That is more dependent on the link loading philosophy of the system and on the requirements of the code being changed. You can be object-oriented without supporting dynamic linking.

AS/400s can do both:

[1] PTFs can be "no-IPL" PTFs, which can be activated as soon as

    they are applied.

[2] More sensitive code might require an IPL to become active because

    of possible consistency problems that would result if you just     "threw it in there."

|> And yes, modules are added on the fly without rebooting the machine
|> unless it involves changes in parts of the operating system that can
|> be considered 'kernel'.
|>
|> The new Microkernel version appears very much the same as the CISC
|> OS/400 v3.1 from the wrappers, and older AS/400 CISC software, like
|> those working under version 2.x of the OS, will run directly without
|> any code changes, on the RISC version of the OS, assuming observability
|> is built to the code (what AS/400 software that isn't?) Just install your
|> current software; no need to call your VAR for the RISC upgrade of your
|> programs.

The MI interface is an abstraction layer. Which allows us to change anything we want underneath it, as long as we adhere to the original "contract" specified by the MI interface. This is a very object-oriented way of looking at the system.

|> In fact, the RISC version looks practically the same as the CISC version,
|> and every part and module has the same behaviour that I think they are
|> literally the same. Only the 'kernel' is switched.
|>
|> The term "object oriented" also applies to the very paradigm and concepts of
|> the OS/400 itself. Everything is treated as an encapsulated object. Everything has
|> an object header tag, which includes among others, the owner of the object,
|> the security status of the owner, which is inherited by the object. Adding
|> and configuring devices in the AS/400 are derived from a base class of
|> preconfigured objects and templates, which the device inherits its characteristics
|> from. New users are configured and inherit the qualities from preexisting
|> classes of users.

We can't go too far with this object-oriented stuff now. The AS/400 has always been "object based", ie: we manipulate objects. That is not necessarily the same as "object-oriented."

The newer RISC versions are now more object-oriented in their implementation than previous versions. Unfortunately, just like on the older models, the user sees very little of that. This translates to "we define the objects and you may use them, but you can't inherit from them or define your own new objects."

|> One interesting aspect of the architecture is that OS/400 does not use
|> byte addressing, which MVS and OS/390 uses (and just about every OS in this
|> world.) Instead, it uses "object" addressing. Pointers in OS/400 never point
|> to byte addresses; rather, they point to objects (a 128 bit address decoded
|> by the microcode in the Machine Interface.) The objects can reside anywhere
|> in the vast "single level store" memory space or universe---the AS/400 does not
|> make a distinction on what is RAM or main memory, and what is virtual memory.
|> It will address whole arrays of disks like they are RAM in a single contingous
|> space of memory.
|>
|> Rgds.
|>
|> Chris
|>
|> Rei Hino/Sailor Mars Ami Mizuno/Sailor Mercury Minako Aino/Sailor
|> Venus Makoto Kino/Sailor Jupiter Haruka Tenoh/Sailor
|> Uranus Michiru Kaioh/Sailor Neptune Setsuna Meioh/Sailor Pluto
|> Usagi Tsukino/Sailor Moon Hotaeru Tomoe/Sailor Saturn
|> Chiusagi Tsukino/Sailor Chibimoon *****crobato_at_kuentos.guam.net*****
|>
|>
 

-- 
Michael B. Brutman
brutman_at_vnet.ibm.com
Standard Disclaimer: Not speaking for IBM