Re: Product library vs SBMJOB

[CRPence <CRPbottle@xxxxxxxxx>]

vhamberg@xxxxxxxxxxx wrote:
> Yes, indeed!
>
> FYI - I have a scenario where product libraries get rather messy
> and actually don't seem to work.
>
> I have a command or a menu that has PRDLIB(VMHLIB) in it. I run the
> FNDSTRPDM command over a file in VMHLIB but I use *LIBL. I get a
> message that the file is not found.
>
> My PRDLIB was replaced by QPDA, as set in FNDSTRPDM - so my library
> is no longer in the list - can't find my file.
>
> If there were to be a DCR, I'd lobby for letting the library that was
> pushed onto the PRDLIB stack (Chuck - excuse my loose terminology!)
> still be in the search path. The system knows it is there, because
> when the command is done, then that PRDLIB is back.

  I agree that the transient nature of the library in the PRD portion 
of the library list can be origin for some confusing results.  I expect 
that the given case has its origin moreso from a design issue.

  IMO adding each stacked product library as a new entry in the PRD 
portion of the *LIBL is way too complicated for any legitimate payback. 
 One obvious difficulty is deciding on ordering and duplication issues; 
the current *LIBL concept disallows duplicates, but managing adding them 
properly [without much complexity] to allow *LIBL searches, that would 
almost be a requirement.  Besides, that idea goes against the original 
concept of the Product Library.  The PRDLIB() feature was at least in 
part created as a way to eliminate library list growth, and why the 
product library is active only for the duration of the command or menu 
that activates the product.  FWiW that can be inferred from the doc 
reference to the S/38, where it shows how for example that in the past 
ADDLIBLE QRPG might have to be done just to get stuff to work; often the 
result was systems where INLLIBL was setup from job start with a dozen 
or more libraries that the user may or may not even use in the day.

  The product library is for the /use by the product/ to find its own 
objects, not for /use by a user/ for finding objects owned by the 
product.  If the user wants to be able to search the product's library 
[atypical] then they could just add the library to the USR portion of 
the list.  That a request with PRDLIB(VMHLIB) can access stuff from 
VMHLIB when performing another command or menu with PRDLIB(*NOCHG) is 
IMO best left as something to be understood by the developer of the 
product; i.e. a side effect.  However the case where the user actually 
needs or wants to find an object in a product library should be rare. 
When such a need exists, the PRDLIB() is not a good way to make it 
happen, because the product library is placed into the PRD portion of 
the library list using a LIFO /stack/ implementation, where the 
currently active product utilizing the named product library is the only 
product library visible in *LIBL [there is a two-library concept, but 
AFaIK it is limited to IBM use only].  Most likely such a perceived need 
is a sign that the product was built outside the norm for i5/OS; e.g. 
user data is in a product library [e.g. VMHLIB], instead of in QUSRSYS 
[or e.g. VMHDTALIB].

Regards, Chuck