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



This was already sufficiently responded to. My response now, is mostly just to add more search keywords for the archive and some doc references.

The PRDLIB [Product Library] concept was established to enable a product to easily effect the required *LIBL necessary for the product to function from [and for the duration of] its command or menu. Rather than coding within the product itself to manage the library list by ADDLIBLE [& RMVLIBLE], the programmer can get that /free/ from the OS, by specifying the library on the PRDLIB parameter on the CRTCMD or CRTMNU [and associated CHGCMD or CHGMNU]. When a new invocation is made to utility-2 from the currently active utility-1, a new product library can be established specific for that invocation of utility-2, and that product library is reset upon return to utility-1. Having provided this feature, also resolved a problem whereby many utilities would /add/ but never remove their library from the list; even if only failing to do so in canceled requests, due to lack of a cancel handler, where again it was now /free/ from the command or menu.

The product library concept is to have the library available in the list, only for the duration of that invocation of the product. If a product needs to establish its product library, it can & probably should do so in the *CMD and *MENU objects that activate the product. A product could do so also [or similarly, by user versus product library list entries] via the Change Library List (QLICHGLL) API when there are alternate activations of the product [i.e. besides using the Command or Menu objects] to ensure the library list assumptions are met. However the whole concept is nullified in so doing, because it is then the application rather than the OS via PRDLIB() that is doing the work to manage the library list.

The following document has some supporting details of the above, about /product library/, although worded with respect to S/38 environment:
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/books/sc413735.pdf

Also this corrected link [the link found by google was broken] has more supporting details about product libraries. A reader comment card could be submitted, requesting to have this topic updated to clarify that /product libraries/ are not carried into a submitted job via INLLIBL(*CURRENT); similarly for the SBMJOB command documentation:
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rbam6/ulibl.htm

Although the SBMJOB carries the non-product [user & system] libraries for a request to keep the [*CURRENT] library list of the requesting job as the initial library list for the submitted job, the product libraries are not carried over, because the function that will run in the batch job is expected to have its own product libraries if\when the submitted request utilizes that feature. Although the SBMJOB /could/ carry the product libraries portion of the *LIBL into the new job as part of INLLIBL(*CURRENT), doing so would not only be a change to the default behavior, but also rarely of any value except when the application is coded, or the user is making, incorrect assumptions about what *CURRENT does. To make such a change happen, a new special value would best be created [e.g. *CURRPROD; to suggest *CURRENT + PRD libs], and then it would need to be specified; if the OS or any particular system made the choice to make that [behavior or] new value the default, there could be some incidents of unexpected results.

Adding reference to another snippet of product library discussion:
http://archive.midrange.com/midrange-l/200801/msg01135.html

Regards, Chuck

rob@xxxxxxxxx wrote:
When you do a SBMJOB INLLIBL(*CURRENT) it will not include any
"product" libraries. For example, if you do a STRPDM and then
do a DSPLIBL (not EDTLIBL!!!) you will also see:

Library Type
...
QPDA PRD ...

Now, if you do SBMJOB CMD(DSPLIBL OUTPUT(*PRINT)) INLLIBL(*CURRENT)
the output will not include QPDA.

On one of our machines I ran this command (V5R4 and above only):
CRTPRXCMD CMD(QGPL/STRIM) TGTCMD(MKSIM/STRIM)
The vendor's STRIM command added MKSIM to the library list as a
production command (see also CHGCMD CMD(xxx) PRDLIB(MKSIM) )

However if a developer submits certain vendor options it doesn't
get the library list right because it uses *CURRENT and product
libraries do not carry over to the submitted job.

I can get by this. Just wondering what the general consensus is
about this. In other words, should SBMJOB carry over the product
library? Should I DCR this? Maybe I should report this to my
software vendor exactly where the error occured. Maybe they missed
adding a product library to a particular command.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.