|
View previous topic :: View next topic
|
| Author |
Message |
Captain Paralytic
Warnings : 1
New User
Joined: 21 Apr 2010
Posts: 40
Location: UK
|
|
|
|
This is quite a deep situation so I hope I manage to explain it correctly.
I have a COBOL program which normally runs in batch under JCL. Let's call it MAINPROG.
Now MAINPROG calls a dynamic subroutine RNCAL which in turns calls the dynamic subroutine POSTB.
MAINPROG also calls POSTB directly.
In the JCL the STEPLIB contains the library PRDQ.B.LOADLIB which contains MAINPROG and it also contains PROD.B.LOADLIB which contains RNCAL and POSTB.
In my REXX program, I allocate all the files required by MAINPROG, POSTB & RNCAL and then call MAINPROG thus:
"CALL 'PRDQ.B.LOADLIB(MAINPROG)'"
This fails because it cannot find RNCAL and POSTB, which I would expect.
If I copy RNCAL and POSTB to a library that is already in my ISPLLIB concatenation, all is well.
However, what I would rather do is to temporarily add the PROD.B.LOADLIB library to my ISPLLIB so that I always pick up the current versions of POSTB & RNCAL.
My reading of the subject seems to suggest that invoking:
address ISPEXEC "LIBDEF ISPLLIB EXCLDATA ID('PROD.B.LOADLIB')"
should achieve what I require, but MAINPROG still complains that it cannot find the dynamic subroutines.
I know that the LIBDEF call is doing something because if I change it to:
address ISPEXEC "LIBDEF ISPLLIB EXCLDATA ID('PRDQ.B.LOADLIB','PROD.B.LOADLIB')"
then I can change the call to:
CALL MAINPROG
and MAINPROG is found, but the execution still fails to fine the subroutines.
Does anyone here have any idea as to what magic words I need to chant to achieve my aim?
TIA |
|
| Back to top |
|
 |
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
IIRC
the ISPLLIB ddname is allocated as a TASKLIB at ISPF startup
so a <system> BLDL/LOAD/LINK will find the <called> thing at any time
for the subsequent LIBDEFS an ISPxxxxx DDNAME is allocated and ISPF will issue a <directed> BLDL/LOAD/LINK,
( ISPF keeps track of the LIBDEF stack, so it knows the sequence of DDNAMES to use )
but that is done ONLY for modules called thru ISPF services.
try to split the screen an issue a TSO ISRDDN
as I said IIRC, but it much agrees with what You see |
|
| Back to top |
|
|
don.leahy
Active Member
Joined: 06 Jul 2010
Posts: 765
Location: Whitby, ON, Canada
|
|
|
|
| Have you tried ISPEXEC "SELECT PGM(MAINPROG)" ? |
|
| Back to top |
|
|
Captain Paralytic
Warnings : 1
New User
Joined: 21 Apr 2010
Posts: 40
Location: UK
|
|
|
|
| don.leahy wrote: |
| Have you tried ISPEXEC "SELECT PGM(MAINPROG)" ? |
Yes I had tried that, but hadn't mentioned it in this post. Somewhere I had read something that "seemed" to suggest that the LIBDEF only affected programs called by the SELECT statement, but this was belied by the fact that both a TSO and a REXX call would happily invoke the main program from a LIBDEFed library, just not the dynamic subroutines.
Anyway the result of using ISPEXEC "SELECT PGM(MAINPROG)", is the same failure as before:
CEE3501S The module POSTB was not found.
plus the ISPF processor crashing. |
|
| Back to top |
|
|
Captain Paralytic
Warnings : 1
New User
Joined: 21 Apr 2010
Posts: 40
Location: UK
|
|
|
|
| enrico-sorichetti wrote: |
IIRC
for the subsequent LIBDEFS an ISPxxxxx DDNAME is allocated and ISPF will issue a <directed> BLDL/LOAD/LINK,
( ISPF keeps track of the LIBDEF stack, so it knows the sequence of DDNAMES to use )
but that is done ONLY for modules called thru ISPF services.
|
The calling of the main module seems to work even when I do
adddress TSO CALL ....
so I guess this is still considered to be under ISPF services?
| enrico-sorichetti wrote: |
try to split the screen an issue a TSO ISRDDN |
Well I tend to use DDLIST (which is the ISPF command to invoke ISRDDN), but I'm not sure what you are expecting me to see, nor why splitting the screen before issuing it is relevant?
I never see LIBDEFed libraries in DDLIST. |
|
| Back to top |
|
|
Captain Paralytic
Warnings : 1
New User
Joined: 21 Apr 2010
Posts: 40
Location: UK
|
|
|
|
| Interestingly, the table of search sequence in the ISPF Services Guide (SC34-4819) suggests that coding EXCLDATA instead of DATASET in the LIBDEF command, prevents the existing ISPLLIB from being searched, even though in practice it obviously is. |
|
| Back to top |
|
|
don.leahy
Active Member
Joined: 06 Jul 2010
Posts: 765
Location: Whitby, ON, Canada
|
|
|
|
| Captain Paralytic wrote: |
I never see LIBDEFed libraries in DDLIST. |
Are you sure about that? They should be visible under a generated ddname (i.e. they are not listed under ISPLLIB)
When you tried SELECT PGM(MAINPROG), what was LIBDEF'd to your ISPLLIB? |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
| Quote: |
| but I'm not sure what you are expecting me to see, |
to understand under what ddname the LIBDEFFED dataset is allocated
| Quote: |
| nor why splitting the screen before issuing it is relevant? |
it is relevant to see the allocation during the execution of the <mother> dialog
You might be able to do it from the <current> screen only at the end of the dialog, when the libdefs have been cleared
| Quote: |
I never see LIBDEFed libraries in DDLIST. |
You might have issued the ddlist command only at the end of the dialog, when the libdefs have been cleared |
|
| Back to top |
|
|
Pedro
Global Moderator
Joined: 01 Sep 2006
Posts: 2547
Location: Silicon Valley
|
|
|
|
Try using CMD instead of PGM. Yes, there is a difference.
| Code: |
| SELECT CMD(MAINPROG) |
Differences:
1. The parameter list to MAINPROG is different. You might be able to ignore in MAINPROG if you do not do anything with the parameter list.
2. From ISPF Services manual:
"The command processor (a program coded to support a unique argument list format) can then use MVS contents supervision macros such as ATTACH, LINK, LOAD, or XCTL. This is because ISPF attaches MYCMD as a subtask to ISPF. The load library, defined using LIBDEF ISPLLIB, is passed as a task library to the subtask."
I assume COBOL uses LINK, LOAD, or ATTACH. |
|
| Back to top |
|
|
Pedro
Global Moderator
Joined: 01 Sep 2006
Posts: 2547
Location: Silicon Valley
|
|
|
|
I did not notice this at first reading:
| Quote: |
In the JCL the STEPLIB contains the library PRDQ.B.LOADLIB which contains MAINPROG and it also contains PROD.B.LOADLIB which contains RNCAL and POSTB.
...
This fails because it cannot find RNCAL and POSTB, which I would expect. |
I would have expected the members to be found from STEPLIB. Perhaps there is some COBOL thing going on that I am not familiar with. It should work with LINK or LOAD. |
|
| Back to top |
|
|
Captain Paralytic
Warnings : 1
New User
Joined: 21 Apr 2010
Posts: 40
Location: UK
|
|
|
|
| Pedro wrote: |
I did not notice this at first reading:
| Quote: |
In the JCL the STEPLIB contains the library PRDQ.B.LOADLIB which contains MAINPROG and it also contains PROD.B.LOADLIB which contains RNCAL and POSTB.
...
This fails because it cannot find RNCAL and POSTB, which I would expect. |
I would have expected the members to be found from STEPLIB. Perhaps there is some COBOL thing going on that I am not familiar with. It should work with LINK or LOAD. |
There members ARE found in STEPLIB. You have taken one sentence from my description of when it works (in JCL) and one from where it doesn't work (under ISPF in the FOREGROUND) and put them together.
If run in JCL where I can specify a STEPLIB, it works fine.
If run in the FOREGROUND under ISPF, if the library containing POSTB & RNCAL is concatenated to ISPLLIB, it works fine.
If run in the FOREGROUND under ISPF, if the library containing POSTB & RNCAL is LIBDEFed to ISPLLIB, it fails. It will find MAINPROG in a LIBDEFed library but not the dynamic subroutines. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
| Quote: |
If run in the FOREGROUND under ISPF, if the library containing POSTB & RNCAL is LIBDEFed to ISPLLIB, it fails. It will find MAINPROG in a LIBDEFed library but not the dynamic subroutines.
|
because as I said before
| Quote: |
for the subsequent LIBDEFS an ISPxxxxx DDNAME is allocated and ISPF will issue a <directed> BLDL/LOAD/LINK,
( ISPF keeps track of the LIBDEF stack, so it knows the sequence of DDNAMES to use )
but that is done ONLY for modules called thru ISPF services.
|
in other words a LIBDEF DOES NOT concatenate the <library> to the original DDNAME
I will not waste time run testing it for ISPLLIB , tested it for the ISPPLIB
just showing the allocations ..
here it is
the REXX script ( the relevant part )
| Code: |
000014 panels = "ENRICO.ISPF.PANELS.LIBDEFFD"
000015 zrc = $ispex("LIBDEF ISPPLIB DATASET ID('"panels"') STACK")
000016 If zrc ¬= 0 then do
000017 exit 4
000018 end
000019 load = "ENRICO.ISPF.LOAD.LIBDEFFD"
000020 zrc = $ispex("LIBDEF ISPLLIB DATASET ID('"load"') STACK")
000021 If zrc ¬= 0 then do
000022 exit 4
000023 end
000024 zrc = $ispex("DISPLAY PANEL(ZLIBD1)")
000025 zrc = $ispex("LIBDEF ISPLLIB")
000026 zrc = $ispex("LIBDEF ISPPLIB")
|
the panel is irrelevant ( needed to wait for an enter )
the isrddn on the split screen
| Code: |
> ISPLLIB
ZARES1 SHR,KEEP > DIT130.SDITMOD1
ZARES2 SHR,KEEP > FMN810.SFMNMOD1
ZARES2 SHR,KEEP > IGY410.SIGYCOMP
...
> ISPPLIB
STOR04 SHR,KEEP > ENRICO.ISPF.PANELS
ZARES2 SHR,KEEP > ISP.SISPPENU
ZARES2 SHR,KEEP > ISF.SISFPLIB
ZARES1 SHR,KEEP > FAN140.SFANPENU
ZARES2 SHR,KEEP > FMN810.SFMNPENU
.....
STOR02 SHR,KEEP > ISP11971 ENRICO.ISPF.PANELS.LIBDEFFD
STOR01 SHR,KEEP > ISP12005 ENRICO.ISPF.LOAD.LIBDEFFD
|
|
|
| Back to top |
|
|
Captain Paralytic
Warnings : 1
New User
Joined: 21 Apr 2010
Posts: 40
Location: UK
|
|
|
|
| enrico-sorichetti wrote: |
in other words a LIBDEF DOES NOT concatenate the <library> to the original DDNAME |
Enrico I already know why it doesn't work. If you read my OP you will see that my request was:
Does anyone here have any idea as to what magic words I need to chant to achieve my aim?
I was asking how to achieve my aim. I was not asking for further explanations of how what I was already doing was not working. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
| Quote: |
| I was asking how to achieve my aim. I was not asking for further explanations of how what I was already doing was not working. |
my reply was also an explanation about You asking why split to see the the allocations
anyway the answer is very simple ...
You cannot do it from COBOL
You can do it from from assembler
1) scanning the allocated ddnames ( ISP.... ) for the requested dsname , or,
2) instead of using LIBDEF allocate a known DDNAME
and issue a <directed> LOAD/CALL Yourself |
|
| Back to top |
|
|
Pedro
Global Moderator
Joined: 01 Sep 2006
Posts: 2547
Location: Silicon Valley
|
|
|
|
You must not have read my earlier post:
| Quote: |
Try using CMD instead of PGM. Yes, there is a difference.
Code:
SELECT CMD(MAINPROG)
|
|
|
| Back to top |
|
|
Captain Paralytic
Warnings : 1
New User
Joined: 21 Apr 2010
Posts: 40
Location: UK
|
|
|
|
| Pedro wrote: |
You must not have read my earlier post:
| Quote: |
Try using CMD instead of PGM. Yes, there is a difference.
Code:
SELECT CMD(MAINPROG)
|
|
Hello Pedro,
Yes, you are right that I missed it and yes, you are right that it works!
Do you know in what document the differences between the 2 are discussed? I tried looking in the ISPF Services Guide, but I cannot find those 2 parameters described? |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
| ISPEXEC--SELECT |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
| Back to top |
|
|
Pedro
Global Moderator
Joined: 01 Sep 2006
Posts: 2547
Location: Silicon Valley
|
|
|
|
The issue about ATTACH, LINK, LOAD is described in the ISPF Services Guide manual.
Under LIBDEF, there is a section for Usage Notes, with a section for 'User Link Libraries'. |
|
| Back to top |
|
|
|
|
