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 [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
