On Wed, 29 Jan 2014 13:38:46 -0500, Micheal Butz <[email protected]> wrote:
>Once you enter ISPF, however it is still part of the search chain for MVS/CSV >so I thought I could find >Where the program was found. > >Joblib/steplib/TSOLIB or link list That last list is a bit too simple. If you're looking at a task (TCB) that loaded a program, then you need to consider that TCB's tasklib (TCBJLB), and its parent TCB's tasklib (if any), and its parent TCB's tasklib (if any), ..., up to the first jobstep TCB you come to. The jobstep TCB's TCBJLB will point to the JOBLIB or STEPLIB, if any. Any lower-level TCB might have a TCBJLB that points to the same tasklib as its parent, or a different a tasklib, so you'll probably want to avoid checking the same DCB more than once as you move up the TCB chain. Tasklibs are setup in many places. It's not just TSOLIB or ISPLLIB. Yes, TSOLIB may setup one for the TMP to use when attaching programs. Also, if ISPLLIB is allocated when you enter ISPF then ISPF will set it up as a tasklib for the tasks it attaches (and the ones they attach, ...). But additionally, the TSO/E CALL command will setup a tasklib when it does an ATTACH, and ISPF may setup another one if a program running under ISPF does a LIBDEF for ISPLLIB (and that will be separate from the ISPLLIB DD statement) and then uses ISPEXEC SELECT CMD to run a command. (But if the program uses ISPEXEC SELECT PGM then the ISPLLIB LIBDEF will not be used as a tasklib.) Next, any program using ATTACH may setup another one for its new subtask. So there could be a lot of levels of TCBs, each with a TCBJLB, and each possibly representing a different library concatenation or the same concatenation as some other TCB above it. I don't recall that you've mentioned searching LPA yet, so don't forget about doing that, and in the proper order. Another issue will come, I think, from an ATTACH or a LOAD that specifies a DCB pointer. None of the TCBs will point to that, so you wouldn't know to look in that library concatenation. And ATTACH, for example, might load the first program from one library but specify a different one as the tasklib for any subsequent module loading the new task does. Finally, if authorized code is involved, then your code also needs to account for the fact that when authorized code tries to load a module the system may ignore a module in a non-authorized library if it can find one in an authorized library later in the library search order. So if the module was loaded by an authorized caller you may need to bypass some library concatenations when doing your search. (And yes, I do mean "may" in this paragraph. Sometimes unauthorized libraries will be ignored, and sometimes they won't, depending on the macro and the keywords used, but the details are more than I want to consider this late at night.) I don't think you've really explained the details of what you're trying to accomplish, but I have the feeling that the general case may be much more complicated than you think it is if you want to handle everything properly. -- Walt ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
