DTJ Number 3 September 1987 - Digital Technical Journals

New ProductsBy late 1982, we decided to include both IATand CTERM support in the Pluto terminal server,but only IAT support in Poseidon. In addition,the original code from the prototype Vf1 03 terminalserver was migrated to a UNIBUS PDP- 11'system; this code was called I.AT-11.By early 1983, a significant number of VMSdevelopers were using the prototype I.AT-11servers. This software was maintained by the IATdevelopers. It was important that the softwareworked reliably since the VMS developers wereusing it in developing the VAXcluster software.As noted earlier, the original developmentteam for the CTERM terminal server on Plutoexperienced a number of problems. Therefore,in early 1984, a new terminal server was implementedon Pluto, based on the I.AT- 11 code andnot on the RSX software. This new server, containingsoftware only from IAT, was referred tointernally as Plato.The prototype I.AT- 11 code was developedinto a product to run on version 3. 7 of the VMSsystem. This product became available in July1984, somewhat before VMS V AXcluster supportappeared in V AXfVMS version 4. 0. One monthlater, the Ethernet Terminal Server, the productname for the Pluto terminal server, became available.The risk of having the VAXcluster offeringadversely affected by an unproven terminalserver was limited by releasing it with the earlierversion of the VMS system. Thus we took advantageof extensive "free" testing from over 1000internal users.In March 1985, the DECserver 100, the productname for the Poseidon terminal server, wasreleased. The DECserver 100 implementationwas radically different from the other terminalservers.DECserver 100Although the Ethernet Terminal Server andI.AT- 1 1 products provided the benefits of serverbasedterminal interconnect, they did not fullyimplement Digital's ter';Ilinal server strategy. Forserver technology to bcome pervasive, it mustcompete with other terminal connection methodson the basis of cost alone. In cluster andmulti-host systems, servers provide necessaryand desirable added functions. Therefore, theyshould be compared with other connectionmethods by assigning some value to the additionalfeatures and then using cost/performanceas the deciding factor. In small single-systemienvironments, the added fJatures of server technologyare not necessarily perceived as addingvalue; then cost becomes the sole factor for comparison.Digital's servers are at a disadvantage inthis situation because they offer features that costmore. Digital must pursue dual path to developservers for some applications and to maintain andexpand backplane terminal interfaces for others.As noted earlier, we knew that the EthernetTerminal Server could compete effectively oncost alone for large numbers of terminals; forsmaller configurations, however, it could competeonly on the basis of grater functionality. Itsfixed cost is relatively high, although the incrementalcost for each terminal added is low. Thuswe started to design a low-cost terminal server.The first decision we made was an importantone: the product would i be a local terminalserver and nothing more. !Telephone data linesusually terminate inside computer rooms. Therefore,Pluto, which is suited to computer roomconfigurations, already filled the need for a terminalserver with modem control capabilities.Poseidon was specifically designed to be distributedalong an Ethernet throughout an officeenvironment, near the atached terminals. Ofcourse, multiple Poseidons could also be used inwiring closets and computer rooms.We also believed that Pluto already provided ahardware base for other communication serverapplications; therefore, P9seidon need not supportapplications other than terminal serving.I -Although often desirable (rom the standpoint ofthe company's total product set, generality isalso the archenemy of low cost. Hardware thatserves many functions also has capabilities thatare unused in some applications. Those unusedcapabilities represent a cot from whkh no benefitis derived when an iolated application is1viewed.On the other hand, hardware designed for aparticular application can optimize cost and performanceby eliminating any unnecessary capabilities.The Ethernet Terminal Server and DECserver100 illustrate both ;ends of this spectrum.The hardware base for the former functions in anumber of general roles related to communications,such as the DECnet Router or DECnetjSNAGateway products. Consequently, this producthas a high entry cost, but a low incremental costas each terminal is adde