First, thanks for all the praise. It's always
good to hear the thoughts of those that appreciate the product.
But I do want to interject a thing or two about security:
First, when debugging problem state code, z/XDC
conforms to that straightjacket. It cannot be
used to violate system integrity. It cannot be used to elevate authority.
Second, z/XDC has support for z/XDC-specific
security rules that you can set up to control who
can use it and what it is and is not allowed to
do, both when running in problem state and in supervisor state.
Thanks for the last 4 or 5 decades. It's been a good run.
Dave Cole
At 11/9/2025 04:15 PM, Jon Perryman wrote:
On Sun, 9 Nov 2025 08:33:07 -0700, Bob Shimizu <[email protected]> wrote:
>First, I must admit my bias.Â
Despite z/XDC blemishes, It's a great product
that you most likely will choose. Remember the
saying, the solution to the problem changes the
problem. Don't waste your time with TSO TEST.
AFAIK, your choices are z/XDC and IBM Debugger.
The choice must be based on your needs and
requirements. I only spent 2 seconds using IBM
Debugger so I can't speak about its features but
it did support multiple languages (including
HLAsm). If you're working within an application
environment, then it might be your choice. If I
remember correctly, it even supports CICS.
We could easily spend an hour discussing
features we love about z/XDC but it will be not
so obvious features that will irritate you most.
For instance, z/XDC can be implemented in abend
recovery which means z/XDC can always be
active with no overhead or my recovery routines
can limit when z/XDC gets control. I can create
breakpoints in other address spaces, SSI, SRB, PC routines or ???.
>z/XDC was, and is aimed at Assembler professionals.
You need to identify the bad as well as the
good. Since we don't know your situation, you
will have site considerations and levels of acceptable risk.
Vendor system software developer. Typically,
very experienced and very trusted. z/XDC is not
restricted in any way. We can be the destroyer
of worlds and very experienced in seeing what
many may overlook. For instance, I have set breakpoints in the SSI for WTO's.
Everyone else: z/XDC may (or may not) have
controls to restrict activities. Should they
have access sensitive / dangerous code or data?
How about CSA, PSA, SSI, exits or ???. Is
bypassing security an acceptable risk.
>Nothing else allows you to work on APF-authorized, or multitasking code
>as easily. It's VASTLY better than causing one dump at a time and
>puzzling out what may be going on inside the architecture. Instead, each
>Trace or Breakpoint in z/XDC serves as a dump, allowing you to look all
>around the A-space (or indeed the system itself) at each point.
Great points but I suggest the op considers the
downside. From my perspective, the op should
first ask questions to determine if these
products are viable for his environment. While
"serves as a dump" is true, this ignores the
usefulness and dangers of point in time
capabilities. You can change memory during these breakpoints.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
