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



Nothing wrong with disagreeing. Albeit I am not too sure of what expressed was actually in disagreement, except maybe the reasonableness of or complexity of, any design change. :-) I will however attempt to further persuade your viewpoint with some more comments.

Although the design could change, I posit the minor bit of confusion that the current design can effect is insufficient to justify [radical] change. A change would likely be even more significant in its potential for impact on both different utilities\products and user confusion for even more objects from utilities\products being presented in object lists from *LIBL. I contend that the expectation should be adjusted to align with the design as it stands, rather than to expect that the design could or should be changed to attempt to /resolve/ the issue.

Let us consider Query/400 as an example, instead of your utility. After starting Query/400, _what_ from the product library QQRYLIB would a _user_ want or need to access? The answer... Nothing. If a [utility or] product is using the PRDLIB() to effect enabling the user to access objects in that product library, my assertion is that having coded such a dependency is a _design flaw_ for that product. The user should almost exclusively, only ever expect to see what is in the USR portion of the *LIBL; i.e. *USRLIBL. The potential for objects from the product library being presented in lists for *LIBL is merely an unfortunate side effect. When the product uses adopted authority to access the objects from the product library, the *peon user would be unaware, for inability to see unauthorized objects in the list. The above details using an example, what I was trying to point out as a /design issue/ for the use of VMHLIB, whereby a user of the product was incorrectly expecting to find /product objects/ in their invocation of FNDSTRPDM.

"Having to use ADDLIBLE when you are working under the assumption that PRDLIB already did that FOR you - let the system do it, as you first said - seems counter to the purpose of PRDLIBs. So that is you use ANY other product's tools, you are at risk of losing touch with yours."

I am arguing that ADDLIBLE is the /correct tool for the job/ here. That /assumption/ is what I am implying is the origin of the problem. That assumption is in conflict with the concept of /product library/. The product library being transient, active only for the duration of the command [or menu], is not intended to provide general /user/ access to the named library. The intention is only to enable the /product/ access to the named library. When there is an /assumption/ that the library will be in *LIBL, from any perspective other than the run-time of the product, then that assumption is faulty. That is because when another product invocation occurs, that other product is then in control, and its own library then is available [to that other product which is now higher in the stack]. The product library should never be assumed to exist in *LIBL for any /user/ requests made from within the product. When the product library is in *LIBL, that does have the potential to confuse a user when they are able to /see/ [access or objects presented in lists from] the product library in *LIBL; e.g. when issuing a command that uses PRDLIB(*NOCHG) which presents either the Library List itself [but it shows PRD] or objects from the *LIBL. If the user or the product wants that the user have the capability to access objects from a library [product library included] outside of the product run-time, then the user or the product should be adding that library to the SYS or USR portion of the *LIBL, not to the PRD portion; i.e. use of ADDLIBLE.

So... any /user/ of a product should *not* expect to be able to access the objects in the product library. A user should only expect [with obvious exceptions being user-data libraries] to find non-system and non-product objects, that is, what is in the *USRLIBL.

Regards, Chuck

vhamberg@xxxxxxxxxxx wrote:
Methinks I might disagree with some of your thoughts, Chuck - the first time!! And I have not given this a tremendous amount of time.

As to search order, I have to believe that product libraries end up in some kind of stack - so the order could be inferred from that -
again, different products should probably - heh - not have the same
object names - but that is a dangerous assumption.

There are also 2 slots for product libraries in a job - not sure how that would apply, but it is something not generally known.

Having to used ADDLIBLE when you are working under the assumption that PRDLIB already did that FOR you - let the system do it, as you
first said - seems counter to the purpose of PRDLIBs. So that is you
use ANY other product's tools, you are at risk of losing touch with
yours.

You focused on my example of a PDM function - I think I had the same problem with some SQL stuff - where I thought I'd have my data files
in the LIBL but nope, the product library had been replaced.

This CAN be a design issue - product libraries should be used only when appropriate - we have several products, and sometimes one
product will use something in another product - the control of
library lists in this case is a slight challenge.

So I think that one must be very careful using product libraries - they do not always behave as you might expect.

Of course, I could easily be wrong!!

Thanks again Chuck!
Vern

CRPence wrote:

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