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
