Re: Product library vs SBMJOB

[CRPence <CRPbottle@xxxxxxxxx>]

  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.