[Binyamin Dissen] 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.
Without knowing anything more about this problem that what little you
say here, I would guess that the most likely culprit would be that
your program created an ESTAE(X) what was newer than the ESTAE(X)
that was z/XDC. Thus, when the abend or breakpoint was reached, your
ESTAE(X) received control ahead of z/XDC.
Often in this sort of situation, a sophisticated ESTAE(X), after
taking a dump, or setting footprints or some such, will perform some
sort of cleanup/shutdown processing (freemain storage areas, close
datasets, whatever) prior to percolating, at which point, z/XDC will
receive control.
Eventually, the user will issue a GO or TRACE to resume execution.
This will cause the main program to resume execution in an
environment that has been corrupted by the user's own ESTAE(X), so
all hell will break loose.
When debugging, and when z/XDC receives control, you can find out
whether or not newer ESTAE(X)s exist (and have percolated control to
z/XDC) simply by issuing a LIST SCBS command.
You can avoid the problem altogether simply by being aware of what
you are doing and by using a HOOK command (instead of an AT or TRAP)
command to set your initial breakpoint in code that runs after a
newer ESTAE(X) has been created.
Maybe that's what happened to you, maybe not, I don't know.
Certainly, there are other causes of programs running differently
with vs. without z/XDC present in the environment. Usually, such
discrepancies are indicative of otherwise hidden pathological
behavior on the part of the user's program, the most common of which
would be the use of an uninitialized pointer field.
When z/XDC is added to the environment, the shape of allocated
storage changes. So an uninitialized field might normally contain a
zero, but when shapes change, said field might now contain a
non-zero, and things will go south in random ways. So the fact that a
program "works when z/XDC is removed" usually means that there is
something wrong with the program, not with z/XDC. And removing z/XDC
does not fix the problem, it merely lets it go back into hiding.
[Binyamin Dissen] 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.
That's a shame, because it would have been interesting to get to the
root of the problem. Certainly, if said root had been an actual z/XDC
bug, I would have fixed it, and everybody would have benefited from that.
However, if it had been a subtile misbehavior of your program, then
you missed an opportunity to improve your program.
And (as I think is the likeliest case) if the misbehavior had arisen
from a problem with the way in which you were using z/XDC, then I
could have given you helpful suggestions, and perhaps you would have
found the product to be more useful that you expected.
Oh well.
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
