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 SDWALSLV field when retry is from a STAE or STAI recovery routine.
The value must not reflect entries that were placed on the linkage stack through a PC instruction.
The value must reflect only those entries associated with programs that are problem state and running with the same PSW key as the program that activated the ESTAE-type recovery routine.
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.