× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.