Bernd, you should be fine because in your environment any async exits that get dispatched will not have TRAP instructions in them. Traps would probably only be inserted into the exit code by a debugger. And since with our debugger, the code that gets control first for the exit is our code so we can handle the problem before any Traps are allowed to occur. It is an issue with the design of the Trap facility, which we were already aware, but there are a number of ways it can be overcome.
Chuck Arney Arney Computer Systems -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Bernd Oppolzer Sent: Tuesday, April 09, 2013 7:20 PM To: [email protected] Subject: Re: Use of the TRAPx Instructions Maybe, what's most important in this context: the test driver supports only single threaded testing, no subtasking. So, if I read your posts correctly, we should not have a problem, right? Kind regards Bernd Am 10.04.2013 02:08, schrieb Bernd Oppolzer: > Hello, > > I don't understand all of this discussion, but: > > we are using TRAP2 now for some time in our site specific debugging > tool without problems. I would like to know if you see a hidden > problem in our method of using it. > > Before switching to TRAP2, we did the same thing by catching 0C1 > abends with ESPIE. The method goes like this: > > from the compile listing (PL/1 or ASSEMBLER), we get the offsets of > interesting points in the load module, for example loop starts and > ends, procedure starts and ends, if ... then ... else etc.; these so > called "structure blocks" are marked after initial load (in the past > by hex zero, now with TRAP2 instructions). > > Then the module is called by the test driver; the test driver also > builds the parameter data from the test case database etc. > > Then the test driver exit catches the TRAP2 interrupts (in the past > the 0C1 abends) and lists all the program activitiy. Of course, it > restores the original opcodes and resumes execution after each > interrupt. > > There is only one TRAP2 handler routine which is registered in the > DUCT at start of the testdriver, using a special SVC. This is the only > place in the whole installation where TRAP2 is used. The programs that > we are testing are all application programs, TCB mode, as far as I know. > And: there will never be a second TRAP instruction before the handler > resumes using RP. > > Is there any risk that we will get into a situation like the one that > you described? > We never encountered any problem, so far. The system is z/OS, too, of > course. > > Thank you, kind regards > > Bernd > > > > > Am 09.04.2013 22:36, schrieb Morrison, Peter: >> 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 >> > > ---------------------------------------------------------------------- > 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
