Believe it or not, a lot of thought DOES go in at the Operating System level about the proper action to take for a given problem. When I was learning about Parallel Sysplex in zOS, for example, we were told that there are certain failures that can take down the entire sysplex (all participating machines). One of these is failure of the common time reference. If the clocks get out of sync, BOOM!
At first glance, this sounds horribly radical, but the logic was simple: Maintaining data integrity is the first priority. Under certain types of failure situations, where data integrity was threatened, the best solution was to stop everything so it could be restarted in a controlled fashion. Long, long ago, when MVS was first being designed, a conscious decision was made regarding recovery. Every routine in the OS had to be protected by a recovery routine, or by the recovery routine of it's caller. The idea was to prevent a single application or component failure, no matter how serious, from affecting the rest of the workload. End user applications are EXTREMELY well insulated from the OS. Even OS component failures don't do anywhere near the harm they did in earlier operating systems. This doesn't mean the applications don't fail, they just don't usually take anyone else with them. When an application abends, it's because something has happened that it can't handle. Not that it COULDN'T handle it if it wanted to. There are SPIE and STAE exits provided that can catch just about ANY error condition (including operator cancel), and try to do something about them, but covering all possible contingencies is just too much for the average programmer, and would make the apps orders of magnitude more complex. At least with zOS, you get a dump and diagnostic information that you can use to track down the problem. You also have manuals to explain the codes and error messages. By default, you get almost NOTHING from Windows (there isn't even a manual to explain the failure codes), and very little from the various ix-es. > -----Original Message----- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of > Adam Thornton > Sent: Tuesday, October 28, 2003 2:43 PM > To: [EMAIL PROTECTED] > Subject: Re: [LINUX-390] Memory access faults. > > > On Tue, 2003-10-28 at 13:32, Fargusson.Alan wrote: > > > The problem with laying this at the feet of the application > programmer > > is that they are not perfect, and when the program fails it actually > > the end user that suffers. > > Yes, but do you have a better suggestion? > > I mean, in the common case, you got this error because somewhere, > there's a pointer that's pointing at something that's not > yours to read > (or write). Probably that's an application error; maybe it's > a hardware > failure. In any event, what *is* the correct behavior? > > You certainly don't want to give bad data to the end user. You don't > want to give him whatever happens to be at that address, > since it almost > certainly isn't what he really wants and if he uses it he's basing a > decision on bad information. What *do* you do other than > say, "Uh, this > program tried to go grab hold of the wrong thing; please > report a bug" ? > > Adam >
