Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!oliveb!tymix!antares!doctor!jms From: jms@doctor.Tymnet.COM (Joe Smith) Newsgroups: comp.sys.amiga.tech Subject: Re: MEMF_PHYSICAL? Summary: We're not the only ones with an unprotected single address space. Keywords: address protection Message-ID: <237@doctor.Tymnet.COM> Date: 2 Jun 89 22:40:18 GMT References: <8906010252.AA11810@jade.berkeley.edu> <367@xdos.UUCP> <7039@cbmvax.UUCP> Reply-To: jms@doctor.Tymnet.COM (Joe Smith) Organization: McDonnell Douglas Field Service Co, San Jose CA Lines: 60 Would you believe that an airline reservation system runs on a single-address system without memory protection? It's surprising they don't have more problems. Aren't you glad we don't have 1800 hard disks on a single Amiga? Newsgroups: comp.risks Subject: RISKS DIGEST 8.74 Message-ID: <12497182468.17.NEUMANN@KL.SRI.COM> Date: 26 May 89 23:13:37 GMT From: Andrew Birner Subject: SABRE disaster caused by "core corruption" According to an article by Margie Semilof, entitled "SABRE Recovers from Network Crash", in Communications Week, May 22, 1989, the recent SABRE outage occurred when the "Online DASD formatter was changed erroneously by another software program operating at the same time. This 'core corruption' resulted in the destruction of critical system data on SABRE's 1,800 DASDs." The article later quotes Jim Juracek, vice president of systems engineering for SABRE Computer Services: "All the predictable things are covered," Juracek said. "The unpredict- able things, such as when a software program gets clobbered by another program . . . [ellipsis hers] there is no way to work with this." ------------------------------ Newsgroups: comp.risks Subject: RISKS DIGEST 8.76 Message-ID: <12498530828.14.NEUMANN@KL.SRI.COM> RISKS-LIST: RISKS-FORUM Digest Wednesday 31 May 1989 Volume 8 : Issue 76 From: WHMurray@DOCKMASTER.NCSC.MIL Subject: SABRE >Is SABRE is too tightly coupled to its hardware to be moved to a >platform that provides hardware memory protection? Or is it just plain >too big to be ported? SABRE, like most reservation systems, runs on ACP or TPF. These high-performance, limited function operating systems run on hardware with memory protection, i.e., 370 XA. However, for performance reasons, they do not exploit the isolation features of the hardware. All application code runs in a single address space and at the same level of privilege. While this strategy is inherently dangerous, there are compensating controls imposed on application code. The strategy has been very successful. The res systems have achieved extraordinary reliability and stability for any kind of system, let alone systems which are both mammoth and monolithic. [discussion of portability deleted] If you were to begin today, knowing what we know, you would never permit anything so large and monolithic to come into existence. On the other hand it is too large, important, valuable, and vital to kill. Like many other successful applications from the sixties, it has a life of its own. While we may migrate many of its functions to compartmented sub-systems, the core is likely to be with us for a very long time. William Hugh Murray, Fellow, Information System Security, Ernst & Whinney 2000 National City Center Cleveland, Ohio 44114 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 -- Joe Smith (408)922-6220 | SMTP: JMS@F74.TYMNET.COM or jms@tymix.tymnet.com McDonnell Douglas FSCO | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-D21 | PDP-10 support: My car's license plate is "POPJ P," San Jose, CA 95161-9019 | narrator.device: "I didn't say that, my Amiga did!"