Peter, thanks, no the IBM documentation is not "confusing." The concepts are somewhat complex, and I have not written any ESTAE code in nearly twenty years. I get it now, I think.
The problem is the intersection of what I want to do, what MVS wants to do, and what LE wants to do. We are in some conflict there, and I think MVS and LE are going to win this argument. <g> I am going to start a new thread. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Peter Relson Sent: Wednesday, August 28, 2013 6:21 AM To: [email protected] Subject: Re: Questions about ESTAE(X) A recovery routine cannot change SDWACLUP (or most of the fields in the SDWA) and have such a change be useful to anything. If you are intended to change it, usually SETRP will let you do so, or it's a field relevant to retry or it's one of the "communication" fields. SDWACLUP is on not only for TERM=YES but also for all other retryable abends. >if I don't issue any ESTAE(X), then >*something* gets control on "normal" ABENDs That's called RTM, regardless of the type of abend. >Am I correct that you apparently can't issue an ABEND macro >(effectively) in >a recovery routine? I would so "no" but it depends what you mean by effectively. Once termination begins (think cancel) an ESTAE(X) without TERM=YES will not get control, but an ESTAE(X) with TERM=YES will. I think that applies to nested recovery too (a nested recovery routine is a recovery routine set within the ESTAE(X) routine itself). For TERM=YES, normal rules of nested recovery, percolation, and even retry apply (a nested recovery routine can retry back to the recovery routine that created it; it cannot retry back to the mainline). >if an ESTAE(X) TERM=YES is chained after an ESTAE(X) TERM=NO, is there >any way to get the chained recovery routine to percolate a >TERM=YES-type ABEND? I must not be understanding. The "chained recovery routine" in the sentence above appears to be the TERM=YES routine. It can of course "percolate" a "TERM=YES-type ABEND" (in fact it has no choice but to percolate). But when it percolates, the TERM=NO routine will not get control, specifically because it is TERM=NO and this was a "TERM=YES-type ABEND". So overall, I really don't know what is confusing. The basic point is "if you have nothing to clean up if the job is going to terminate due to the error, then you usually do not need TERM=YES". For example, if you might ordinarily freemain something, but if the system will do so upon job termination (as it will, in effect, do for region subpools) then you might choose not to worry about getting control in recovery for that termination case to do the freemain. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
