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...?
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/
--------------------------------------------------------------------------------
This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
