[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.
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.
[...] 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.
- 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.
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.
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.
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.
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:
Sure, dumps do a great job of providing comprehensive snapshots of a
single instant in time. And, sure, a lot of effective debugging can
be done by a programmer who is highly skilled in analysis, who is
highly experienced with the program he is debugging and who is highly
experienced with the system environments within which that program is running.
It is perhaps ironic, but it turns out that I have to look at dumps
quite frequently, because when a customer has a problem that I cannot
recreate at home, and the customer cannot provide a way for me to
connect into his system, then he has to send me a dump, and I have to
look at it.
But in any case, the troubles with dumps are:
(1) It may take a decade or more to acquire the experience to read
them effectively.
(2) As storage sizes grow, they are becoming more and more unmanageably huge.
(3) The moment of the dump, especially the "harder" ones (of which
there are plenty), often will be taken thousands or even millions of
instructions away from the initial cause of the failure, long after
intervening code may have corrupted the information necessary to find
the true problem.
(4) The visual presentation of a dump to the user is utterly abysmal!
(Yes, IPCS has loads of good structural formatters, but sooner or
later, you're going to wind up having to mentally decode raw hex-EBCDIC.)
(5) Stepping through a program (an essential feature of all
interactive debuggers) is simply not possible with dumps. (but that's
on my to-do list ...) To accomplish the equivalent of "setting a
breakpoint" requires either setting a SLIP trap or setting an 0C1
bomb and then rerunning the program and taking another 100 megabyte
dump. (Ok, maybe not always 100 megabytes.) The turnaround time from
one snapshot to the next is immense!
I have no problem at all with dump formatters as they do not have
any of the drawbacks above.
Actually, point (3) above is a "consistency of data" issue, not
unlike the ones Mr. Dissen raise regarding z/XDC.
Dave Cole REPLY TO: [EMAIL PROTECTED]
Cole Software WEB PAGE: http://www.xdc.com
736 Fox Hollow Road VOICE: 540-456-8536
Afton, VA 22920 FAX: 540-456-6658
----------------------------------------------------------------------
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
