I agree and disagree with John. I do have lots of places in code I have written that die a very ugly death at the point I get to an illogical situation because I do want to see what is going on at that instant.
In other cases, such as data exceptions, I swallow the error and send back a return code to the originator of the data. To say 'it depends on the situation' is an understatement. Is it important that the task survives, except in the most extreme cases? Can you re-start a new task and pickup where you left off? Many questions, many answers. After 45 years I have learned that there are as many ways to solve problems as there are programmers. I continually learn new things every day from interactions with others. If my comments were interpreted as being a hard and fast rule, then I am sorry. I think we all need to remember that what worked for us in a given situation may have been the 'best' solution, but any answer has to fit a given situation and mine may not be right for yours. Chris Blaicher Principal Software Engineer, Software Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8260 | M: 512-627-3803 E: [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of John Gilmore Sent: Wednesday, August 28, 2013 10:19 AM To: [email protected] Subject: Re: Task to subtask communications Chris Blaicher wrote: <begin extract> Rather than rely on task structure to limit failure damage, each task should establish its own recovery environment and pass back a return code via some non-destructive way. </end extract> and I suspect that we disagree sharply about this. That tasks should establish their own recovery machinery is certainly correct. Recovery is not, however, always possible; there are indeed situations in which it is seldom or never possible; and in my experience too much use of recovery machinery often muddies the waters, making diagnosis of the underlying problem or problems more difficult than it would have been if the at-failure-time environment had been better preserved. We are not, of course, dealing with an either/or situation here, but segregating operations that can fail in their own subtasks remains a very valuable device. In this sense "relying upon task structure to limit failure damage" is wholly appropriate. John Gilmore, Ashland, MA 01721 - USA ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ATTENTION: ----- The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
