RE: SAA Historical perspective

[Tom Daly <Tdaly@xxxxxxxxxxxxxx>]

Comments inline...


 |  -----Original Message-----
 |  From: James Rich [mailto:james@eaerich.com]
 |  Sent: Monday, February 18, 2002 16:18
 |  Subject: RE: SAA Historical perspective
 |
<snip>
 |
 |  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.


I like to think of QSYS.LIB as an object bag.



 |  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


Personally, I never liked the QRPGSRC, QRPGLE, QCLSRC, QDDSSRC, etc.
method.  Just one source file for all source types.  I then group related
items - like our APIs, others' APIs, and BagOTricks into individual source
files.

I think having a hierarchy of directories to search for source members might
be overkill.

JMO.


Tom