There is one retry situation you must avoid: the situation where
the retry routine runs with a linkage stack entry that is inappropriate.
Consider the following example, where PGM1 activates an ESTAEX routine
that handles recovery for PGM1, PGM2, and PGM3.
caller ---> PGM1
BAKR
:
ESTAEX
:
BALR --------> PGM2
BAKR
:
BALR --------> PGM3
BAKR
***abend***
:
retry point
:
<-------- PR
Both PGM2 and PGM3 use the BAKR instruction to save status; each
BAKR adds an entry to the linkage stack. Within PGM3,
"retry point" indicates
the location where the ESTAEX routine is to retry. After PGM3 issues
the BAKR instruction, the last entries in the linkage stack are:
- Entry 1 -- caused by PGM1's BAKR
- Entry 2 -- caused by PGM2's BAKR
- Entry 3 -- caused by PGM3's BAKR
When the abend occurs in PGM3, unless you take special measures,
the linkage stack level is reset to the level that was current when
PGM1 activated the ESTAEX recovery routine. However, retry from the
abend in PGM3 occurs within PGM3. The linkage stack level and the
retry routine are not
"in synch". Measures you take to avoid
this situation involve:
- Passing the recovery routine a value that represents the difference
between the level of the linkage stack that the retry routine in PGM3
needs and the level of the stack at the time PGM1 activated the ESTAEX
routine. (In our example, the difference is 2 entries.)
- Having the recovery routine set the value "2" in the SDWALSLV
field in the SDWA.
At a retry, the system uses the value in SDWALSLV to adjust the
linkage stack. In this way, the retry routine has the appropriate
current linkage stack entry.
Two ways your program can track the entries in the linkage stack
are:
- Count the number of entries added to the stack through BAKRs since
PGM1 activated the ESTAEX routine. Subtract from that total the number
of entries taken from the stack through corresponding PRs.
- Issue the IEALSQRY macro, which returns the number as output.
In either case, the recovery routine must receive the value and
must place it in SDWALSLV. In summary, the value in SDWALSLV is the
difference between the number of linkage stack entries present when
the retry routine gets control and the number that were present when
the recovery routine was activated. The system preserves the additional
entries on the linkage stack for use by the retry routine. These
linkage stack entries must exist at the time of the error; the system
does not create any new entries.
The following rules apply to the value in SDWALSLV, as it pertains
to linkage stack entries:
- The system ignores the value when the recovery routine is a STAE,
STAI, or FESTAE routine.
- When retry is from an FRR, the value can reflect entries caused
by a PC instruction. All other times, the value can reflect only
entries caused by a BAKR.
- For unauthorized ESTAE-type recovery routines, all entries must
have the same state (problem or supervisor) and have the same PSW
key as the program that activated the recovery routine. For authorized
ESTAE-type recovery routines or FRRs, this restriction does not apply.
- For ESTAE-type routines, the value must reflect only those entries
associated with programs that have been established by a program running
under the RB of the retry routine. See RB considerations.
If any of these rules are broken, retry still occurs but the system
ignores the entry that did not conform and all subsequent entries.