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 <[email protected]> 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 <[email protected]> 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" <[email protected]> >> To: [email protected] >> 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:[email protected]] On >> Behalf Of Rob Scott >> Sent: Monday, April 08, 2013 10:19 AM >> To: [email protected] >> 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 [email protected] with the message: INFO IBM-MAIN >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
