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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
