>>>Hooks in common-storage modules causing 0C1s for later callers (from another poster)
WRT hooks, this statement is actually false. It is not even partly true. This because whenever a dynamic hook is reached by execution, the very first thing it does is remove itself and restore the original code. Thus, no subsequent caller will ever suffer an 0C1. WRT breakpoints, yes, 0C1s will occur when an address space, not involved in the debugging session, attempts to execute a common storage breakpoint. However, there are many simple techniques an XDC user can engage to make this possibility either not occur or occur with vanishingly low probability. Dave Cole z/XDC Developer On Mon, Apr 8, 2013 at 11:18 AM, Rob Scott <[email protected]>wrote: > 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. > > Rob Scott > Lead Developer > Rocket Software > 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA > Tel: +1.781.684.2305 > Email: [email protected] > Web: www.rocketsoftware.com > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Binyamin Dissen > Sent: 08 April 2013 10:33 > To: [email protected] > Subject: Re: New Software Tool for z/OS Developers Announced by Arney > Computer Systems > > I have not been at an installation that has used XDC for a while, so some > of my comments may be old. > > In the standard environment, TSO TEST was a lot easier to use. > > I had problems using the XDC VTAM to trap simple XMEM (a PC out of the > client address space). Seems like the application frequently had weird > abends after giving the GO (or whatever the XDC resume from breakpoint > command was). > > I doubt that XDC can do locked code - if they can, my apologies and I will > actually try look at it. And if they do it without requiring code changes, > even the better. > > I will admit that I am old school - SVCdump, GTF traces, etc. So I can > live without it. > > On Sun, 7 Apr 2013 15:32:20 -0400 Micheal Burn <[email protected]> > wrote: > > :>What else debugs XMEM SRB authorized code etc :> :>Sent from my iPhone > :> :>On Apr 7, 2013, at 2:30 PM, "Shmuel Metz (Seymour J.)" < > [email protected]> wrote: > :> > :>> In <[email protected]>, on 04/07/2013 > :>> at 12:29 PM, Micheal Burn <[email protected]> said: > :>> > :>>> Seems that Dave Cole finally has Competition :>> :>> He has always > had competition. The real question is whether the :>> competitive products > are better. There isn't enough information in the :>> announcement to say; > using TRAP2 and TRAP4 is more of an :>> implementation detail than a > feature. > :>> > :>> -- > :>> Shmuel (Seymour J.) Metz, SysProg and JOAT > :>> Atid/2 <http://patriot.net/~shmuel> > :>> We don't care. We don't have to care, we're Congress. > :>> (S877: The Shut up and Eat Your spam act of 2003) :>> :>> > ---------------------------------------------------------------------- > :>> 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 > > -- > Binyamin Dissen <[email protected]> http://www.dissensoftware.com > > Director, Dissen Software, Bar & Grill - Israel > > > Should you use the mailblocks package and expect a response from me, you > should preauthorize the dissensoftware.com domain. > > I very rarely bother responding to challenge/response systems, especially > those from irresponsible companies. > > ---------------------------------------------------------------------- > 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
