I rarely use TERM=YES. I use RTM exits almost exclusively for error reporting and setting a retry. About the only time TERM=YES is used is in the primary driver task for a cross memory server so that its RTM exit can reset the PC services available flag to minimize D6 abends. But I don't even rely on that. I just code the calling interfaces to treat and report D6 abends as unexpected server terminations. I rely on the RTM to cleanup address space and task level resources. The real issue is common resources that are shared system wide or between 2 or more address spaces. For this, I prefer resource managers, particularly address space resource managers. And I know its authorized and probably only necessary for cross memory servers which by definition must be authorized. This may seem off topic but the topic is about cleaning up after a termination event (TERM=YES) such as a CANCEL.
Address space resource managers are guaranteed to execute, even if an address space is forced. Consider an address space that has terminated because it has exhausted its memory. If you have anything but the simplest tasks to perform, there may not be storage to do cleanup. My experience is that in serious error conditions, the RTM exit may not be the best way to cleanup common resources. The only advice I have is that if you define an address space resource manager, be sure you have a timer exit to time it out should it go in a loop. This probably will never get used but a loop in an address space resource manager, which runs in the master address space is a non-trivial problem. Do with this information as you wish. But if you are considering TERM=YES for anything but the simplest resource cleanup, consider a resource manager. I rarely use TERM=YES. I prefer resource managers. And I only use resource managers to cleanup common resources. Most of the stuff I write uses neither. Kenneth -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Peter Relson Sent: Wednesday, August 28, 2013 8: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. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
