× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.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 on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.