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
