 |
Description  |
|
|
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to digital computer systems and more
specifically to apparatus and methods for controlling digital computer
systems.
2. Description of the Prior Art: FIG. 1
As digital computer systems have grown more ubiquitous and varied in size
and function, the need for cooperation among computer systems has
increased and is presently a dominant consideration in the design of
computer systems. Traditionally, there have been two models for
cooperation. In one, the single-system model, all of the cooperating
systems are treated as components of a single system. Typically, one of
the cooperating systems functions as a coordinating CPU. and the other
cooperating systems function as peripheral devices for the CPU system In
the other, the network model, all of the cooperating systems are connected
to a network and the network, instead of any of the cooperating systems,
defines the manner in which the cooperation takes place.
a. The Single System Model
In FIG. 1, single system 101 illustrates a contemporary example of the
single-system model. CPU 103, usually a minicomputer or a mainframe, is
connected to a group of personal computers 105. Each personal computer 105
has its own CPU and memory, and is capable of executing programs on its
own. However, when CPU 103 and PC 105 are cooperating. CPU 103 deals with
PC 105 as a coprocessor, an interactive terminal, as a source for batch
jobs, or as a source or destination for file transfers.
CPU 103 and PC 105 can serve as coprocessors only if both systems execute
the same instruction set and have the same operating system. When this is
the case, the systems may interact to the extent that PC 105 can receive
and execute a program from CPU 103, and vice-versa. An example of such a
system is provided by an IBM PC-XT/370 connected to an IBM 370 main frame.
The PC-XT 370 is capable of executing the IBM 370 instruction set, and
consequently, the PC-XT 370 may execute a program such as a compiler
available on the IBM 370 main frame.
In the other arrangements, CPU 103 and PC 105 may execute different
instruction sets and have different operating systems. When PC 105 is
acting as an interactive terminal, it operates under control of a program
in CPU 103. In response to that program. CPU 103 provides data to and
receives data from PC 105. In this arrangement. PC 105 is functionally no
different from any other terminal attached to CPU 103. Since PC 105 is
functionally a terminal, there is no direct interaction in this mode
between a program executing on PC 105 and CPU 103. At most, a program
executing on PC 105 may use data which PC 105 receives as a terminal and
provide data which PC 105 operating as a terminal provides to CPU 103.
When PC 105 is acting as a source for batch jobs, it creates a file which
contains a program executable by CPU 103 and any data required for
execution of the program and then transfers the file to CPU 103. CPU 103
then executes the program and returns the result to PC 105. In this
arrangement, there is no interaction during execution of the batch program
between PC 105 and CPU 103. Finally. PC 105 may be a source of or
destination for files for CPU 103. In general, what is involved is a
transfer of entire files between the systems. For example, a user of PC
105 may produce a document file and then transfer the complete document
file to CPU 103, and a later user may transfer the document file from CPU
103 to PC 105 for another editing session. Again, there is no interaction
between CPU 103 and PC 105 beyond that required to transfer the document.
In some cases, however, specific records may be transferred from a file in
CPU 103 to PC 105. An example of a system involving a CPU 103 and PCs 105
having different instruction sets in which the PC 105 operates as just
described is the IBM 3270-PC attached to an IBM 370 PC. An example of a
system in which a PC 105 receives individual records from a file is an IBM
personal computer attached to an IBM system 38 computer which is executing
the IBM personal computer-system/38 transfer facility.
Of the above systems, the only one which permits extensive cooperation
between PC 105 and CPU 103 is the one in which both PC 105 and CPU 103 can
execute the same instruction set. In the other cases, PC 105 functions
either as an I/O device connected to CPU 103 or as a mere source of or
destination for data. The disadvantages of the prior-art arrangements are
obvious. First the requirement that PC 105 must execute the same
instruction set as CPU 103 in order for the two systems to cooperate
effectively puts severe constraints on the designs of CPU 103 and PC 105
and of the system to which they belong. Second, when the two systems are
different. PC 105 cannot simultaneously use its own local intelligence and
the greater power of CPU 103. If PC 105 has access to CPU 103, it is
operating as a terminal or as a source of or destination for files, and is
not effectively using its own processing power; on the other hand, if PC
105 is executing a program on its own, it has no effective access to CPU
103. The user of system 101 thus has the choice between burdening CPU 103
with tasks which could be more effectively performed by PC 105 and
burdening PC 105 with tasks which could be more effectively performed by
CPU 103.
b. The Network Model
The most effective means heretofore available for achieving cooperation
between different computer systems has been the network. A typical
prior-art network is the IBM system network architecture (SNA), as
described in Systems Network Architecture Concepts and Products, GC
30-3072-1, 2.ed, IBM. Feb. 1984.
Network 107 consists of some number of computer systems 111 connected by
network system 117 Communication between two computer systems 111 attached
to network system 117 is by means of network protocols 113 specifying
operations to be performed using the network When computer system 1 111
requires resources available in computer system 2 111 to perform an
operation, computer system 1 111 provides a network protocol 113 to
network system 117. Protocol 113 is received by logical unit (LU) 115
connected to system 1 111 LU 115 is network system 117's interface to
individual computer systems 111. LU 115 then directs protocol 113 via
network system 117 to LU 115 for computer system 2 111 and computer system
2 111 performs the operation specified by protocol 113. If the operation
involves return of data to system 1 111, system 2 111 sends a return
protocol as just described.
The kinds of cooperation which may take place in network 107 are determined
entirely by network system 117. Network system 117 defines the form and
semantics of network protocols 113 Consequently, if system 2 111 performs
an operation for which there is no network protocol 113, system 1 111
cannot use network system 117 to have system 2 111 perform that operation
for it. The advantage of having network system 117 define the protocols is
that the behavior of network system 117 is not affected by the kinds of
computer systems attached to it; the disadvantage is that features of the
attached computer systems for which there are no system protocols are
simply unavailable to other attached computer systems. Another
disadvantage of cooperation via network system 117 is the relatively high
overhead. All forms of cooperation, no matter how simple, must be handled
by network system 117. In particular, the high overhead of network systems
of the SNA type have prohibited their use where only a small number of
systems need cooperate.
The prior art thus has provided for close cooperation among systems capable
of executing the same instruction set, has provided systems which
"cooperate" by treating one of the computer systems as a component of the
other, and has provided networks which allow systems to cooperate only as
defined by the network. There is, however, a need for close cooperation
among machines having different instruction sets without the limitations
and overhead of cooperation across a network. That need is filled by the
present invention.
SUMMARY OF THE INVENTION
The present invention relates to computer systems and in particular to the
control of one computer system by another computer system. In the present
invention, a first computer system is controlled by a second computer
system. The first and second systems are connected by apparatus for
transferring data between them. A program in the second computer system
forms a message termed a call protocol and sends it via the data transfer
apparatus to the first computer system. The call protocol specifies a
routine in the first computer system. The first computer system receives
the call protocol from the data transfer means. A program in the first
computer system interprets the call protocol and calls the specified
routine.
In further aspects of the invention, the program in the first computer
system may form a message called a return protocol containing data
returned by the specified routine. The first computer system sends the
return protocol via the data transfer apparatus to the second computer
system, where the program in the first computer system obtains the data
returned in the protocol from the protocol. Additionally, the call
protocol may contain arguments to be used in calling the specified
routine. Each of the cooperating computer systems may send call protocols
and receive return protocols.
It is thus an object of the invention to provide improved means by which
digital computer systems may cooperate;
It is a further object of the invention to provide means by which one
computer system may call routines in another computer system;
It is another object of the invention to provide protocols produced by one
computer system which specify routines to be called in another computer
system;
It is an additional object of the invention to provide protocols for
returning data produced by a call to another computer system;
It is a still further object of the invention to provide call protocols
which include data to be used in an invocation of the routine specified in
the call protocol.
Other objects and advantages of the present invention will be understood by
those of ordinary skill in the art after referring to the detailed
description of a preferred embodiment and the drawings, wherein:
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is block diagrams showing prior-art cooperation between systems;
FIG. 2 is a block diagram showing cooperating systems of the present
invention;
FIG. 2A is a diagram showing the general form of call and return protocols
in the present invention;
FIG. 3 is a diagram showing mutually cooperating systems employing call
protocols;
FIG. 4 is a block diagram of a preferred embodiment;
FIG. 5 is a detailed diagram of Request 429 in a preferred embodiment;
FIG. 6 is a detailed diagram of I/O structures in VS 401 in a preferred
embodiment;
FIG. 7 is a block diagram of MP 435 in a preferred embodiment;
FIG. 7A is a block diagram of IP 414 in a preferred embodiment;
FIG. 8 is a flow chart of the WS I/O loop in a preferred embodiment;
FIG. 9 is a detail of block 803 of the flow chart of FIG. 8;
FIGS. 10 and lOA are detailed flow charts of CPR 751 in IP 435;
FIG. 11 is a flow chart of a typical level 767 handler in a preferred
embodiment;
FIG. 12 presents the data structures for vsopen in a preferred embodiment;
FIG. 13 shows the OPEN call protocol in a preferred embodiment;
FIG. 13A shows the OPEN return protocol in a preferred embodiment;
FIG. 14 shows the data structures for the OPEN operation in VS 401 in a
preferred embodiment; and
FIG. 15 is a flowchart for the level 769 OPEN routine in a preferred
embodiment.
Reference numbers employed in the drawings have three digits. The most
significant digit is the number of the drawing in which the item referred
to by the reference number first appears; thus, reference number 215
refers to an item shown in FIG. 2 or 2A.
DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT
The following detailed description of a preferred embodiment of the
invention will begin with a general overview of the invention, will then
show how the invention is embodied in a particular set of cooperating
computer systems, and finally provide examples of operations which are
performed in the cooperating computer systems using the invention.
1. Overview of the Invention: FIGS. 2. 2A, and 3
As indicated in the Summary of the Invention, the present invention permits
two computer systems to cooperate at the level of the call and return
operations. The call and return operations are well-known in he art. In
the call operation, one routine, termed the caller, performs instructions
which suspend the caller's execution by saving the present state of the
execution of the caller and commencing an execution of another routine,
called the callee. In the return operation, the callee performs
instructions which terminate its own execution and restore the saved state
of the caller, thereby causing caller's suspended execution to resume. In
addition, the caller may place data termed parameters at a location in
memory known to both the caller and the callee. By means of the
parameters, the caller may provide data for use by the callee and the
callee may return the results of its operation to the caller. The machine
instruction sets for some computers contain call and return instructions
which perform the operations described above. However, the operations may
be performed on any system by using operations such as load, store, and
branch to perform the functions necessary for call and return.
Present-day programming practice uses call and return to construct large
programs out of subroutines. Call and return are particularly advantageous
because they insulate the caller from the detailed implementation of the
callee. All that the caller needs to know to use the function provided by
the callee is the callee's interface, that is, the means used by the
system to identify the callee (usually the callee's address in memory),
the parameters required by the callee, and the effect of the callee's
execution. Any callee can be called by any caller which knows the
interface, and as long as the interface does not change, changes to the
callee will not affect callers.
The present invention permits computer systems to communicate with each
other by means of call interfaces In its most general form, the invention
permits a caller executing on one system to call a callee on another
system The invention may be used to call any kind of routine which is
available in the system, but is particulary adapted for calling system
routines. System routines are routines which applications programs running
on the system can invoke when they need to use system resources. Among the
resources accessible by means of system routines are the functions
provided by the system's operating system, those provided by its file
system, and those provided by its data base system. Thus, communication by
means of call interfaces permits a program executing on one system easy
access to the system resources of another system.
Communication using the call interface is particularly useful when the
communicating machines have different instruction sets or different
operating systems. The properties previously described for the call
interface are retained, and consequently a caller on one system which
calls a callee on another system need only know the callee's interface,
and need have no knowledge of specific characteristics of the callee or
the system in which the callee will execute. Communication between
different types of systems is becoming increasingly important as small
systems such as personal computers are connected to large systems. In such
an environment, the present invention permits the personal computer full
access to the facilities of the large system. For example, the size and
complexity of the file systems used with a typical personal computer are
limited; however, if the personal computer is connected to a minicomputer
or a main frame, the present invention permits the personal computer to
use any function provided by the file system on the minicomputer or main
frame.
FIG. 2 presents a block diagram of two cooperating computer systems
incorporating the present invention. Computer systems 231 and 233 may be
similar or different computer systems. Each contains memory (203 and 219)
for storing data and programs and a CPU (201, 221) for manipulating the
data under control of the programs. It is immaterial for the present
invention whether either of the computer systems contains more than one
memory or more than one CPU. Systems 231 and 233 are connected by means of
data transport (DT) 213. DT 213 includes the physical means used to
transfer data from one system to the other and the programs required to
control the physical means. Again, the exact nature of DT 213 is
immaterial to the present invention. For example, when the two systems are
closely linked, it may be a means of exchanging interprocessor messages
between the systems. In less closely linked systems, various asynchronous
and synchronous data transport systems may be employed and the physical
means used to transfer the data may be any means which will transfer
representations of data from one system to the other.
The present invention has components in both system 233 and system 231.
Arrows connecting the components indicate flow of data between them.
Actual movement of data is performed by CPU 201 or 221 in response to
instructions in the program components. In system 233, there are a
program, MP 227, which produces call protocols, storage 225 for the
parameters for the call, and protocol buffer 223 for storing the call
protocol until it is output over DT 213 to system 231. In system 231,
there are a program, IP 211, which interprets the call protocols produced
by MP 227 and performs the call in system 231, protocol buffer 209, for
storing the protocols received from system 233, and parameter storage 207
for storing the parameters for the call. The invention operates as
follows: Calling program 229 places parameters for the routine in system
231 which it wishes to call in storage 225 and then invokes MP 227.
Depending on the implementation, the routine to be called may be specified
either in the parameters or in the call to MP 227. MP 227 uses the
contents of storage 225 to form the proper call protocol, places the
protocol in protocol buffer 223, and does whatever is required in system
233 to cause DT 213 to transfer the protocol to system 231. Calling
program 229 resumes execution after MP 227 receives the return protocol
from system 231 in prot 223, places data obtained from the return protocol
in call params 225, and returns.
IP 211 in system 231 has suspended execution until DT 213 indicates that it
has received a call protocol from system 233. DT 213 places the call
protocol in protocol memory 209, and IP 211 uses the data in the call
protocol to set up parameters for the call in storage 207 and then to call
called program 205. When called program 205 does a return operation, the
values returned are in storage 207. IP 211 uses those values to form a
return protocol, places the return protocol in storage 209, and causes DT
213 to transfer the return protocol to system 233. When DT 213 in system
233 receives the return protocol, it stores it in protocol storage 223 and
causes MP 227 to resume execution. MP 227 takes the values returned by the
return protocol, puts them into parameter storage 225, and returns.
Calling program 229 then retrieves the returned values from call
parameters 225.
FIG. 2A presents generalized representations of call protocols 215 and
return protocols 217. While the precise form of a given call or return
protocol is dependent on the called procedure and on the implementation of
the present invention, a call protocol 215 will in general contain at
least an identifier for the routine being called, shown in FIG. 2A as RI
235 and the call parameters, shown as CPAR 239. In some embodiments, the
call protocol will contain a value specifying the length of the protocol,
here CPL 237; in others, there may be a terminator value marking the end
of the protocol. Return protocol 217 has the same general form: RI 235
indicates the routine whose parameter values are being returned, RPL 241
indicates the length of the return protocol, and RPAR 243 contains the
return parameter values. Again, a terminator may be used to indicate the
end of the return protocol.
An important advantage of the present invention lies in the fact that from
calling program 229's point of view, there is no difference between a call
to a routine in system 233 and the call to the routine in system 231. In
both cases, calling program 229 places the parameters in memory, specifies
the location of the callee, and suspends execution. When the called
program does a return, calling program 229's execution resumes and the
data received from the called program is available in the parameters.
Indeed, the only practical distinction between the two calls is that the
call to the routine in system 231 requires more time.
The foregoing discussion has dealt only with calls from system 233 to
routines in system 231. It is, however, also possible to use the invention
for calls in both directions. Such a form of the invention is shown in
FIG. 3. FIG. 3 shows the memories (305, 343) of two systems (301, 303). In
FIG. 3, each system has components for providing calls to and receiving
calls from the other system, and DT 325 includes a path for calls from 301
to 303 and another for calls from 303 to 301. System 301 uses MP 317,
parameter memory 321, and protocol memory 323 to make a call received from
calling program 319 into a call protocol 215 for system 303, and system
303 uses IP 327, protocol memory 341, and parameter memory 339 to call
called program 337 in response to the protocol received from system 301.
Data returned by called program 337 goes back to system 301 via return
protocol 217 as described above. System 303 uses MP 329, parameter memory
333, and protocol memory 331 to make a call received from calling program
335 into a call protocol 215 for system 301, and system 301 uses IP 315,
protocol memory 309, and parameter memory 307 to call called program 311.
Again, data returned by called program 311 is returned to system 303 via a
return protocol 217, as previously described. By exchanging calls as
described above, systems 301 and 303 can jointly perform a task which
neither could perform by itself. For example, if the task involved two
data bases, one accessible to system 303 and the other accessible to
system 301, either system could access the other's data base as it
required.
2. A System Embodying the Invention: FIG. 4
A preferred embodiment of the present invention is implemented in a VS
computer system (VS) and a Professional Computer system (PC), both
manufactured by Wang Laboratories, Inc. The PC must include a 928 data
link board. A coaxial cable connects the PC and the VS.
FIG. 4 is a block diagram of the above implementation. In the block
diagram, components which have the same names as components of FIG. 2
perform the same functions. Thus, IP 414, like IP 211, processes call
protocols. As in FIG. 2, solid arrows indicate flow of data between
components of the invention; dashed arrows indicate that the data
structure which is the source of the arrow contains a pointer specifying
the data structure which is the destination of the arrow.
VS system 401 is a minicomputer which has as its main components CPU 403,
memory 402, a | | |
