Re: Explaining single level store to non i people

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