The following are additional things you should consider that are
specific to ESTAE-type recovery routines:
- During processing of the first and all subsequent recovery routines,
the system allows or disallows asynchronous processing (such as a
timer exit) depending on how you specify the ASYNCH parameter when
you define the routine (that is, through the ASYNCH parameter on ESTAE,
ESTAEX, and ATTACHX).
- The following list describes what the system does when it is done
processing a particular recovery routine (either because the recovery
routine percolates, or because the recovery routine itself encounters
an error and has no recovery routine of its own that retries):
- Accumulates dump options
- Resets the asynchronous exit indicator according to the request
of the next recovery routine
- Ignores the I/O options for the next recovery routine
- Initializes a new SDWA
- Gives control to the next recovery routine.
If all recovery routines fail or percolate, the task is terminated.
- If a non-job step task issues an ABEND macro with the STEP parameter,
the system gives control to recovery routines for the non-job step
task. If the recovery routines do not request a retry, the job step
is terminated with the specified completion code. Subsequent recovery
routines for the job step task get control only when you specify TERM=YES
on the macros that defined those recovery routines. You can specify
TERM=YES on ESTAE, ESTAEX, FESTAE, and ATTACHX. ARRs always get TERM=YES.
If
the recovery routines for the job step task do not retry, subsequent
recovery routines for any other non-job step tasks get control in
the same way they would if the job step task itself encountered the
error and then did not retry.
- For some situations, the system gives control to ESTAE-type recovery
routines only when the TERM=YES parameter was
specified (including ARRs, which always get TERM=YES). The situations
are:
- System-initiated logoff
- Job step timer expiration
- Wait time limit for job step exceeded
- DETACH macro was issued from a higher level task (possibly by
the system if the higher level task encountered an error)
- Operator cancel
- Error occurred on a higher level task
- Error in the job step task when a non-job step task issued the
ABEND macro with the STEP parameter
- OpenMVS is canceled and the user's task is in a wait in the
OpenMVS kernel.
When the system gives control to the recovery routines defined
with the TERM=YES parameter as a result of the above errors, the system
takes the following actions:
- Sets the SDWACLUP bit
- Gives control to all such routines in LIFO order
- Does not enter any ESTAI routine previously suppressed by a return
code of 16, or any previously entered recovery routine that requested
percolation
- Ignores any request for retry.