> All I want to do at this point is determine where the mismatching BAKR/PR > occurs. That is quite difficult because from the application point of view, anyone can issue a BAKR or PR any time and, unless the stack just happens to be full, or empty relative to the current RB, the instruction will just "work". In the case of a misplaced PR that can cause you to be flung back to somewhere unexpected. Unfortunately the stack restores the registers (excl 14-1) and PSW state perfectly, so more often than not, that particular error may go unnoticed for a long time. > We can't "see" which is the active stack entry, but can at least > compare the the contents of the stacked registers in the current entry > before/after a suspect call and assume there's a mismatch if they're > different. That's not a definitive test. But perhaps better than nothing at a pinch. > The empty stack condition is a non-issue as it turned out the invoking > program using BAKR/PR so if we encounter an empty stack condition it is > also a mismatch. The single most likely cause is mismatched entry/exit linkage between a calling function and an internal subroutine or another external function. If you have access to source code you might find it just by having a general idea of where the problem is occurring and then browsing the listings. Otherwise you will probably need to pull out the big guns. Set a slip trap and catch a dump for the problem you're seeing. Then (in IPCS) format the linkage stack and look for evidence. If the events are close enough there will be residual data in the stack entries that can give you a clue. CC
