> How is SRB to TCB percolation instantiated? RTM1 looks for and dispatches any FRRs that are active. When all of those have percolated, it locates the designated "victim" TCB (hidden under a rock at SCHEDULE time) and schedules an ABTERM to that task.
That victim task's current recovery routine (if any) gets an SDWA with the SDWAERRx flags set to indicate the task/RB wasn't in control at the time of the error. If you don't spot those the error can be an utter mystery. > Is an automatic FRR added which does the percolation if nothing recovers? No. It is RTM itself that does all of that. > Stored somewhere in memory? Well obviously it must be, but it is not something you can change. The identity of the victim is placed in SRBPTCB prior to the SCHEDULE macro being issued. The system stores that under a rock prior to dispatching the SRB and in the SSRB if the SRB is suspended. You can probably figure out what rock that is, but it would be a bad idea to try to change it. As an OBTW, I really don't like this particular behavior. It was a cheesy way to indicate to the scheduler that the SRB had gone belly up. It is a royal pain in the butt dealing with asynchronous abends arising from this particular piece of arcana. I never set the purge TCB address in SRBs that I use. Something a little more elegant is called for. CC ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
