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
