Only if you do tricky stuff. Such as playing with the PFLIH. If you get a program check there you may get a disabled wait. The FLIH will recognize unexpected recursion.
Don't know if there is a "standard" IBM supported way to do this, though. On Sat, 23 Dec 2023 10:20:58 -0800 Tom Brennan <[email protected]> wrote: :>Thanks Peter! I always appreciate your responses and also the responses :>from others at IBM. But I was trying to ask a question that I may not :>be able to ask correctly. Let me try anyway: :> :>I was referring to my experience with a JES2 exit which setup its own :>recovery routine. In that code you could see it free any getmain'd :>memory, etc. like you mentioned. But also in that code was an error :>that caused an 0C4. So when the x'00' I added for temporary debugging :>ran that user-coded recovery routine, I was surprised to get an 0C4 :>instead and had to fix the recovery routine. :> :>So of course JES2 had it's own recovery routine in place that handled :>the 0C4 and we got a dump and JES2 went on its merry way, perhaps after :>disabling that exit (I can't remember). :> :>So my question to Jon was, is there any environment in z/OS where there :>is absolutely no recovery routine? And if a program interrupt occurs I :>get no abend processing whatsoever and (I guess) a disabled wait. :>That's what I thought Jon was implying, that there are environments :>where I MUST code a recovery routine just to keep the system running at :>all. I don't think there is such an environment. :> :>And after all this typing I still am not sure I can relay my question :>correctly. So ignore it if I'm not making sense :) It's academic anyway. :> :>On 12/23/2023 7:54 AM, Peter Relson wrote: :>> Tom B wrote :>>> So are you implying that in z/OS there are environments where I can run :>>> a program without any built-in basic recovery? :>> :>> To be a bit snide, you "can" run a program without any recovery, of course. :>> Whether you should or not is an entirely different question. :>> :>> I view their being two main reasons for recovery (and not necessarily in the order I show): :>> :>> First, to deal with resources that might otherwise be left in an undesired state if you don't have recovery. :>> Maybe that's storage you obtained or an ENQ or lock that you hold or any number of other things :>> (perhaps even that you prefer to return to your caller with a return/reason code in that case rather than :>> an abend). But if you know that the system will release the resource in question in a timely fashion, maybe you don't care. :>> For example, suppose you know that you are the jobstep program and you obtain private :>> storage in a jobstep or task-related subpool and blow up, :>> Maybe you don't bother freeing it because you know that the task will terminate and the system will free the storage :>> (in your mainline you would probably free the storage for cleanliness reasons, but maybe you take the cheap way out in an abend case). :>> But if you might be called by something else, that's a different ballgame. In that case, :>> you do not know that the task will terminate - the caller might have recovery that retries. :>> :>> Second, to capture serviceability data such as what was running and what was going on in order to help diagnosticians. :>> That might be information in the SDWA and your use of recording to logrec; :>> it could be a message written to the job log (but calling almost any service out of :>> recovery might mention having recovery to protect something bad happening within that flow). :>> It could be a dump of some type. In the "freeing storage" case, :>> maybe the recovery isn't so much about freeing the storage but more about capturing data to help someone figure out what went wrong :>> :>> 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 -- Binyamin Dissen <[email protected]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
