⟦e35b5b0d4⟧

TextFile

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

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_ 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.

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.

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_ 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_ 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_ 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_ 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_ 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_ 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

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

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_ 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).

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

DataMuseum.dk

CP/M

⟦e35b5b0d4⟧ TextFile

Derivation

TextFile