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
