Mike Butz writes: If a main program uses a Estae rtn then does Multiple Attaches specifying > the same ESTAE rtn on the ESTAI parm of the attach can the recovery routine > determine the abending TCB >
If you are getting control in any non-FRR recovery routine (ESTAI, ESTAE(x) or ARR) then the current TCB is always the abending TCB and, except in one "interesting" case, the error occurred in the current task. The interesting case is where CALLRTM TYPE=ABTERM is issued against your task by another unit of work, e.g. in the case of SRB to task percolation. The SDWA contains information about what was actually going on when the abend occurred and so if you're going to write robust error recovery code, you *REALLY* need to pay attention to that information. With that said, writing good general purpose recovery code is extremely hard. It is better and much easier to tailor your recovery as narrowly as you can to limit the recovery to the section of logic that you're trying to protect/deal with. For that reason alone the idea of using a single ESTAE routine as both an ESTAI and an ESTAE across multiple tasks and RBs within those tasks is just a bad idea unless you go to the trouble of building some underlying recovery infrastructure and leave plenty of footprint information so the recovery code can quickly determine "where" and "why" it is being entered and make sensible decisions about providing diagnostics and retry (or not). Most of the time the better path of valor is to request diagnostics, burp up a message about what went wrong and then percolate. You will seldom get in trouble for bailing out, but a surprising percentage of major failures come from ill-advised retry efforts. Another issue that almost always trips people up is the intersection between ESTAE-class recovery routines and the RB and linkage stack level. You need to read the topics on "providing recovery" very carefully and once you think you understand them, read them again twenty or thirty times. z/OS recovery has great power and flexibility, but it also has more ways of confounding and astonishing you than you can possibly imagine. So let me throw in some personal opinion. ESTAI recovery routines are worthless archaic garbage and should be completely avoided for any new code. They violate the principles outlined above and they build up like dandruff because they apply to every RB on every subtask. On the other hand ESTAE and ESTAEX, while they can be used very narrowly as outlined above, their use is specific to a particular (usually "P") RB and linkage stack level so you need to bracket your code with ESTAE creates and deletes with some frequency and that hurts performance. So if you're going to provide task-mode recovery these days, I would strongly recommend using IEAARR to "call" the code you want to protect. It is almost zero cost and you can tailor it as narrowly as you want. And may the force be with you... -- This email might be from the artist formerly known as CC (or not) You be the judge. ---------------------------------------------------------------------- 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
