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
