I got a SYSUDUMP from the client and the contents of the active linkage stack entry seems consistent with the BAKR/PR code. However, there's an extra PRB which I think is causing the actual mismatch! I know why it's there, and will have to redesign the logic to ensure it exits properly.
Thanks to all who responded. Robert Ngan CSC Financial Services Group From: John Gilmore <[email protected]> To: [email protected] Date: 2011/12/12 16:25 Subject: Re: Quick test for empty stack? Sent by: IBM Mainframe Assembler List <[email protected]> Chris Craddock has given you some very good generic advice. What I want to do is to make clear that [only] some forms your problem can take are comparatively easy to diagnose. An analogy will help here. We all know that unbalanced parentheses are easy to diagnose. One sets a counter to zero and scans the expression containing parentheses from left to right, start to finish, adding 1 to the counter for every left parenthesis encountered and subtracting one from it for every right parenthesis encountered. Then, if the resulting count is not zero when EOE is reached, its parentheses are unbalanced. This is true enough, but its converse is not: What are not so often discussed are 1) that the final count can be zero for an expression containing unbalanced parentheses and 2) that more diagnostic information is available from this scan than that provided by its global. outcome. Consider the sequence of parentheses ( +1 ( +2 ) +1 ( +2 ( +3 ( +4 ) +3 ) +2 ) +1 ( +2 ) +1 ) +0 ) –1 ( +0 . . . The final count is zero, but these parentheses are not balanced. The count of -1 makes this clear. It identifies the presence of an extra, irrevocably incorrect right parenthesis (along with a subsequent--gratuitous because unmatched--left one). In fact every zero in such a sequence marks the the beginning of a new subsequence that can be examined independently. In your situation, assimilating left and right parentheses to (stacking) BAKRs and PRs, a count of -1 corresponds to an attempt to pop an empty linkage stack, a deficit of BAKRs. Have you encountered this situation.? If not, . . . If you in fact have access to the source code you can run your own counter. Use OPSYN, write a pair of macros that generate code to increment/decrement such a counter, execute BAKR/PR, etc., etc. Et voil� ! You have instrumentation without source-code modification. Take away the OPSYNs and the status quo ante is restored. As Chris Craddock has already noted, such a botched sequence can be without external symptoms for a time. It is a stroke of luck when they appear immediately; and a counter of this kind may be helpful in identifying where to begin to look (before symptoms, which are often misleading, appear). John Gilmore, Ashland, MA 01721 - USA
