|
DataMuseum.dkPresents historical artifacts from the history of: CP/M |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about CP/M Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - metrics - download
Length: 73472 (0x11f00) Types: TextFile Names: »D79«
└─⟦a2495fc4f⟧ Bits:30005867/disk10.imd Dokumenter (RCSL m.m.) └─⟦this⟧ »D79«
\f i T_A_B_L_E_ _O_F_ _C_O_N_T_E_N_T_S_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _P_A_G_E_ 1. SCOPE .................................................. 1 2. GOALS IN DISTRIBUTED SYSTEMS DESIGN .................... 2 2.1 Connectability .................................... 2 2.2 Resource Sharing .................................. 3 2.3 Flexibility ....................................... 3 2.4 Robustness ........................................ 4 2.5 System Performance ................................ 4 3. MODULARITY ............................................. 6 3.1 Modularity and System Functionality ............... 6 3.2 Distribution on Multiple PU Configurations ........ 7 3.3 The Relationship between Modules .................. 8 4. MODULES AND HARDWARE COMPONENTS ........................ 9 4.1 Modules, PU's and Peripheral Devices .............. 9 4.2 Modules and Memory ................................ 10 5. SYSTEM AND COMPONENT DESIGN ............................ 12 5.1 Two Levels of Functional Relationship ............. 12 5.2 Level d ........................................... 14 5.3 Level i ........................................... 14 5.4 Component Design and Generality ................... 15 6. THE INTER MODULE COMMUNICATION (IMC) ................... 18 6.1 Object Transfer ................................... 18 6.2 Basic Concepts of IMC ............................. 19 6.3 The IMC Addressing and Communication .............. 19 6.4 IMC Functions ..................................... 21 6.5 Service Classes ................................... 22 7. INTERCONNECTION MEDIA AND GENERALITY ................... 24 A_P_P_E_N_D_I_X_: A. REFERENCES ............................................. 25 A.1 ADDITIONAL REFERENCES ............................. 26 \f ii \f F_ 1_._ _ _ _ _ _ _ _ _S_C_O_P_E_ 1. The purpose of the present document is to lay down some general ground rules for the construction of a wide range of distributed systems. All the systems will be built using a standard reper- toire of microprocessors and processor interconnection media. Each type of system will be built to specific functional require- ments, including the achievement, to some specified degree, of some or all of the general goals described in chapter 2. Due mainly to properties of the available processors and inter- connection media, the distributed systems will share the follow- ing characteristics: - The hardware configuration of a system will constist of A NUMBER OF PROCESSORS AND AN INTERCONNECTION STRUCTURE on which communication is achieved by means of message pas- sing. - Each processor and the software it hosts provides some distinct part of the total system functionality. - Message passing between processors is encumbered by a stochastic non-zero degree of uncertainty, and also by a stochastic non-zero delay. Consequently THE TOTAL SYSTEM STATE REPRESENTATION WILL AT ANY GIVEN _6_æ_å_ TIME BE SCATTERED ACROSS THE PARTICIPATING PROCESSORS, _6_æ_å_ AND THESE MAY EACH HAVE A DIFFERENT VIEW OF THE SYSTEM STATE. These characteristics are taken as basic facts and it is not considered fruitful to attempt to make a distributed system appear and behave like a single, monolithic machine. \f F_ 2_._ _ _ _ _ _ _ _ _G_O_A_L_S_ _I_N_ _D_I_S_T_R_I_B_U_T_E_D_ _S_Y_S_T_E_M_S_ _D_E_S_I_G_N_ 2. This chapter will describe what is considered the main goals in distributed system design. These goals represent general qualities which should be present in each individual system regardless of its functional purpose. The sequence in which they are presented represents no priority list. 2_._1_ _ _ _ _ _ _ _C_o_n_n_e_c_t_a_b_i_l_i_t_y_ 2.1 One of the main reasons for the growth within the area of dis- tributed systems and local area networks is the fact that comput- ing power has become cheaper, and consequently the nature of com- puting systems develop towards decentralized intelligence and geographical distribution of hardware and services. The ability to get dynamic access from one terminal to different host computers (without re-cabling) or make different host com- puters share access to peripheral devices or large databases are examples of important system requirements today. Once the geographical distributed computing components have been interconnected by an interconnection medium, _1__å_ FULL ADDRESSABILITY OF FUNCTIONAL UNITS SHOULD BE _6_æ_å_ AVAILABLE AT THE HIGHEST SOFTWARE LAYERS. NO ARBITRARY _6_æ_å_ RESTRICTIONS ARISING FROM HARDWARE OR LOW LEVEL PROTO- COLS ARE TOLERABLE. This goal in distributed systems design will be referred to as connectability. The interconnection architecture should at the same time be well suited for interfacing to international market standards, equip- ment and networks. \f 2_._2_ _ _ _ _ _ _ _R_e_s_o_u_r_c_e_ _S_h_a_r_i_n_g_ 2.2 Shared access to and optimal utilization of expensive peripheral devices are other important goals in distributed systems design. The basic operating system in a distributed system should turn the service of such devices into a multiuser service and provide for access control and service distribution, supporting the im- plementation of a work station type of service on top of costly peripheral devices like printers and magnetic tape stations. This, however, does not include sharing of memory resources. We will return to this point later. 2_._3_ _ _ _ _ _ _ _F_l_e_x_i_b_i_l_i_t_y_ 2.3 Re-configuration flexibility is of vital importance to distribut- ed systems. _5_>_å_ A DISTRIBUTED SYSTEM IS FUNCTIONALLY A MYRIAPOD, EACH _6_æ_å_ SINGLE FUNCTION BEING UNAWARE OF AND UNAFFECTED BY THE _2__å_ PRESENCE OR ABSENCE OF THE MOST OF THE REST OF THE CONFIGURATION. It must be possible to add new functions to an existing system by adding the necessary functional components. If part of the new function is performed by a functional component which is already present in the system, it must be possible to utilize this compo- nent. If the hardware requirements for a desired function are already met by an existing system, it should be possible to install the new function without adding new processors or other hardware. Applications should as far as possible be independent of the hardware forming the interconnection structure, thus providing for re-configuration flexibility at this level too. \f 2_._4_ _ _ _ _ _ _ _R_o_b_u_s_t_n_e_s_s_ 2.4 With respect to system reliability a distributed system must have a high degree of robustness. _3__å_ THE INDIVIDUAL FUNCTIONAL COMPONENTS, BEING MORE OR LESS SELF-CONTAINED IN THEIR SERVICE AND FUNCTIONALITY, _6_æ_å_ MUST PROTECT THEMSELVES FROM FAILURE OR MALFUNCTION IN _4__å_ OTHER COMPONENTS, THUS BEING ABLE TO SURVIVE AND ACT WELL-DEFINED WHEN SUCH MALFUNCTION OCCURS. Basically some independence is present in the hardware of a dis- tributed system. The individual processors or devices may fail or collapse (for software or hardware reasons) without affecting the functionality of the larger part of the remaining system. It is important that the overall architecture of distributed systems includes and strengthens this survivability independence between the distributed functional components shaping the total system. 2_._5_ _ _ _ _ _ _ _S_y_s_t_e_m_ _P_e_r_f_o_r_m_a_n_c_e_ 2.5 In distributed systems the question of performance and capacity is not only a question about the performance and capacity of the individual processors, but just as well a question about the possible system performance and capacity one can reach by inter- connecting a large number of processors and devices. It must be possible to upgrade a system, i.e. increase its per- formance/capacity, by adding more processing power onto an exist- ing processor interconnection structure. _3__å_ IDEALLY THE PERFORMANCE LIMITATION OF A DISTRIBUTED _2__å_ SYSTEM SHOULD BE DETERMINED BY THE CAPACITY OF THE _5_>_å_ INTERCONNECTION STRUCTURE RATHER THAN BY THE KINDS OF PROCESSORS USED. \f And as the transfer rate and capacity of processor interconnec- tion media increase, this limitation will vanish as well. \f F_ 3_._ _ _ _ _ _ _ _ _M_O_D_U_L_A_R_I_T_Y_ 3. The basic design principle which is applied in order to achieve the goals in distributed systems as described in the preceding chapter is: _5_>_å_ MODULAR CONSTRUCTION USING STANDARDIZED MODULE INTER- COMMUNICATION MECHANISMS. The remainder of this document contains a discussion of a number of issues concerning modular decomposition, properties of mo- dules and requirements for inter module communcation. This discussion provides: - a set of guidelines for the decomposition of large systems into modules which may run on separate processors, - a description of the basic functional requirements which must be satisfied by RC's distributed operating system in order to support inter module communication. This chapter serves to introduce the term module. 3_._1_ _ _ _ _ _ _ _M_o_d_u_l_a_r_i_t_y_ _a_n_d_ _S_y_s_t_e_m_ _F_u_n_c_t_i_o_n_a_l_i_t_y_ 3.1 A module performs a well-defined function. The functionality of a module is clearly described in the module interface specification. In other words: if it cannot be said on one or just a few pages what the thing does, the thing is not a module. Modules may be characterized as disjoint functional macro compo- nents being ordered in an unhierarchical manner around the inter- connection structure and communicating only by means of well-de- fined inter module communication standards. \f As such, a distributed system may functionally be regarded as a network whose nodes are modules connected according to their functional relationship. 3_._2_ _ _ _ _ _ _ _D_i_s_t_r_i_b_u_t_i_o_n_ _o_n_ _M_u_l_t_i_p_l_e_ _P_U_ _C_o_n_f_i_g_u_r_a_t_i_o_n_s_ 3.2 By the term PU we will in the following refer to a processor running autonomously, hosting its own application software and not being (physically) a slave to other processors. Slave pro- cessors running on (intelligent) controller boards will be re- ferred to as slave PU's. One PU may contain several - tightly coupled - CPU's, an example of such a PU is iAPX432 (iAPX432 is a trademark of Intel Corpor- ation). A module runs on one PU. Thus there is no inter-PU communication within one module. In other words inter-PU communication is inter module communication. On the other hand several modules may share one PU. In this case the operating system must divide the processing capacity of the PU between the modules in a transparent fashion. PU-sharing is necessary to obtain flexibility. It must be possible to add (SW) functions to a system without adding new hardware. A module must be independent of the physical position of other modules in the system in order to meet the flexibility require- ments. This means that communicating modules, i.e. modules which together perform some part of the system functions, must not base their relationship upon any assumptions about the geographical or logical module positions in the system. 3_._3_ _ _ _ _ _ _ _T_h_e_ _R_e_l_a_t_i_o_n_s_h_i_p_ _b_e_t_w_e_e_n_ _M_o_d_u_l_e_s_ 3.3 A module should not be dependent with respect to its survival on the behaviour of other modules, and it should be functionally\f independent of whether other modules with which it cooperates are running on the same or another PU. If this condition is not met, it will not be possible to put mod- ules together freely on a multiple-PU configuration. A particular consequence of the independence property is that modules cannot share memory. All inter-module communication and synchronization must utilize the general inter-module communication mechanisms. Even between two modules running on the same PU. In the following chapters these points will be gone over more de- tailed. \f F_ 4_._ _ _ _ _ _ _ _ _M_O_D_U_L_E_S_ _A_N_D_ _H_A_R_D_W_A_R_E_ _C_O_M_P_O_N_E_N_T_S_ 4. The relationship between the hardware structure of a system and modules is characterized in the following. 4_._1_ _ _ _ _ _ _ _M_o_d_u_l_e_s_,_ _P_U_'_s_ _a_n_d_ _P_e_r_i_p_h_e_r_a_l_ _D_e_v_i_c_e_s_ 4.1 - Each module occupies one 'slice' of a PU, including its ba- sic monitor and operating system service (scheduling etc.). - Each module occupies through inter module communication a 'virtual slice' of the interconnection structure. The load upon this structure caused by two communicating modules may vary (being zero for periods) according to the intensity of the inter module activity. - Each module may control none, one or several peripheral de- vices. The service of a single peripheral device is always requested by one and only one module, its owner module. The owner module may then in its turn be a server to other mo- dule(s) and possibly implement a multiuser access to the service of the device. Thus _4__å_ EACH PERIPHERAL DEVICE SUCH AS A DISC, A PRINTER, AN _5_>_å_ EXTERNAL COMMUNICATION LINE OR A TERMINAL IS DIRECTLY CONTROLLED BY ONE AND ONLY ONE MODULE. The relationship between modules and hardware is illustrated by an example in fig. 1 showing a MULTIBUS/ETHERNET system (MULTIBUS is a trademark of Intel Corporation. ETHERNET is a trademark of Xerox Corporation). In this figure the orthogonality between modules and hardware is visualized. \f While the hardware structure of a system function may be composed differently from installation to installation or from time to time in order to meet system requirements, the modules providing the system functionality should be independent of such recon- figurations. Figure 1: Example of a distributed modular system. 4_._2_ _ _ _ _ _ _ _M_o_d_u_l_e_s_ _a_n_d_ _M_e_m_o_r_y_ 4.2 A MODULE HAS ACCESS ONLY TO ITS OWN MEMORY RESOURCES. This ownership is meant in the sense that memory access rights should not pass from module to module at runtime. This is due both to the flexibility and to the robustness requirements to distributed systems. Since modules should be location independent and as far as poss- ible independent of the characteristics of the interconnection media, modules must not assume access to common memory. Modules must not 'peep into each others cards', and optimizations in lo- cal cases should be done only 'behind the back' of the involved modules. \f Furthermore each module must protect its own memory resources (data-buffers, tables etc.) by timer mechanisms in order to se- cure the guaranteed functionality, thus gaining robustness. _4__å_ A MODULE WOULD NOT BE ABLE TO PROTECT ITS MEMORY RE- _1__å_ SOURCES (BY MEANS OF TIMER MECHANISMS), IF ACCESS RIGHTS WERE PASSED AROUND TO OTHER MODULES AT RUNTIME. Hence each module has its own data buffer resources, administered by the module itself probably on the basis of a memory managing function in the basic operating system. Data passed from one module to another is copied from a buffer resource belonging to the producer module to a buffer resource belonging to the consumer module. This is done by the module intercommunication service. The overhead introduced hereby in cases where modules do have access to some amount of common memory (maybe because they share the same PU) may be minimized by means of hardware data move facilities utilized by the inter module communication mechanisms. This implies that a system should not be broken down into too small module components since each module claims a certain amount of memory in order to secure the required service and data flow. It is however important that modules, thus being self-contained with respect to data resources, may calculate, dimension and control for themselves the internal flow of data. For the purpose of the internal flow- and congestion control _4__å_ A MODULE SHOULD ACCORDING TO ITS OWN NEEDS AND FUNC- _5_>_å_ TIONAL PROPERTIES ALLOCATE, DEALLOCATE AND ADMINISTER THE DATA BUFFERS IT USES. \f F_ 5_._ _ _ _ _ _ _ _ _S_Y_S_T_E_M_ _A_N_D_ _C_O_M_P_O_N_E_N_T_ _D_E_S_I_G_N_ 5. So far we have introduced a module concept and described it in different aspects by means of well-known system concepts. As a guideline to systems design, a description by analogy might be useful. 5_._1_ _ _ _ _ _ _ _T_w_o_ _L_e_v_e_l_s_ _o_f_ _F_u_n_c_t_i_o_n_a_l_ _R_e_l_a_t_i_o_n_s_h_i_p_ 5.1 There is an analogy between modules in a distributed system, communicating through the standardized inter module communication mechanisms on one hand, and on the other hand processes (tasks) in a centralized system, communicating by means of the basic system services. Modular decomposition is just the next level up from decomposition into (pseudo-)parallel tasks. In a top-down design phase of a distributed system, modules will probably be the natural functional components after the first or second level of system decomposition. The next level of functional decomposition, i.e. decomposition of modules, will bring out module building blocks such as processes, interrupt handling routines etc. These two functional levels each have their own design object- ives. IN DESIGNING MODULE INTERFACE SPECIFICATIONS ONE SHOULD _5_>_å_ FOCUS ATTENTION ON THE REQUIRED BEHAVIOR OF THE TOTAL _4__å_ SYSTEM, WHILE DESIGN OF PROCESS OR DEVICE CONTROLLER _4__å_ INTERFACE SPECIFICATIONS IS PRIMARILY CONCERNED WITH _5_>_å_ THE BEHAVIOR AND FUNCTIONALITY OF THE SPECIFIC MODULE TO WHICH THESE COMPONENTS BELONG. For convenience, we will refer to these two levels as level d (distributed) and level i (internal). \f E_x_a_m_p_l_e_ _1_: Consider a distributed system which (among other functions) has a number of user terminals and one printer for hardcopy purposes. It will be natural to consider the printing function as a single module, since this provides the flexibility to attach the printer to the system anywhere it might be convenient. Thus the rest of the system will not care about the physical position of the printer, since it is addressed logically through the standard- ized inter module communication. The next level of functional decomposition will bring out some- thing like the following components: Figure 2: Example of a module (printing function). P is the printer itself, PC the printer controller (maybe on the PU-board), B is a process (task) handling the controller inter- face (interrupts etc.) and A is the application-specific process of this module, using the service of B, controlling the data buf- fers (data to be printed) and providing a multiuser interface (at level d) using the standard inter module communication mechanisms. The illustrated module may be a general printing module (it might be extended with a spooling facility), or it may be a specialized module dedicated to this specific system. The internal components P, PC and B are probably general purpose components and A a system dedicated component. \f The functional interfaces between the individual module-compo- nents (P, PC, B and A) rely upon special hardware and monitor fa- cilities. These components interface to each other at level i, while A interfaces to the distributed users at level d. 5_._2_ _ _ _ _ _ _ _L_e_v_e_l_ _d_ 5.2 Level d is the module level, which has already been considered in the previous chapters. The example above may be typical in the way that a level d inter- face often will be a logical multiplexing point, i.e. a module being accessed by (or accessing) a number of user/server modules. In the next chapter we will go into a more detailed description of the requirements to the standard inter module communication mechanisms. 5_._3_ _ _ _ _ _ _ _L_e_v_e_l_ _i_ 5.3 Level i covers all kinds of internal communication. Processes (tasks) within the same module will normally communi- cate by means of the facilities provided by the basic system running in the PU hosting the module. This usually implies some synchronization mechanism based upon the exchange of access to message buffers. The interface between processes and controllers (to peripheral devices) normally implies interrupt handling and different con- trol and data I/O commands. Based upon internal facilities like these, each individual module should be made as strong as possible with respect to performance and storage optimization. \f At this level physical data moving should be avoided. Providing the internal components with the possibility of sharing data, tables, variables and code sequences (procedures) will support a good module performance and reduces storage requirements. In this way processes and components generally within a single module will become more or less closely coupled components. _4__å_ ROUGHLY SPEAKING, THE LEVEL D INTERFACES IN A SYSTEM _6_æ_å_ MAY BE SAID TO PROVIDE THE SYSTEM ROBUSTNESS AND FLEX- _4__å_ IBILITY AT AN EXPENSE OF PERFORMANCE AND STORAGE RE- _5_>_å_ QUIREMENTS, WHILE CLOSE COUPLED LEVEL I COMMUNICATION _6_æ_å_ INCREASES PERFORMANCE AND REDUCES STORAGE REQUIREMENTS _5_>_å_ AT AN EXPENSE OF ROBUSTNESS AND POSSIBLE DISTRIBUTION OF THE INDIVIDUAL COMPONENTS WITHIN THE MODULES. 5_._4_ _ _ _ _ _ _ _C_o_m_p_o_n_e_n_t_ _D_e_s_i_g_n_ _a_n_d_ _G_e_n_e_r_a_l_i_t_y_ 5.4 Modules may have more or less general functionality. Some modules may be usable in many connections while others may be dedicated to a specific service in a specific system. The same applies to level i components. Important considerations in component design concern the problem of providing a required service and a service interface without introducing unnecessary restrictions on the general use of the components. In example 1 P, PC and B should be general components usable in any system where this printer type is required. The process A will probably be more or less dedicated to the specific type of printing function required in the example system. The strictest demands for functional generality naturally concern hardware components. In connection with distributed systems it is relevant to consider the use of dedicated memory (data RAM) on controller boards. \f In this connection controllers are grouped into three groups: - controllers for peripheral devices - controllers connecting PU's to interconnection structures - the 'in betweens' acting as either-or from system to system, i.e. communications controllers (line controllers etc.) Dedicated onboard RAM on the first group of controllers (periphe- ral device controllers) is considered to be owned by the module owning (controlling) the device. An example is a screen control- ler having its screen image in dedicated onboard RAM. This RAM will be directly manipulated by a process in the module control- ling the screen. Figure 3: Module owned RAM on a controller. In contrast to this the hardware architecture of the second group of controllers (controllers attaching PU's to interconnection structures) should be 'hidden beneath' the inter module communi- cation mechanisms. Dedicated onboard RAM (may be dual port) on this type of controller should be used by the inter module com- munication software (firmware) as private memory (as a communica- tion channel). Communicating modules must not assume the presence of common mem- ory or dedicated communication memory in the interconnection hardware. This would violate the flexibility requirements seri-\f ously, both with respect to general system reconfigurations, with respect to redesign and reconfiguration in the interconnection structure, and with respect to the general applicability of the involved modules in other environments. Figure 4: Controller RAM in the interconnection structure. The third group of controllers, (communication line controllers) should be able to operate both as module components (the line being an external communication line to another system) and as hardware components in the interconnection structure of a system (the line serving inter module communication purposes). This means that onboard RAM on a communications line controller in some cases will act as module owned and controlled memory, if the controller interface provides the possibility for this. \f F_ 6_._ _ _ _ _ _ _ _ _T_H_E_ _I_N_T_E_R_ _M_O_D_U_L_E_ _C_O_M_M_U_N_I_C_A_T_I_O_N_ _(_I_M_C_)_ 6. This chapter will introduce the basic functional principles of the standardized Inter Module Communication - the IMC. This will include a description of the addressing strategy and a functional description of the IMC control and data transfer mech- anisms. It is also considered, how the IMC may be regarded as a tool which may be used to define different classes of service suited for different system functions, thus preserving homogeneity in the communication within distributed systems and still satisfying the requirements of a wide spectrum of applications. 6_._1_ _ _ _ _ _ _ _O_b_j_e_c_t_ _T_r_a_n_s_f_e_r_ 6.1 Process communication within a single PU, by means of the func- tions provided by the basic system running in this PU (level i communication), normally implies complete object preservation. All abstract data types, whether defined by the monitor, the operating system, a programming language supported by the ma- chine, the hardware (firmware) or the application programs them- selves, have a unique representation which is never destroyed by the basic internal communication mechanisms. This is not the case in communication between PU's. As an ex- ample, consider the memory of a PU as a (numbered) string of bytes, then the representation of a 16-bit integer may be de- fined in two ways: low byte * 256 + high byte or high byte * 256 + low byte Types defined in high level languages have compiler-defined re- presentations which need not be the same in different systems. \f The solution to these problems in systems, which are heterogene- ous with respect to object representation, is not provided by the inter communication mechanisms. Rather they must be solved by application specific software knowing the involved object types and their representation in the different PU's. A basic rule for IMC is that _4__å_ A TRANSFER OF DATA FROM ONE MODULE TO ANOTHER BY THE _3__å_ IMC IS A TRANSFER OF AN (IMPLICITLY NUMBERED) BYTE- STRING. Thus the only data object known by the IMC is a bytestring. 6_._2_ _ _ _ _ _ _ _B_a_s_i_c_ _C_o_n_c_e_p_t_s_ _o_f_ _I_M_C_ 6.2 IMC IS DEFINED AS A SET OF FUNCTIONS The functional interface to the IMC is mainly of an asynchronous kind, i.e. an IMC function call does not imply a waiting point, it only initiates the requested action. Information about incoming events and data from the IMC to the requesting module is passed as return parameters to a call of a WAIT-EVENT function. In an implementation of IMC the WAIT-EVENT function call would normally deliver a parameter resource owned by the request module to IMC. The request module may then continue operation until the resource is returned by IMC, containing EVENT information. This scheme applies to data buffers too. 6_._3_ _ _ _ _ _ _ _T_h_e_ _I_M_C_ _A_d_d_r_e_s_s_i_n_g_ _a_n_d_ _C_o_m_m_u_n_i_c_a_t_i_o_n_ 6.3 The basic address entity in IMC is a PORT, named by a bytestring of 12 bytes. \f Modules identify themselves to IMC by opening one or several PORTS, through which the module may communicate with other mod- ules, addressing their PORTS. Thus communication between modules involves two PORTS, one at each module. Through a PORT it is possible to communicate with the owners of other PORTS. Basically there are two kinds of communication between PORTS: - datagram communication (singlestanding transaction from PORT to PORT) - virtual connection communication (exchange of (streams of) messages), involves two PORTS as end-point PORTS Both kinds of communication may be used freely to any purpose. A PORT may at the same time be end-point PORT for a number of connections to other PORTS and be used for datagram communica- tion. Figure 5: Modules, PORTS and connections. \f 6_._4_ _ _ _ _ _ _ _I_M_C_ _F_u_n_c_t_i_o_n_s_ 6.4 The basic set of functions of the IMC service are briefly gone over below. The detailed description is found in ref. 15. OPENPORT (port, portname) CLOSEPORT (port) CONNECT (port, destination portname) Establishes a connection to the destination PORT. DISCONNECT (port, c-id) Removes the specified connection. GETEVENT (port) Enables an event to be passed from IMC to the module when it occurs. SENDLETTER (port, destination portname, data buffer description) Sends the data as an IMC datagram (connectionless transfer) to the destination PORT. RECEIVELETTER (port, data buffer description) Enables the receipt of a datagram sent from another PORT and destinated for this PORT. SEND (port, c-id, data buffer description) Sends a data-packet on the specified connection. RECEIVE (port, c-id, data buffer description) Enables the receipt of a data-packet on the specified con- nection. RECEIVEALL (port, data buffer description) Enables the receipt of a data-packet on any of the existing connections. GETCREDIT (port, c-id) Reads the current number of waiting receive buffers at the other end of the connection. If zero, it enables an event to occur when the receiving end is ready. \f A means for flow control between modules communicating on a connection. RESET (port, c-id) Reinitializes a connection. Current datatransfers on the connection are aborted. The set of IMC functions introduced here are primarily designed for use in local area network environments. The choise of func- tions and parameters reflect that they are intended for use in systems with highly reliable interconnection medias, although there is nothing that prevents their general use in any type of network. Applying the ISO reference model of Open Systems Interconnection (OSI) (ref. 7), IMC constitutes the layers 5 (session), 4 (transport) and 3 (network), providing a service corresponding to leyer 5, the session layer. Within ISO, work is going on to standardize a local area network session service, but no publication has yet been made for reference. 6.5 6_._5_ _ _ _ _ _ _ _S_e_r_v_i_c_e_ _C_l_a_s_s_e_s_ In order to suit specific application requirements, the IMC func- tions should be considered as a set of tools from which the re- quired functional subset may be extracted in an actual implement- ation. As an example the presence of a superior protocol in some modules intercommunication might cause facilities to control the data flow on an IMC-connection to be redundant. IN SUCH CASES THE REDUNDANT FACILITIES COULD BE OMITTED IN THE ACTUAL IMPLEMENTATION OF THE IMC SERVICE SO THAT _6_æ_å_ THE STORAGE REQUIREMENTS AND THE PERFORMANCE WOULD NOT _5_>_å_ DIFFER ESSENTIALLY FROM A DEDICATED NON-STANDARD SOL- UTION TO THE REQUIRED INTER PU COMMUNICATION. \f The set of standardized IMC functions supplied should be broadly enough to suit a wide spectrum of the multifarious needs of dif- ferent kinds of inter module communication. An actual implementation of (a subset) of the IMC service will be referred to as an implementation of (a number of) IMC classes. An IMC class is defined as the functional specification of a speci- fic type of inter module communication based upon the standard- ized IMC functions. Examples of special classes of inter module communication are - datagram communication only - preconfigured PORTs and connections - connections with flow control The internal implementation of the IMC (internal IMC protocol etc.) on different interconnection structures depends upon the chosen interconnection hardware and the chosen internal communi- cation strategy. These facts should by all means be made invis- ible to the application modules by the functional IMC service in- terface. Fig. 6 illustrates the relationship between a set of IMC classes implemented on different interconnection media. Figure 6: IMC classes and interconnection structures. \f F_ 7_._ _ _ _ _ _ _ _ _I_N_T_E_R_C_O_N_N_E_C_T_I_O_N_ _M_E_D_I_A_ _A_N_D_ _G_E_N_E_R_A_L_I_T_Y_ 7. Within this report it has been a basic assumption that the in- terconnection media considered would guarantee no minimal service with respect to reliability and message passing delay. This assumption has mainly two aspects: - the derived model is independent of the chosen interconnec- tion structure - the derived model does not cover for applications or sy- stems, where a minimal service is needed (and delivered) from the interconnection medium. The latter implies that applications with high real-time require- ments like voice transmission, picture computing and process con- trol in distributed system environments are not covered by the derived model. However, it is the intention in the future to cover these speci- fic application areas too by extending the model, when it may be required. \f F_ A_._ _ _ _ _ _ _ _ _R_E_F_E_R_E_N_C_E_S_ A. 1 Philip H. Enslow, Jr.: "What is a "distributed" data processing system?" COMPUTER, January 1978 2 B. W. Lampson, M. Paul, H. J. Siegert: "Distributed Systems - Architechture and Implementation" Lecture Notes in Computer Science, Vol. 105 Springer Verlag 1981 3 James L. Peterson: "Notes on a workshop on distributed computing" (Held at Cambridge, Massachusetts on October the 12th-13th 1978) Operating Systems Review, July 1979 4 "Report on the Workshop on Fundamental Issues in Distributed Computing" (Fallbrook, California, December the 15th-17th 1980) Operating Systems Review, April 1981, Vol. 15, No 3 5 COMPUTER, January 1978 6 Walter H. Kohler: "A survey of techniques for synchronization and recovery in decentralized computer systems" COMPUTING SURVEYS, Vol. 13, No 2, June 1981 7 ISO Draft Proposal 7498, ISO TC 97/SC 16: "Open Systems Interconnection - Basic Reference Model" COMPUTER COMMUNICATIONS REVIEW, Vol. 11, No 2, April 1981 8 Stephen S. Yau & Chen-Chen Yang & M. Shatz: "An approach to Dristributed Computing System Software Design" IEEE Transactions on Software Engineering, July 1981 \f F_ 9 R. T. Yeh & K. M. Chandy: "On the design of elementary distributed systems" Computer Networks, Vol. 3, 1979 10 A. S. Tannenbaum & S. J. Mullender: "An overview of the Amoeba distributed operating system" OPERATING SYSTEMS REVIEW, 1981 11 B. D. Fleisch: "An architechture for PUP services in a Distributed Operating System" OPERATING SYSTEMS REVIEW, Vol. 15, No 1, 1981 12 Miller & Presotto: "XOS: An operating system for the X-tree architechture" OPERATING SYSTEMS REVIEW, Vol. 15, No 2, 1981 13 J. Hammerum: "DISTMON - et distribueret intermodul kommunikations system" (Danish language) m.sc. in computer science, Danish University, Copenhagen, February 1982 14 RCSL No 31-D631: DISTMON proposal RC Computer 15 RCSL No 42-i1983: DSA/IMC, Functional Description, User's Guide RC Computer A_._1_ _ _ _ _ _ _ _A_d_d_i_t_i_o_n_a_l_ _R_e_f_e_r_e_n_c_e_s_ A.1 Operating Systems Review (ACM), Quarterly Computer Architechture News (ACM), Quarterly Software Practice and Experience, Monthly IEEE Transactions on Software Engineering, Monthly Computing Surveys, Quarterly Computer Networks, Quarterly (and others) \f i T_A_B_L_E_ _O_F_ _C_O_N_T_E_N_T_S_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _P_A_G_E_ 1. INTRODUCTION ........................................... 1 2. RC855 SYSTEM COMPONENTS ................................ 3 2.1 Hardware .......................................... 3 2.2 Software .......................................... 4 3. RC855 CONFIGURATION POSSIBILITIES ...................... 5 3.1 Stand-Alone Systems ............................... 5 3.1.1 Terminals .................................. 5 3.1.2 Word Stations .............................. 6 3.2 Clustered Configurations .......................... 7 3.2.1 Terminals .................................. 8 3.2.2 Terminals and Work Stations ................ 9 3.2.3 Work Stations .............................. 12 3.2.4 Guidelines for Clustered Configurations .... 13 A. REFERENCES ............................................. 15 \f ii \f 1_._ _ _ _ _ _ _ _ _I_N_T_R_O_D_U_C_T_I_O_N_ 1. The RC855 is a member of the RC850 family of Display Terminals and Work Stations. All members of the family have a number of common features, whereas other features are specific to the type of Terminal or Work Station in question. Figure 1: RC855 Display Unit and Keyboard Unit. Applied ergonomics in design has added substantial qualities to the terminals. The user will find it possible to arrange his working place to suit his individual needs. Terminal impact on the environment has, moreover, been reduced to a minimum. The RC855 Work Station is designed for the construction of dis- tributed systems in which each Work Station may be used inter- changeably for communication with a host computer and as a local microcomputer system. \f The RC855 is available as a 'soft-programmed' Work Station, which can alternately be used as: - an Interactive Terminal (IBM 3270 BSC emulation) - a Batch Terminal (IBM 3780 BSC emulation) - a General-Purpose Microcomputer (running the CP/M operating system). The RC855 is also available as a 'hard-programmed', dedicated Terminal for IBM 3270 BSC emulation. A system may consist of a single RC855 or of a cluster of RC855 Terminals and/or Work Stations. A system may start as a single Work Station or Terminal. When ad- ditional Work Stations or Terminals are required locally, the sy- stem can be directly expanded into a clustered configuration. A stand-alone RC855 is designed from the start to serve as a clus- ter controller for other Work Stations and Terminals. The RC- CIRCUIT is used for interconnection in the cluster configuration. The RC855 reflects an ambitious conception of system design and holds new possibilities for the design of distributed systems. It fully recognizes the principles of functional flexibility, dis- tributed system architecture, and true modularity as the basis of economical, advanced solutions to the data processing require- ments. \f F_ 2_._ _ _ _ _ _ _ _ _R_C_8_5_5_ _S_Y_S_T_E_M_ _C_O_M_P_O_N_E_N_T_S_ 2. Below follows a list of the products which can be used in the configuration of the RC855 Systems. A few brief notes are in- cluded. General information about the components can be obtained from the Data Sheet for the individual products. Detailed descriptions of the products should be obtained from the technical documentation for the products. The installation of the hardware equipment is covered by ref. 1. 2_._1_ _ _ _ _ _ _ _H_a_r_d_w_a_r_e_ 2.1 RC855,01xx W_O_R_K_ _S_T_A_T_I_O_N_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Multifunction Work Station supporting one or two flexible disc drives. (xx determined by national language character set). RC855,11xx C_U_/_D_I_S_P_L_A_Y_ _S_T_A_T_I_O_N_,_ _3_2_7_0_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Dedicated Terminal for IBM 3270 BSC emula- tion. Partly functioning as stand-alone Ter- minal, partly as control unit for other Ter- minals. (xx determined by national language character set). RC855,21xx D_I_S_P_L_A_Y_ _S_T_A_T_I_O_N_,_ _3_2_7_0_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Dedicated Terminal for IBM 3270 BSC emula- tion. Interconnected by the RC-CIRCUIT to an RC855,11 or RC855,01. (xx determined by na- tional language character set). TF663L RC855 MODEM CABLE, 25 m TF663M RC855 MODEM CABLE, 12 m TF663S RC855 MODEM CABLE, 5 m \f TF664 RC-CIRCUIT WALL-RECEPTACLE, WITH SURFACE BOX TF665 RC-CIRCUIT WALL-RECEPTACLE, WITH FLUSH BOX TF661 RC-CIRCUIT CABLE, 5 m, TERMINAL END RC762-1 8" FLEXIBLE DISC DRIVE, FIRST UNIT RC762-2 8" FLEXIBLE DISC DRIVE, SECOND UNIT RC862 SERIAL PRINTER, 120 CPS, 80 COL. RC867 SERIAL PRINTER, 120 CPS, 136 COL. RC868 DAISY-WHEEL PRINTER, 55 CPS 2_._2_ _ _ _ _ _ _ _S_o_f_t_w_a_r_e_ 2.2 SW1804 I_B_M_ _3_2_7_0_ _B_S_C_ _E_M_U_L_A_T_O_R_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Emulation software package. SW1803 I_B_M_ _3_7_8_0_ _B_S_C_ _E_M_U_L_A_T_O_R_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Emulation software package. SW1811 C_P_/_M_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Control Program/Microcomputers (operating system). SW1812 W_O_R_D_S_T_A_R_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Word processing package. SW1813 D_A_T_A_S_T_A_R_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Data entry, retrieval, and updating program package. SW1814 C_I_S_ _C_O_B_O_L_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Compact Interactive Standard COBOL (compiler and run-time system). \f F_ 3_._ _ _ _ _ _ _ _ _R_C_8_5_5_ _C_O_N_F_I_G_U_R_A_T_I_O_N_ _P_O_S_S_I_B_I_L_I_T_I_E_S_ 3. 3_._1_ _ _ _ _ _ _ _S_t_a_n_d_-_A_l_o_n_e_ _S_y_s_t_e_m_s_ 3.1 Stand-alone systems can be based on either the dedicated RC855 Terminal or the RC855 Work Station. The choice should be reviewed in terms of the functions which the system is required to perform. 3_._1_._1_ _ _ _ _ _T_e_r_m_i_n_a_l_s_ 3.1.1 If only IBM 3270 BSC emulation is required, the RC855,11 CU/DIS- PLAY STATION should be chosen. Figure 2: RC855,11 CU/DISPLAY STATION; configuration outline. M_i_n_i_m_u_m_ _c_o_n_f_i_g_u_r_a_t_i_o_n_: - RC855,11 CU/DISPLAY STATION - TF663 RC855 MODEM CABLE O_p_t_i_o_n_: - one printer (see chapter 2). \f 3_._1_._2_ _ _ _ _ _W_o_r_k_ _S_t_a_t_i_o_n_s_ 3.1.2 If other functions than the IBM 3270 BSC emulation are required, the RC855,01 WORK STATION should be chosen. Figure 3: RC855,01 WORK STATION; configuration outline. M_i_n_i_m_u_m_ _c_o_n_f_i_g_u_r_a_t_i_o_n_: - RC855,01 WORK STATION - RC762-1 8" FLEXIBLE DISC DRIVE, FIRST UNIT - SW1811 CP/M O_p_t_i_o_n_s_: - one printer (see chapter 2) - RC762-2 8" FLEXIBLE DISC DRIVE, SECOND UNIT - TF663 RC855 MODEM CABLE (if communication is required) - SW18xx various software packages as described below. The RC855,01 is a versatile Work Station, which can alternately be loaded with a number of software packages: SW1804 I_B_M_ _3_2_7_0_ _B_S_C_ _E_M_U_L_A_T_O_R_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Makes the stand-alone RC855,01 act as an RC855,11 CU/DISPLAY STATION. \f SW1803 I_B_M_ _3_7_8_0_ _B_S_C_ _E_M_U_L_A_T_O_R_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Enables the RC855,01 to operate as an RJE station, submitting files from disc to a host computer and receiving data for disc storage or printout. SW1812 W_O_R_D_S_T_A_R_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Enables the RC855,01 to operate as a word processing system. SW1813 D_A_T_A_S_T_A_R_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Enables the RC855,01 to operate as a local filing system, allowing users to enter data for later retrieval, local processing, or submission to a host computer. SW1814 C_I_S_ _C_O_B_O_L_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Enables the RC855,01 to be used for local development of applications for processing locally on the RC855,01 WORK STATION (or another computer). Furthermore the user has the possiblity of installing and running most of the CP/M based software packages available on the market. 3_._2_ _ _ _ _ _ _ _C_l_u_s_t_e_r_e_d_ _C_o_n_f_i_g_u_r_a_t_i_o_n_s_ 3.2 The cluster concept of the RC855 has much to offer in terms of functional flexibility and provides a number of configuration possibilities. Up to eight RC855 Terminals/Work Stations may be grouped as a cluster for connection to a single BSC communication line. The Terminals and Work Stations in a cluster are interconnected by means of the RC-CIRCUIT, a simple, twisted wire pair. \f C_o_m_p_o_n_e_n_t_s_: 1 R_C_-_C_I_R_C_U_I_T_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ each: 2-8 TF664 (or TF665) RC-CIRCUIT WALL-RECEPTACLEs The choice of Terminals and/or Work Stations for cluster confi- guration should also be reviewed in terms of the functions which are required within the cluster. 3_._2_._1_ _ _ _ _ _T_e_r_m_i_n_a_l_s_ 3.2.1 If only IBM 3270 BSC emulation is required, the cluster should be configured using dedicated RC855 Terminals. C_l_u_s_t_e_r_ _c_o_n_f_i_g_u_r_a_t_i_o_n_: 1 R_C_8_5_5_,_1_1_ _C_U_/_D_I_S_P_L_A_Y_ _S_T_A_T_I_O_N_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ each: 1 TF663 RC855 MODEM CABLE 1 TF661 RC-CIRCUIT CABLE, TERMINAL END 1-7 R_C_8_5_5_,_2_1_ _D_I_S_P_L_A_Y_ _S_T_A_T_I_O_N_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ each: 1 TF661 RC-CIRCUIT CABLE, TERMINAL END O_p_t_i_o_n_: - o_n_e_ _p_r_i_n_t_e_r_ _(_s_e_e_ _c_h_a_p_t_e_r_ _2_)_ _e_a_c_h_ _R_C_8_5_5_,_1_1_ _a_n_d_ _R_C_8_5_5_,_2_1_ _ _ _ _ _ _ An attached printer is available as a common resource within the cluster, i.e. the printer can be accessed by other Ter- minals than the one to which it is physically connected. Each of the RC855 Terminals performs the following functions: editing of data on the display, processing of commands from the host, and print controlling on the attached printer. The RC855,11 CU/DISPLAY STATION additionally performs the fol- lowing functions: remote BSC communication with the host, status reporting, queue administration for all printers in the cluster,\f and routing of the communication within the cluster. (The Terminal which controls the cluster communication is often re- ferred to as c_i_r_c_u_i_t_ _m_a_s_t_e_r_ or p_r_i_m_a_r_y_ _t_e_r_m_i_n_a_l_ of the cluster). Figure 4: RC855,11 CU/DISPLAY STATION AND RC855,21 DISPLAY STA- TIONs; cluster configuration outline; example. Expanded to its maximum, the cluster comprises sixteen devices. 3_._2_._2_ _ _ _ _ _T_e_r_m_i_n_a_l_s_ _a_n_d_ _W_o_r_k_ _S_t_a_t_i_o_n_s_ 3.2.2 Also the RC855,01 WORK STATION can be incorporated a cluster configuration; any combination of up to eight Terminals and/or Work Stations is possible. \f Figure 5: RC855 Terminals and RC855 Work Station; cluster confi- guration outline; example 1. The RC855 Work Stations in the cluster will operate according to the software package loaded, i.e.: SW1804 I_B_M_ _3_2_7_0_ _B_S_C_ _E_M_U_L_A_T_O_R_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ The Work Station will form part of the cluster acting as an RC855,21 DISPLAY STATION. SW181x v_a_r_i_o_u_s_ _s_o_f_t_w_a_r_e_ _p_a_c_k_a_g_e_s_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ The Work Station will operate in local mode running DataStar, WordStar, etc. The RC855 Work Station can also be equipped with its own line for host communication, which adds the following capabilities accor- ding to which software package is loaded: \f SW1804 I_B_M_ _3_2_7_0_ _B_S_C_ _E_M_U_L_A_T_O_R_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ The Work Station is given the capability to operate as a stand-alone Terminal, i.e. as an RC855,11 CU/DISPLAY STATION. SW1805 I_B_M_ _3_7_8_0_ _B_S_C_ _E_M_U_L_A_T_O_R_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ The Work Station is given the capability to operate as an RJE station. Figure 6: RC855 Terminals and RC855 Work Station; cluster con- figuration outline; example 2. \f 3_._2_._3_._ _ _ _ _W_o_r_k_ _S_t_a_t_i_o_n_s_ 3.2.3 A cluster may constist entirely of RC855,01 WORK STATIONs. Figure 7: RC855,01 WORK STATIONs; cluster configuration outline; example. In a cluster of RC855 Work Stations, also the IBM 3780 BSC Emulator may utilize the RC-CIRCUIT, thereby allowing a number of Work Stations to access a host via a single BSC communication line. Only the Work Station attending the host communication will receive data/messages for display, printing, or diskette storage from the host. (That particular Work Station is often referred to as the circuit master). The facilities offered on the Work Stations other than the circuit master allow for job/data submission only. \f 3_._2_._4_ _ _ _ _ _G_u_i_d_e_l_i_n_e_s_ _f_o_r_ _C_l_u_s_t_e_r_e_d_ _C_o_n_f_i_g_u_r_a_t_i_o_n_s_ 3.2.4 When configuring clustered RC855 Systems, the configuration should always be reviewed in terms of the following guidelines: - a cluster may at most comprise eight Terminals and/or Work Stations (to each of which a printer may be connected). - a Work Station operating in local mode (i.e. running local applications, such as DataStar or WordStar) is logically disconnected from the cluster. - within a group of Terminals and/or Work Stations interconnected by means of the RC-CIRCUIT, only one circuit master can be active at a time, i.e. only one logical cluster is allowed to exist at a time. - an RC855,11 CU/DISPLAY STATION being part of the cluster must necessarily be the circuit master. - in a cluster of Terminals and/or Work Stations running the IBM 3270 BSC Emulator, the printers are available as a common re- source in that cluster. Otherwise printers are dedicated re- sources of the Terminals/Work Stations to which they are con- nected. - flexible disc drives are always dedicated resources of the Work Station to which they are connected. \f F_ \f F_A_._ _ _ _ _ _ _ _ _R_E_F_E_R_E_N_C_E_S_ A. 1 RCSL No 42-i1685: R_C_8_5_5_ _T_e_r_m_i_n_a_l_ _S_y_s_t_e_m_,_ _I_n_s_t_a_l_l_a_t_i_o_n_ _G_u_i_d_e_ Henning Christensen, January 1982 A_b_s_t_r_a_c_t_: This manual describes the installation of the hardware equipment of the RC855 terminal system. It con- tains: notes on planning, specifications of the RC-CIRCUIT and the cable connections, and a survey of the equipment. \f F_ \f «eof»