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
midrange.com
