Re: LIBL limitation of 25 libraries

Hello Paul,

Well, your attitude is a little strange.  You don't want the vendor installing 
"stuff" into QSYS but _you're_ 
quite happy doing it?  Hmm ....

"Properly" is using the system the way it was designed -- not inventing your 
own processes.  A vendor utility 
library added to the library list was fine for the S/38 but is no longer 
appropriate for the AS/400.

There is nothing wrong with a 3rd party product putting objects in QSYS or any 
other library (QUSRSYS for 
instance - since the name stands for USER-SYSTEM) provided they don't get 
carried away.  They should only be 
putting commands in QSYS (and, of course, objects whose type requires them to 
be in QSYS).  They may put 
configuration data in QUSRSYS although I would prefer they kept that in their 
product library -- makes 
SAV/RST easier.  There is the possible risk that their command names may 
eventually conflict with IBM 
commands but that can be handled with a suitable naming convention (and there 
is always the risk that vendor 
commands names may be used by IBM for their own products).

Here is what they should be doing (in my not so humble opinion).  They have two 
methods:

1) Use the LODRUN function to install their product.  The installation program 
creates any required objects, 
restores 1 or more libraries containing their objects.  The final act is to 
copy any commands into QSYS.

2) Use the RSTLICPGM function to install their product.  This is more complex 
than LODRUN because they need 
to create PRDDFN and PRDLOD objects and exit programs to manage the 
installation.  It is better because the 
standard program product installation is used (which is already understood 
because it is used to install all 
the IBM products).  The exit programs handle creating any required objects and 
finally copy the commands to 
QSYS.

In both cases they should be creating a user profile to own their product 
objects (not QSECOFR, QPGMR, or any 
other IBM profile -- especially not QDFTOWN)).  Usual security guidelines apply 
to this profile -- no 
password, etc.

In both cases I dislike configuration information being specified during 
installation.  Installation should 
attempt to use sensible defaults so the product will at least work after it has 
been installed.  There should 
always be a separate configuration command to be run after installation (if 
neccesary) and whenever the 
customer needs to make changes.

Option 1 is useful for simple products which involve little more than restoring 
a library to install.

Option 2 is for more functional products although it does require the vendor to 
purchase SystemView (or 
whatever it is called now) to build the product but the customer does not need 
to buy this (and most vendors 
can get the software effectively free of charge anyway).

There is no need for you to feel any more nervous about vendor products than 
IBM's products.  If you do have 
reason to be nervous perhaps you shouldn't be buying products from that vendor?

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 -------------------------------------------------------
> Date: Thu, 03 Dec 98 20:01:42 -0500
> From: "PaulMmn" <PaulMmn@ix.netcom.com>
> To: MIDRANGE-L@midrange.com
> Reply-To: MIDRANGE-L@midrange.com
> Subject: Re: LIBL limitation of 25 libraries

> 
> Please define properly:  I don't like the idea of 3rd party products
> stuffing parts of themselves into the QSYS library.  Just makes me nervous.
> (:  I'll keep our utility libraries.
> 
> --Paul E Musselman
> PaulMmn@ix.netcom.com
> 
> >Hello Paul,
> >
> >Yes, I do that too.  The point is though, I SHOULDN'T HAVE TO.  The
> >vendors should do it properly!
> >
> >Regards,
> >Simon Coulter.
> 
> >>
> >> We solved this particular issue:  We have our set of Utility Libraries
> >> (present in USRLIBL system value and (almost) all library lists in JOBDs,
> >> etc.).  And we copied the DBU command to our library, making the DBU41
> >> library the Product Library.  Problem solved!
> >>
> >> -- Paul E Musselman

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