You're right. #DIE is what I was describing. I confuse and conflate things myself.
I think there is a HOOK macro in z/OS that assembles into a Monitor Call instruction for a User event to be traced by GTF, but I could be conflating some more . Bill Fairchild Franklin, TN ----- Original Message ----- From: "Frank" <[email protected]> To: [email protected] Sent: Tuesday, April 9, 2013 10:43:27 AM Subject: Re: New Software Tool for z/OS Developers Announced by Arney Computer Systems Bill, You are thinking of the #DIE macro. That assembles into a x'00' instruction with a special identifier for zXDC. If zXDC is established as the newest ESTAE, the #DIE would cause a debugging session to start. Otherwise a S0C1 is generated. A HOOK, either a dynamic HOOK or the #XDCHOOK macro, is indeed a SVC call. This can be problematic in certain environments such as SRBs, FRR protected environments, etc. For this reason, we distribute a "HOOK script" that can be used to establish XDC into environments where a SVC is not allowed. The script can be found in the *.XDCCMDS library. Hope this helps, Frank On Tue, 9 Apr 2013 14:55:43 +0000, DASDBILL2 <[email protected]> wrote: >Maybe you are confusing/conflating the HOOK command with the HOOK macro, which >long ago (pre-HOOK command days) was the way to start interactively debugging >your code with XDC. You put the HOOK macro into your code at the point where >you wanted to start debugging/tracing and reassembled that module. The HOOK >macro assembles into a DC X'00' instruction, which causes a program >interrupt, followed by a unique identifier that XDC's ESTAE routine uses to >identify your HOOK macro as a request to get XDC involved rather than a >"normal" program interrupt that was caused by attempting to execute a "normal" >DC X'00' instruction op code. The X'00' will always generate a program >interrupt even in XMEM. > > >Bill Fairchild >Franklin, TN > >----- Original Message ----- >From: "Micheal Butz" <[email protected]> >To: [email protected] >Sent: Tuesday, April 9, 2013 8:19:56 AM >Subject: Re: New Software Tool for z/OS Developers Announced by Arney Computer >Systems > >Hi > >I have used XDC sparingly but isn't >The HOOK command a SVC which won't work in XMEM > >Sent from my iPhone > >On Apr 9, 2013, at 8:48 AM, David Cole <[email protected]> wrote: > >> Hi Bill, >> >> It seems to me that the HOOK command would have addressed both of your >> PITAs. >> >> Best, >> Dave >> >> >> On Tue, Apr 9, 2013 at 7:09 AM, DASDBILL2 <[email protected]> wrote: >> >>> That sounds great. Having to put code into my code in order to start >>> using XDC has always been a PITA for me. And debugging my recovery >>> routines (ESTAE, e.g.) were an even bigger PITA. >>> >>> >>> Bill Fairchild >>> Franklin, TN >>> >>> >>> ----- Original Message ----- >>> >>> From: "Chuck Arney" <[email protected]> >>> To: [email protected] >>> Sent: Monday, April 8, 2013 5:37:43 PM >>> Subject: Re: New Software Tool for z/OS Developers Announced by Arney >>> Computer Systems >>> >>> I'll share a few thoughts I have on a couple of these issues. >>> >>> One of our design goals for TDF was to require no user code changes. We >>> feel that you should never have to add code to your program, let alone >>> design facilities into your code to support the job of the debugger, in >>> order for you to debug the application's code. To do that only adds work >>> for the developer and invites bugs that would not have existed in the first >>> place. We do recognize there are a few environments there it becomes >>> necessary to insert a macro call in order to get the debug process >>> initialized and we support that, but normally the user program does not >>> require any modification. >>> >>> About debugging locked code: Typically I would not discuss future product >>> development plans in a public group like this one, but we long ago said >>> that >>> we were providing an interactive debugger and a non-interactive debugger. >>> Due to the long development and beta test times we devoted to bring the >>> product to market, release 1.1.0 of TDF provides only the interactive >>> debugger. The non-interactive piece will come in a future release. You >>> can >>> find more details about the non-interactive debugging facility on our >>> website. Our design for supporting the debugging of locked code is to use >>> the non-interactive debugger. With no user interaction during the >>> execution, and no service calls, the desired debug information can be >>> collected while locks are held with no ill effects and no lock integrity >>> issues. If the lack of support for locked code in the interactive debugger >>> becomes an issue for a customer, we can certainly discuss that and >>> entertain >>> other ideas. >>> >>> Our Pass-through support allows shared local code to automatically handle >>> the Traps without abends. Our Identify facility can be used to allow >>> debugging of shared common storage code. All with no user program changes. >>> We have implemented some very nice facilities in this product that are >>> designed to make the job of debugging code quick and easy. And, no code >>> changes are needed. >>> >>> Chuck Arney >>> Arney Computer Systems >>> >>> -----Original Message----- >>> From: IBM Mainframe Discussion List [mailto:[email protected]] On >>> Behalf Of Rob Scott >>> Sent: Monday, April 08, 2013 10:19 AM >>> To: [email protected] >>> Subject: Re: New Software Tool for z/OS Developers Announced by Arney >>> Computer Systems >>> >>> I have been using z/XDC to debug software in a variety of exotic >>> environments over the last 10 years or so and I have to say that the >>> software has saved man-months in debugging and development time. >>> >>> In response to the individual points : >>> >>>>> In the standard environment, TSO TEST was a lot easier to use >>> >>> Most of my XDC debug sessions involve a tiny subset of simple one-character >>> inputs or PF-key presses - I do not find it hard to use at all. >>> >>>>> I had problems using the XDC VTAM to trap simple XMEM (a PC out of the >>> client address space). >>> >>> I am almost always in some sort of cross-memory environment when debugging >>> using XDC and would say that XDC's ability to handle precisely this is why >>> most ISVs have licensed the software. >>> >>>>> I doubt that XDC can do locked code >>> >>> XDC can get control to debug locked code - however it must release the held >>> locks in order to communicate with the user and provide the ability to >>> single-step. >>> The user can then instruct XDC to re-establish locks before the program >>> execution is resumed. >>> Obviously there are inherent risks with this, however I would imagine that >>> anyone debugging locked code is doing so on a developer sandpit system, so >>> I >>> do not see this as a big issue. >>> If you are planning holding a lock while providing a single-step debug >>> session, I imagine that you would not get very far before you would get a >>> catch-22 situation with a system service. >>> >>>>> Hooks in common-storage modules causing 0C1s for later callers (from >>>>> another poster) >>> You can solve this with a simple comparison in the code before the #XDCHOOK >>> macro. >>> >>> To debug a complex, cross-memory, multi-task, multi-ASID piece of software, >>> a few simple XDC macro statements (and surrounding CLCs) in the code seems >>> a >>> very small price to pay for what you get. >>> >>> ---------------------------------------------------------------------- >>> 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 > >---------------------------------------------------------------------- >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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
