System intercommunication processor used in distributed data processing system4466063Abstract A distributed data processing system including a general, communications network, and a plurality of local systems which each include a central processing unit, associated memory, and at least one peripheral device. The control of the intercommunication is effected by respective systems intercommunication processors, each attaching one local system to the network. Each SIP has a programmed processor, a local and a network interface, and a bidirectional buffer. The system intercommunications processor will provide for address and code parameter translation, resource requesting and allocating access granting and protecting of the local resources and information objects, while sharing resources among plural requesters. Also failure management and control panel simulation is effected by the systems intercommunications processor. Claims What is claimed is: Description BACKGROUND OF THE INVENTION
TABLE I
__________________________________________________________________________
MI0
A19M
A17M
A15M
A14M
A13M
A12M
A11M
A10M
A9M
Selection
__________________________________________________________________________
0 X X 0 0 0 0 0 0 0 Selection of
the CM (1)
0 X X 0 0 0 1 0 0 0 Selection of
LCM
0 X X 0 0 1 0 0 0 0 allocation
of buffer No
1 to the PM
0 X X 0 0 1 0 0 0 1 allocation
of buffer No
2 to the PM
0 X X 0 0 1 0 0 1 0 allocation
of buffer No
1 to the CM
0 X X 0 0 1 0 0 1 1 allocation
of buffer No
2 to the CM
0 X X 0 0 1 0 1 0 0 allocation
of buffer No
1 to the LCM
0 X X 0 0 1 0 1 0 1 allocation
of buffer No
2 to the LCM
0 X X 0 0 1 1 1 1 0 RAZ IRTC
Real-time
clock (2)
0 X X 0 1 0 0 0 0 0 timer initi-
alization (3)
0 X X 1 0 0 0 0 0 0 initializa-
tion system
IT (4)
1 0 0 0 most significant address
selection
bits RAM 64 K (5)
1 0 1 0 0 0 0 0 0 0 selection
buffer No 1 (5)
1 0 1 0 0 0 0 0 0 1 selection
buffer No 2 (5)
1 1 1 1 1 1 1 most selection
significant
PROM (5)
__________________________________________________________________________
The bit MIO defines the type of store access to the peripheral. The following notes (1)-(5) are explained: In Table I (1) The address bits A1M to A8M specify the address of the CM concerned and the nature of the command. (2) The real-time clock interrupt (IRTC) is reset to zero. (3) The address bits A1M, A2M specify the number of the initialized timer. (4) I1M specifies the command word sent. (5) A1M to A8M indicate the least significant address bits of the store. The bits marked "X" do not matter. The internal communication mechanism of the SIP and the I/O buffers of the DBMM will now be described. The location of the SIP between an LS and the communications network means that the SIP has to manage a great deal of information passing through it. This information follows various paths depending upon its nature and origin. A distinction must be made between: the commands to the SIP issued by the LS and received by the PM of the SIP which preprocesses them; the outgoing requests emitted by the PM to the communications network; the incoming requests received from the communications network and sent to the PM for analysis. After analysis, these requests may be communicated to the LS by the PM. the data emitted by an LS to the communications network; the data received from the communications network and sent to the LS. The communications network, which makes possible a continuous bidirectional traffic of 300 kwords per second, also implies rapid transfers through the SIP. Outside the PM processing time, it is therefore important for the transit time of the information through the SIP to be as rapid as possible. To attain this objective, the invention makes use of the following facilities: use of the modules (LCM, CMI) controlled by the PM and working in parallel with it; use of a communication mechanism facilitating the exchanges between the three components under consideration, (LS, PM, communications network via the CM). The communication mechanism comprises the two I/O buffers 50 and 51 (each of which are 256 word RAM) with triple access, and an allocation mechanism associated with each of them. FIG. 7 shows the principle of this mechanism for a buffer (e.g. 50). In FIG. 7, buffer 50 may be independently allocated to one of the three components concerned (PM, LS, CM) via the PM bus, the LS bus or the CM bus and multiplexer 52 in FIG. 2, which consists of selectable gates 52a, 52b and 52c shown in FIG. 7. The allocation control is carried out by the PM itself and the allocation mechanism 61 is a wired logic mechanism contained in CA 49 of the DBMM. A module (LS, CM) which has been allocated a buffer may use the latter exclusively as long as it has not been restored to the PM. In fact, the use of an I/O buffer by one of the three modules consists in carrying out an information exchange with the LS or with the communications network via the CM. The allocation mechanism is controlled by the PM by means of the following I/O instructions (reference to Table I): Allocation of the buffer to the PM; Allocation of the buffer to the LCM; Allocation of the buffer to the CM which has direct access to this buffer. The allocated buffer contains the execution order which is interpreted by the module responsible for processing the requested exchange. The PM is informed of the end of processing via an interrupt (CMIT1, CMIT2, LCEOE); it may then either analyze the information received or use the buffer concerned for another exchange. FIG. 8 shows the sequencing of the allocation mechanism between the three modules PM, LCM and CM. The LCM 21 will now be described in detail. This module controls the transfers between the main store 16 of an LS and the I/O buffers 50 and 51 allocated to it. It manages the interface with the CPU 15 and simulates the operator commands of the control panel. The interface with the CPU 15 is organized on following principles: 1. When a CIO start addressed to the SIP is decoded, there are two possibilities: a. The LCM is in an exchange state. In this case, the LCM loads the contents of the data bus into the mail box register (60, FIG. 5), transmits an interrupt (PCCST3) to the PM and switches to the execute state. The LCM returns to the exchange state when the PM executes a read mail box register 60 instruction via the selection of the LCM (Table I). b. The LCM is in an execute state. In this case the LCM rejects the CIO start (CR=1). 2. On the decoding of an SST addressed to the SIP, there are also two possibilities: a. The LCM is not ready to provide a status word to the LS (WST), the SST is thus rejected (CR=1) b. The LCM is ready to communicate a status word to the LS via an interrupt (WST); thus, when the instruction SST is decoded, it is accepted and the status word is sent on the data bus. The CA 31 of the LCM controls the switching between the states needed to control the CPU/LCM interface and the latter are shown in detail in FIG. 9. The possible states are: IDLE 1, IDLE 2: entered via the signals TMP or LCMSN. CAC1: CIO start accepted and entered via signal CIO. CACN1, CACN2: CIO start rejected and entered by the signals CIO.LCMSN or CIO.CLMSN. SAC1, SAC2, SAC3, SAC4: SST analyzed and entered via the signals SST.WST or LCMSN or UNCOND. SACN1, SACN2: SST rejected and entered via the condition SS.WST. ARE1, ARE2: address recognized and entered via the condition TMP.ARE. AREN 1, AREN2: address not recognized and entered via the condition TMP.ARE. The signals or (active) logic conditions needed for switching between states are defined below. LCMSN: read-out of the mail box register by the PM. LCMSN: no read-out of the mail box register by the PM. ARE: address recognized. ARE: address not recognized. AC: command accepted. UNCOND: unconditional jump. TMP: synchronization from the CPU. TPM: synchronization from the SIP. SST: SST command decoded. CIO: CIO start command decoded. WST: LCM ready to provide a status word. WST: LCM not ready to provide a status word. TPM/TMP: the generation of TPM (synchronization from the SIP) automatically causes the generation of TMP which switches the state sequencer into an IDLE state. This serves to synchronize the SIP, and a TMP (synchronization from the CPU) is always necessary for switching into another state. The LCM is in an IDLE 1 state, i.e. mail box clear. On the receipt of a start CIO (condition TMP.ARE), the LCM switches to the state ARE1 (address recognized) and then to the state CAC1 (CIO accepted) and, on the activation of TMP, to state IDLE 2. When the PM has read out the mail box register (LCMSN), the LCM once more switches to IDLE 1 state (exchange). If the LCM is in the execute state IDLE2, mail box occupied, the receipt of a CIO start causes it to switch to state ARE2 (address recognized) and then to state CACN2 (CIO not accepted) via condition CIO.LCMSN, The LCM switches to state IDLE on the next TMP. While the LCM is in an execute state, it follows the path IDLE2.fwdarw.ARE2.fwdarw.CACN2.fwdarw.IDLE2. As soon as the LCM switches to an exchange state, the activation of LCMSN allows the LCM to switch to the IDLE state where the next CIO start may be accepted, i.e. the switching path is ARE 2.fwdarw.CACN1 .fwdarw.IDLE2, or ARE2.fwdarw.CACN.LCMSN.fwdarw.CACN1.fwdarw.IDLE1. Likewise, if the LCM is in the state IDLE1 and if it is ready to provide a status word, the SST decoding path will be IDLE1.fwdarw.ARE1.fwdarw.SAC1.fwdarw.SAC3.fwdarw.IDLE1. If the LCM is not ready to provide a status word, the path followed will be IDLE1.fwdarw.ARE1.fwdarw.SACN1.fwdarw.IDLE1. If the LCM is in the state IDLE2, there are also two possibilities. Where the LCM is ready to provide a status word, the path will be IDLE2.fwdarw.ARE2.fwdarw.SAC2.fwdarw.SAC4.fwdarw.IDLE2, or IDLE2.fwdarw.ARE2.fwdarw.SAC2.fwdarw.SAC4.fwdarw.SAC3.fwdarw.IDLE1, or IDLE2.fwdarw.ARE2.fwdarw.SAC2.fwdarw.SAC1.fwdarw.SAC3.fwdarw.IDLE1. If the LCM is not ready to provide a status word, the path followed will be IDLE2.fwdarw.ARE2.fwdarw.SACN3.fwdarw.IDLE2, or IDLE2.fwdarw.ARE2.fwdarw.SACN3.fwdarw.SACN1.fwdarw.IDLE1. The various possibilities take into account the fact that the LCM may switch between the execute and exchange states (the dotted line separates FIG. 9 into two parts, that where the CIO start is accepted and that where it is rejected). In addition, due to synchronization problems, the LCM must switch via intermediate and different states, e.g. the activation of LCMSN or LCMSN. Where the address is not recognized (ARE), the LCM will alternate between IDLE1 and AREN1 or IDLE2 and AREN2, successively, depending upon the particular case. The simulation of an operator command from the control panel is carried out by the allocation of a command block located in an I/O buffer (described later with reference to FIG. 10). The format of a simulation command block is defined below. ##STR24## Word 1 contains 2 bits defining a simulation command (OO). Word 2 contains the bits defining each command to be simulated. Bit MCN: Master Clear (no parameter) Bit INT: control pannel interrupt (no parameter) Bit INST: execution of a program instruction by instruction (no parameter) IPL: initial loading program (parameters on control panel keys) RUN: start of a program (no parameter) LR: load a register, number specified in REP (4 bits) (content parameters to be loaded) HALT: halt the CPU X: not used in this particular context. The commands can therefore be simulated by program via the I/O buffers, or directly by the control panel via multiplexer 37 (FIGS. 4 and 10). The interpretation of these controls by the CPU is performed by a module located within it. The exchange of information blocks between the SIP and the LS by direct access to the store will now be described. The exchange of information blocks is explicitly requested by the PM from the LCM when an I/O buffer is allocated to it. This buffer then contains the directives concerning the requested exchange. The format of a command block is defined below. ##STR25## Bit IT: issue of an interrupt to the CPU as soon as the transfer operation has been carried out (IT=1). Here, the status word is transferred on the bus when the SST is executed by the CPU. MAD 128, MAD 64: two most significant bits defining the address of 128 kwords. Bit S: indicates the direction of exchange. The exchange mechanism with the LS is described with reference to FIG. 10 (structural diagram of the LCM) and FIG. 11 (detailed flowchart of the microprogram controlling the exchange mechanism with the LS). This microprogram, shown in FIG. 12, which is stored in CA 31 of the LCM, is a typical example of the various microprograms used in this invention. Initially, CA 31 of the LCM is in the IDLE state shown by micro-instruction 1 (uI1) awaiting the allocation of an I/O buffer (50 or 51) intended for it. As soon as LCRS=1 (test 80, to determine whether the buffer is allocated to the LCM), the first two words of the buffer (command block) are loaded into register MAR (memory address register) 38 of the LCM (group from uI2 to 8). The loading path of register MAR 38 is via logic gates 71 controlled by the micro-commands (uc) of the DBMM. The lefthand bit of the buffer is then tested (test 81). If SIM=0 (simulation command), the command to be simulated in MAR 38 is sent to CPU 15 (uI 27). If SIM=1, counters MAR 38, BAR 39 (buffer address register) and BLR 72 (block length register) are loaded with the exchange parameters contained in words 3 and 4 of the command block (uI 9 to 12). The loading path is via gates 71 for MAR, BLR and BAR, and via gates 73 for addressing the I/O buffer, under the micro control of the appropriate control automats of the LCM and DBMM. The exchange may then begin. A request is made for the SIP/LS bus (uI 13 and 14 and test 83). As soon as the bus has been obtained (active CEACK in test 84), the transfer of a word is carried out (uI 15 to 19 if the direction of transfer is from the buffer to main store 16, and uI 20 to 26 if it is the other way round). Test 85 defines the transfer direction. The operation -1 is carried out on BLR, +1 on BAR and +2 on MAR. Next a test 82 is made on LREQZ to determine the state of BLR. If BLR.noteq.0, the word transfer sequence begins again. If BLR=0, bit IT is tested (test 86). If IT=0 an interrupt is sent to the PM (uI 30) indicating that the command is terminated. The LCM switches to the IDLE state when the PM has de-allocated the buffer to the LCM (LCRS=0 in test 87). If, in test 86, IT=1, an interrupt is sent to CPU 15 (uI 28) and the I/O instruction SST is awaited (test 88). On its receipt, the status word is put on to the bus (uI 29). At the end of the exchange (PCES=0 in test 89 if the state word is accepted by the CPU) an interrupt is sent to the PM (uI 30), the I/O buffer is de-allocated and a return is made to IDLE. Where a command is simulated (uI 27), a monostable multivibrator is triggered at the start of the simulation and reset at the end. The state of the monostable multivibrator is tested in test 90 and if it is zero an interrupt is sent to the PM as already described. Tests 91 and 92 are made in the word transfer sequences pending the loading signals TRMS. and TRSMST respectively. In FIG. 10, 32 and 33 are bidirectional interface circuits which store the data during an exchange, while 37 is a multiplexer which selects either the command from the I/O buffer via MAR 38 or those from the control panel (PAN SIM) under control of control automat 31. The microprogram for this sequencer is described in detail in FIG. 12 and the exact description of each microinstruction bit is given below. NONE: -1 (decrement) on the length of the block to be transferred EOCE: clearing of the P 800 bus (LS) by the LCM PONE: +1 (increment) on the address of the I/O buffer LCEOE: interrupt to the PM indicating the end of the execution of a command LCW: READ/WRITE on the I/O buffer BIOEN: BIO (Bus in/out data) activated CEREQ: request for P 800 bus by the LCM MARL 1N: loading of register MAR (right-hand part) MARL 2N: loading of register MAR (left-hand part) MADVAL: main store address.fwdarw.bus (valid) BIOVAL: data.fwdarw.bus (valid) PTWO: +2 (double increment) on the address of the main store TMR: synchronization sent to the main store WST: wait state (interrupt to the CPU at the end of an exchange) RIT: reset to zero of interrupt on receipt of SST LCSA: synchronization of an operation on the I/O buffer WLCF: loading of the mail box of the PM (LCM.fwdarw.PM) BALRLN: loading of registers BAR, BLR SIME: simulation. CMI 22 is responsible for controlling the SIP access to the interface with the communications network via CM 13, sending the CM the commands loaded by the PM into a mail box register of the CMI (42) and loading the results from the CM into the mail box register (41) of the PM before alerting the mail via an interrupt. The exchange mechanism is described with reference to FIG. 13 (structural diagram of the CMI) and FIG. 14 (state sequences of the CMI control automat). There are two possibilities: 1. Command word sent to the CM from the PM As soon as a command word is placed in the mail box register (BLCMI) 42 by the PM, the control automat 40 switches to state E1 (BUS REQ) from state E0 (IDLE) in which an ICM/CM interface request is initialized. On receipt of a signal indicating that the interface has been allocated to the ICM (BUS AL.), the latter switches to state E4 (ECH OUT) and transmits the command WRITE after having put the address of the CM on the address bus and the contents of (ICM LB) 42 on the data bus. On detection of an end of exchange (signal EOE), control automat 40 issues an interrupt (IMBE) to the PM specifying that the CMI mail box register is once more available for communication of another command and at the same time switches to state E5 (ALERT PM). The control automat returns to state E0 (IDLE) as soon as the PM executes an I/O instruction (READ) which is interpreted by the ICM as an acknowledgment of the interrupt (PM.OK). 2. Result word from the CM to the PM As soon as an interrupt from the CM is received by the CMI control automat, the CMI switches from state 1 (IDLE) to state E0 (BUS REQ) in which a bus request is initialized. On the receipt of a signal indicating that the bus has been allocated to the ICM (BUS AL.), the latter switches to state E2 (ECH IN) and issues the command READ after having put the address of the CM on the address bus. On detection of an end of exchange and after the result word has been loaded into the mail box register of the PM (41), the control automat 40 switches to state E3 (ALERT PM) and issues an interrupt CMI T1 (or CMI T2) to the PM. As soon as the PM has read out its mail box by executing an I/O instruction (READ), the control automat 40 switches to state E1 (IDLE). The conditions needed for switching between states are shown in FIG. 14. The initialization functions, which include the procedures of initialization, remote loading and remote starting are described with reference to the flow chart of FIG. 15. These procedures are stored in the PROM store (2 kwords) of the SIP. The LS may be of different types. A tributary LS has no automatic starting and loading capacities and must be remote-loaded and remote-started. A pilot LS has self-loading, self-triggering capacities (hardware and software) and may remotely load and start tributary LS. An initial LS is used by the operator responsible for the starting and initialization of the global distributed data processing system. This may be a pilot LS or tributary LS. The initial LS is started by the operator, and the local SIP and its peripherals are initialized by the master clear (MCL) of the system, ref. 170 in flow chart 15. The SIP of the initial LS initialized the local CM ref. 171 before locally simulating the IPL (initial program loader) ref. 173. The initial SIP waits for a time .theta.1 before simulating the IPL to allow the LS time stabilize, particularly the disc units, ref. 172. If the initial LS is a tributary LS it sends a start CIO IPL to the tributary SIP (control panel keys set to the address of the SIP) refs. 174 and 175. The local (tributary) SIP on receipt of a CIO IPL issues a command to supply power to all the LS (execution by the local CM which is powered) and waits for a global system stabilization time .theta.1, refs. 176 and 177. As soon as the whole of the system has stabilized, the SIP broadcasts a request for the remote loading and remote starting of the main store of its LS (16 on FIG. 1) and of the RAM (25 on FIG. 4) of the SIP itself, ref. 178. On receipt of this broadcast request, the pilot LS which are capable of remotely loading the tributary LS concerned respond positively, ref. 180. The tributary LS then issues a remote loading command to a selected pilot LS ref. 181 which undertakes the initialization of the tributary LS. If the local LS is a pilot LS ref. 182, on the simulation of IPL by its SIP, the initial program is loaded locally (the keys of the control panel indicating the peripheral used for loading) ref. 183, and then an initialization module capable of remotely loading the tributary LS and self-loading the local LS (pilot here) is activated, ref. 184. The numbers of the LS which can be remotely loaded by each pilot LS are given to the local SIP which, on receipt of incoming requests which can be satisfied by the local pilot LS, responds positively to the tributary LS concerned. Where the initial LS is a pilot LS, the SIP issues a power on command to all, ref. 179. The tributary LS then sends a command for remote loading to the selected pilot LS (the first positive reply received from a pilot LS is selected) ref. 181, and the SIP proceeds with the remote loading and starting of the tributary LS via a request for remote loading and triggering to its pilot LS ref. 186, followed by the execution of this order, ref. 188, which awaits the loading of the pilot SIP, ref. 187. This command consists in executing in the tributary LS the remote loading of system and user programs into the main store, the simulation of LR, LCM, RUN on the control panel of the P 800, the remote loading of the coordination execution in the RAM of the tributary SIP and the branching to the start address of this program of the SIP, this being shown by ref. 189. At the end of execution, the tributary SIP and LS switch to an operational state, ref. 190 and 191. When the pilot LS has loaded or is sure that another pilot LS's loaded all the tributary LS which it can load remotely (via the last incoming request test, ref. 192) it initializes itself, ref. 193. This consists in loading the RAM of its own SIP, starting the SIP at the level of the RAM, loading its own P 800 system and starting it. At the end of this sequence, the pilot LS and SIP switch to an operational state, ref. 194 and 195. DESCRIPTON OF THE COORDINATION FUNCTIONS The operation of the various elements of the SIP and the communication mechanisms with its own LS and the others located on the communications network via the CM have already been described. What now remains is therefore to describe explicitly the coordination functions allocated to the coordination layer, i.e. the SIP. The coordination layer, i.e. the SIP, performs the following actions on the commands from an LS via its operating system. Initialization of the entire system (already described). Allocation of the resources according to availability and local load. Communications between processes belonging to different users applications. Translation of address and coding parameters between the global and local levels. Detection of faults in the system. Protection of applications by monitoring the rights of access to the resources and object at the level of each LS. Three types of command are sent from the local system to the coordination layer by the communication mechanisms already described (connection, transmission reception block, etc.). They are the commands, messages and service requests. Commands are sent either in the addressed mode or in the broadcast mode and are directly executed by the LS and SIP concerned. These may be used to initialize the overall system and also during reconfiguration or maintenance, i.e. when the system does not yet have or no longer has the capacity to process other orders. Messages sent to a mail box (logical addressing) allow processes belonging to respective different user applications to communicate. Service requests are sent by active processes which wish to acquire a resource. The receipt of these three types of orders implies the initilization of a micro-transaction consisting of several steps concerning the processing of the order. A micro-transaction is set up as soon as a command, a message or a request is received and is destroyed once the order has finally and completely been performed. Micro-transactions are transferred between LS by the communication mechanisms previously described. The steps make it possible to synchronize the various LS concerned and provide starting points in the event of reconfiguration. Every micro-transaction consists of a two-word header, followed by information constructed in relation to the nature of the order, as shown below. ##STR26## In this invention, only the commands may be directly addressed to an LS. The other orders always comprise at least one step during which the information is broadcast to an LS sub-assembly or to all of them. The execution of the orders received from outside the LS is described below. ##STR27## A command is always executed by the LS units addressed. The messages are directly loaded into the specified mail boxes if the size of the message sent will fit into the available space in the mail box. A distinction should be made between the mail boxes used in the format of an order and those of the SIP. The latter represent a physical space (usually a register) allowing the various components of the SIP and in the CM to intercommunicate, while the former represent a logical space or logical address referenced by its name (associative reference). The name of the mail box (LB), for example, indicated in a message describes a logical space referenced by its special name in the RAM store of the SIP. ##STR28## The orders may, for instance, define the opening, closing, reading or writing of the LB by creating processes. The reading of a mail box by the destination process is carried out during its initial execution or by positioning an event bit if the process is being executed. N steps may be distinguished in the microtransaction where N>1; an example is given below. ##STR29## When a complete message is arranged in a mail box, an event is broadcast so as to inform the creator process that a message is available for it. If this process is being executed, it can then program a read-out of the mail box. The execution order and the event are sent in broadcast mode to locate the mail box and the creator process in the SIP concerned. The format is defined below. ##STR30## The three-bit code indicates the nature of the descriptive block. There are eight possible types. If the address of the next link=0, the present block is the last. In the case of a message, therefore, the destination SIP carry out a filtering process on the mail box name, the size of the message and possibly on the name of the source process. There are two possible types of service requests. All the resources defined by the source process are concerned, e.g. the updating of multiple copies of data bases. The mechanism used is similar to that used for the mail boxes, i.e. an execution order is directly broadcast while any data accompanying it are sent as a function of the storage space available at the destinations. The format is defined below: ##STR31## The detailed processing of a request is described with reference to the flow chart of FIG. 16. This processing corresponds to the SIP pre-processing, source and destination, described in the general flow charts of FIG. 2, refs. 106 and 108. The left hand column refers to the origin SIP, the middle column to destination SIPi, the right hand column to further destination SIPj. When the SIPk (source) receives a service request from a process located in its own LS, it undertakes certain necessary steps, e.g. translation of the parameters (local.fwdarw.global), assembly of the request into a query format and its transmission to all (represented by 200). The SIPk (source) switches to a wait state, ref. 201, this being the selection phase. This service request is received by all the SIP connected to the overall communications network and, on the receipt of an incoming request, each SIP analyzes the information associated therewith. In the flow chart of FIG. 16, the request is received by the SIPi (destination) and SIPj which are in the wait state, ref. 202 and 203 respectively. The wait state relates only to the service request in question. In this invention, a request issued on the communications network is received by all the SIP's, including the source SIP, i.e. the concept of privilege does not exist. The incoming request is analyzed (refs. 204 and 205) by each SIP with respect to the following: The definition of the request makes possible an initial screening of the LS which should have the resources to process the request received. For example a compiler is needed for a compilation request, and the telecommunications programs (network and procedure) are needed to process a telecommunication's request. The application domain name makes possible a second screening giving an equitable distribution of the applications relative to the available resources and thus to the LS, and also makes possible the definition of interactions between these applications (protection and balancing). A table of the application domains known is constructed at the level of each SIP when the overall system is generated (after initialization). A third screening process may be carried out on the user resource requested by consulting a descriptive table of the local resources (located in the main store of the SIP). After these three screening processes, each SIP can determine whether its LS has the capacities needed to process the request, refs. 206 and 207. If the result of these analyzes is negative, the SIP switches to the wait state. If the result is positive, another analysis is performed to determine whether these resources are available, refs. 208 and 209. If not, the SIP awaits availability before replying. When all the resources asked for are available (system and user) within an LS, an acknowledgment of receipt is broadcast and all the necessary resources are allocated to the source SIP, while the SIP itself goes into the stand-by state, refs. 210 to 211. A distinction must be made between the system and user resources. For example, a user resource may be the compiler in a request for the compilation of a program, or a central processing unit for the execution of a program. In a telecommunications request, for instance, the programs may be the user resources but the protocols and procedures of the network are the system resources. The system selects an LS from among those giving a positive reply, one possible selection criterion used being that the first positive reply is selected. The architecture of the system allows only one positive reply to be selected by the source SIP if several SIP give a simultaneous positive reply. Here, it will be assumed that the two SIP's, SIPi (dest.) and SIPj (dest.) have the required resources and that they are available. SIPi (dest.) and SIPj (dest.) reply positively via a broadcast OK (refs. 210 and 211) but the reply from SIPj (dest.) is received before that from SIPi (dest.) by the SIPi (source). The automatic selection mechanisms ensures that SIPj (dest.) is selected (refs. 212 to 214), one property of the communications network being that a broadcast transmission is received by all at the same time. Thus the SIPi (dest.) is informed in this broadcast transmission that it has not been selected, the request is annulled (ref. 215) and a return is made to the wait state 202. The SIPk (dest.) selected awaits the execution order from the SIPk (source), ref. 215A. FIG. 17 shows the automatic selection principle. SIPi, SIPj and SIPk are connected to the communications network. The SIPk issues a request broadcast to all (REQUEST), received by all with a time delay. In the next transmission frame, SIPj, and SIPi reply positively (OKj, OKi) and these replies are received by all, but OKj is received by all before OKi because of its location on the network, and thus every unit is informed of the selection of SIPj. SIPk sends the execution order to SIPj, and SIPi is freed. The execution phase begins (described by refs. 216 to 221) in which the execution order is sent to SIPj, 216, any data sent 217, the translation of the parameters from global to local, the request is loaded into the main store of the LS and an interrupt is sent to the CPU for the execution of the request, 218. The SIPj switches to a wait state 219 and, at the end of the execution of the request 219a sends the data to the SIPk, 220. Then the results are sent to the SIPk, 221 which, in turn, loads them into the main store of its LS and informs it via an interrupt 222. The SIP switches to state END 222A relating to the request concerned. In general, the SIP source awaits the number of responses specified in the service request issued. When this number is reached, the source SIP terminates the micro-transaction or continues it if the data have to be sent. The number of steps required for the emission of data depends upon the table relative to the data blocks and the temporary store available in the units concerned. In a second type of service request, a choice of m resources is possible out of n, where n>m. In this case, the first step consists in executing the order received only after automatic selection performed based on the analysis of the replies sent by the various LS capable of processing the request. The format of this type of request (query and execution) is defined below: ##STR32## One field in the request word is designed to specify the number of resources requested (m). Each SIP receiving this query analyzes it and decides in the same way as before its capacity to process the incoming request. If the resources requested are available, a positive reply is broadcast and these resources are allocated to the source process of the request. In the query the number of resources required is specified (m). As long as this number is not reached, the SIP, having the necessary capacity and receiving the replies from the others, reply as soon as the resources requested are available. As soon as this number is reached, the SIP which are capable but have not yet replied cancel the request and the source may issue data associated with the request. In the event of simultaneity, the LS's capable of replying positively are selected as already described if the specified number is reached after receipt of their own reply. Otherwise, the request is cancelled and the resources freed. In fact, there is automatic self selection based on the analysis of the request issued and the replies provided by the available SIP. Each resource is described in an associated 8-word descriptive block (similar to the mail boxes). The format is defined below. ##STR33## The three-bit code defines the type of resource requested from among eight possibles: (1) mail box, (2) logical files, (3) physical peripherals, (4) communication line, (5) queue, (6) descriptive table of the active processes, The two unused possibilities may be used to specify other resources. Selection is made by taking the first resources which reply (identical for all). The replies are sent as soon as the necessary resources are available (system and user). The processing unit (CPU) is automatically allocated if the source process has a higher priority or the same priority as the procedure being executed. Otherwise the response time is weighted as a function of the load on the processing unit (percentage occupation) as shown on FIG. 18. T.sub.max is calculated (programmed in the two timers PM) so as to be a low fraction of the processing time of the service request, but also so as to be significant in view of the normal variations in response time. Thus the use of the resources are optimized by sharing them fairly between the applications. The translation of the parameters is necessary to allow already developed applications to use the common resources while retaining their local identifiers (file code N.sup.o, code line N.sup.o, etc.). Translation is thus carried out into local code N.sup.o .fwdarw.global code N.sup.o by the concatenation of the local code N.sup.o to the unit N.sup.o. The translation global code N.sup.o .fwdarw.local code H.sup.o is carried out using a correspondence table. Certain translations are used to reduce the storage space occupied in the local units. The field name in 6 ASCII characters (global) is transformed into 1 octet (8 bits) at the level of an LS. The SIP can detect a loss of coherence in a message or the failure of an LS via the CM. The CM can detect the abnormal behaviour of a source or a destination, or the loss of information, and can thus inform the SIP on such detection. The information supplied is: Loss of information; Transmission of an impossible message (repeated errors, absence of reply from the destination); Receipt of an impossible message (repeated errors, absence of reply from the source). The SIP acts on reaction of one of these items of information from the CM. A loss of information can be detected because a coherent message is always framed by two control words (STX, ETX). STX indicates start of message and ETX its end. As soon as the CM detects a loss of information (receipt of a packet by a destination whereas said destination has sent a negative acknowledgment of receipt, RNR on a broadcast call), it eliminates all information from the channel concerned until the detection of a new coherent message (STX), implying that the SIP will receive an incomplete message without (ETX). In this case, as soon as the SIP receives a new message from a source (STX) whereas the previous one has not been terminated by (ETX), it cancels the incomplete message and asks for its retransmission from the corresponding source. When the SIP receives information pertaining to the transmission or reception of an impossible message, it isolates the LS at the origin of the problem by sending a command to the CM to disconnect the LS concerned. On receipt of this command, the CM no longer takes account of the information received in the frames allocated to the specified LS until it has been reconnected.
Appendix
__________________________________________________________________________
Interface physical SIP/LS P 800 (bus signals)
Number
Type of
of
lines
lines
Description Mnemonic Source
Dest.
Function
__________________________________________________________________________
Control
1 accepted ACN SIP CPU I/O dialog
Control
6 bus interrupt coded lines
BIECOO, BIECO5
SIP CPU queries
Control
16 I/O lines bus
BIOOON, BIO15N
TOUS
TOUS
data channels
Control
1 bus occupied BUSYN SIP SIP bus control
CPU CPU
Control
1 character CHA SIP Mem character mode
CPU exchange
Control
1 request bus BUSRN SIP CPU bus request
Control
1 acknowledge CLEARN CPU SIP master clear (MCL)
Address
18 address lines
MADOO, MAD15,
SIP Mem addressing
MAD64, MAD128
CPU SIP
Control
1 selected master
MSN SIP SIP priority control
CPU CPU
Control
1 input OK OKI CPU CPU selection of
SIP SIP next master
Control
1 output OK OKO CPU CPU selection of
SIP SIP next master
Control
1 power supply failure
PWF CPU SIP power supply
control
Control
1 monitor external inter-
SCEIN CPU SIP interrupt
rupts sampling
Control
1 monitor priority chain
SPYC CPU SIP priority control
Control
1 Master clock to
TMPN CPU SIP exchange sync.
peripheral (CU) signal
Control
1 master clock to store
TMRN CPU Mem.
exchange sync.
SIP signal
Control
1 CU clock to master
TPMN SIP CPU exchange sync.
signal
Control
1 clock store to master
TRMN Mem.
SIP exchange sync.
CPU signal
Address
16 address lines
ADRON, ADRFN
SIP SIP addressing
CM CM
Control
1 bus sync. BULKN SIP SIP synchronization
CM
Control
1 bus input priority
BPRNN SIP of
SIP selection of next
CM master
Control
1 bus output priority
BPRON SIP SIP selection of next
of CM
master
Control
1 bus request BREQN SIP bus bus request
con-
trol
Control
1 bus occupied CBUSYN SIP SIP bus control
CM CM
Control
1 communications module
CMITN CM SIP interrupt
interrupt
Data 16 data bus DATON, DATFN
SIP SIP data bus
CM CM
Control
1 initialization
INITN SIP CM initialization
Control
1 I/O READ command
IORON SIP CM exchange sync. signal
Control
1 store WRITE command
IOWON SIP CM exchange sync. signal
Control
1 store READ command
MRDON CM SIP exchange sync. signal
Control
1 store WRITE command
MWTON CM SIP exchange sync. signal
Control
1 XFER recognition
XACKN CM SIP exchange sync. signal
SIP CM
__________________________________________________________________________
LIST OF REFERENCES
(1) E. Douglas Jensen "The Honeywell Experimental Distributed Processor A
Overview". Computer, January 1978, p 28-38.
(2) Heart F.E., Ornstein S.M., Crowther W.R. & Barker W.B. "A New
Minicomputer/Multiprocessor for the ARPA Network" NCC (1973) p
(3) Ornstein S.M., Crowther W.R., Kraley M.F., Bressler R.D. & Michel A.
"Pluribus A Reliable Multiprocessor" NCC (1975) p
(4) Vidas B. Glydys & Judith A. Edwards "Optimal Partitioning Of Workload
for Distributed Systems" Digest of Papers, Compcon 76 Fall, September
1976, p 353-357.
(5) Thomal O. Wolff "Improvements In Realtime Distributed Control". Diges
of Papers, Compcon 77 Fall, September 1977, p
(6) Le Cann G. "A Protocal to Achieve Distributed Control In Failure
Tolerant Multicomputer Systems". SIRIUS Research Report IRIA CRTI 002
1977.
(7) Farber D.J. "A Distributed Computer System". Report 4, Dept. Of
Information And Computer Sciences, University of California, Irvine,
U.S.A.
|
Same subclass Same class Consider this |
||||||||||