sjl@amdahl.UUCP (Steve Langdon) (08/14/86)
In article <266@dmsd.UUCP> bass@dmsd.UUCP (John Bass) writes: > Mac memory run's without parity and certain ESD events, AC line faults, and > other powersupply problems can leave bits corrupted in memory without detection. > Furthermore the error detection on Mac floppies is very poor. > > Using computers without parity protection in critical medical service is a > timebomb -- the resulting missinformation may kill someone. > > I would say than any use of a mac to maintain charts, medication, or provide > advisory AI services should be avoided ... use an IBM computer or some > UNIX machine with parity memory and much better disk channel error detection. > > Non-parity machines make nice toys, but I hope they stay out of medicine and > other critical applications (fire, police, military, CIA, FBI, etc) where > peoples lives are at stake. [Sorry for the long quote, but it all seemed important] I find myself in the rather unusual position of being forced to disagree with John who's opinions I normally respect. However, in this case I feel that he is making a serious error in suggesting that parity and disk channel error detection are the things that make a system suitable for "critical applications" Good system design and proper checks and balances are much more important than the difference between a small amount of error detection hardware and a medium amount of error detection hardware. I suspect that at least 2 orders of magnitude more errors result from bad software design than the problems he mentioned. I believe that further discussion on this topic should move to mod.risks, but I have not used a "Follow-up to" line to enforce this as others may disagree. -- Stephen J. Langdon ...!{ihnp4,cbosgd,hplabs,sun}!amdahl!sjl [ The article above is not an official statement from any organization in the known universe. ]
mazlack@ernie.Berkeley.EDU (Lawrence J. Mazlack) (08/15/86)
>> From: PUGDOG (11554) >> Subject: Medical Uses of a MAC >> >> BUT, lately, due to availability at work, I have been playing with the MAC >> a little, and realize it does have some nice features. I am still not >> convinced it is a legitimate machine for anything but graphics, ESPECIALLY >> FOR USE IN MEDICINE -- I AM NOT CONVINCED! >> >> In fact, no one has been able to convince me. I haven't found one legitimate >> application -- enven "manufacturers" of "rumored" products have not sent >> the information they have promised. > >Mac memory run's without parity and certain ESD events, AC line faults, and >other powersupply problems can leave bits corrupted in memory without detection >Furthermore the error detection on Mac floppies is very poor. > >Using computers without parity protection in critical medical service is a >timebomb -- the resulting missinformation may kill someone. > >I would say than any use of a mac to maintain charts, medication, or provide >advisory AI services should be avoided ... use an IBM computer or some >UNIX machine with parity memory and much better disk channel error detection. > >Non-parity machines make nice toys, but I hope they stay out of medicine and >other critical applications (fire, police, military, CIA, FBI, etc) where >peoples lives are at stake. Actually, I don't think that this is such a big problem. BUT, I do think that weak product support and short product lifetime makes it a tough choice because just about the time that you have developed an application, the machine and it's interfaces changes -- and there you are, having dropped serious resources into a machine that is poorly supported (because it is "obsolete") and requires significant hassle to integrate with new equipment. Macs are real nice for technology mavens and short term word processing, but are probably a marginal call for an application where the cost of the computer is not important in comparison to the cost of the information that has been gathered.
bass@dmsd.UUCP (John Bass) (08/17/86)
In article <3544@amdahl.UUCP>, sjl@amdahl.UUCP (Steve Langdon) writes: > > I find myself in the rather unusual position of being forced to disagree with > John who's opinions I normally respect. However, in this case I feel that he > is making a serious error in suggesting that parity and disk channel error > detection are the things that make a system suitable for "critical applications" > Good system design and proper checks and balances are much more important than > the difference between a small amount of error detection hardware and a medium > amount of error detection hardware. I suspect that at least 2 orders of > magnitude more errors result from bad software design than the problems he > mentioned. > -- > Stephen J. Langdon ...!{ihnp4,cbosgd,hplabs,sun}!amdahl!sjl I have used macs for nearly two years, and have noticed both memory and disk data corruption without comment from either the OS or hardware. Unreported disk read errors resulting in random software failures are common on Macs -- Most people just try another disk or drive and live with it. I shudder to think my life might require trusting a mac somewhere. Before ANY software validition can be correct its LOADED and RUNNING image must be correct -- I.E. reliance on distorted software is futile. I hope that Stephen is not suggesting that it's hopeless so why bother. I contend that certain MINIMUM AND RELIABLE hardware checks are necessary to support higher level decisions on integrity. In critical applications this includes power certification, hardware certification, AND SOFTWARE certification. The Mac is extremely at a disadvantage here since it lacks both minimum hardware error detection and hardware memory management to protect the OS from corruption by applications (which may distort operation of applications run at a later time). Will Stephen please clearify what he disagrees with??? Is he really suggesting that the hardware checks are not necessary and that software only checks are enough?? Or does he agree that minimum hardware checks are necessary, and that I am in error only by not taking a stronger stand, I.E. requiring that the system environment, system hardware, and system software must all be validated?? I don't think that mod.risks is the right place to complete this discussion for two reasons -- most people using macs don't read it -- and -- we are talking specifically about the short commings of using Macs for a certain application. -- John Bass (DBA:DMS Design) DMS Design (System Design, Performance and Arch Consultants) {dual,fortune,polyslo,hpda}!dmsd!bass (805) 541-1575
sjl@amdahl.UUCP (Steve Langdon) (08/29/86)
In article <267@dmsd.UUCP> bass@dmsd.UUCP (John Bass) quotes my reply to his earlier posting on this subject, and says: > > I have used macs for nearly two years, and have noticed both memory and > disk data corruption without comment from either the OS or hardware. > Unreported disk read errors resulting in random software failures are common > on Macs -- Most people just try another disk or drive and live with it. > I shudder to think my life might require trusting a mac somewhere. > > Before ANY software validition can be correct its LOADED and RUNNING image > must be correct -- I.E. reliance on distorted software is futile. I hope > that Stephen is not suggesting that it's hopeless so why bother. I contend that > certain MINIMUM AND RELIABLE hardware checks are necessary to support higher > level decisions on integrity. In critical applications this includes power > certification, hardware certification, AND SOFTWARE certification. The Mac > is extremely at a disadvantage here since it lacks both minimum hardware error > detection and hardware memory management to protect the OS from corruption by > applications (which may distort operation of applications run at a later time). > > Will Stephen please clearify what he disagrees with??? Is he really suggesting > that the hardware checks are not necessary and that software only checks are > enough?? Or does he agree that minimum hardware checks are necessary, and that > I am in error only by not taking a stronger stand, I.E. requiring that the > system environment, system hardware, and system software must all be validated?? > ... I am saying that you must carefully analyze the requirements of the application and ensure that the complete system meets the appropriate criteria. This includes the hardware, software, and human aspects of the system design. Checks and balances involving each of these elements are often necessary. It is also important to avoid over-specifying a system just because a code word like "medical" is used; in the DOD procurement area this is known as "gold plating". The original request was: > I am in medical school, and am designing and installing medical office > systems. I would like a good package for the MAC. BUT I need to FIND ON > first!!! I do not believe that the Mac is any less suitable to keep track of a doctor's calendar than any of the other micros that might be used. The other causes of error in this application are so much more significant than those introduced by a micro (even without parity) that it would be stupid to demand triple-redundancy or other such measures used in highly sensitive applications. Other follow-up messages showed examples of appropriate use of the Mac in medicine. For example: > ... I use the Mac for everything from writing manuscripts > for publications to creating exhibits for meetings to organizing and > managing patient data... > I would have to agree with Franklin Tessler that the Mac is a > wonderful tool for the physician who is in the business of information > transfer. Many fields of medicine are very visually dependent, such as > radiology, pathology, surgery, etc. In order to transfer information, > diagrams are often a necessary part of the process. There is no better > desktop computer on the market for this type of work. Granted, the > ... > By the way, there is software available right this very moment for > sportmedicine. I happen to have a nice template for Filevision that combines > anatomic diagrams interactively with the database of information on various > jogging, skiing, etc. minor injuries. It is a very effective way of keeping > track of this information, for reference as well as patient education. I'd be > glad to send you a demo if your interested. I don't believe that there is > anything on the IBM that even comes close to the filevision program. Both these quotes describe applications that the Mac fits well. I doubt that many would argue with the clerical applications, but those who worry about graphic applications such as radiology should consider the error properties of the sensors. Even if one were to incorrectly assume perfect input, how many frame buffers have parity, let alone ECC? On the other hand, if the computer running a life-support system relied on normal commercial quality error detection hardware I would be aghast. Careful use of reliable hardware, paranoid software, and alert users is essential. I hope that this rather longer explanation of my views provides the clarification John (and possibly others) wanted. -- Steve Langdon ...!{decwrl,sun,hplabs,ihnp4,cbosgd}!amdahl!sjl +1 408 746 6970 [I speak for myself not others.]