Peter,
Thanks for the corrections.
It's been awhile since I looked at the logic.
Sometimes I forget things.
Best,
Dave
At 11/23/2023 08:56 AM, Peter Relson wrote:
<snip>
Jon Perryman <jperr...@pacbell.net) wrote:
> 3. Abend recovery can be more difficult. It's been a long time but if I
> remember correctly, ESTAE creates a linkage stack entry and an abend causes
> linkage stack entries to be flushed up to the ESTAE entry thus limiting
> recovery to the CSECT which requires setting up recovery environment for
> each point that requires recovery.
That's not quite correct. What happens is this:
* ESTAE-create does not create LSEs (Linkage Stack Entries). What
it does do is mark the LSE that is current at the time of ESTAE-create.
* Then ESTAE cancel will purge all LSEs that are newer that what
existed at ESTAE-create time.
That can be quite a rude surprise if you're using BAKR/PRs without
regard to ESTAE-create points.
<snip>
That's not quite correct either.
ESTAE(X) cancel does not do that. The sequence of
ESTAE(X) create, BAKR, ESTAE(X) cancel
is rejected with return code x'24' because you are not canceling
from the right linkage stack entry.
It is retry from any recovery routine (ESTAE-type or FRR-type) that
by default resets the linkage stack to the time-of-set entry.
You can consider that a "purge" if you want. It doesn't typically
have to do anything to "purge", just reset the "current pointer".
This default can be overridden by setting SDWALSLV within your
recovery routine.
For example, set to 2 if you want the retry to be two entries past
the time-of-set linkage stack level. There are authorization
restrictions with respect to how far you can go.
Perhaps you were thinking about PR canceling an ESTAE-type recovery
routine that is associated with the former linkage stack level.
That does happen. That is analogous to what happens if you end an
RB with which an ESTAE-type recovery routine.
ESTAE-x recovery is removed by the system automatically when the RB
with which it is associated terminates
or when the linkage stack entry with which it is associated is removed.
BAKR is simply not a great approach for saving registers from module
to module. Recovery complications are one of the downsides.
Performance is another. Limitation on the size of the linkage stack
(unless you expand it) is another.
Most find that BAKR is nice for initial entry, but intra-component
linkage is better handled with save areas.
You're not going to want to set up new recovery for every module
that gets control (both for complexity and performance).
Many z/OS components have the concept of a "recovery mainline" with
individual modules each providing a "module recovery exit". The
recovery mainline calls each appropriate module recovery exit, so
that the module recovery exit can take care of logic specific to
that module, with the recovery mainline doing the routing and taking
care of logic that is general to the flow. We find that that makes
it more natural to keep recovery in synch with module changes.
Peter Relson
z/OS Core Technology Design
