On Mon, 1 Jan 2007 14:17:07 -0500 "Craddock, Chris" <[EMAIL PROTECTED]> wrote:
:>I don't work for Dave Cole and he doesn't owe me anything, but I have to :>defend his honor here... I am by no means challenging his honor. I am not attempting to attack his product. :>> 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. All I can say is that I had unexpected results using XDC when my code wanted to retry. The problems did not occur when XDC was removed from the picture. I guess I could have spent time trying to debug the issue, but I found it easier to proceed without it. :>> 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. TEST works in the batch TMP as well. I can script a TEST session to debug a batch program. And it is extremely powerful. I have been using it for more than 20 years. :>> 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. Only to the claim that XDC can test system programs - there are limitations. :>> 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. You set a trap at an instruction, but when you look at the data you shouldn't have made it there - because the data has changed in the meantime. A difficult problem to shoot if you don't cause a stop when it occurs. :>> 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. Or, as above. :>> 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. I am not trying to "disparage" it. I was pointing out the limitations. I write a lot of system exit code which get control in weird situations, and sometimes early in the IPL process. I am sure that it is quite adequate to test a standard APF program or a new SVC (though I really don't go to the effort to use XDC in those situations since it is easier for me to setup PER or SLIP/GTF). :>> 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. Different strokes ..... I find PER to be superior in trapping. XDC certainly will provide better displays. :>> 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 tried and cannot figure out how to do it. I have to do a series of displays, down the chain. Perhaps you can give me the syntax to do the above? :>> 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? Drawbacks being locks and serialization. :>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. IPCS certainly call dump formatters. Yes, there is the problem with a dump in that you can't change something and have it go on. But it will capture a true system state. -- Binyamin Dissen <[EMAIL PROTECTED]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. ---------------------------------------------------------------------- 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
