OK, I am now up and running with the help of the amazing MAKEAUTH scripts. Thanks to Dave and everybody else who responded.
Regards Robin -----Original Message----- From: David Cole [mailto:dbc...@colesoft.com] Sent: 10 June 2014 19:50 To: Robin Atwood Cc: IBM Mainframe Discussion List; Calin Cole; Frank Chu; Bob Shimizu Subject: RE: Problems with XDC hooks 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
