RE: SAA Historical perspective -- RPG400-L

On Fri, 15 Feb 2002 jpcarr@tredegar.com wrote:

> What the heck does Single Level Store have to do with Stream File Source
> Files?
>
> The pros and cons of where the compiler gets it's input file from has very
> little to do with SLIC's architecture. or the OS/400 that rides on top of
> it.
>
> Come back with your detailed understanding of what Single Level Store does
> from PowerPC architecture's perspective.
> What does it provide what does it preclude?

Oh boy, looks like I may have got some terms mixed up.  Here is what I was
thinking:

I used the term 'single level store' to describe the file system structure
of OS/400's native file system (the stuff in /QSYS.LIB).  You can't have
libraries within libraries - all libraries are at the same level.  The
library list is just a search path, not a file hierarchy.

By rich file hierarchy I meant a file system that has directories (or
libraries or whatever) within directories with no limit.

Here is a real world example that I think illustrates the weaknesses of
the native OS/400 file structure.  We have a library that contains many
little useful programs, modules, binding directories, etc. of useful
utilities and APIs.  The source members and object can be broken down into
three general categories:  APIs that we write and maintain, APIs that
others wrote and maintain, and an assorted and unrelated 'bag of tricks'.
Due to the restrictions of the file system, all the source for all these
categories is together (in say QRPGLESRC) with no delineation between them
other than naming convention.  We could make seperate source physical
files for each category but then we would have all the types of source
physical duplicated three times (as in QCLSRCUS, QCLSRCTHEM, QCLSRCUTIL
etc.).  It wouldn't due to have each category in a seperate library
because these three groups do belong together as all of them are for
programming.

If we could compile from the IFS then this particular would be solved.
Source could be stored like this:

/QOpenSys/eaerich/util/era_apis/

with many directories underneath for whatever we need

/QOpenSys/eaerich/util/other_apis/

with whatever directories are needed

/QOpenSys/eaerich/util/bag_o_tricks/

with this one really needing many directories because each little utility
has little to do with another.

Once compiled, the objects would fit very well into the existing OS/400
native file system.  We just need one library to hold them (and one
library to rule them all...).  But hey - what if the library list could
include stuff on the IFS?  IOW, what if OS/400 could run executables on
the IFS?  That might be a Good Thing(tm).

But objects fit quite well into the existing model, and running stuff in
the IFS could be risky, so that doesn't really matter.  But source control
and project management absolutely scream for a deep filesystem structure.
Change the compiler, organize projects, forget about a very difficult port
of CVS (which probably wouldn't be accepted into the mail code - not that
it matters, this is open source), and live happy.

P.S.  I researched the term 'single level store'.  I have been using it
wrong.  I apologize for using the term incorrectly.

James Rich
james@eaerich.com