I took a look at your website and it isn't clear to me which products would have to constantly reissue ESTAEX.
You certainly could define PC-CP routines that handle the IEAARR yourself and completely avoid the issue. On Thu, 7 Dec 2023 10:06:36 -0800 Ed Jaffe <edja...@phoenixsoftware.com> wrote: :>On 12/7/2023 5:22 AM, Peter Relson wrote: :>> Tom H wrote :>> <snip> :>> There is another difference between running under an ESTAEX and an IEAARR, and that is you cannot use IEALSQRY to determine the linkage stack depth if you need it for retry. You must keep track of it yourself. :>> </snip> :>> :>> That's a good observation. And you're right. But it is not intentional. That was an oversight from when I created IEAARRs 25 years ago. Those PC numbers are treated specially by RTM and do not have a "true" ARR (which is why IEALSQRY does not play well with that situation), rather the linkage stack entry itself has the information needed to give control to your recovery routine. No one had ever brought that to my attention. :> :>We wondered if this oversight was APARable. Tom decided to keep track of :>it himself, but I can envisage situations for other products where :>someone else's code can get control (in-between) and potentially cause :>problems for this approach. :> :>We have observed IEAARR is so much faster than ESTAE[X] that we want to :>convert some of our existing products over to use it. But, this IEALSQRY :>issue is a sticking point that fills me with some trepidation and FUD. :> :>Would it be okay if we opened a case about this with L2...? -- Binyamin Dissen <bdis...@dissensoftware.com> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
