Re: Product libraries in the library list

Joep,

As I have not had a reason to really look at product libraries in the past,
and I found your question to be quite interesting, I "cheated" and
contacted a developer who has been pretty much in charge of LI (Librarian)
for going on thirty years.

The product libraries, as you might expect, are intended for the use of
software providers.

The first product library is managed by command analyzer/librarian as the
result of a command being executed which had a "PRDLIB" value specified
for it. In this situation, the command analyzer would retrieve and save
(if present) the name of the library currently in the PRDLIB slot, replace
the current PRDLIB with the one specified via the new command attribute,
then transfer control to the CPP. When the CPP returned, command analyzer
updates the PRDLIB slot in the library list to the name of the previous
"PRDLIB" library.

The second product library is used by various software offerings such as
SEU to add the library of the source syntax checker, RPG when compiling to
a previous release, etc.

An example would be editing a source member of type "RPG" in PDM. Pressing
F21 (F21=System command) and DSPLIBL to look at the library list shows two
product libraries (QPDA and QDEVTOOLS)
ASP

Opt Library Type Device Text

QSYS SYS System Library

QSYS2 SYS System Library for CPI's

QHLPSYS SYS

QUSRSYS SYS System Library for Users

QPDA PRD

QDEVTOOLS PRD

QGPL USR General Purpose Library



Library QDEVTOOLS is part of product 5770WDS (IBM Rational Development
Studio for i )

A 2nd product library is also added to the library list when compiling and
using the "previous" level of the compiler on the TGTRLS parm. When
compiling a RPG pgm to a previous VRM you'll find these libraries in the
library list:
ASP
Opt Library Type Device Text
QSYS SYS System Library
QSYS2 SYS System Library for CPI's
QHLPSYS SYS
QUSRSYS SYS System Library for Users
QDEVTOOLS PRD
QRPG PRD
QGPL USR General Purpose Library
QTEMP USR

Recollection is that the 2nd product library was added primarily for
compilers and development tools. Off hand Rochester doesn't know of any
other uses of that slot in the library list. (Insert by Bruce -- BUT as
the 2nd product library is available with the API there could be MANY users
that IBM would not need to know about. That's why APIs are published
though they may seem a bit odd in terms of why would someone use this --
the reason is there's "someone" who needed it and asked for it, in this
case Toronto... -- end of insert by Bruce). When the QLICHGLL API was
introduced, it provided the same support as some of our internal
interfaces. (Insert by Bruce -- Many, many years ago there were internal
(not generally published) interfaces across various product offerings.
This practice was stopped and APIs were introduced (or in some cases
commands) to provide the same level of access across products (like the i
operating system to/from other IBM/non-IBM products) with exit points,
callable APIs, etc. -- end of insert by Bruce). Previous users of
internal interfaces then moved to the formal API/exit/whatever.

Hope this helps and it sounds like you may have found a use for the API,
Bruce

On Tue, Feb 18, 2020 at 5:21 AM Joep Beckeringh via MIDRANGE-L <
midrange-l@xxxxxxxxxxxxxxxxxx> wrote:

I meant:

Next I used QLICHGLL to specify two product libraries. When I run the
commands the same thing happens as before, but product library 2 remains
what I set in QLICHGLL.

Joep Beckeringh


Op 18-2-2020 om 10:23 schreef Joep Beckeringh via MIDRANGE-L:

Hi Mark,

Thanks for your assistance.

What I found is that product library 1 acts like current library; i.e.
when a command has PRDLIB specified, product library 1 is set to the
specified library and reset to its previous value when the command
finishes.

To be sure, I just tested with two commands, each with its own product
library specified:

First I started with a library list with no product libraries:
- Run command A; product library 1 is set to command A's product library
- Run command B: product library 1 is set to command B's product library
- Finish command B: product library 1 is rest to command A's product
library
- Finish command A: product library is removed from library list

Next I used QLICHGLL to specify two product libraries. When I run the
commands the same thing happens as before, but product library remains
what I set in QLICHGLL.

As it is, this appears to be quite useful for us, because we have a
situation where we want a program library present in the library list,
undependent of the user library list. And because we might have a
development version of that program library, being able to set two
product libraries seems to fit what we need. I just wonder why it was
designed this way and why I can find so little documentation of it.

Joep Beckeringh


Op 17-2-2020 om 16:36 schreef Mark Waterbury:

Joep,

IIRC, I think the concept was that if you always only use the PRDLIB
of a *CMD to add a product library to the "product library" portion
of the *LIBL, then it behaves like a (limited) "stack." So, the
first command puts a library on the PRDLIB part of the *LIBL, and
then, if a second "nested" command uses a PRDLIB, it puts its library
onto the *LIBL, temporarily replacing the first PRDLIB. Then, when
the second nested command exits, it restores PRDLIB, leaving the
first PRDLIB in the first position, so that when control returns to
the calling command processing program (CPP), it still has its own
PRDLIB.

I think the QLICHGLL API is the only way to get two libraries in the
PRDLIB slots, and in that case, you are responsible for restoring
them upon exit.


NOTE: I have not tested all possible permutations and combinations.

Hope that helps,


Mark S. Waterbury

On Monday, February 17, 2020, 8:14:16 AM EST, Joep Beckeringh
via MIDRANGE-L <midrange-l@xxxxxxxxxxxxxxxxxx> wrote:
Hi all,

According to the documentation of QUSRJOBI and QLICHGLL there can be two
product libraries and one current library in the library list.

The current library can be changed by
- using command CHGLIBL or
- using command CHGCURLIB or
- using API QLICHGLL or
- using a command that has CURLIB specified.

But the only ways I have found to change the product libraries are
- using API QLICHGLL or
- using a command that has PRDLIB specified.

The funny thing is that by using QLICHGLL you can specify two product
libraries, but when defining or changing a command you can only specify
THE product library. I found out that THE product library is actually
product library 1. If I use QLICHGLL to set two product libraries and
after that I use a command with PRDLIB(*NONE) only product library 1 is
removed; product library 2 remains set. If after that I use another
command with PRDLIB(*NONE) product library remains set.

Does anybody know why there are two product libraries in the library
list and why a command can only affect the first?

Joep Beckeringh
Software Architect
Pantheon Automatisering B.V.
Heerenveen

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com