From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-0.0 required=3.0 tests=BAYES_20 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 13 Jul 93 23:15:23 GMT From: agate!howland.reston.ans.net!usc!cs.utexas.edu!milano!photon.mcc.com!brel and@ucbvax.Berkeley.EDU (Mark A. Breland) Subject: Re: In defense of Admiral tuttle Message-ID: List-Id: In article 93Jul13120046@goldfinger.mitre.org, emery@goldfinger.mitre.org (Davi d Emery) writes: >A problem that I've seen with much of the rush towards 'consortium' >solutions (and this is NOT a criticism of MCC or any particular >consortium, but rather a criticism of "the rush") is that they tend to >be very language and technology specific. For instance, OSF's DCE has >serious problems with respect to Ada, and even with respect to the >emerging POSIX .4a standard. The X Window System has had problems >with concurrency until recently. [much good POSIX and language interoperability/unability stuff deleted] I realize you weren't specifically calling out MCC as part of "the rush", Dave, but you provided me with an entree to elaborate on a paradigm shift we have here as well. ;) Your point about the unsuitability of technology and language specific solutions is 100% accurate. Why? Because the end result is a point solution directed at a highly vertical slice of the problem space. I don't understand your indictment of consortiums as being pre-disposed to address problems with such vertical solutions, unless, of course, all members have an identical problem they want to solve in the same way. The system architecture migration topic I mentioned; however, represents the more adaptable approach you recommend...to be responsive to a broad range of technologies/languages. We envision problem solutions to be inclusionary rather than exclusionary because of the quite broad and eclectic mix of our members. Therefore, our implementations of major initiatives (such as system migration) are language and hardware independent. It does a major insurance company no good to be told we can convert any huge mainframe dependent architecture to a parallel architecture at 5 times the performance and half the expense, BUT ONLY IF the legacy code is written in FORTRAN IV targeted for re-implementation as Lisp...and all the insurance company's software is written in COBOL. See? So the point is, diverse consortiums with common problems can yield robust, adaptable, and flexible solutions...and that's the direction we deliberately pursue to provide the most benefit for all our members. --- Mark A. Breland - Microelectronics and Computer Technology Corporation (MCC) Advanced Systems and Networks | voice: (512) 338-3509 3500 West Balcones Center Drive | FAX: (512) 338-3900 Austin, Texas 78759-6509 USA | internet: breland@mcc.com