<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
