SRB-to-task percolation

Start of change When an SRB is scheduled and the fields SRBPASID and SRBPTCB are supplied, or IEAMSCHD is used with the PTCBADDR= parameter and SYNCH=NO, the specified TCB is defined as the SRB's related task. This TCB is in the ASID specified by SRBPASID or the Home ASID of the issuer of IEAMSCHD. When an SRB with a related task ends abnormally and the FRR for the SRB does not exist or does not request a retry, the error is percolated to the recovery routine for the related task. This percolation is called SRB-to-task percolation. End of change

SRB-to-task percolation occurs if none of the FRRs defined by the SRB retry, or if the SRB does not have an FRR. Either case creates a request for the system to perform SRB-to-task percolation. The system ignores the request whenever the related task has already ended. If serialization is requested on the SETRP macro in the FRR for that SRB, the percolation request is deferred if the task is already in recovery. (See the SERIAL=YES parameter of the SETRP macro in z/OS MVS Programming: Authorized Assembler Services Reference SET-WTO.) Serializing SRB-to-task percolation ensures that information about multiple SRB failures is not lost.

Note: SERIAL=YES should not be specified unless the task's recovery routine expects it.

The system processes requests for non-serialized SRB-to-task percolation as follows: the system abnormally ends the task and passes the information about the SRB's error to the most recently activated recovery routine for the task.

The system processes requests for serialized SRB-to-task percolation as follows:

If the task is already in recovery, the system saves and queues the information about the SRB's error for processing later when the task recovers from the previous error.
If the task is not in recovery, the system abnormally ends the task and passes the information about the SRB's error to the task's recovery.

When one of the task's recovery routines that is not a nested recovery routine (defined in Providing recovery for recovery routines) requests a retry and retry is allowed, the system checks for queued requests for SRB-to-task percolation and takes the following actions before performing the retry:

If any requests are queued, the system dequeues a request and again enters the recovery routine that requested the retry. The system repeats this process as long as there are queued requests.
When the queue is empty or depleted, the system honors the retry request and gives control to the retry routine.

Figure 1 shows this process.

The environment for a task recovery routine entered as a result of SRB-to-task percolation is the same as the environment described earlier under Percolation for the same unit of work.

However, the information in the SDWA describes the error that occurred in the SRB. Whenever serialized SRB-to-task percolation is requested and the system must queue a request, the system obtains an area from the user's private area to preserve the information about the SRB's error. If no space is available, the system cannot preserve that information but still enters the task recovery for the request. If an SDWA is available, the system sets the SDWARPIV bit to indicate that error-time information is not available. Also, the system sets the SDWACOMU field to zeros because the system cannot preserve its contents to pass from the SRB's FRR to the task's recovery routine.