Hi Bill, Monitor Call instructions would be cool, and around 3 decades ago or so, I researched MVS' OCO infrastructure that supports MCs... but no, there are no MC instructions anywhere in z/XDC, and there never have been.
Perhaps one time I did have a HOOK macro in z/XDC, I don't remember. But if I did, that would have been in the 1980s... ancient history. In the event that a customer does want to assemble a hook into his code, what we do have is a #XDCHOOK macro, and that devolves down to an SVC. But as I noted previously, assembling hooks into code is optional and is available for reasons of convenience. After all, when you want to discard and restart a debugging session over and over again, having a hook in the code is more convenient that manually setting that hook over and over again. But then again, it also is possible to put the HOOK'ing command into a script and cause that script to be run automatically upon each debugging session restart. The point is, z/XDC offers choices to meet differing ideas of needs, preferences and convenience. Best, Dave On Tue, Apr 9, 2013 at 11:46 AM, DASDBILL2 <dasdbi...@comcast.net> wrote: > 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" <fr...@colesoft.com> > To: IBM-MAIN@LISTSERV.UA.EDU > 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 <dasdbi...@comcast.net> > 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" <michealb...@optonline.net> > >To: IBM-MAIN@LISTSERV.UA.EDU > >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 <dbc...@gmail.com> 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 <dasdbi...@comcast.net> > 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" <ch...@arneycomputer.com> > >>> To: IBM-MAIN@LISTSERV.UA.EDU > >>> 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:IBM-MAIN@LISTSERV.UA.EDU] > On > >>> Behalf Of Rob Scott > >>> Sent: Monday, April 08, 2013 10:19 AM > >>> To: IBM-MAIN@LISTSERV.UA.EDU > >>> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >>> > >>> ---------------------------------------------------------------------- > >>> For IBM-MAIN subscribe / signoff / archive access instructions, > >>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> > >> ---------------------------------------------------------------------- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > >---------------------------------------------------------------------- > >For IBM-MAIN subscribe / signoff / archive access instructions, > >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > >---------------------------------------------------------------------- > >For IBM-MAIN subscribe / signoff / archive access instructions, > >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
