Hans;
IMHO,
Your fifth point isn't really single level store, as you say, programmers and thus apps don't care, it is the OS architecture. The i/OS architecture could be implemented on another file system, they are "just" objects. The Amiga (Intuition) implemented a similar object oriented OS over a "conventional" file system back in the 80's. IMO a superior OS that died because of the lack of advertising/inertia
As to your forth point, There are several companies that would not exist if Windows/*NIX OSs had to have the level of "native" security that single level store requires of i/OS. Putting the security overhead in the guts of the kernel and OS is much more efficient that putting it on top of the OS.
Duane Christen
--
Duane Christen
Senior Software Engineer
(319) 790-7162
Duane.Christen@xxxxxxxxxx
Visit PAETEC.COM
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Hans Boldt
Sent: Friday, August 14, 2009 8:30 AM
To: midrange-l@xxxxxxxxxxxx
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
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
