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. >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? The DBC640Q WTOR is issued and I *can* connect using XDCCDF (we sorted out the RACF stuff). I just cannot set any breakpoints. So how do I debug this beast? Thanks Robin -----Original Message----- From: David Cole [mailto:[email protected]] Sent: 10 June 2014 02:20 To: IBM Mainframe Discussion List Cc: Calin Cole; Frank Chu; Bob Shimizu; Robin Atwood Subject: Re: Problems with XDC hooks Hmmm. There's not enough information here to give a definitive solution, but I will comment a little bit on some of what I am able to glean. >The advice is to issue a 'SET ZAP SPROT' command but that makes no difference. The fact that SET ZAP SPROT does not resolve your issue indicates that your program is not running with APF authorization, i.e. JSCBAUTH=0. "SET ZAP SPROT" is effective only when JSCBAUTH=1. 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 noticed the "//xxxRENT8 DD DUMMY " trick but that has no effect on an STC. I assumed you substituted "XDC" for "xxx". You might also try adding //XDCREFR8 DD DUMMY to your target program's JCL in case the program you're trying to breakpoint is refreshable instead of reusable. >but that has no effect on an STC 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. >An XDC hook seemed the obvious way to go because the first thing it >does is cancel a lot of the LE SPIE traps. I have tried this two >ways, dynamically and assembling in the #XDCHOOK macro, but the >result is the same. The hook is executed and the WTOR is displayed >and I can connect to the ASID via XDCCDF. You're right, a hook would be the best way to go... So let's try to solve that. When you say "the WTOR is displayed", do you mean the DBC640Q wtor? When you say you "cannot connect". What are the symptoms? One thing that occurs to me is that you might not have the RACF authority to connect. But of course, that's just a guess... Well rather than continue with what are just guesses here, why don't you instead just contact us and we'll resolve this quickly. Frank Chu is our tech support guy, and he's truly one of the great ones. He can be reached at... [email protected] 540-456-6164 I hope this helps. Dave At 6/9/2014 09:39 AM, Robin Atwood wrote: >I have inherited a newly acquired mainframe server which I am >trying to instrument with XDC. It has a number of worker ASIDs which >are RENT, reside in an APF library but run in problem state with all >authorised stuff is done by a user SVC. This is because each ASID is >a TSO batch job which starts up ISPF, which in turn promptly selects >a PL/1 program to make sure everything is LE enabled. (I know, it >was something I did in a previous life.) > >An XDC hook seemed the obvious way to go because the first thing it >does is cancel a lot of the LE SPIE traps. I have tried this two >ways, dynamically and assembling in the #XDCHOOK macro, but the >result is the same. The hook is executed and the WTOR is displayed >and I can connect to the ASID via XDCCDF. But when I try to set a >break-point or step through the code I get: > >DBC045E STORAGE ACCESS VIOLATION - ABEND 0C4-04 OCCURRED DURING ZAP ATTEMPT >- PROTECTED AGAINST >DBC045E ACCESS - TARGET IS IN KEY-0 STORAGE. > >DBC045E ZAP METHOD ATTEMPTED: NORMAL ADDRESSING > >DBC045E FOR POSSIBLE RESOLUTIONS TO THIS PROBLEM, TYPE AN H AT THE LEFT AND >PRESS ENTER > >The advice is to issue a 'SET ZAP SPROT' command but that makes no >difference. I noticed the "//xxxRENT8 DD DUMMY " trick but that has no >effect on an STC. The curious thing is we have another server which is >linked RENT and loads XDC as its ESTAE; stepping through that is no problem. >What have I missed here? > >TIA >Robin > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [email protected] with the message: INFO IBM-MAIN Dave Cole ColeSoft Marketing 414 Third Street, NE Charlottesville, VA 22902 EADDRESS: <mailto:[email protected]>[email protected] Home page: www.colesoft.com Facebook: www.facebook.com/colesoftware YouTube: www.youtube.com/user/colesoftware ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
