Jon:
Thanks for these excellent points.
I should point out that z/XDC interfaces with any security system. You
can lock it down selectively, to the point where it's a political
question rather than a technical one.
"May I look at 'alien memory' (that outside my address space, or in
Common Storage)?"
"If I can look at alien memory, may I write to it?"
These are important considerations, and you may allow some individuals
or groups to have free rein in certain applications.
For example, the guys writing multitasking applications, PC Calls or
SRBs probably have the requisite knowledge not to do anything careless.
They know what they're doing. Others may not.
Many pure development environments run without ANY security system so
z/XDC can by default go anywhere/do anything. In a commercial
environment, folks make heavy use of z/XDC's security rules.
Often our customers used security through obscurity, and only a handful
of senior people even knew of z/XDC's existence.
Jon is right though. z/XDC is a power tool. Treat it with the respect
you would a motorcycle or a chainsaw.
Sincerely,
Bob
On 11/9/25 14:15, 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
