Aucbvax.2490 fa.works utzoo!decvax!ucbvax!works Fri Jul 31 03:27:04 1981 Big AND Small >From Rivanciw@Darcom-HQ Fri Jul 31 03:23:25 1981 In reading the debates pro and con on big systems and little systems, where big systems are large mainframes and little systems are personal workstations it seems that the best of both worlds would be architectures for office automation that encompass both. Let me illustrate how we have attempted to incorporate both worlds in our OA plans. DARCOM has a DEC 10 (DARCOM-KA) on the ARPANET which it uses to provide electronic mail and other OA services to a broad community of users throughout the command (the command is all over this country). Access is via ARPANET. Advantages here are that for a relatively inexpensive yearly charge a remotely located single user can obtain OA service with a communications capability as powerful as the ARPANET. This service is in such demand that we cannot supply services in large enough quantities (thus the DEC 10 will soon be replaced with a couple of 11/780s to provide more services). One level down (in computer size) DARCOM uses what it calls LARGE CLUSTER machines. These are mini computers (DEC 11/70 size) which provide LOCAL OA services to 100-150 users. Long- haul communications is accomplished via the RELAY computer to the ARPANET (or dial-up communication channel to non-ARPA computers). These Large Clusters are not hosts on the ARPANET. The computer I am working on right now is one of these large clusters. This message is routed to the RELAY computer which routes it to the ARPANET for delivery. The next level down SMALL CLUSTER. The small cluster is a general purpose micro computer (like the ONYX or "C" Machine). The Small Cluster services 8-30 users. It communicates with the LARGE CLUSTER for large file storage and backup. Communi- cations on the small cluster are handled via the large cluster or the RELAY. The lowest level is the personal workstation (one user). We haven't gotten there yet in large scale implementation. Yes, we have a lot of personal workstations around but have not yet incorporated them into our large scale implementation plans yet. This architecture is used for economies of scale and incremental investment on behalf of the user. For example, let me paint a typical scenario of one of DARCOM's subordinate commands or activities just entering into the world of office automation: The Commander or somebody at the command wants to try office automation. Now they are unsure of its benefits so they don't want to spend mucho money. The buy a mailbox on our DARCOM-KA (LARGE MAINFRAME). With this mailbox they can experiment with all the OA tools. After a short while they want 5 or 10 other people at their command or activity to get mailboxes so that they can communicate via electronic mail. They buy more mailboxes on the large mainframe. Then it is determined that office automation is good for the command. They make large scale plans to provide OA services to 100, or 200, or 300, or how-ever-many prople. At this point the economies of scale move towards the LARGE CLUSTER machine. With a large cluster installed locally, the command is essentially running their own OA. But soon they find that more and more users are demanding service. Enter the small cluster. As one division goes from one or two users (who were getting OA services on the large cluster) to a demand to provide services to 8 or 10 people in that particular division, a micro computer is installed in the division to provide those services (and offset the demand on the large cluster). An example of this implementation is DARCOM Headquarters. We began by buying accounts on the big DARCOM-KA (large mainframe). When demand grew to 60 users we brought a large cluster into the building. The number of users on the large cluster grew from 60 last Oct to 210 as of last week. We now have some 20 micros on order. These micros will service 8-10 user each so we now supply services to an additional 160-200 individuals. As folks move off the large cluster to the small cluster there are more folks wainting in line behind them for accounts on the large cluster. This multi-level (of size?) architecture seems to be working pretty well for providing services to our command. Randy ----------------------------------------------------------------- gopher://quux.org/ conversion by John Goerzen of http://communication.ucsd.edu/A-News/ This Usenet Oldnews Archive article may be copied and distributed freely, provided: 1. There is no money collected for the text(s) of the articles. 2. The following notice remains appended to each copy: The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996 Bruce Jones, Henry Spencer, David Wiseman.