Re: LIBL limitation of 25 libraries

[DAsmussen@xxxxxxx]

Denis,

In a message dated 98-11-27 16:40:58 EST, you write:

> Swapping the library list could be made to work. But they are co-dependence
(
> The production system need access to the sales system for customer info...).
> The thing is i would need to establish all those dependencies and modify all
> programs to include the swap routines. This can work but i would much prefer
> adding more entry to the libary list. Less work, more simple code, less 
> maintenance when a new application is added... If there is extra processing 
> du to the library list, i would upgrade the AS/400 (cheaper than the
software 
> modification)

We have the exact same problem at my current site (and did at the last as
well), and it has to do primarily with the volume of vendor applications
installed and, sometimes, poor implementation by those vendors.  Not a problem
(yet) at the production level, but a _SERIOUS_ problem at the development
levels.  For example:

Production:
 1) QTEMP
 2) QGPL
 3) BPCSUSRF (User-modified files for BPCS)
 4) BPCSUSR (User-modified programs/objects for BPCS)
 5) BPCSPTF (Patched BPCS programs/objects from vendor) 
 6) BPCSO (Base BPCS programs from vendor)
 7) BPCSS (BPCS Source for creation of work files during MRP generation)
 8) BPCSF (BPCS base files as shipped)
 9) COMLIB (Common user-modified/created objects not specific to BPCS)
10) FOCLIB (Objects for execution of FOCUS query tool)
11) FOCSHR (Query definitions for shared FOCUS applications that won't be
blown away with a FOCUS upgrade)
12) DBU41 (Library for database tool)
13) EXTERMIN8 (Library for debugging tool)
14) HAWKEYE (Library for Xref tool)
15) INFPRD (Library for all interfaces to Tandem, ES/9K, DEC, and PC systems)
16) COSTPRD (Library for product costing programs)

Sixteen libraries isn't bad, until we move to the development box where we
have production, prototype, development, CMS, CASE tool, and developer
libraries.  The developer libraries are handled via CHGCURLIB, which doesn't
take a list entry.  None of these new libraries can be added to the system
portion of the library list, as an aborted install of any given product would
disallow anyone from signing on.  The development environment must also access
prototype, as new objects might be moved up the promotion chain that are
needed to access new file structures but are not yet in production.  Add to
the above list:

 1) User-modified files for development
 2) User-modified objects for development
 3) Base files for development
 4) Interface objects for development
 5) Cost objects for development
 6) User-modified files for prototype (UAT)
 7) User-modified objects for prototype (UAT)
 8) Base files for prototype (UAT)
 9) Interface objects for prototype
10) Cost objects for prototype
11) AS/Set object library ASSETO
12) AS/Set files library ASSETF
13) No less than 4, and up to 5 libraries added by the CMS tool based upon
environment

Heaven forbid we add any more 3rd party applications!  We already have to rip
stuff out of the development library list in order to properly test.  Yes,
cost and interface applications could be folded into other modified
applications, but we'd prefer to keep them seperate as they work outside of
both BPCS and each other.  Even ye olde DOS PATH and APPEND statements work
better than this!  WE NEED MORE LIBRARY LIST ENTRIES!!!

JMHO,

Dean Asmussen
Enterprise Systems Consulting, Inc.
Fuquay-Varina, NC  USA
E-Mail:  DAsmussen@aol.com

"If you hear a toilet flush followed by the words 'uh-oh', it's too late." --
Unknown Father of a Four-Year-Old
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---