Maybe you are confusing/conflating the HOOK command with the HOOK macro, which long ago (pre-HOOK command days) was the way to start interactively debugging your code with XDC. You put the HOOK macro into your code at the point where you wanted to start debugging/tracing and reassembled that module. The HOOK macro assembles into a DC X'00' instruction, which causes a program interrupt, followed by a unique identifier that XDC's ESTAE routine uses to identify your HOOK macro as a request to get XDC involved rather than a "normal" program interrupt that was caused by attempting to execute a "normal" DC X'00' instruction op code. The X'00' will always generate a program interrupt even in XMEM.
Bill Fairchild Franklin, TN ----- Original Message ----- From: "Micheal Butz" <michealb...@optonline.net> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, April 9, 2013 8:19:56 AM Subject: Re: New Software Tool for z/OS Developers Announced by Arney Computer Systems Hi I have used XDC sparingly but isn't The HOOK command a SVC which won't work in XMEM Sent from my iPhone On Apr 9, 2013, at 8:48 AM, David Cole <dbc...@gmail.com> wrote: > Hi Bill, > > It seems to me that the HOOK command would have addressed both of your > PITAs. > > Best, > Dave > > > On Tue, Apr 9, 2013 at 7:09 AM, DASDBILL2 <dasdbi...@comcast.net> wrote: > >> That sounds great. Having to put code into my code in order to start >> using XDC has always been a PITA for me. And debugging my recovery >> routines (ESTAE, e.g.) were an even bigger PITA. >> >> >> Bill Fairchild >> Franklin, TN >> >> >> ----- Original Message ----- >> >> From: "Chuck Arney" <ch...@arneycomputer.com> >> To: IBM-MAIN@LISTSERV.UA.EDU >> Sent: Monday, April 8, 2013 5:37:43 PM >> Subject: Re: New Software Tool for z/OS Developers Announced by Arney >> Computer Systems >> >> I'll share a few thoughts I have on a couple of these issues. >> >> One of our design goals for TDF was to require no user code changes. We >> feel that you should never have to add code to your program, let alone >> design facilities into your code to support the job of the debugger, in >> order for you to debug the application's code. To do that only adds work >> for the developer and invites bugs that would not have existed in the first >> place. We do recognize there are a few environments there it becomes >> necessary to insert a macro call in order to get the debug process >> initialized and we support that, but normally the user program does not >> require any modification. >> >> About debugging locked code: Typically I would not discuss future product >> development plans in a public group like this one, but we long ago said >> that >> we were providing an interactive debugger and a non-interactive debugger. >> Due to the long development and beta test times we devoted to bring the >> product to market, release 1.1.0 of TDF provides only the interactive >> debugger. The non-interactive piece will come in a future release. You >> can >> find more details about the non-interactive debugging facility on our >> website. Our design for supporting the debugging of locked code is to use >> the non-interactive debugger. With no user interaction during the >> execution, and no service calls, the desired debug information can be >> collected while locks are held with no ill effects and no lock integrity >> issues. If the lack of support for locked code in the interactive debugger >> becomes an issue for a customer, we can certainly discuss that and >> entertain >> other ideas. >> >> Our Pass-through support allows shared local code to automatically handle >> the Traps without abends. Our Identify facility can be used to allow >> debugging of shared common storage code. All with no user program changes. >> We have implemented some very nice facilities in this product that are >> designed to make the job of debugging code quick and easy. And, no code >> changes are needed. >> >> Chuck Arney >> Arney Computer Systems >> >> -----Original Message----- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >> Behalf Of Rob Scott >> Sent: Monday, April 08, 2013 10:19 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: New Software Tool for z/OS Developers Announced by Arney >> Computer Systems >> >> I have been using z/XDC to debug software in a variety of exotic >> environments over the last 10 years or so and I have to say that the >> software has saved man-months in debugging and development time. >> >> In response to the individual points : >> >>>> In the standard environment, TSO TEST was a lot easier to use >> >> Most of my XDC debug sessions involve a tiny subset of simple one-character >> inputs or PF-key presses - I do not find it hard to use at all. >> >>>> I had problems using the XDC VTAM to trap simple XMEM (a PC out of the >> client address space). >> >> I am almost always in some sort of cross-memory environment when debugging >> using XDC and would say that XDC's ability to handle precisely this is why >> most ISVs have licensed the software. >> >>>> I doubt that XDC can do locked code >> >> XDC can get control to debug locked code - however it must release the held >> locks in order to communicate with the user and provide the ability to >> single-step. >> The user can then instruct XDC to re-establish locks before the program >> execution is resumed. >> Obviously there are inherent risks with this, however I would imagine that >> anyone debugging locked code is doing so on a developer sandpit system, so >> I >> do not see this as a big issue. >> If you are planning holding a lock while providing a single-step debug >> session, I imagine that you would not get very far before you would get a >> catch-22 situation with a system service. >> >>>> Hooks in common-storage modules causing 0C1s for later callers (from >>>> another poster) >> You can solve this with a simple comparison in the code before the #XDCHOOK >> macro. >> >> To debug a complex, cross-memory, multi-task, multi-ASID piece of software, >> a few simple XDC macro statements (and surrounding CLCs) in the code seems >> a >> very small price to pay for what you get. >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
