Re: Where is IBM? -- MIDRANGE-L

Hi Joe! First of all, don't get me wrong - I think the iSeries is a great machine. But I have to take issue with some of your comments.

Regarding virtual memory, today, practically all operating systems (at least desktop level and above) implement virtual memory addressing. Windows, Linux, all forms of Unix, OS/2 (if anyone really cares anymore), OS/390, etc. Virtual memory simply means that a logical address in a process is mapped by the CPU to a physical address. The CPU and operating system together manage memory over-commitment by mapping memory to a page file on disk and swapping back and forth when necessary.

What OS/400 adds to that is the concept of single level store, in which the persistent store (hard disks) is basically considered one big swap file. Any address in any process can refer to any piece of memory anywhere within the (necessarily) large address space.

Let's compare this to the typical system design. In other operating systems, an address normally only refers to the space assigned to a particular process. Processes, therefore, are then prevented from accessing storage belonging to other processes. On the other hand, in a single level store architecture, since a pointer can point anywhere within the entire address space, not only must the pointer have more bits for the address, but the pointer must also contain permission information to prevent the pointer from being used to access (or worse, change) storage it has no business to. Thus, the 16 *byte* pointer.

What does this mean to the system programmer? Back when this architecture was first released, memory was still rather expensive, and so limiting the memory requirements of programs was important. In systems programming, pointer usage had to be avoided.

What about the applications programmer? RPG programmers still deal with files on a record by record basis, just like applications programmers on more conventional architectures. There's nothing really in RPG or COBOL that take advantage of the single level store concept! Likewise, SQL still offers up data on a row by row basis. In fact, this is necessary to maintain the integrity of the database. On the other hand, even some conventional operating systems offer API's that map files to memory, mimicking single level store.

OK, so we've had a commercial implementation of single level store for 25 years now, and the concept was certainly known before that. (I learned about it in my operating systems course in the late 70's.) But have you ever noticed that no other computer manufacturer offers an operating system with single level store? Fact is, there are a lot of trade-offs to make in system design, and other manufacturers simply decided to put their priorities elsewhere.

As I said, I still think OS/400 is a great system in spite of the heavier than normal resource requirements, which don't really matter anymore since RAM is now so cheap. One consequence of single level store is that security had to be designed into the architecture at a much lower level, which is probably one reason why the system is so stable and reliable.

(Oh yeah, one more advantage of single level store is that it makes it easier for the systems programmers to implement persistence in object oriented frameworks, for those interested in Java.)

What's my point in all this? Single level store is certainly an interesting idea. But in my opinion, it's not really that significant a factor in the success of the AS/400 and iSeries. And because of it's heavy resource requirements, it may have been a limiting factor, especially in the days of the S/38. But then who knows where we would be today if the S/38 had been designed with a more conventional architecture?

Cheers! Hans

Joe Pluta wrote:

Not gonna fight, Walden, because it's too long and tiring.  Your use of the
word "supports" has to do with the fact that Windows uses physical memory,
whereas OS/400 uses a virtual address space.  I really don't want to take
the time to explain the difference between physical memory and addressable
memory space, but I'll give it one shot.

Windows is constrained by its physical memory, the limit of which has JUST
been upped to 39 bits and again, we have no idea how that has been
implemented in the APIs - what I read implies that only a few APIs support
this sort of addressing.  But even so, this simply means that, if you were
willing to spend the money (roughly $75K for the full 512GB of cheap memory,
or closer to $200K for RDRAM), you could theoretically index a file of
around half a terabyte.

OS/400 uses a completely virtual address space, though Leif asserts that the
usable AS/400 memory space is about 50 bits.  This is still roughly 1000
terabytes, and is far above anything Windows can even dream about.  Because
of the virtual memory scheme, the AS/400 can have a file with terabytes of
data that the operating system will page in and out, index, and so on,
completely transparently to the programmer.

I hope this explains my point, because if it doesn't, I'm not up to the job
of explaining it.  These are the discussions that make it crystal clear to
me that OS/400 is light years ahead of PC operating systems, and if you
disagree, then it's unlikely that anything I say will change your mind.