MIDRANGE dot COM Mailing List Archive


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

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

Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2015 by MIDRANGE dot 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 here. If you have questions about this, please contact