Hi Robin, I understand now what your issues are, and I have a
solution. First, though, let's examine what's going on.
At 6/10/2014 03:18 AM, Robin Atwood wrote:
Dave - Thanks to you and the others that replied.
Your program is running in problem state and has no authority to
acquire supervisor state, so z/XDC does not have that authority either.
I can link the module AC(1) but because it's running under the TMP
if you issue a MODESET you will get abend 047.
Yes, that is what happens when JSCBAUTH=0... MODESET abends with an s047.
This is a puzzling comment, since z/XDC's honoring the //XDCREFR8
and //XDCRENT8 ddnames is not in any way contingent upon the type
or program being debugged. There must be missing information here.
I put both DD statements in the STC's JCL. Surely the module with
the hook has already been loaded into key 0 storage before the hook
is executed and therefore the DD statements can make no difference?
Yes, that certainly is true. When the load modules already reside in
key=0 storage, then yes, //XDCREFR8 and //XDCRENT8 will have not effect.
The DBC640Q WTOR is issued and I *can* connect using XDCCDF (we
sorted out the RACF stuff). I just cannot set any breakpoints.
Understood:
- Your program is running in problem state with execution key=8
and no authorization (JSCBAUTH=0).
- z/XDC inherits the authority of its environment, so it too is
running in problem state with execution key=8 and no authorization.
- Your target load modules are reentrant and already preloaded
into key=0 storage.
- So z/XDC cannot set breakpoints into your target load modules.
So how do I debug this beast?
Here's how... Once your problem state debugging session has started,
you need to find a way to make it run in supervisor state. To do that...
- You need to start up an unrelated authorized debugging session
within a second TSO session. (The easiest way to do that is to go to
ISPF's Command Shell [=6] and issue "XDCCALLA IEFBR14".)
- Then (RACF permitting) you can use that session to switch your
problem state debugging session into supervisor state.
- Then you will be able to proceed with your original (now
supervisor state) debugging session and set breakpoints to your
heart's content.
To assist with this process, I have written three command scripts
named MAKEAUTH, MAKEAUT2 and MAKEAUT3. You can find them in the
DBCOLE.XDCZ1D.XDCCMDS library, and you can run them with z/XDC's READ command.
You will find detailed step-by-step instructions in the scripts'
commentary, starting with the MAKEAUTH script.
RACF permitting, this should go off without a hitch, but if you do
run into RACF issues, get back in touch and we'll sort that out too.
Important! This process allows z/XDC to run in supervisor state, but
it does not in any way change the authorization level of the target
execution thread. In other words, the program being debugged will
continue to run in problem state with execution key=8 and no
authorization (JSCBAUTH=0).
IHTH,
Dave Cole
Thanks
Robin
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
