Re: Explaining single level store to non i people

Hans Boldt wrote:

Joe wrote:

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.

On the other hand, the internals of single-level store are rarely exposed
to the iSeries programmer. Within a program, you still deal with a model
where you open, read, write, update, and close files. That is, the
programmer deals with a model not unlike that of conventional systems.

Actually, you can't really have it any other way. One way or another, the
operating system still needs to synchronize access to the "file" objects.

Your objection really has nothing to do with my statement.

I'll try to make it a little clearer.

In a traditional system, you have multiple places where things get read into and out of memory. One example is reading data from a file, which is relatively trivial (at least when reading from something like a disk drive). Another example is reading a program in; that requires a different sort of read as well as some cool address translation as you move it from disk to physical memory. These two things are very different in non-SLS systems, but they're virtually identical in SLS, because in both cases as far as the application level and supporting routines are concerned, it's just a memory access.

If you don't understand the different between that and the fundamental differences in, say, a Unix or Windows environment between loading a program and reading a disk file, then I guess I'm unable to get my point across. Similarly with the JVM issue. JVMs don't page. If you're not convinced, run Java on any memory starved system (*nix, DOS, i5/OS) and watch the thrashing.

This is just common sense stuff. If you don't see it, that's cool.

Joe