On Sun, 31 Dec 2006 08:57:01 -0500 David Cole <[EMAIL PROTECTED]> wrote:
:>>[Binyamin Dissen] 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 - TEST works better in that regard :>>2. Does not support locked environments (neither does TEST) :>>3. Provide consistent data in a multiprogramming environment, where :>>other threads may be changing data that caused the trap (neither does TEST) :>>It probably is a quite adequate tool for other environments when the :>>application code does not have ESTAE's that sometimes retry). :>>I am all for Full Screen / Source Level debuggers - but no product :>>out there really does the job well enough (IMHO). It could be done :>>via CP (under VM) but I don't see the great return over the effort. :>>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). :>>I have no problem at all with dump formatters as they do not have any of the :>>drawbacks above. :>In his post, Mr. Dissen raises several objections to z/XDC that are :>either factually wrong or that raise the concern that z/XDC does not :>reliably display accurate information. I need to respond. I am by no means attempting to disparage z/XDC. I know many who use it heavily, and it works for their applications. :>>1. [XDC] Requires environment changes to support its ESTAE [...] :>Sometimes true. Sometimes not. z/XDC itself is, of course, an ESTAE :>(or an ESTAEX or an ARR or an FRR. It's up to you and your needs.) So :>the presence of z/XDC itself inevitably an environmental change. :>However, that "environmental change" benefits the debugging process :>rather than aggravates it. :>Sometimes, it is appropriate for a customer to modify his own ESTAE :>routine so that it will call z/XDC; however, that is not necessary. :>z/XDC provides simple methods that can be used to activate a :>debugging environment at pretty much any point of a target program's :>processing, regardless of whether it is main code, exit routines, PC :>routines, authorized routines, SRB routines, whatever. My experience (in the past - things may have changed) is that the application ESTAE did not properly get control and recover when XDC was in the picture. Remove it and all works fine. :>>[...] and the normal ESTAE logic doesn't seem to work well :>What does this mean? It is a random accusation given without a shred :>of supporting evidence. :>"Doesn't seem to work well"? I dunno. I guess the interaction of :>multiple recovery routines in an environment can seem confusing. :>However, those interactions occur according to a very small handful :>of simple rules, and so with only a little thought they can be :>understood. It doesn't take long to figure it all out. :>If there is something about the z/XDC's logic that "doesn't seem to :>work well", let me know specifically what it is. I'll fix it. As above. I have applications with multiple levels of ESTAE(X)/FRR and they work fine in recovery, percolating when expected. With XDC in the picture things went wrong. I have not made the effort to research the problem. :>> - TEST works better in that regard :>TEST uses SVC 91 for its breakpoints. (Currently, z/XDC uses 0C1s.) :>Consequently, TEST cannot be used in PC routines, in HASN<>PASN :>environments, in FRR protected environments, in locked environments, :>in SRB routines, generally in any of the many environments in which :>IBM defines that SVCs are prohibited. z/XDC can be used interactively :>in all of those environments. Technically an SVC can be used in the environment - if one hooks the FLIH. :>>2. [XDC] Does not support locked environments (neither does TEST) :>Purists have trouble with compromises. It's a shame. Because then :>they miss out on their benefits. :>If you are willing to accept certain inevitable compromises, z/XDC :>can be used to debug most programs that hold locks. Admittedly, you :>had better do so on a sandbox system since there will be some locked :>programs that cannot be debugged safely (or that cannot be debugged :>at all) with XDC. :>But if the limitations and dangers are understood, then z/XDC can be :>a valuable tool for debugging most locked code. I wonder as to the limitations and when it could work. :>>3. [XDC does not] Provide consistent data in a multiprogramming :>>environment, where other threads may be changing data that caused :>>the trap (neither does TEST) :>Again, this is a purist's issue. Yes, certainly scenarios can be :>conjured up that are problematic, but in almost all real world :>situations, the "consistency of data" issues being alluded to here do :>not interfere with the debugging process. Not at all. A trap is taken, but the data changes since other threads are updating the queues. PER puts the machine in a stopped state. And if one is already on a sandbox ....... :>I have many customers that use z/XDC with great effectiveness in :>highly multitasking environments, dozens of tasks, some persistent, :>others effervescent. In most of these situations, the programmer :>actually would not even want other tasks to be frozen. Depends on what they are doing. When I put in a STOP, I want the current exact environment and want it to be stable while I poke around. I will grant that my code is not typical, but it does exist. :>>It [z/XDC] probably is a quite adequate tool for other environments :>>when the application code does not have ESTAE's that sometimes retry). :>Yes, z/XDC is at least that. :>But for myself and my customers (a fairly large number these days), :>the presence of ESTAEs and their recovery routine is in no way a :>hindrance to z/XDC's use. In fact, z/XDC is a great tool for :>debugging, not just a program's main code, but also its ESTAEs, its :>ESTAEXs, its ARRs, its FRRs *and* their recovery routines. :>About Dumps: If ones only other choice was dumps, as opposed to VM/PER, I probably would use XDC on more occasions. The advantage of PER over dumps is that I can fix up things or set additional traps and let the machine resume. -- 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
