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
