RE: calling commands in unknown (at compile time)

Might as well add my preferred technique for adding temporary libraries into 
the library list...

1. Retrieve and save ProductLibrary #2.
2. Retrieve ProductLibrary #1 and set it as ProductLibrary #2.
3. Set ProductLibrary #1 as the target library.
4. Perform action that needs the target library.
5. Retrieve ProductLibrary #2 and set it as ProductLibrary #1.
6. Set ProductLibrary #2 as the saved ProductLibrary value.

There are more steps listed than actually necessary since some steps can be 
done in combination. E.g., the 'retrieves' in steps 1 & 2 are done together 
with a retrieval of the library list that gets the 'product' libraries. And the 
'sets' in steps 2 & 3 are done together since both product libraries would be 
set at once. The Change Library List (QLICHGLL) API can be used to set product 
libraries.

The technique concept in general is to push product libraries one at a time 
onto the top of the two-element stack while saving those that get dropped off 
of the bottom end. The process should be reversed as functions are ended.

If a product library is already specified, it can usually be left in the list 
after moving it down a slot. This is mostly a courtesy to some function higher 
up the stack that's going to expect its library still to be there when things 
return that far.

Once you have your general procedures for 'pushing' and 'popping' the 
ProductLibrary stack, use them over and over again.

Tom Liotta

midrange-l-request@xxxxxxxxxxxx wrote:

  7. Re: calling commands in unknown (at compile time) (Jerry Adams)

May I add another caveat or two?

I've been through situations as described here.  The library (say, LIBA) 
may or may not, as Darrell said, exist in the library list.  If it does 
exist, it may occupy any position in the library list (1-n).  After 
deleting and adding it, though, it is blatantly in position numero uno.

This may not be a good thing later on.  If this is a batch job, it 
*probably* doesn't matter.  However, if it is an interactive job, it 
*may* be perilous.  If LIBA was already in the list (say, #7 on your hit 
parade), leaving it at #1 *could* skew later jobs.

The original library list needs to be saved and, after you're through 
with LIBA (as #1), restore the original library list so that things are 
back where everyone is expecting them.  Another way to do this for an 
interactive job is to simply issue the SIGNOFF command at the end of the 
job (if you can wait that long) since a new log in will set up the 
library list as intended. 

Darrell A Martin wrote:

This requires another step. First *remove* the "target" library from the 
job library list, MONMSG, *then* add it, in first position, MONMSG.

This avoids the trap of the target library already existing in the job 
library list. If an add to first position is attempted for a library 
already in the list, CPF2103 is issued and the library remains in the 
original position. If  that position is lower in the list than another 
library that contains a copy of the command or program, that incorrect 
copy will be executed.