Re: Explaining single level store to non i people

[Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>]

The essential goodness of SLS is that no part of the application is ever 
involved with moving things between memory and disk.  Everything has an 
address, and when you access that address, the operating system decides 
whether data is available or whether it needs to be paged in.

This is hugely beneficial from the standpoint of only requiring a single 
paging mechanism that can be performance tuned to the hilt.  Not only 
that, but it can automatically support any new technology including as 
Mike has already mentioned, moving to the cloud.

Perhaps the largest potential problem with SLS is that paged memory 
works best with procedural code rather than object oriented code.  
People using the same code sequence and each having their own contiguous 
memory area (the RPG/PAG model) is going to work much better in a paged 
environment than the random-access nature of object-oriented 
programming, where bits of data and code are littered all over the 
virtual memory space and need to be accessed sporadically.

Most other points, from security to obscurity, are pretty much red 
herrings, as they all apply in one way or another to every system and 
thus aren't really specific to SLS.  For example the 16MB space 
boundary, while problematic, is a design tradeoff specific to the i5/OS 
implementation and not an inherent limitation of SLS itself.  This last 
paragraph is an HPO (Humble Pluta Opinion, TM, PatPend).

Joe

> Folks:
>
> Can anyone recommend a good way to explain single level store for non i, but technical, people (i.e., java devs, windows devs, etc)?
>
> david
>
>