Linkage stack at time of retry

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.