Re: Product library vs SBMJOB

Vern,

I think that it would be nice if the product library concept (e.g. adding a library or libraries to the *LIBL temporarily) would extend to the user portion of the *LIBL. Something like:
ADDLIBLE TMPLIB *LAST TYPE(*USERTEMP) SCOPE(*ACTGRP).

That would eliminate much of the *LIBL machinations when crating a commercial product that needs to integrate into another application.

-mark


At 7/13/08 10:23 AM, you wrote:

Chuck

We have basically come to a similar conclusion - forego the convenience to the user of running a qualified command or menu and getting the product library from that. This is instead of the traditional way of using ADDLIBLE and then running the command or menu.

At least in some cases. Again, we have some things where customers can write exits. Use of the product library can result in some surprises, as customers don't usually think in terms of that setting.

As for the 2 slots, I don't think those are part of the LIFO stack - they would both be put on that stack if you used another command with a PRDLIB. I guess I was thinking that the search path could include all the libraries on the stack, as well as the things you see. But this could very well make a mess - as in extremely unexpected results - and you'd not know, unless IBM publishes the stack contents - what was in the path.

So I relent!! Was just dreaming, I think - now on to a VB cash register app for a state fair concession.

Vern

-------------- Original message --------------
From: CRPence <CRPbottle@xxxxxxxxx>

> Comments inline.
>
> vhamberg wrote:
> >
> > CRPence wrote:
> >>
> >> 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.
> >
> > Thanks for the reply - here's the bit that seems a little
> > self-contradictory to me - in your first reply you said that the
> > intent of using a PRDLIB was so you did NOT have to ADDLIBLE to get
> > at things in your own library, that of your product.
>
> Yes. The PRDLIB provides an easy alternative to the utility, from
> having to perform ADDLIBLE & RMVLIBLE to manage its own library list,
> just to enable its runtime to /see/ its objects; easy because it is
> system controlled, when specified on the *CMD or *MENU. Of course as
> with any available feature, the /product library/ support has its limits
> and caveats.
>
> > Am I mixing apples and oranges here? You suggest that there is no
> > reason an application would want to run a system command against its
> > own resources - that did not make sense to me.
>
> I was suggesting instead, that "there is no reason" a *user* of the
> application "would want to run a system command against" the resources
> of the product. From the text "I run the FNDSTRPDM command", I had
> inferred /I/ was /the user/, not the application. Sorry. My slanted
> application programming view has the hardened rule, that a product does
> not invoke an optionally installed product. With that, I was a bit
> /thick/, disallowing the thought that the request was being made by
> anything other than a /user/ of the product.
>
> So having just written that, along with Simon's reply and the last
> sentence of your post ["issues with side effects in my own coding"], I
> think I finally recognize [or now infer] what I had missed before. That
> is, in your scenario... It is the *application* that is making the
> FNDSTRPDM request, rather than the *user* making that request from
> within the product.? If so, then the post by Simon alludes to and even
> explains, a bit of the complexity of the Product Library feature that I
> had purposely omitted. I did not realize those nuances of PRDLIB() had
> any relevance in the described scenario, because I was trying merely to
> portray the following perspectives:
>
> First, from the _perspective_ of the /programmer/ of the product.
> The PRDLIB feature enables the /runtime/ of the _product or utility_ to
> have access to a named library, automatically via its *CMD or *MENU,
> without having to code an ADDLIBLE into the product. That means while
> the product is the currently active stack entry, because the PRDLIB()
> feature has since automatically added the named library to the *LIBL,
> requests by that product runtime to perform actions like CALL and OPEN,
> will be able to find the objects critical to its runtime.
>
> Second, from the _perspective_ of the /user/ of the product. The
> /user/ of the product should have no need for nor knowledge of, the
> Product Library. Thus the user should have no expectation of what the
> PRDLIB() support can provide for their utilization of the Library List.
>
> So.... Given _my new understanding of your scenario_ has since been
> clarified, I will suggest that you have found the /exception/ case [or
> one of; I had thought it was Office, not ADT, that used both Product
> Library slots]. Because you are using another /product/ within your
> /product/, where *both* take advantage of the /Product Library/ feature,
> you may experience that difficulty. I had actually been implying that
> the failure in that scenario would *always* occur, to _emphasize_ that
> the programmer should _not assume_ that the product library is there for
> anything but typical run-time like CALL and OPEN; i.e. not for command
> nor for menu invocations. I was implying that the invocation of another
> product which was also using PRDLIB(), would _unconditionally_ replace
> your own product library, thus preventing that _new invocation_ from
> seeing your specified product library in *LIBL. Although safest to
> infer that will be the effect, what actually occurs is more complicated
> than that. Again, see Simon's 10-Jul post.
>
> > I guess I'm thinking that the system DOES know what product
> > libraries have been used - you mentioned an LIFO stack - that's
> > what I assumed was the mechanism. One could always put a limit on
> > the number of stack entries. So it is not Impossible to know what
> > those are, hence, they COULD be included in the search path.
> > Now what are the side effects?
>
> The current limit is two. Again, I really do not believe trying to
> extend that feature would have much value. And worse, if it were
> extended, that its use would allow for even more confusion for the
> programmer and user than it can already. Just imagine the results from
> an interactive job doing nothing but GO MENUxxx to navigate, possibly
> navigating through some of the same list of menus.
>
> > Hey, I'm fighting my own issues
> > with side effects in my own coding now!!! ;-)
>
> For the given case, you could ADDLIBLE just before the FNDSTRPDM, and
> RMVLIBLE just after. Or forgo use of PRDLIB() entirely for your own
> utility, coding that application to control the USR portion of the
> library list.
>
> Regards, Chuck