Digital PDFs
Documents
Guest
Register
Log In
XX-6A696-D6
May 1985
15 pages
Original
0.5MB
view
download
Document:
VAX Strategy c1979
Order Number:
XX-6A696-D6
Revision:
0
Pages:
15
Original Filename:
VAX%20Strategy%20c1979.pdf
OCR Text
C O M P A N Y BASIC STRATEGY ,QOD/Gordon Bell Last edit: 11/l C O N F I D E N T I A L 03 NOT COPY IDi'1354 BASIC PRODUCT STRATEGY Provide a set of homogeneous distributed computing system products so a user can interface, store information and compute, without re-programming or extra work in many styles and the following computer system sizes: as a single user computer within a terminal; at a small, local shared computer system; or via a large central computer or network. Achieve a single VAX, distributed computing architecture by 1985 (as incaswed by revenue)through: focusing on homogeneous distributed computing with varying computing styles including high availability and ease (economy) of use as the DEC advantage; building new 11 hardware to fill the product space below VAX; building new 11 software products that also run on VAX; and developing software for ll-VAX migration and 11 user base protection. Provide essential standard IBM and international network interfaces. Define, and make clear statements internally and to our users about programming for DEC compatibility. "\j‘\\ Provide general applications-level products that run on 8, lo/20 and ll/VAX-11 above the language-level to minimize user costs, including: word processing, electronic mail, and profession-based / ~.-_/-I CRT-oriented calculators; __ - VY&J+ transaction processing and data base query; general libraries, such as PERT: simulation, etc. aimed at many professions that cross many institutions (industry, government, education, home); and general management libraries for various sized business. Provide specific profession (e.g. electrical engineering, actuarial statistician) and industry (e.g. drug distributor, heavy manufacturer) products as needed via the product line groups. Provide cost-effective 8, lo/20 systems through: building hardware that runs current operating systems; and making market support and DEC-standard language enhancements. This strategy is intended to cover the full range of DEC's future products. Since technology shifts rapidly and market opportunities emerge that we don't now understand, it may be necessary to provide non-compatible, point products. These should be proposed and reviewed accordingly. nnxc STRATEGY DO NOT COPY Page 2 OOrJKordon Bell Last edit: 11/17/18 - - Latest edit l/,0,79 - Wed Essence and Rationale o f the St,ratmgy The essence or the s t r a t e g y i s simplicity through adopting a Single architecture. This simplicity is “eeded so that we can build the network and di*trib”ted p r o c e s s i n g .9tP”ct”IICS which our C”stonleP.9 are n o w demanding. The s t r a t e g y i s a ” evolutionary resut of the 1975 choice t o extend the II nrchitecturc and COYeP it.9 c u s t o m e r base. Given that the architecture and early customer acceptance are i” place, the strategy moves to build ow subsequent products on VAX, while continuing to sell B’S, ,0,20’s and II’S, Focus is imperative in order to avoid the redundant deYelopme”t efforts aCPOSS base hardware and software, a n d tc’ move development to fully distributed computing and to applications. The strategy also minimizes manufacturing and field start-up costs and takes advantage of the learning effect by moving to a single architecture. The motivations for the homogeneous architecture are numerous and include the customer desires for a range of products on which to build products (in the case of OEMs) and applications (in the case of end users). Such a range in size and over time, allows planning and investment of SoftWare and it permits computers to be associated with various organizational units (eg. central group, small group, office, the person, 0~ the home) on a” “as needed” basis. Although, superficially it appears to be p~slble to have “ume~ous prchitectures that are serpnented by size and by market, the user requiPeme”ts to cross both size and applicationa boundaries are signiricent. I” fact, give” that IBM is segme”tLng its prOducts both by size and application, the main strength of the strategy is to have a single architecture with which a user c a n be comrortoble rather than Sounded by a manufacturer segmentation. ~~’ ~. The most compelling reason for basiag the strategy on the single VAX architecture, beSideS the technical excellence of the product is the belief that we can not build the truly distributed computing system of the 80’s with heterogenous architec,tures. It is possible to build distributed computing networks as we do today, but the homogeneous architecture approach insures that programs nay be assigned to any “ode, where they will give the Same results. There is “0 need for the organizational and comwtation overhead signified by different manuals, separate training, recompilation of prwgrxms, and translation of data among machines in the network. This strategy is aimed at beating the competition using OUP existing highly tuned minicomputer hardware and software to support and grow our existing User base. It provides us with a unique offering in the marketplace of the ‘80’s which is likely to be based o” the defacto standard IBM 3601370 architecture and the ensuing defacto architectwes ooming from the semiconductor companies. Sine VAX is fundamentally better than either of these architectures, we muat make it the standard architecture via transition from the PDF-11, whiCh tms bee” the standard architecture Of the 70’5. The strategy is aimed at high volume through multiple channels of distribution, versus a more stat&?, low growth through supporp of a” existing multi-system, customer base. .I COMPAN~Y .~ l C O N F I D E N T I A L BASIC STRATEGY Do NOT COPY OOD/Gordo" Bell Last edit: ll/17/78 -- Latest edit l/10/79 - Wed Page 3 How Can We Win Against lBM? A competive viewpoint is the most important check on strategy. Both the recently accounted IBM 8100 Distributed Processsing system and the System 38 computers are the first computers from IBM that, on the surface, look worth owning. They may be as significant as the 360 and their Selectric The System 38 with a 48-bit virtual address is technically typewriter. uniqucand may offer the user some very large benefits. ,.,-~ "a The 8100 is a radical departure from IBM pricing as 0.5 Megabytes of primary memory and a 60 Megabyte disk are $ 29 K. A comparable DEC product sells for several times this now. The 8100 is exactly in the price range of the systems we sell and where we make most of ow revenue. It is the second product in this price range within a year; the Series t minicomputer family patterned after the 11/04-11/34 was the first product. On the surface, the product is low priced, with lots of capability, but it also has a new communications structure (versus the one we have used substantially unchanged since 1961). This structure permits easy peripheral and terminal interfacing for both the office and factory environment. There is a" extensive range of peripherals, terminals and communications to the 360/370. Since the product is sold by DPD, the strategy seems to keep account control and to make the money on the numerous locked-i", generally overpriced terminals. IEM will 'have: a 3601370 line in the $100 K to $10 M pi-ice range with lots of plug compatible competitors, several operating systems to support, a large backlog, a newly announced 8100 for Distributed Processing around the mainframe; a System 32134138 for Distributed Processing and as a Mainframe for small organizations; the Systems 3 to 15 for Distributed Processing; the System 1 for the would-be minicomputer buyer; the 5100-series Personal Computers for the scientist, engineer, analyst and xoall business; and TLT$M PLk seeiproductsfor in the termir+,,_, hll of these I: T&M T@&# are incompatible, except for a communications link and the fact that they r'c 311 USI? the &bit EBCDIC byte. Products are relatively segmented to ,x31-1 yei CUStOmer clauses and different languages are used to further segment and hinder application mobility. Finally, they've sold via DPD and GSD, with i=rL,, Office Products no doubt looking on and waiting for a" entry via electronic I ‘/L y 6 mail and word processing. b;hile on the surface, the 8100 stands to be IBM's most significant product, it seems to be a serious mistake as it introduces another incompatible computer system with which customers will have to deal. This means that the making of a compatible, fully distributed processing system will be I~:::;c"l.ially iropor,sible. However, since IBM feels it can not move very rapidly in any product space because of the installed base, product options are limited. Hence new products seem to be highly targeted at specific, new non-IEM markets in a" incompatible fashion to get incremental t-avenue and growth. - \/k~S cj (5 COMPANY BASIC STRATEGY OOo,oordo” CONFIDENTIAL W NOT C O P Y Page 4 Bell 42 COMPANY e CONFIDENTIAL DO NOT COPY BASIC STRATEGY OOD/Gordon Bell Last edit: 11/17/78 -- Latest edit l/10/79 &ti Page 5 A PRODUCTS IN 1981-82 HARDWARE COOMPONENTS HMOS LSI, with first "test" product Interconnection hierarchy with software compatibility l-10 Mhz and/or 10-100 Mhz inter-computer bus w 50+ Khz comm.-comoatible multidrop for terminals, peripherals, and small systems; 0.3-19.2 Khz comm.-compatible for low cost terminals. Significant competitive memories Solid state modules for software Low end floppies and low cost taw Removeable and low cost disk m Hi-volume mid- and hi-end disks in A80/R81 with backup Terminals for everyone! Low cost (dumb) and block mode (VT1621 Office environment for Quality printinn, electronic mail, and full-DS!e l text Professional using graohics (and/or color) with target application software Factory environment terminals and interface systems HARDWARE SUBSYSTEMS Remoteable printers, job entry, concentrators, sensor-control Communications concentrator - Mercury Memory (Hierarchv) Manaaement -~Jt&?5fJ for REO/RBl, RL04, tape and disk cache KERNEL SYSTEMS based on processor-disk-commlrnications (see family tree figure) 780 replaced by Superstar (const. price >3x performance) J&Q - Memory Manaixer - Comm. Concentrator 780 - Multiprocessor m - RP/R80-81 + RLO2-04 780 - AK/RL04 Comet - AP/R80-81 + RL Hydra (Including Memory Manager - Comm. Concentrator) Nebula - A80-81 + RL Nebuls - RL02/RLO4 (higher cost, quick to market personal computer) LSI VAX - RLO4 - Gr&ics Terminaa (personal computer) ,r l 11/74 with no hi end replacement llL22) - multiDroce3sor m - RP/REO-81 + RL02-04 2lu-m COMP,ANY C O N F I D E N T I A L EASIC STRATEGY DO NOT COPY OOD/Gordon Bell Last edit: 11/17/78 -- Latest edit l/10/79 - Wed page;7 native mode VMS layered products. . Shift DECNET strategy to strong IBM interconnect and VAX binary image compatibility for distributed proccssinK; constrain PDP-11 DECNET ~llNC'~I~UNAi.I'rY . Converge on ease EX'I'IZNSIONS, speed up IJE 20 network capabilities. of CEC '20 to VAX movement through common language definitions, (common implementations where feasible) cqmmon user-level utilities and data conversion routines. For each new DEC 20 or' VAX customer, a?, time progresses, make the movement between systems more attractive. l ,. M F. :: ,- .5 h_ r 9 . REAL TIME + . REAL TINE. Y-~COi&TS SiMPL.E ~TERMHALS, . RATIONALE FOR THE BASIC STHATEGY ‘OOD/Gordon Bell Last edit: 10/30/78 Mon -- Latest edit: 11/6/78 Man Page 1 -Change the CurrentStrategy? We have arrived at the current strategy by integrating ow past customer needs, with thq result that nearly every past system we have ever built is ’ being evolved. This evolution creates too many systems with converging functionality. By prolongiw the phaseover to VAX, we’re unable to invest enough in VAX due to continuing and evolutionary support costs. Also, we’re unable to provide applications, or have any slack resources to respond to competitive threats (,eg. large micros or focused products such as the 8100). I ‘.~ We are just beginning to get a feel for the expense of putting new software systems in the field, and there are other systems still to come. Since we provide many choices, we find our sales and customers have difficulty deciding what to sell and buy. This makes us difficult to understand and to do business with. Lots of low volume products mean we don’t have adequate volume to amortize the start-up manufacturing, sparing and training expenses. -Not Anaressivelv Evolve All Four Base Hardware Architectures? In reality, our past strategy has been almost a divisional product structure. Customers can choose among the 4 basic hardware computer systems with 2+3+7+1 models and then select the appropriate software system, among 2+2+7cl software systems for 6, 10/20, 11 and VAX respectively. This gives us severai hundred systeios. Th*s number of altcrnaiivee is too Larse , resulting in small and decreasing volumes of each of the systems as all architectures are extended to cover a full range that we believe our customers require. We can not afford all the necessary enhancements to support four architectures over the range of size and use that our customers demand. ‘>- While any of the architectures can be implemented at any si.ze dowm to and including LSI chips, there is no significant differential cost of the processor between the 10/20, VAX and an 11 with coinmercial and scientific instruction-sets.- An evolved 8 to handle the strategic range would even be the same cost. The main differenti.als are: the cost of the memory to hold the task:: and the size of the operating system software. The lo/20 operating systems have been oriented to generality, and while VMS and TOPS 20 have roughly the same functionality, the lo/Z0 requires 512K bytes of resident memory, whereas VMS require 256~ bytes. This occurs because TOPS 20 has evolved and because of the efficiency of VAX architecture. VMS also has real time capability. Similarly, it is now inappropriate to consider 10/20 based architecture for terminals and personal computers, when compared with VAX, because small problems cannot be encoded to be competitive with modern 8- and l&bit microprocessors. Furtheremore, extensions to the 10/20 architecture would require basic work in the operating system and languages to build a VAX competitive product. l RATIONALE FOR THE BASIC STHATEGY OOD/Gordon Bell Last edit: 10/30/78 Mon -- Latest edit: 11/6/78 Mon - _ __-- - Page 2 - Why Not Sement Products Ev Market? -_l Since the lo/20 has significant commercial software and since it is believed that our customers arc insensitive to architecture, we mj~Eht simply have a market segmented approach and use 11’s at the low eitd and 10/20’s j.n the high end. Lower priced 10/20’s would be implemented war time as appropriate. ’ O u r technica, users (EDU, ESG and even LDP) do not segment cdmputer purchases into commercial ‘IS scientific. A “control” customer such as DuPont doesn’t segment its appliccations either. E v e n NASA w a n t s COEOL t o Universities off-load their mainframe and to do administrative EDP. likewise want a single machine, and hence the software will be “pulled” into existence. Version 4 of VAX COBOL executes faster than the 20’s already. Since there is basic incompatibility between the 11 and 10 architectures, thF: tnigration problem is enorRISUS. Now our large c o m m e r c i a l custotier b a s e is with 11’s. Our users perceive VAX and 11 are of the same family. l The lo/Z0 still requires basic changes (CIS, 30-bit addressing) to bring it up to VAX performance and capability together with compi~lers and some basic software (eg. multi-keyed ISAM). TRAX-36 and RSTS 36 will also have to h!lild off our 11 b a s e . In short , vhilr it might bc feasible to build lo/20 coftware so t,hat our 11 u.?ers could meet our strategic goals for :! islributcrl processing, we would still fall short of the distributed system - can b!Illd wLth a single architecture as described in a subsequent :!;ti&le.~~ N-Do Customers Prfceive The qituation? __L In mid October, a group at Bell Laboratories, building PBX systems visited IIS and made the comments: “Only you have the basic architecture in VAX to cover the range of products we need for distributed processing. This includes: terminals, offices and large offices. starting Give us a truly compatible range of VAX machines, with a VAX-on-a-chip and extending through the IBM 3033. (Don’t corrupt VAX, since as in the 11, we must preserve our software base, given that the processor is only 4% of the cost.) The machines must have a reliability and security orientation. Why don’t you do it? We will help fund the development.” -.. NAI'LONALE I~'011 THE UAS.tC S'I'R,"'~EtiY 'OOD/Gordon Bell Last edit: 10/30/78 Man -- Latest edit: 11/6/78 Mon Page 3 Recent discussions with Stanford, ITT, CERN, NASR (Ames) indicate concurrence even though they are large lo/20 and 360/370 users. MIT is proposing to build a homogeneous VAX-based network. DuPont wants a similar structure, but is less rigid on the need for a homogenous architecture even though they've standardized on the RSTS machine internally for many of their systems. (There's a videotape describing their needs arid ideas.) ' CERN, and NASA (Ames), for cxnmplc, feel ttnt the lnrgc tmninframi? may be on the wax out as we offer small group-level computing with VAX.. There are probably lo/20 customers who feel strongly thnt wo shol~lld tn:;c our future on 10/2O's. The main reason to focus on the single architecture is that it is part of the 11 family. NhJhv Have A Single Architecture? There are technical, marketing and economic reasons for choosini a single architecture at this time on which to base a major part of our future. However, this does not mean that we must neglect our lZ- and 36.-bit user base. While compu;er networks can and have been built with heterogenous computers and IEM is bettip- that jut can build distributed computing systems with only similar machines, a single architecture is the most effective for distributed computing systems. The homogeneous (identical) architecture approach insures that software will give the came results no matter where executed and therefore programs may be run anywhere in the network, data stored anywhere and programs moved about in their object form without the overhead of recompiliry or translation as data is transferred. This also insures that the human interface to the system remains constant, because identical software is executed in different machines instead 3f relying on software that is specificed to have identical interfaces (e.g. languages, command languages, file systems, utilities). I- From a user viewpoint, the homogeneity is ideal, and the SUCCFSS can be verified by reviewing the history of IBM's decision to build the 360 (and not continue with the 1401 1410, 7070 and 7090 series machines), even though there was an incredible base of these machines. This uas also the time that Honeywell established itself with the 20%series and RCA with the 301. The homogeneity provides a simpicity for the entire DEC organization and its customers, and lets us all focus on end use applications rather than choosing a particular operating system and language. Currently, we have too many low level, incomplete choices and the software efforts of us and our users are not focused. An applications base can only be built effectively on a good, stable architecture. Economically, a homogeneous architecture is essential because it allows us to concentrate and become a focused, high volume manufacturer and take advantage of learning curves. While 10% learning curves mean a doubling of manufactured quantity causes a 10% decrease in cost, they also imply that having two very similar products at one-half volume causes 10% higher costs in each. There are similar effects of learning in hardware, software and sales training costs, although the learning costs are small in comparison with the logistics and.start-up costs associated with our many, different though functionally equivalent, products. We become difficult to do business with in the process. / . RATIONALE FOR THE BASIC STIIATECY OOD/Gordon Bell Last edit: lo/30178 Mon -- Latest edit: 11/6/78 Mon Page 4 my Base The Rrchiteue OR VAK? Although we went through the arguments in the spring of 1975 when we decided to build VAX instead of building lower cost versions of the 36-bit architecture, we now hnvr a real mnchinc that met it:; dcvclopment goals and has user acceptance on which to base future products in a natural, evolutionary fnxhion. Mostly, the choice of VAX in 1975 was based on having a large, PDP-11 user base. Furthermore, the choice to stay with the 8-bit byte was of convenience because of the IBM and communications worlds. The VAX architxture was designed to permit the building of a range of machines with sizes that are j~mportant to us. Our targeted range of i,ilPlc:nhnt;lLiori wiis 1000: 1 arid thins i:; 3LtainnbLc with an LSI implementation for terminal applications in January 1982. This is why a small page size and L;imple p;,.:iv: system wnn cho:icn, vcr'sus a lnrger page sj.zc and more complex scheme that would have been particularly oriented at large systems. liowever, it would not be wise to build the machine 1000 times as large in 1982, because it would take thr? system size beyond the suggested $250 K selLing price limit and into mainframe price and customer expectations twritory. Thus , in January 1982 the LSI VAX could sell for sever& hundred dollars at a board level. An ECL technology machine might be' confi~wcd to sell for $ 400 K, giving I;he 1OOO:l in price snd a range of 611 Kbytes of SAM znil ROM for VMS in the terminal to ils much as 32 Mbytes in the large confl,guration (4000 64 K chips, costing $GOK and occupying 20 PC Soardsj. VAX hns -i! so drsignr d to address the high cost of programming. Already VAX ha been acclaimed (by a custonw in our ada) as the best machine for impl~~mcnti~ni: :nftwnrc. The lnrgc iddrcss space eliminates the need for much of the effort we spend encodi~ni: large programs into overlays. The architecture ins instructions for the important data-types, the addressing is independent of the data-types and the important language constants we built into the hardware. There is clear separation among program ;ind data. The procedure call instructicn r711~ows more sub-program sharing than with architectures that are dependent on conventions (e.g. 360 and 10/Z@) znd it eliminates n class of systems progranning errors resulting from the multiple assignment of general registers among different programs. The 32-bit address space of VAX appears adequate for the computing needs in the foreseeable future and there is extension capability given that any special needs arise. The address space and protection modes also give us a capability to run sub-programs witten in different languages as a single pr0gralil. This capability is unique and may turn out to be the single most important attribute of the machine. Since only one other computer has the capability, we don't understand it or how valuable it will be. . RATIONALE FOR THE BASIC STRATEGY I' OOD/Gordon Bell Last edit: 10/30/78 Mon -- Latest. cdlt: 11/G/78 Man *.. I Page 5 Another technical reason is based on the encoding efficiency of the VAX instruction-set. The VAX architecture can encode a Fortran program in about l/2 to 2/3 the space of a comparable large computer such as a 360 or our 36-bit computer, while providing 32-bit addresses versu.s 211 op 20 bits Benchmarks in BLISS and FORTRAN show of addI*essing for the 360 or 10/20. this now, and the Common Family Ar'chitecturc studit?:: also indicate similar ’ results. While memory cost is decreasing, memor'y is still a significant fraction of system cost. Three years of cost decline at the historical rate of 20X, is required to get factor of 2 the cost differ&e back. That is, from a memory cost viewpoint, we have a 3-year cost edge on the market. More importantly, there is a similar effect on performance. By having only l/2 the bits to move between primary and secondary memories, the performance is higher due to disk-MOS memory swapping bottlenecks. Finally, we have an 11 user base on which to build that is approximately 7 and 50 times as large as our 36-bit base in terms of installed equipment dollars and installed units. Wh? Not Use The lo/20 As Thea? The software and user base on the lo/20 is the major reason to not arbitrarily reject the archi~tectnrc. On thr other hand, since the 11 USES base is larger and has grown more rapidly, its software base is larger and we have to protect and build on it as a higher priority. Right now, the lo/20 requires increacntal investment to make it competitive with VAX and the rest of the mainframe market. fixtension to provide a 1ir,g;e aJdL‘f33 space, to cxtcnd thi: floating point range to fulfil customer commitments, and to give a competitive commercial instruction set for COBOL are needed. Making these hardware investments requires comparable software investments and ws must zggain wait to compete beczuse there is a new machine and software to support. Subsequent iyplementations for small systems will be expensive both in terms of new software and start-up because TOPS 20 has been oriented toward large imainframe generality. Smaller systems will require contractions. Also it stands to only cloud the market more as alternatives for mid-range systems will include 2 VAX and 1 or 2 11-based systems. As small systems are implemented there is a need for compatibility with the even larger 11 base. Whv Cistraed ComputLn&? Distributed computing keys off our strength in interactive computing through timesharing, small systems, real time computation, terminals, and networks. Furthermore, we believe this is what our customers want. The issue is not distributed computing, but solving the problems that it creates.
Home
Privacy and Data
Site structure and layout ©2025 Majenko Technologies