>From a z/OS architectural point of view you're not supposed to be aware of the >linkage stack depth. The (possibly naive) view implicit in the software >architecture is that if your program adds a linkage stack entry then it should >also remove it. Most of the problems you will encounter with the stack arise >from one of two causes. The first is simple programming errors; adding and >then not removing an entry, or removing more than you added.
The other (more subtle) error is assuming that the linkage stack contents at the time of an abend will be the same at the point of retry. If you add stack entries AFTER setting a recovery environment, then (by default) those will be gone when you get control after a retry. You can change that behavior by explicitly setting the SDWALSLV value, but that's potentially problematic in a chicken and egg sense. Another important point is that what you read about in PoPs is not necessarily the way z/OS materializes the stack from a software POV. The definition of "empty" depends on a variety of factors. For example, any stack entries created by a prior RB are not accessible, so it is possible to have a non-empty linkage stack that appears empty relative to the current RB. And there are complexities regarding the intersection between the linkage stack and recovery. IEALSQRY was intended to be used in conjunction with recovery routines. As such it deals with all the nuances of the ways that the stack might be "shaped" at time of entry - which is a polite way of saying it is kind of a performance pig. The best way to catch one of these problems is to set a slip trap for the offending condition and then take a look at the dump. CC Sent from my iPad On Dec 9, 2011, at 1:49 PM, "Robert Ngan" <[email protected]> wrote: > Yes it's z/OS (MVS). Thanks for the hint, I found IEASLQRY and will look > at that.
