Re: Product library vs SBMJOB

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

-------------- Original message --------------
From: 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