On 02-Dec-2014 09:05 -0600, Steinmetz, Paul wrote:
I'm re-evaluating my management of libl for some 3rd party products.
Currently, I have the products that are widely used in the QSYSLIBL.
That use of the System or User portions of the library list has
always been discouraged, irrespective the popularity of the deprecated
implementation; perhaps a carry-over from the S/38 where perhaps there
was no Product library support.? If there is a perceived /requirement/
for effecting that setup, in order to make the products functional, then
the products are probably at least somewhat poorly designed [with
respect to the PRD portion of Library List concept].
I recently had a RDB40 upgrade fail because it was calling INSTALLC
with 2 parameters, but found INSTALLC from DBU10 expecting 1
parameter. It took a week with Prodata support till the issue was
discovered, easy fix. Prodata is fixing their RDB40 install process.
The ten-byte naming often and quite legitimately is blamed. For lack
of a product-specific naming prefix for each specific object, the fully
qualified name [with library name included] generally suffices in place
of the actual name-prefix. Yet without an arbiter of naming, a naming
authority and all parties honoring that, a _potential for conflicts_
would always remain.
Using library-qualified invocations are much more acceptable [and
even often expected] for installation than for actual run-time. Of
course the dynamic nature in the run-time invocations is mostly about
the convenience of testing alternative code; entry into the product can
easily enough restrict the how dynamic their invocations will be.
Prodata support is suggesting using PRD lib.
That is what IBM does with Licensed Program Products (LPP) they ship.
Third party products generally do\should as well. If the library with
the conflicting object had been in QUSRLIBL instead of QSYSLIBL, then
their proper use of PRDLIB() would have prevented the conflict due to
the temporary override to the order of the User LIBL; of course
acknowledging that with the install-path vs a run-time-path the
scenarios are distinct.
I've had issues with this with AJS and BRMS, they both use PRD.
Anything specific to report? They might be defects, or possibly
exposing oversights or just plain poor-quality design.
IBM documentation states you can have up to 2 PRD libs, but haven't
seen that happen.
PDM uses two at least sometimes; e.g. within 2=Edit of a source
member from within the WRKMBRPDM. IIRC the *CMD object can only support
one, though does support a Current Library (CURLIB) override beyond just
the support to override the Product Library (PRDLIB); those parameter
keywords on Create Command (CRTCMD) and Change Command (CHGCMD).
The Change Library List (QLICHGLL) API provides the capability to
modify "the current library, the two product libraries, and the user
part of the current thread's library list."
<
http://www.ibm.com/support/knowledgecenter/ssw_ibm_i_71/apis/qlichgll.htm>
Anyone have success with using PRD lib for managing a product libl?
The IBM products seem to have little difficulty managing them; or at
least suggesting their LPPs have long been quite dependent on the PrdLib
might be an apt description.
I could add all these products to over 100 jobds, but I prefer not
going that route.
That would effect what would have been available via the QUSRLIBL
[not QSYSLIBL]; adding the library names via the Initial Library List
(INLLIBL) parameter of those JOBD is not the same as what adding those
libraries to QSYSLIBL had been providing. Moving the third party
product libraries further down the list is not generally helpful to
remove the potential for name collisions; the fact that the many
libraries are in the list and more importantly, possibly in an
undesirable [path] order, is the issue of concern. In conjunction with
PRDLIB(), those various other product libraries in the UsrLibl would not
present a problem, but that presumes all the products either [will] have
no conflicts or that they use PRDLIB() support already [or something
else] to prevent such name conflicts.
Ensuring each of the products functions according to one [or two]
specific Product Library List entry, irrespective the remaining portions
of the library list [system, user, current] is the ideal solution; i.e.
ensuring those libraries are *not* added, except when needed, and each
product adjust the PRDLIB according to its needs.
Has anyone found some new magic on managing the libl for multiple
3rd party products?
I would expect their commands already use Proxy commands [or still
use the old convention of a duplicate command object] copied into a
common library, or recommended or scripts to effect that; the /common/
library is unlikely to be the same for every customer. Products that do
not operate with commands, hopefully have an alternate approach that
limits the potential for a name conflict to as few possible objects as
possible; e.g. just one [service] program that, like the PRDLIB() of a
*CMD object, that establishes either a PRDLIB() or similar effect.
Lacking the scripts or the automatic effect from the install, those
customizations might be effected as part of system change management to
be reapplied with any maintenance to those products. But of course, the
possibility exists such that the product was not [properly] designed to
operate that way outside of what can be easily achieved with CHGCMD
PRDLIB(prd_lib_name) to their *CMD objects.
midrange.com
