To me, all those alleged disadvantages to SLS seem like a trifle when compared to the problems that arise when one runs out of space on, say the "c:" drive, under Windows. Expansion of any DBMS, file systems, individual file, and even disk clean-up operations are shut down.
Under IBM i, you just pop an additional drive into the bay and the capacity of the DBMS and every file system is automatically extended, no matter where they may have resided physically. In countless cases, that has been worth its weight in gold.
-Nathan.
----- Original Message ----
From: Hans Boldt <hans@xxxxxxxxxx>
To: midrange-l@xxxxxxxxxxxx
Sent: Friday, August 14, 2009 7:30:02 AM
Subject: Re: Explaining single level store to non i people
On Thu, Aug 13, 2009 at 19:17, David Gibbs<david@xxxxxxxxxxxx> wrote:
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: Other people have offered fine technical answers. But to put things
into perspective, you should be prepared to address other issues that
might be raised in response:
First, one disadvantage for programmers is that, in order to address the
entire memory space, pointers have to be big. While memory is certainly
cheap now, that hasn't always been the case. One result is that some
programming techniques common on other systems, such as linked lists, are
rather memory-hungry.
Second, as someone else mentioned, there's that 16M limit on spaces. You
can get around that using teraspaces. But a teraspace is an independent
memory space just like on a conventional operating system. (In contrast,
in a more conventional O/S, typically, each process can take advantage of
it's own 64-bit address space.)
(Compare teraspaces with AR mode on z/OS. AR mode was a way to get past
the 31-bit addressing limit of the mainframe. But now that the
z/Architecture can support 64-bit addressing, AR mode can be easily
avoided.)
Third, from the point of view of the application programmer, there is
little functionality available that is unique to the single-level store.
That is, for the most part, RPG, COBOL, and Java programmers don't need to
be aware that they're on a system with a single level store. That is,
objects are accessed using API's, not via direct manipulation of the
store.
Fourth, you have to address the security issues that arise from many
processes running in the same address space. On other systems, processes
don't (normally) have access to the memory of other processes. Thus,
single-level store systems need to have very robust security to ensure
that processes don't interfere. But that simply adds overhead.
Fifth, having a substantially different architecture than conventional
systems can make porting of applications more problematical.
To summarize, there are advantages and disadvantages to single-level
store. Weighing the pros and cons, I have to wonder if the iSeries would
be further ahead today if it had a more conventional architecture.
Cheers! Hans
midrange.com
