Re: Laymans explaination for single level store?

just to keep things in perspective, the SLS does have its
disadvantages.  It is after all 30 years old!

The 16 meg space size limit is a problem.  Why should the APIs that
list to a user space have to include logic that cuts off the list
because of the size limit of a space?

The object name limitation of 10 or 30 characters should not be.  Long
symbolic names are very useful, esp for end users.

The use of 16 byte pointers to address any object or byte on the
system is very elegant yes, but what is the "point"?  Pointers to
system objects and pointers to data bytes are entirely different
animals.  Why force them to share the same 16 byte structure? 
Arguably pointers to system objects like programs and files should
always be stored as symbolic links, with long object names and the
ability to make that link a relative one ( search the library list )
or an absolute link. A 16 byte system pointer has no place in a user
application.  And my guess is that such pointers are a hassle in
system code also, what with their built in permanent authority to the
object pointed to.

The aspect of the system that has stood the test of time, the ability
of a program to be automatically reassembled when the CPU instruction
set has changed, has nothing to do with SLS.

The ability of the system to run code from 25 years ago is due in part
to the fact that the system has not been changed much in the last 25
years!   Introduce long file names, change the character size from 1
byte to 2 or 4 byte unicode, allow libraries to contain sub libraries.
 Enhancements like that would be great, but they would likely require
a source code recompile of programs.

-Steve Richter


On Tue, 30 Nov 2004 08:26:48 -0500, cwilt@xxxxxxxxxxxx
<cwilt@xxxxxxxxxxxx> wrote:
> Paul,
> 
> Nice explanation.
> 
> If you don't mind, I'm going to add that to my list of layman's quotes.
> 
> Charles Wilt
> iSeries Systems Administrator / Developer
> Mitsubishi Electric Automotive America
> ph: 513-573-4343
> fax: 513-398-1121
> 
> 
> 
> 
> > -----Original Message-----
> > From: PaulMmn [mailto:PaulMmn@xxxxxxxxxxxxx]
> > Sent: Tuesday, November 30, 2004 12:06 AM
> > To: midrange-l@xxxxxxxxxxxx
> > Subject: RE: Laymans explaination for single level store?
> >
> >
> > If I may--
> >
> > Imagine if you will an uber-computer that consists of an infinite
> > number of bytes of real (RAM) memory.  This computer has no disk
> > memory.
> >
> > Storing anything in this computer consists of writing to a fragment
> > of the bytes in this immense memory space.  It doesn't matter if the
> > thing being stored is a program, a data area, a database file, or any
> > other object.
> >
> > You write an object to a block of memory.  A program is executed
> > directly from the memory it occupies; there is no need to move it
> > anywhere.  A file is accessed by observing the data as it resides in
> > its normal resting space.
> >
> > An object is moved from library to library by removing an entry from
> > a list and writing it to another.  No movement of the object is
> > required.
> >
> > This is the S/38 / AS/400 / iSeries / i5 computer system.  As far as
> > OS/400 is concerned, it HAS that infinite memory space in which to
> > play.  The fact that there's a memory to disk mapping system and a
> > sophisticated swapping algorithm to make it work in the real world is
> > merely a 'temporary' inconvenience.
> >
> > --Paul E Musselman
> > PaulMmn@xxxxxxxxxxxxxxxxxxxx
> >
> >
> > ps--  I've always liked this system--   When the hardware has
> > outlived its usefulness, you 'merely' jack up the operating system,
> > slide out the old hardware, slide in the new hardware, let down the
> > OS, and it's off and running with new and improved technology.  No
> > changes to the objects in the memory space required!  [If you don't
> > count the CISC to RISC conversion process, that is!]
> > --
> > 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.
> >
> --
> 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.
> 
>