🚀 go-pugleaf

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 <Andrew-Birner%ZENITH.CP6%LADC@BCO-MULTICS.HBI.HONEYWELL.COM>
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!"