DataMuseum.dk

Presents historical artifacts from the history of:

CP/M

This is an automatic "excavation" of a thematic subset of
artifacts from Datamuseum.dk's BitArchive.

See our Wiki for more about CP/M

Excavated with: AutoArchaeologist - Free & Open Source Software.


top - metrics - download

⟦e35b5b0d4⟧ TextFile

    Length: 73472 (0x11f00)
    Types: TextFile
    Names: »D79«

Derivation

└─⟦a2495fc4f⟧ Bits:30005867/disk10.imd Dokumenter (RCSL m.m.)
    └─⟦this⟧ »D79« 

TextFile

           
           \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»