Peter, since you did such an excellent job of describing the problem, I've decided to describe to you how TDF is going to handle asynchronous exits. Before doing so, I need to clearly state that for the current release of the product the asynchronous exit debugging is a restriction. Months ago I looked into the problem and devised a solution but I didn't implement it because I had many other things on my plate. Second, all of the technology I'm about to describe exists in TDF right now. It's just a new implementation of the same intercept technology already being used.
The TRAPx instruction alone is insufficient to accommodate full fledge debugging. As you mentioned, its anchored off the Dispatchable Unit Control Table (DUCT) so its scope is a dispatchable unit, a TCB or SRB. In a complex system involving multiple tasks and multiple address spaces, this scope is easily exceeded. So a mechanism must exist to automatically extend the scope of the trap environment as the application grows in scope. The mechanism used by TDF is called Dynamic Program Intercepts. Without going into great detail, suffice it to say that TDF intercepts content supervision (LOAD, XCTL, LINK and ATTACH) , RTM exit and key schedule service calls. So when a new task is attached, through commands, you can define whether TDF automatically sets up the trap environment for a new task. You actually attach a TDF program that sets up the environment and transfers control to your program with a newly setup trap environment. When you create an RTM exit, a small program in TDF actually gets control and it wraps your RTM exits. TDF can also wrap key schedule services like IEAMSCHD so that when an SRB is scheduled, it initializes the DUCT just as if the SRB had a hook macro assembled into it. The bottom line is that the MVS implementation (or lack of it) of the TRAP instruction can be compensated through intercept technology. So now specifically to asynchronous exits. There are 3 ways to schedule asynchronous exits that I know of, by STIMER(M), by SCHEDIRB and by the old, SCHEDXIT. If there are other ways, please let me know. Since I haven't really started coding this I haven't finished all my research. STIMER(M) is by SVC. The existing TDF SVC intercept can be easily extended to include STIMER (M) . SCHEDIRB and SCHEDXIT are branch entry calls. TDF provides a mechanism called Branch Entry intercepts which are very special TRAP breakpoints that redirect execution of Branch entry calls (like SETFRR for example) to an intercept similar to the way SVC and PC interception works. Regardless of the type of schedule service, TDF replaces your exit address with a program that would wrap your exit. The front end would "stack" the prior trap environment and the back end would "unstack" it. This is a simple explanation to a complex problem. Kenneth -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Binyamin Dissen Sent: Tuesday, April 09, 2013 4:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Use of the TRAPx Instructions Looking as the DUCT, it also contains an indication of base address space or subspace. I would think that an ASYNC exit/IRB would not useethe basespace indicater of the current RB. On Tue, 9 Apr 2013 16:17:25 -0500 Kenneth Wilkerson <redb...@austin.rr.com> wrote: :>You are certainly correct about the z/OS implementation of the TRAPx :>instruction. I often wondered why the hardware designers decided to :>implement it such that it inherits the user state and not a predefined state :>and why they didn't provide a service to "register" trap interfaces so they :>could be shared or the asynchronous exit issue could be solved. You have to :>be able to acquire key 0 to even examine the DUCT let alone modify the DUCT :>to define the required trap control blocks. This means, of course, that the :>application creating the trap environment must be authorized. :> :> But despite these z/OS limitations, in my mind, the asynchronous exit :>issue is just a restriction. It's no bigger a restriction then the fact that :>the TRAP can't be executed in HOME ASC (SAC 768) or Secondary ASC mode (SAC :>256) or in transaction processing. Your scenario involves the asynchronous :>exit also invoking a TRAPx instruction. So simply stated, asynchronous exits :>cannot be debugged using the TRAPx instruction without a service to :>determine if the TRAP control blocks are currently in use and perform a TRAP :>stack function. But even this problem can be solved with a little extra code :>(a PC routine) that stacks the current trap save area if it's in use. :> :>Certainly, the TRAPx instruction has fewer limitations than other available :>methods. Every method is going to have restrictions. In my asynchronous :>exits, I typically simply update a control block and post a task to process :>whatever it is that I'm trying to process. :> :>Kenneth, TDF Architect :> :>-----Original Message----- :>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :>Behalf Of Morrison, Peter :>Sent: Tuesday, April 09, 2013 3:37 PM :>To: IBM-MAIN@LISTSERV.UA.EDU :>Subject: Use of the TRAPx Instructions :> :>I have had extensive experience with the use of the TRAPx (TRAP2/TRAP4) :>instructions in a z/OS environment. :> :>z/OS offers no support for setting up to enable them. Basically, you need :>to anchor things in the DUCT (Dispatchable Unit Control Table). There is :>one DUCT set up for each TCB and SRB. (Note that ONLY ONE DUCT is set up :>for a TCB - not one DUCT per RB level. THIS IS VERY IMPORTANT!) (preserving :>a specifically formatted DUCT is important, but is not relevant to the :>discussion below. Just be aware that there are issues associated with it) :> :>Generally, you can regard TRAPx as a 'fancy branch'. The target is the :>routine whose address is set up in the control blocks. The hardware saves :>all state in the 'trap save area' first. :> :>BUT, there is a very significant problem when using TRAPx with z/OS! When :>your trap routine gets control, system state is as before the TRAPx :>instructions was executed. This includes the fact that interrupts are :>probably enabled. Why does this matter? Because, in z/OS, in TCB mode, if :>an interrupt occurs, processing of that interrupt could involved :>de-scheduling the TCB, deciding to request a new RB level, and later, :>redispatching the TCB, so that the new RB level will get control. :> :>This can lead to the following scenario: :> :>1: TCB-mode code executes a TRAPx instruction :>2: The hardware saves all state (PSW/Regs) in the Trap Save Area :>3: The registered Trap handler routine is given control and starts :>executing... :>4: an interrupt occurs :>5: During processing of the interrupt, the current TCB has a new RB level :>stacked over it :>6: The TCB is resumed. Execution now is for the new RB level :>7: The new code executes a TRAPx instruction :>8: The hardware saves all state in the Trap Save Area. BAZINGA! The old :>information is overwritten! :>9: The registered trap handler routine is given control and starts :>executing... :> :>Because the trap save area has been overwritten, the lower-level handler, :>when it resumes execution, is not using correct information. There is not :>even any way to know that this has occurred. :> :>While the situation CAN be circumvented by preventing asynchronous RB :>stacking (there is a bit in the TCB for this), this can play havoc with :>debugging as, for example, asynchronous exits to do with I/O won't :>execute... :> :>For the above reason, use of TRAPx instructions as a way to implement :>breakpoints in code that executes on z/OS in TCB mode is not a good idea... :> :>Peter Morrison :>Principal Software Architect :>CA :>6 Eden Park Drive :>North Ryde NSW 2113 :>Tel: 02 8898 2624 :>Fax: 02 8898 2600 :>peter.morri...@ca.com :> :>---------------------------------------------------------------------- :>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 -- Binyamin Dissen <bdis...@dissensoftware.com> 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 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
