Does REXX contain a means to set an alternate load Library?

[MNMan]

Can someone give me direction to resolve an issue involving REXX code initiated from ISPF. The problem I am having is during the execution of the REXX program I am calling an Assembler module(that resides in the systems LINKLIST) which in turn calls a module that resides in a library that is not found in the standard search libraries. The implicit call to the assembler program goes fine until it has to find(LOAD) the module residing in the vendor/private load library. If I call the REXX program using batch JCL and specify the vendor library as the STEPLIB then everything is OK - the assembler program can find the vendor module via the STEPLIB DD statement. However, this REXX code is initated via ISPF option 6 so I assume the 'steplib' needs to be set from within the REXX code. Does anyone have any idea as to how this can be resolved?

Thank you.
MNMan

 

[TonyJollans]

Hi MNMan,

If the program is part of a package, it may need to be in a particular DD concatenation. Before worrying about that it's worth trying to see if it works with a LIBDEF ISPLLIB definition.

Enjoy,
Tony

--------------------------------------------------------------------------------------------
We want to help you; help us to do it by reading this: Before you ask a question.

 

[MNMan]

Thanks for the response Tony! I had tried LIBDEF in the format of ....

ADDRESS ISPEXEC "LIBDEF ISPLLIB DATASET ID('"LOADLIB"')"
ADDRESS ISPEXEC "SELECT PGM(PULVR)"

... where "LOADLIB" was a REXX variable defined as the DS Name to the Vendor/private library. However, this did not work either - maybe I have a parameter error of sorts or missing something else.

I am not following your first suggestion. If you are suggesting to include the vendor library in the systems linklist, that would probably work. However, our systems people are rather reluctant to include another libary in the linklist concatenation.

Any other Ideas?

 

[TonyJollans]

Hi MNMan,

My problem here is that I no longer work on a mainframe so am doing this from memory and could say something completely wrong. Given that caveat, can you reallocate the STEPLIB to your TSO session to include the vendor library - if you can do it manually (TSO ALLOC REUSE or whatever the syntax is) I can sort you out some code later (but will be away for a couple of days). If you can't do that I best defer to someone whose knowledge is more current.

Enjoy,
Tony

--------------------------------------------------------------------------------------------
We want to help you; help us to do it by reading this: Before you ask a question.

 

[rexxhead]

STEPLIB is a protected name. You may be able to FREE it, but you will not be able to ALLOC. TSO provides the TSOLIB facility for adding loadlibs to the search order: "The TSOLIB command provides for an additional search level that TSO/E uses when searching for commands and programs. With TSOLIB, you specify load module libraries containing executable commands and programs, which are put to the top of the standard search order."

Frank Clarke
Tampa Area REXX Programmers' Alliance
REXX Language Assn Listmaster

 

[MNMan]

Tony,
I could manually allocate the steplib in TSO and that would work for me. However, this REXX is part of an ISPF initiated application that has hundreds of users. So that is not a viable option.

Thanks again.
MNMan

 

[MNMan]

REXXHEAD,
Thanks for the TSOLIB suggestion! It appeared that TSOLIB was the answer until I read the documentation in 'z/OS V1R4.0 TSO/E Command Reference' stating "If the TSOLIB command is issued from any other environment, like ISPF or REXX, only the TSOLIB command with its DISPLAY operand is valid. The TSOLIB command must be issued from a "TSO/E READY" environment." I tried the TSOLIB command anyway in my REXX code and recieved the following error:
IDY00046I TSOLIB terminated. A valid TSOLIB environment does not exist.
IDY00046I The TSOLIB command with the ACTIVATE, DEACTIVATE or RESET operands must be invoked from the TSO/E READY environment.

Any other ideas?

Thank you.
MNMan

 

[KiwiREXXDude]

I have found that you often can't re-allocate or free STEPLIB in foreground, so maybe you could try running it in batch? Can't you also do a "CALL 'my.data.set(pgm)'"? Can't remember...

 

[MNMan]

KiwiREXXDude,
Certainly STEPLIB would work if I was able to run this REXX in Batch. However, this application must be initiated under ISPF Option 6 since there is a potential of 3000 different end-users. Also it would work to make an explicit call to the Assembler program, if it resided in the same libary as the utility it must call. However, the assembler pgm will reside in a system's linklist library which then calls another utility that resides basically in 'my.data.set'.

Still looking for ideas.

Thanks.
MNMan

 

[KiwiREXXDude]

You do know that ISPF option 6 is only a command prompt? Also that you can easily run ISPF in batch using allocates and an ISPSTART CMD(...)?

 

[kevinf2349]

When you say 'calls' do you mean via an assembler CALL macro? If so then an assmebler CALL links the CALLED module into the original so you shouldn't need the individual CALLED program in a link library as such. Why can't you simply copy the module into a library that is in the STEPLIB for TSO....or better yet...into a LNKLST library? In fact if this is a facility that 3000 people are going to use I think I could make a pretty darn good arguement that it should even be in LPA...but that will have even more stringent requirements.

It seems strange to me that you company requires this for 3000 people and yet they need it to be set up in such a unusual and frankly non-standard way. My advice would be to keep it simple.

 

[MarcLodge]

MNMan,
I think that modules/programs called from TSO must be in the STEPLIB or associated LPA or LNKLIST ddnames. ISPF adds a further ddname to these, namely ISPLLIB. Your allocation of this library should have told any subsequent program to go searching there when looking for sub programs. If you have coded this correctly (and it looks like you have) and the assembler call does not work, then I can only assume that assmebler does not recognise the fact that it is running under the control of the sub envirnomnet (ISPF)and only looks in STEPLIB (or LPA or LNKLIST). The fact that you can run this in batch, with the library allocatated to STEPLIB, and it works, tends to lead me down this path.

In order to test this theory out, try to get the module that the vendor's assembler routine is calling, onto one of the libraries allocated to your TSO STEPLIB or LPA/LNKLIST. This might be a bit tricky as these are often protected, and you may have to talk to a friendly systems programmer.

Hope this helps a little.
Marc

 

[StefanGerman]

Hi MNMan,

as rexxhead stated correctly, you can't reallocate STEPLIB within a running TSO. TSO itself has to be considered as a batch job. But in many shops there are additional products for these purposes. My client uses CA-TSOPLUS (see

http://www.cai.com/products/announcements/tsoplus.htm)

which allows to add further libraries to the DD-Name STEPLIBX, which is dynamically searched by the system routines.

Hope this helps.

Stefan

 

[stevexff]

MNMan

Your sysprogs may be reluctant to put vendor libraries in the linklist, but they might be amenable to concatenating them to the STEPLIB in your TSO procedure. Failing that, many sites have an initial CLIST that runs when each TSO session is started. Usually this just starts ISPF, but you might be able to get them to put the TSOLIB command in there for you, before ISPF gets started. Note that this is a CLIST, not a REXX - you should be able to issue the TSOLIB from the CLIST.