Re: LIBL limitation of 25 libraries -- MIDRANGE-L

Hello Dean,

Well, here is a perfect example of what Mike Crump was talking about when 
lamenting 3rd party vendors neglect 
of the product library component of the library list.  (Minor correction - the 
system manages two slots for 
active product libraries although each command or menu can specify only one.)

In your production example there are at least 4 libraries that could be removed 
if the utility developers 
made proper use of the product library.  FOCLIB, DBU41, EXTERMIN8, and HAWKEYE 
should all be added to the 
library list automatically by proper definition of their respective commands.  
Their installation programs 
should copy the primary commands to QSYS (just like the IBM installation 
process RSTLICPGM -- which more 
vendors should be using anyway).  Doing this means the commands are in 
everyone's list (secured 
appropriately) and the system manages the product library component 
automatically -- no stepping on anyone's 
toes.

It also avoids vendor products stealing space in the system portion of the 
library list simply to ensure 
their commands are available.

Your Development example is a little harder (although it would be helped 
considerably by proper use of the 
product library) but it does sound to me as if your development environment 
needs some rework -- but that 
requires a great deal more knowledge about your environment and also leads to 
"religous" discussions  about 
the appropriate use of development, test, and production environments.

Regards,
Simon Coulter.

//----------------------------------------------------------
// FlyByNight Software         AS/400 Technical Specialists
// Phone: +61 3 9419 0175      Mobile: +61 0411 091 400
// Fax:   +61 3 9419 0175      E-mail: shc@flybynight.com.au
// 
// Windoze should not be open at Warp speed.
//--- forwarded letter -------------------------------------------------------
> X-Mailer: AOL 3.0 16-bit for Windows sub 41
> Date: Sat, 28 Nov 98 05:05:21 -0500
> From: DAsmussen@aol.com
> To: MIDRANGE-L@midrange.com
> Reply-To: MIDRANGE-L@midrange.com
> Subject: Re: LIBL limitation of 25 libraries

> 
> 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

+---
| 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
+---