× 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.



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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.