I was never good at keeping secrets but I don't understand the mystery. It does not matter if it is a simple batch program or an environmentally complex program. When our code runs it is covered by our recovery routines but those exits are removed before the user code runs so that the user recovery routines are in effect. If the user code has established a recovery routine we place an automatic system breakpoint at its entry so if entered the code can be single instruction stepped or otherwise debugged. If the user code does not have a recovery routine, or it percolates, we have a lower level recovery routine established so that it can report on the user code abend. We also provide a UI option to establish a recovery routine on behalf of the user code if the user program does not have its own recovery routine. It's all about abend reporting and optionally about being able to debug the user recovery. We report on our own abends if appropriate (that is unexpected situations), let the user recovery exit run, with a breakpoint established, if defined by the user code or we report on the unhandled user code abend. It's very straight forward and according to z/OS rules, without any user code changes.
Chuck Arney Arney Computer Systems -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of David Cole Sent: Monday, April 08, 2013 9:19 PM To: [email protected] Subject: Re: New Software Tool for z/OS Developers Announced by Arney Computer Systems These days, the notion that using z/XDC requires modifying user code is no longer true. Yes, for mature and environmentally complex programs (i.e. programs consisting of many parts running in a variety of states and recovery environments), there are advantages with integrating an interface for z/XDC into said program's existing ESTAE[X] routines. However, although convenient, that is not really necessary, especially for programs that involve simpler recovery environments. That's because z/XDC has a utility (XDCCALL[A]) that can be used to establish an initial debugging session right at program startup. And once started, a HOOK command can be used to dynamically establish a debugging environment in the immediate vicinity of any area of the code that you wish to debug, regardless of that code's recovery environment. Also, (security permitting) the HOOK command can be used to create a debugging session in any other running address space in the System, again without any code changes to the target whatsoever. The notion of, using TRAP2 instructions instead of X'00' opcodes for breakpoints has gotten me rethinking the idea, and I have to admit, there are some advantages. But a debugger still has to be able to capture other abends (0C4s are a common example), and as far as I know, that is still going to necessitate that any debugger have at least a part of its product be established as a recovery routine (ESTAE[X] or FRR). If there is a way to avoid that, I'm all ears. Dave Cole z/XDC Developer On Mon, Apr 8, 2013 at 6:37 PM, Chuck Arney <[email protected]> wrote: > 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
