Providing recovery for recovery routines

In some situations, the function a recovery routine performs is so essential that you should provide a recovery routine to recover from errors in the recovery routine. Two examples of such situations are:

The availability of some resources can be so critical to continued system or subsystem operation that it might be necessary to provide a recovery routine for the recovery routine, thus ensuring the availability of the critical resources.
A recovery routine might perform a function that is, in effect, an extension of the mainline routine's processing. For example, a system service might elect to check a caller's parameter list for fetch or store protection. The service references the user's data in the user's key and, as a result of protection, suffers a program check. The recovery routine gets control and requests a retry to pass a particular return code to the mainline routine. If this recovery routine ends abnormally and does not provide its own recovery, then the caller's recovery routine gets control, and the caller does not get an opportunity to check the return code that it was expecting.

You can activate an FRR from either another FRR or from an ESTAE-type recovery routine. When activating an FRR from an ESTAE-type recovery routine, the ESTAE-type recovery routine must have acquired a lock after being entered, or the FRR must be an EUT FRR.

You should activate an ESTAE-type recovery routine only from an ESTAE-type recovery routine. IBM® recommends you do not activate an ESTAE-type recovery routine from an FRR, because it might not get control in the correct order.

Any recovery routine activated from a recovery routine is called a nested recovery routine. A nested recovery routine can retry provided the error for which it gets control is retryable. Whether the nested recovery routine can retry is independent of whether the recovery routine that activated the nested recovery routine can retry. For example, a recovery routine might get control for a non-retryable error. The recovery routine itself might encounter an error for which its recovery routine (the nested recovery routine) gets control and can retry. The retry routine from a nested ESTAE or ESTAEX recovery routine runs under the RB of the ESTAE-type recovery routine that activated the nested recovery routine.

Nested FRRs do not have access to their owning FRR's SDWA or 304-byte work area. The system makes a temporary copy of these areas and re-uses the original SDWA and work area when giving control to the nested FRR. Nested FRRs do have access to their owning FRR's 24-byte parameter area.