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...
fr...@colesoft.com
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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Dave Cole
ColeSoft Marketing
414 Third Street, NE
Charlottesville, VA 22902
EADDRESS: <mailto:dbc...@colesoft.com>dbc...@colesoft.com
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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
