Re: Product library vs SBMJOB

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