I don't work for Dave Cole and he doesn't owe me anything, but I have to defend his honor here...
> The problem I have with XDC is that its method of trapping (an 0C1): > 1. Requires environment changes to support its ESTAE and the normal ESTAE > logic doesn't seem to work well It depends on your approach. I have a single set of recovery routines that deal with all aspects of recovery and diagnostics. I recognize when I am in a debugging situation and call XDC right out of the mainline of my recovery code. The XDC debug session does whatever it is going to do. XDC sets up the environment appropriate for what the user did. When XDC returns control to the recovery routine it gives either RC=4, in which case I simply return to RTM and life goes on, or RC=0 - which indicates that I am to proceed with recovery processing myself. You would see RC=4 if, for example the user said "GO", or any of the forms of TRACE. Basically anything where control was expected to pass back to the application. You would see RC=0 is the user had said "END NOASK" or any variation thereof. In that case the expectation is that normal recovery (if any) will come into play. The issue of whether the application eventually regains control via a retry (in this case) depends on what the application's own recovery does. That's how you test your own recovery logic. That approach is utter simplicity and is completely consistent with what RTM expects a recovery program to do. You could even use XDC directly as a recovery routine (although I would NOT do that) or you can just treat it as part of your built-in debugging environment. The only time you run into trouble with "who's on first?" situations is those cases where you're trying to plant a debugging environment from the outside - and that's fraught with difficulty anyway. > TEST works better in that regard I really don't agree at all. TEST is a pathetic debugger and it only supports task mode under TSO and even that is only done in a half-hearted fashion. I cannot think of ANYTHING where I would consider TEST to be superior. > 2. Does not support locked environments (neither does TEST) True. And since there's nothing (other than a VM system) that can test locked or disabled code, it is hardly a fair criticism of XDC. > 3. Provide consistent data in a multiprogramming environment, where other > threads may be changing data that caused the trap (neither does TEST) XDC works very well in heavily multitasked environments, but you do have to know what you're doing with it. I would assume that anyone capable of developing a complex multitasking application would likewise be able to use XDC to debug it. > It probably is a quite adequate tool for other environments when the > application code does not have ESTAE's that sometimes retry). XDC works with any ESTAE-class recovery (STAI, STAE, ARR) and with FRRs set by enabled and unlocked programs. The locked/disabled case was mentioned above and those are pretty difficult to debug with any tool including VM. > I am all for Full Screen / Source Level debuggers - but no product out > there really does the job well enough (IMHO). That's in the eye of the beholder I suppose. XDC has been extremely useful for me. The fact that XDC doesn't support locked/disabled code is certainly no reason to disparage it, particularly in comparison with other approaches. > It could be done via CP (under VM) but > I don't see the great return over the effort. That's pretty much what the IBM developers have already. Unfortunately their bag of tricks is not shared with the outside world. As far as I can tell, XDC is the best alternative in the wild. > One of there days I will > probably get around to writing a CP command with the full functionality of > indirect addressing of the TEST LIST command (cannot figure out how to do > > L 1R?+8?+C? > > via the D command). Pretty much what you have above, but with a D instead of an L :-) But seriously, the command syntax is documented and there is online help. > I have no problem at all with dump formatters as they do not have any of > the drawbacks above. Pardon?!! You have got to be kidding right? Aside from the sheer time wasting effort in capturing and processing a dump, you can't just dynamically add control block formatters in an IPCS session. With an online debugger (XDC in this case) you can trace executing code a line at a time if you want, you can display registers and storage, you can map and format code and data areas... a whole bunch of things that you cannot do at all in a dump. CC ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
