Is there a resource class and profile for users allowed to elevate privilege? When you validate access do dangerous features, or does the instation include AUFIT in the profile?
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר ________________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of David Cole <[email protected]> Sent: Monday, November 10, 2025 7:08 AM To: [email protected] <[email protected]> Subject: Re: Assembler debugger External Message: Use Caution 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
