Yes, and I'd add:
if you get 4096 - free 4096
Don't free 1024 like I did once. Code like that tests just fine but
then dies 8 hours later when the address space runs out :)
On 12/23/2023 8:12 AM, Colin Paice wrote:
Expanding on what Peter said. It is horses for courses.
If you are writing a program which can be running for months before restart
you need to clean up everything - for example ensure any storage obtained
is released.
Someone gave me some guidance
if you open it - close it
if you get it - free it
if you lock it, - unlock it
if you change something (which is not yours) unchange it
Leave nothing but footprints (trace entries)
You need to release locks (in the correct order) to maintain transactional
and data integrity. Think of two phase commit, and with database updates -
all updates need to occur or none.
In some of the code of the product I was involved in - sometimes there was
the same amount or more code in the recovery routine than in the mainline
code!
Colin
On Sat, 23 Dec 2023 at 15:55, Peter Relson <[email protected]> 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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
