CA1223968A - Real-time distributed data-base management system - Google Patents
Real-time distributed data-base management systemInfo
- Publication number
- CA1223968A CA1223968A CA000475497A CA475497A CA1223968A CA 1223968 A CA1223968 A CA 1223968A CA 000475497 A CA000475497 A CA 000475497A CA 475497 A CA475497 A CA 475497A CA 1223968 A CA1223968 A CA 1223968A
- Authority
- CA
- Canada
- Prior art keywords
- local
- variable
- processor
- value
- procedure
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B19/00—Programme-control systems
- G05B19/02—Programme-control systems electric
- G05B19/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
- G05B19/042—Programme control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
- G05B19/0421—Multiprocessor system
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B19/00—Programme-control systems
- G05B19/02—Programme-control systems electric
- G05B19/418—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS], computer integrated manufacturing [CIM]
- G05B19/41835—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS], computer integrated manufacturing [CIM] characterised by programme execution
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
- G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
- G06F15/161—Computing infrastructure, e.g. computer clusters, blade chassis or hardware partitioning
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B2219/00—Program-control systems
- G05B2219/20—Pc systems
- G05B2219/22—Pc multi processor system
- G05B2219/2241—Real time database, each processor stores in local memory used variables
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B2219/00—Program-control systems
- G05B2219/20—Pc systems
- G05B2219/22—Pc multi processor system
- G05B2219/2242—Program references to variable by absolute address, update of absolute address
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B2219/00—Program-control systems
- G05B2219/30—Nc systems
- G05B2219/31—From computer integrated manufacturing till monitoring
- G05B2219/31203—Purpose, identification of messages, programs, variables
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B2219/00—Program-control systems
- G05B2219/30—Nc systems
- G05B2219/31—From computer integrated manufacturing till monitoring
- G05B2219/31324—Distributed real time knowledge, database
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B2219/00—Program-control systems
- G05B2219/30—Nc systems
- G05B2219/34—Director, elements to supervisory
- G05B2219/34345—Database for sequential control of several machines by messages
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B2219/00—Program-control systems
- G05B2219/30—Nc systems
- G05B2219/34—Director, elements to supervisory
- G05B2219/34403—RTI real time, kernel, processing
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B2219/00—Program-control systems
- G05B2219/30—Nc systems
- G05B2219/34—Director, elements to supervisory
- G05B2219/34404—Allocate storage, memory in each processor for a copy of needed data
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
- G06F2212/25—Using a specific main memory architecture
- G06F2212/251—Local memory within processor subsystem
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
- G06F2212/25—Using a specific main memory architecture
- G06F2212/253—Centralized memory
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02P—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
- Y02P90/00—Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
- Y02P90/02—Total factory control, e.g. smart factories, flexible manufacturing systems [FMS] or integrated manufacturing systems [IMS]
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
Abstract
17.
ABSTRACT
An improved real-time distribute data-base system that stores in the local memory of each processor copies of only those variables necessary for execution of the programs in that processor. Performance is enhanced by using the absolute address of variables in each program reference, with automatic updating of all program references when the location of variables are changed. Flexibility in user application programming is enhanced by permitting combination and conditional updates of variables through the interaction of multiple processors.
ABSTRACT
An improved real-time distribute data-base system that stores in the local memory of each processor copies of only those variables necessary for execution of the programs in that processor. Performance is enhanced by using the absolute address of variables in each program reference, with automatic updating of all program references when the location of variables are changed. Flexibility in user application programming is enhanced by permitting combination and conditional updates of variables through the interaction of multiple processors.
Description
~22,;3 91~3 BACKGROUND OF THE INVENTION
1. Field of the invention This invention relates to a database management software system, and in particular to an improved realtime distributed data-base management system configured for high-speed operation.
1. Field of the invention This invention relates to a database management software system, and in particular to an improved realtime distributed data-base management system configured for high-speed operation.
2. Prior Art A data-base management system (DIMS) is a generalized software system designed to provide facilities for data base organization, access, and control. A data base is a collection of logically organized information intended for access by multiple users. The data base constitutes the collective requirements of all users. However, any individual user would typically require access to only a portion of -the entire data base.
In a distributed data processing system having multiple computer processors, a general problem arises as to the most efficient organization of the data base and optimum procedures for accessing that data base while minimizing required system resources. The problem becomes particularly acute in real-time computer operating environments, such as are used -to control manufacturing processes. In such an environment, various of the processors require access -to data that is constantly changing, such as -temperature, pressure, flow rate, and other manufacturing process parameters that are input in-to the computer processing system for evaluation and control of -the manufacturing process.
In a -typical multiple processor computer architecture used for realtime manufacturing process control, each processor is couple -to a communications bus, which may be one of several communications bus types. Typically, in a I"
o - 2 - ~23~
real-time operating system, each local processor receives data from or sends data to a number of sub processors. The sub processors are coupled to sensors and/or actuators for interaction with the manufacturing process. Often one processor will need data collected by another processor to update calculations used in -the manufacturing process control.
For example, one local processor may obtain temperature data on a portion of a manufacturing process. This temperature data must be used by a second processor in order to limit the rate of flow of material in another portion of the manufacturing process. However, it is rare that any one processor needs access to all of the data being collected by all of the processors in the system. Therefore, it would be wasteful of processing system resources -to store duplicate copies of the complete data base in each local processor.
Further, it would be wasteful of system communication resources to update each such data base in each processor whenever the data changes. Thus, it is advantageous to devise a data base architecture that provides access by one processing unit to data in another processing unit upon demand.
Some prior art systems have utilized a centralized data base in a main processor, which each local processor accesses as necessary to ascertain the current value of particular variables. However, this architecture is not very reliable, since a failure in the main processor may completely disrupt operation of the processing system as a whole.
. ^~:., ~L2~3~
- pa -Examples of such prior art systems may be found in distributed micro/mini computer Systems" by Cay Weitzman (Prentice Hall, Inc. copyright 1980).
It is advantageous in a real-time computer processing system to permit each local processor to locally store and directly address data that is necessary in the operation of that processor. Such direct addressing permits improved performance by I
/
ho do 3. PD-7200 permitting the processor to fetch data from its local memory without having to calculate or otherwise locate the address of that information. Such local storage of necessary information is also advantageous in providing higher reliability for the system as a whole, since, by locally storing data acquired from another processor, no one processor is dependent upon the accessibility and reliability of a centralized data base. It is also advantageous to provide a real-time data base management system that permits automatic update of data used in a local processor but originally obtained from another processor.
Therefore, it is an object of the present invent lion to provide an improved real-time data base management system which minimizes the memory requirements of each local processor, provides high reliability by locally storing data used in each processor, and minimizes the amount of processing time incurred in transferring data from one processor to another processor.
.
I
4. PD~7200 SUMMARY OF THE INVENTION
The present invention provides a Block Builder procedure and a Real-Time Data Management procedure for locally storing in each processor a copy of each variable needed by the programs executed by that processor. Further, each reference by a program in a local processor to a variable is to the absolute address of the original of that variable, no matter where in the processing system the original of the variable is initially determined. The Real Time Data Management procedure permits each copy of a variable to be updated by the current value of the original variable on a periodic basis or upon the occurrence of a defined condition. Further still, the Real-Time Data Management procedure permits great flexibility in data manipulation, including the ability to have a program in a first processor address an original variable in a second processor, and direct that the most current value for that variable then be stored in a third processor upon the occurrence of a designated condition in a fourth processor, with an acknowledgment signal sent to a fifth processor.
In a distributed data processing system having multiple computer processors, a general problem arises as to the most efficient organization of the data base and optimum procedures for accessing that data base while minimizing required system resources. The problem becomes particularly acute in real-time computer operating environments, such as are used -to control manufacturing processes. In such an environment, various of the processors require access -to data that is constantly changing, such as -temperature, pressure, flow rate, and other manufacturing process parameters that are input in-to the computer processing system for evaluation and control of -the manufacturing process.
In a -typical multiple processor computer architecture used for realtime manufacturing process control, each processor is couple -to a communications bus, which may be one of several communications bus types. Typically, in a I"
o - 2 - ~23~
real-time operating system, each local processor receives data from or sends data to a number of sub processors. The sub processors are coupled to sensors and/or actuators for interaction with the manufacturing process. Often one processor will need data collected by another processor to update calculations used in -the manufacturing process control.
For example, one local processor may obtain temperature data on a portion of a manufacturing process. This temperature data must be used by a second processor in order to limit the rate of flow of material in another portion of the manufacturing process. However, it is rare that any one processor needs access to all of the data being collected by all of the processors in the system. Therefore, it would be wasteful of processing system resources -to store duplicate copies of the complete data base in each local processor.
Further, it would be wasteful of system communication resources to update each such data base in each processor whenever the data changes. Thus, it is advantageous to devise a data base architecture that provides access by one processing unit to data in another processing unit upon demand.
Some prior art systems have utilized a centralized data base in a main processor, which each local processor accesses as necessary to ascertain the current value of particular variables. However, this architecture is not very reliable, since a failure in the main processor may completely disrupt operation of the processing system as a whole.
. ^~:., ~L2~3~
- pa -Examples of such prior art systems may be found in distributed micro/mini computer Systems" by Cay Weitzman (Prentice Hall, Inc. copyright 1980).
It is advantageous in a real-time computer processing system to permit each local processor to locally store and directly address data that is necessary in the operation of that processor. Such direct addressing permits improved performance by I
/
ho do 3. PD-7200 permitting the processor to fetch data from its local memory without having to calculate or otherwise locate the address of that information. Such local storage of necessary information is also advantageous in providing higher reliability for the system as a whole, since, by locally storing data acquired from another processor, no one processor is dependent upon the accessibility and reliability of a centralized data base. It is also advantageous to provide a real-time data base management system that permits automatic update of data used in a local processor but originally obtained from another processor.
Therefore, it is an object of the present invent lion to provide an improved real-time data base management system which minimizes the memory requirements of each local processor, provides high reliability by locally storing data used in each processor, and minimizes the amount of processing time incurred in transferring data from one processor to another processor.
.
I
4. PD~7200 SUMMARY OF THE INVENTION
The present invention provides a Block Builder procedure and a Real-Time Data Management procedure for locally storing in each processor a copy of each variable needed by the programs executed by that processor. Further, each reference by a program in a local processor to a variable is to the absolute address of the original of that variable, no matter where in the processing system the original of the variable is initially determined. The Real Time Data Management procedure permits each copy of a variable to be updated by the current value of the original variable on a periodic basis or upon the occurrence of a defined condition. Further still, the Real-Time Data Management procedure permits great flexibility in data manipulation, including the ability to have a program in a first processor address an original variable in a second processor, and direct that the most current value for that variable then be stored in a third processor upon the occurrence of a designated condition in a fourth processor, with an acknowledgment signal sent to a fifth processor.
3~6~3 5. PD-7200 DESCRIPTION OF THE DRAWINGS
FIGURE 1 is a block diagram of a real-time distributed processing computer system of the type that might be used to control a manufacturing process.
FIGURE 2 is a flow-chart of the Block Builder procedure of the present invention.
FIGURE 3 is a flow-chart of a first part of the Real-Time Data Management procedure of the present invention.
FIGURE 4 is a flow-chart of a second part of the Real-Time Data Management procedure of the present invention.
I
6. PD-7200 DETAILED DESCRIPTION OF THE INVENTION
The present invention, in its preferred embodiment, is composed of two parts: a Block Builder procedure, and a Real-Time Data Management (RTDM) procedure. The Block Builder procedure is performed in a main computer processor, such as the main processor 1 shown in Figure 1. As a prerequisite for operation of the invention, all programs designed to control procedures in the local processors (pa ... on, in Figure 1) must be prepared through interaction with the Block Builder However, the preparation of such user application programs may be done from any of the local processors by means of well-known remote communication procedures between a local processor and the main pro-censor 1.
Figure 2 shows a block diagram of the procedure performed by the Block Builder. Sequence A constitutes the main procedure. As a user prepares an application program, the Block Builder monitors the program text for the occurrence of variable names (stew 20). As each variable name is input by the user, it is tested against a master symbol table or list of variable names to see whether this occurrence is the very first occurrence of the variable (step 22). If so, the Block Builder procedure asks the user to define the attributes of the variable, such as its length, type, and default value (step 24). The Block Builder then queries the user as to what processor will supply the VALUE for the variable (step 26). This processor (denoted "X") is then accessed by the Block Builder and storage for the variable is allocated in that processor (step 28). Also, if a default value is known for the variable at that time, that VALUE is stored in Processor X.
Thereafter, the Block Builder enters the name of the new variable into a symbol table in the main processor, which is a master list of all variables used 3~36~3 7. PD-7200 throughout the entire computer system (step 30). The symbol table entry for the new variable essentially consists of the name of the variable, the attributes of the variable, the absolute address of the variable in the processor where the VALUE of the variable will be determined, and a list of all the references in all programs throughout the system that refer to that variable.
The "absolute address" of a variable refers to the lo processor, and the memory location within that processor, in which the VALUE for what variable is initially stored upon determination by that processor.
In actual practice, a relocatable "absolute" address is used, determined in any of several ways known in the prior art, in order to increase system flexibility and ease of operating system programming. By storing this absolute address for each variable the Block Builder procedure and the RTDM procedure can directly access the current VALUE of the variable, rather than indirectly referencing that VALUE such as may be the case in prior art "look-up tables".
If the user has designated a processor other than the local processor upon which the program is being implemented as the source for the VALVE to be assigned to that variable, then Sequence B is performed step 32)~ Further, if the outcome of the test in step 22 is that a variable designated by a user is not the very first occurrence of the variable, then the Block Builder tests to determine if the present occurrence is the first occurrence of the variable in the current processor (Step OWE If so then Sequence B is also performed.
In Sequence B, shown in Figure 2, the Block Builder allocates storage for a duplicate copy of the variable in the processor that will reference the original variable (step 34). The referring processor is distinguished from the processor in which the VALUE
I 239 6 8 8. PD-7200 for the variable is determined in that any processor within the system may refer to a particular variable (and thus have space allocated in its local memory for a copy of that variable), but only one processor in the system actually determines the VALUE for that variable.
Two important aspects of the present invention are that storage space is allocated for a variable only in referring processors (rather than in all processors), and each program step in a program executed by a referring processor that references that variable is assigned the absolute address of the local duplicate copy of the variable. Thus, during the execution of any program that makes reference to a variable, the program may directly address the local copy of that variable, and through the RTDM procedure obtain a copy of the most current VALUE for that variable and store it in that address in the processor's local memory. In essence, each local processor stores in its local memory a copy of every variable used by the programs executed by that local processor. The values of these variables are automatically updated through the TAM
procedure at a rate specified by the user in each application program. Each program in each local processor references each variable by the absolute address of that variable in the processor's local memory. Further, the RTDM procedure references the absolute address of the original variable in the processor where the VALUE of the variable is determined. This speeds up execution of the program by eliminating the program steps that a look-up table or other indirect access method requires in determining the address or location of the current value for each desired variable As the next step in Sequence B, a reference is added into the master symbol table entry for the variable, indicating the absolute address of any command or other program line that refers to the I
9. P~-7200 particular variable (step owe This is useful in system maintenance where, for example, the location of a variable in the processor that determines the VALUE
of the variable is changed. If such a change occurs, the Block Builder may refer to the master symbol table and determine the absolute address of each and every reference to that variable in every program throughout the processing system. The Block Builder then automatically accesses each of those programs using such references and changes the address of the variable for each such reference.
In the next step in Sequence B, the Block Builder causes each processor in which a program makes reference to a variable to send a "Requesting Task Request" message to the Processor X which determines the VALUE for the variable (step 38). The user must specify the RATE at the which the VALUE for the variable is to be ascertained or whether the VALVE is to be ascertained only upon the occurrence of a condition, the destination that the variable is to be sent to and whether any processor is to be notified upon the completion of the access -to the VALUE for the variable.
Lastly, if the outcome of the test in step 33 is that a variable name is not the first occurrence in the current processor, a step identical to step 36 is performed, adding a reference to the occurrence into the symbol table (step OWE
After the Block Builder procedure sets up the basic structure of storage allocation in each local processor for a copy of each variable to be accessed by that processor, together with absolute address references to the processor in which the VALVE of each variable is determined, control over the real-time data base management system is governed by the RTDM
procedure, outlined in Figures 3 and 4. Each loyal processor has resident a copy of the RTDM procedure.
lo .~239~8 PD-7200 Basically, up to five different types of nodes may exist under the RTDM procedure. A Requesting Processor is a local processor that initiates a request for the current VALUE of a variable. A Source Processor is the local processor in which the VALUE for the variable is actually determined (for example, the value of a variable named TEMPT may be determined in a local processor that records the output of a thermal sensor).
A third type of node is a Conditional Processor, lo in which a flag or status bit may be set upon the occurrence of a particular condition (for example, when the temperature or pressure of a particular point in the manufacturing process exceeds a defined value).
A fourth type of node is a Destination Processor, where the value from the Source Processor is to be sent. The fifth type of node is a Notification Processor, where an acknowledgment signal may be sent by the Destination Processor to indicate receipt of the current VALUE for the variable.
Virtually any combination of the above node types may be combined under the TAM procedure to effectuate maximum flexibility in user application programming.
For example, a Requesting Processor can seek the VALUE
of a variable from a second (or Source) processor upon the occurrence of a user-defined condition in a third (or Conditional) processor. The value of the variable may then be sent to a fourth (or Destination) processor, with an acknowledgment of receipt signal being sent to a fifth (or Notification) processor.
However, one or more local processors may serve in multiple roles. For example, the Requesting Processor will often also be the Destination Processor.
In operation, a user program, or Requesting Task ("RUT"), will request the VALUE for a variable from the RTDM procedure in the processor in which the user program resides (step 3Q0). The RUT Request will specify the absolute address ion SOURCE) of the memory 1~396~ o location containing the VALUE of the variable in the Source Processor which determines that VALUE. The RUT
Request optionally may designate the RATE at which the VALUE of the variable is Jo be fetched, or a Conditional Processor (by means of a CONDITION
indicator) in which the occurrence of a defined condition will cause the Source Processor to fetch the VALUE of the variable.
The RUT Request will also designate (by means of a 10 DESTINATION indicator) the Destination Processor to which the fetched VALUE is to be sent The Destination Processor may be identical to the Requesting Processor.
As a further option, the RUT Request may indicate (by means of the TS/NOTIFICATION indicator) that the Destination Processor is to "time stamp" the received VALUE Jo indicate when the VALUE was received as a check on the requesting process, or the RUT Request may indicate a Notification Processor to which the Destination Processor must send an acknowledgment message upon the receipt of the fetched VALUE.
The RUT Request is stored in the Requesting Processor (step 302) for purposes of system reliability in the event that all or part of the IT Requests throughout the system must be reissued (for example, when a portion of the system has failed).
The Requesting Processor examines the RUT Request to determine if the SOURCE of the VALUE for the variable is in the Requesting Processor (step 304). If so, the RUT Request is tested to determine if the DESTINATION of the VALUE is in the Requesting Processor (step 306~. If so, a third test determines whether a condition must be met and whether the Requesting Processor is also the Conditional Processor (step 308~.
If no condition must be met, or if the Requesting Processor is also the Conditional Processor, then the Requesting Processor fetches the current VALUE from its local memory at the NATE specified in the IT Request, ~23~
12. PD-7200 or upon the local occurrence of the user defined condition (step 310). The Requesting Processor then futures the VALUE in the local memory location specified in the DESTINATION indicator of the RUT Request (step 312). If the TS/NOTIFIQTION indicator has been set in the RUT Request, then at the user's selection either the time at which the VALUE was stored is saved along with the VALUE, or an acknowledgment message is sent to the Notification Processor whose address is specified in the TS/NOTIFICATION indicator (step 314~.
If the source of the VALUE is determined to be in a different processor as a result of the test in step 304, then an RIP Request is sent to the Source Processor indicated by the SOURCE address (step 316). The RIP
Request contains the absolute system address of the variable desired, the information specified in the original RUT Request, and a Request ID that uniquely identifies the particular RIP Request and the Requesting Processor, for reference purposes.
The Source Processor receives and then stores the RIP Request for purposes of system reliability (step 318, Figure 4).
The UP Request is then tested to determine whether a condition must be met, and if so whether the Source Processor is the Conditional Processor (Step 320).
If no condition must be met, or if the Source Processor is also the Conditional Processor, then the Source Processor builds a "send list" (step 322). The "send list" contains the address of the desired variable and the Request ID.
The Source Processor then fetches the current VALUE of the variable from its local memory at the RATE
specified in the RIP Request, or upon the local occurrence of the user-defined condition (step 324).
The VALUE, along with the RIP Request, is then sent to the Destination Processor specified in the RIP Request (step 326).
I
13. POD 7200 If the outcome of the test in step 320 is that a condition is specified, and the Source Processor is not the Conditional Processor, then the Source Processor builds a special "Send List" (step 328). The special Send List includes the information in the regular Send List plus the absolute address of the condition in the Condition Processor, and a ROTE at which the condition status is to be checked.
After the special Send List is built, the Source Processor sends a Conditional Request to the Conditional Processor (step 330). The Conditional Processor stores the Conditional Request (step 332), and then tests for the occurrence of the condition (step 334) at the RATE specified by the user (step 336). When the condition occurs, the Conditional Processor sends a STATUS flag or message to the Source Processor (step 338). The Source Processor then fetches the current VALUE of the variable from its local memory (step 340), and sends the VALUE and the RIP
Request on to the Destination Processor (step 342).
Upon receipt of a VALUE of a variably and an RIP.
Request, the Destination Processor stores the VALUE in the location specified by the DESTINATION indicator in the RIP Request (step OWE If the TS/NOTIFICATION
indicator has been set in the RIP Request, then at the user's selection either the time at which the VALUE was stored is saved along with the VALUE, or an acknowledgment message is sent to the Notification Processor whose address is specified in the TS/NOTIFICATION indicator (step 346).
If, as a result of the test in step 306, the Requesting Processor determines that the VALUE is locally stored, but its DESTINATION is in another processor, then the RUT Request is further tested to determine whether a condition must be met, and if so whether the Requesting Processor is the Conditional Processor (step 348)~ If so, then the Requesting 14. PD-7200 Processor causes a "send list" to be built (step 350), the VALUE fetched from local memory at the NATE
specified or upon the local occurrence of the condition (step 352), and the VALUE and RIP Request to be sent to the Destination Processor (step 354).
If as a result of the test in step 348, the Requesting Processor determines that it is not the Conditional Processor, then the equivalent of steps 328 through 338 are performed by the Requesting Processor lo and the Conditional Processor (step 356)~ This causes the VALUE locally stored in the Requesting Processor to be fetched upon the occurrence of a condition in the Conditional Processor, and then sent to the Destination Processor.
Lastly, if, as a result of the test in step 308~
the Requesting Processor determines thaw the VALUE is locally stored and has a local destination, but that the Requesting Processor is not the Conditional Processor, then the equivalent of steps 328 through 338 are performed by the Requesting Processor and the Conditional Processor (step 358). This causes the Conditional Processor to send a STATUS flag or message to the Requesting Processor. Upon receipt of the STATUS flag, the Requesting Processor fetches the current VALUE of the variable from its local memory (step 360), The Requesting Processor will then perform a procedure equivalent Jo steps 312 and 314 as previously described.
The RTDM procedure thus permits an extremely flexible data base management system that uniquely provides or improved performance in a real-time distributed processing system. Processing speed is enhanced by the fact that each application program uses absolute addresses for all references to memory in its processor, and the RTDM procedure similarly uses absolute addresses into the Source Processor for a variable when obtaining a current copy of the 39 15. PD-7200 variable's VALUE. Maintainability of the system is enhanced by the use of a master symbol table containing references to the absolute address of each program statement referring to each variable. Reliability is enhanced by completely specifying a request for the current VALUE of a variable and storing that request in each pertinent processor. Moreover, system communications overhead and local memory requirements are reduced by only storing in each processor copies of those variables actually used in the processor.
While a wide variety of other procedures and additional procedures can be used in the invention, it should be understood that changes can be made without departing from the spirit or scope of the invention.
Thus, this invention is not to be limited to the specific embodiment discussed and illustrated herein, but rather by the following claims.
FIGURE 1 is a block diagram of a real-time distributed processing computer system of the type that might be used to control a manufacturing process.
FIGURE 2 is a flow-chart of the Block Builder procedure of the present invention.
FIGURE 3 is a flow-chart of a first part of the Real-Time Data Management procedure of the present invention.
FIGURE 4 is a flow-chart of a second part of the Real-Time Data Management procedure of the present invention.
I
6. PD-7200 DETAILED DESCRIPTION OF THE INVENTION
The present invention, in its preferred embodiment, is composed of two parts: a Block Builder procedure, and a Real-Time Data Management (RTDM) procedure. The Block Builder procedure is performed in a main computer processor, such as the main processor 1 shown in Figure 1. As a prerequisite for operation of the invention, all programs designed to control procedures in the local processors (pa ... on, in Figure 1) must be prepared through interaction with the Block Builder However, the preparation of such user application programs may be done from any of the local processors by means of well-known remote communication procedures between a local processor and the main pro-censor 1.
Figure 2 shows a block diagram of the procedure performed by the Block Builder. Sequence A constitutes the main procedure. As a user prepares an application program, the Block Builder monitors the program text for the occurrence of variable names (stew 20). As each variable name is input by the user, it is tested against a master symbol table or list of variable names to see whether this occurrence is the very first occurrence of the variable (step 22). If so, the Block Builder procedure asks the user to define the attributes of the variable, such as its length, type, and default value (step 24). The Block Builder then queries the user as to what processor will supply the VALUE for the variable (step 26). This processor (denoted "X") is then accessed by the Block Builder and storage for the variable is allocated in that processor (step 28). Also, if a default value is known for the variable at that time, that VALUE is stored in Processor X.
Thereafter, the Block Builder enters the name of the new variable into a symbol table in the main processor, which is a master list of all variables used 3~36~3 7. PD-7200 throughout the entire computer system (step 30). The symbol table entry for the new variable essentially consists of the name of the variable, the attributes of the variable, the absolute address of the variable in the processor where the VALUE of the variable will be determined, and a list of all the references in all programs throughout the system that refer to that variable.
The "absolute address" of a variable refers to the lo processor, and the memory location within that processor, in which the VALUE for what variable is initially stored upon determination by that processor.
In actual practice, a relocatable "absolute" address is used, determined in any of several ways known in the prior art, in order to increase system flexibility and ease of operating system programming. By storing this absolute address for each variable the Block Builder procedure and the RTDM procedure can directly access the current VALUE of the variable, rather than indirectly referencing that VALUE such as may be the case in prior art "look-up tables".
If the user has designated a processor other than the local processor upon which the program is being implemented as the source for the VALVE to be assigned to that variable, then Sequence B is performed step 32)~ Further, if the outcome of the test in step 22 is that a variable designated by a user is not the very first occurrence of the variable, then the Block Builder tests to determine if the present occurrence is the first occurrence of the variable in the current processor (Step OWE If so then Sequence B is also performed.
In Sequence B, shown in Figure 2, the Block Builder allocates storage for a duplicate copy of the variable in the processor that will reference the original variable (step 34). The referring processor is distinguished from the processor in which the VALUE
I 239 6 8 8. PD-7200 for the variable is determined in that any processor within the system may refer to a particular variable (and thus have space allocated in its local memory for a copy of that variable), but only one processor in the system actually determines the VALUE for that variable.
Two important aspects of the present invention are that storage space is allocated for a variable only in referring processors (rather than in all processors), and each program step in a program executed by a referring processor that references that variable is assigned the absolute address of the local duplicate copy of the variable. Thus, during the execution of any program that makes reference to a variable, the program may directly address the local copy of that variable, and through the RTDM procedure obtain a copy of the most current VALUE for that variable and store it in that address in the processor's local memory. In essence, each local processor stores in its local memory a copy of every variable used by the programs executed by that local processor. The values of these variables are automatically updated through the TAM
procedure at a rate specified by the user in each application program. Each program in each local processor references each variable by the absolute address of that variable in the processor's local memory. Further, the RTDM procedure references the absolute address of the original variable in the processor where the VALUE of the variable is determined. This speeds up execution of the program by eliminating the program steps that a look-up table or other indirect access method requires in determining the address or location of the current value for each desired variable As the next step in Sequence B, a reference is added into the master symbol table entry for the variable, indicating the absolute address of any command or other program line that refers to the I
9. P~-7200 particular variable (step owe This is useful in system maintenance where, for example, the location of a variable in the processor that determines the VALUE
of the variable is changed. If such a change occurs, the Block Builder may refer to the master symbol table and determine the absolute address of each and every reference to that variable in every program throughout the processing system. The Block Builder then automatically accesses each of those programs using such references and changes the address of the variable for each such reference.
In the next step in Sequence B, the Block Builder causes each processor in which a program makes reference to a variable to send a "Requesting Task Request" message to the Processor X which determines the VALUE for the variable (step 38). The user must specify the RATE at the which the VALUE for the variable is to be ascertained or whether the VALVE is to be ascertained only upon the occurrence of a condition, the destination that the variable is to be sent to and whether any processor is to be notified upon the completion of the access -to the VALUE for the variable.
Lastly, if the outcome of the test in step 33 is that a variable name is not the first occurrence in the current processor, a step identical to step 36 is performed, adding a reference to the occurrence into the symbol table (step OWE
After the Block Builder procedure sets up the basic structure of storage allocation in each local processor for a copy of each variable to be accessed by that processor, together with absolute address references to the processor in which the VALVE of each variable is determined, control over the real-time data base management system is governed by the RTDM
procedure, outlined in Figures 3 and 4. Each loyal processor has resident a copy of the RTDM procedure.
lo .~239~8 PD-7200 Basically, up to five different types of nodes may exist under the RTDM procedure. A Requesting Processor is a local processor that initiates a request for the current VALUE of a variable. A Source Processor is the local processor in which the VALUE for the variable is actually determined (for example, the value of a variable named TEMPT may be determined in a local processor that records the output of a thermal sensor).
A third type of node is a Conditional Processor, lo in which a flag or status bit may be set upon the occurrence of a particular condition (for example, when the temperature or pressure of a particular point in the manufacturing process exceeds a defined value).
A fourth type of node is a Destination Processor, where the value from the Source Processor is to be sent. The fifth type of node is a Notification Processor, where an acknowledgment signal may be sent by the Destination Processor to indicate receipt of the current VALUE for the variable.
Virtually any combination of the above node types may be combined under the TAM procedure to effectuate maximum flexibility in user application programming.
For example, a Requesting Processor can seek the VALUE
of a variable from a second (or Source) processor upon the occurrence of a user-defined condition in a third (or Conditional) processor. The value of the variable may then be sent to a fourth (or Destination) processor, with an acknowledgment of receipt signal being sent to a fifth (or Notification) processor.
However, one or more local processors may serve in multiple roles. For example, the Requesting Processor will often also be the Destination Processor.
In operation, a user program, or Requesting Task ("RUT"), will request the VALUE for a variable from the RTDM procedure in the processor in which the user program resides (step 3Q0). The RUT Request will specify the absolute address ion SOURCE) of the memory 1~396~ o location containing the VALUE of the variable in the Source Processor which determines that VALUE. The RUT
Request optionally may designate the RATE at which the VALUE of the variable is Jo be fetched, or a Conditional Processor (by means of a CONDITION
indicator) in which the occurrence of a defined condition will cause the Source Processor to fetch the VALUE of the variable.
The RUT Request will also designate (by means of a 10 DESTINATION indicator) the Destination Processor to which the fetched VALUE is to be sent The Destination Processor may be identical to the Requesting Processor.
As a further option, the RUT Request may indicate (by means of the TS/NOTIFICATION indicator) that the Destination Processor is to "time stamp" the received VALUE Jo indicate when the VALUE was received as a check on the requesting process, or the RUT Request may indicate a Notification Processor to which the Destination Processor must send an acknowledgment message upon the receipt of the fetched VALUE.
The RUT Request is stored in the Requesting Processor (step 302) for purposes of system reliability in the event that all or part of the IT Requests throughout the system must be reissued (for example, when a portion of the system has failed).
The Requesting Processor examines the RUT Request to determine if the SOURCE of the VALUE for the variable is in the Requesting Processor (step 304). If so, the RUT Request is tested to determine if the DESTINATION of the VALUE is in the Requesting Processor (step 306~. If so, a third test determines whether a condition must be met and whether the Requesting Processor is also the Conditional Processor (step 308~.
If no condition must be met, or if the Requesting Processor is also the Conditional Processor, then the Requesting Processor fetches the current VALUE from its local memory at the NATE specified in the IT Request, ~23~
12. PD-7200 or upon the local occurrence of the user defined condition (step 310). The Requesting Processor then futures the VALUE in the local memory location specified in the DESTINATION indicator of the RUT Request (step 312). If the TS/NOTIFIQTION indicator has been set in the RUT Request, then at the user's selection either the time at which the VALUE was stored is saved along with the VALUE, or an acknowledgment message is sent to the Notification Processor whose address is specified in the TS/NOTIFICATION indicator (step 314~.
If the source of the VALUE is determined to be in a different processor as a result of the test in step 304, then an RIP Request is sent to the Source Processor indicated by the SOURCE address (step 316). The RIP
Request contains the absolute system address of the variable desired, the information specified in the original RUT Request, and a Request ID that uniquely identifies the particular RIP Request and the Requesting Processor, for reference purposes.
The Source Processor receives and then stores the RIP Request for purposes of system reliability (step 318, Figure 4).
The UP Request is then tested to determine whether a condition must be met, and if so whether the Source Processor is the Conditional Processor (Step 320).
If no condition must be met, or if the Source Processor is also the Conditional Processor, then the Source Processor builds a "send list" (step 322). The "send list" contains the address of the desired variable and the Request ID.
The Source Processor then fetches the current VALUE of the variable from its local memory at the RATE
specified in the RIP Request, or upon the local occurrence of the user-defined condition (step 324).
The VALUE, along with the RIP Request, is then sent to the Destination Processor specified in the RIP Request (step 326).
I
13. POD 7200 If the outcome of the test in step 320 is that a condition is specified, and the Source Processor is not the Conditional Processor, then the Source Processor builds a special "Send List" (step 328). The special Send List includes the information in the regular Send List plus the absolute address of the condition in the Condition Processor, and a ROTE at which the condition status is to be checked.
After the special Send List is built, the Source Processor sends a Conditional Request to the Conditional Processor (step 330). The Conditional Processor stores the Conditional Request (step 332), and then tests for the occurrence of the condition (step 334) at the RATE specified by the user (step 336). When the condition occurs, the Conditional Processor sends a STATUS flag or message to the Source Processor (step 338). The Source Processor then fetches the current VALUE of the variable from its local memory (step 340), and sends the VALUE and the RIP
Request on to the Destination Processor (step 342).
Upon receipt of a VALUE of a variably and an RIP.
Request, the Destination Processor stores the VALUE in the location specified by the DESTINATION indicator in the RIP Request (step OWE If the TS/NOTIFICATION
indicator has been set in the RIP Request, then at the user's selection either the time at which the VALUE was stored is saved along with the VALUE, or an acknowledgment message is sent to the Notification Processor whose address is specified in the TS/NOTIFICATION indicator (step 346).
If, as a result of the test in step 306, the Requesting Processor determines that the VALUE is locally stored, but its DESTINATION is in another processor, then the RUT Request is further tested to determine whether a condition must be met, and if so whether the Requesting Processor is the Conditional Processor (step 348)~ If so, then the Requesting 14. PD-7200 Processor causes a "send list" to be built (step 350), the VALUE fetched from local memory at the NATE
specified or upon the local occurrence of the condition (step 352), and the VALUE and RIP Request to be sent to the Destination Processor (step 354).
If as a result of the test in step 348, the Requesting Processor determines that it is not the Conditional Processor, then the equivalent of steps 328 through 338 are performed by the Requesting Processor lo and the Conditional Processor (step 356)~ This causes the VALUE locally stored in the Requesting Processor to be fetched upon the occurrence of a condition in the Conditional Processor, and then sent to the Destination Processor.
Lastly, if, as a result of the test in step 308~
the Requesting Processor determines thaw the VALUE is locally stored and has a local destination, but that the Requesting Processor is not the Conditional Processor, then the equivalent of steps 328 through 338 are performed by the Requesting Processor and the Conditional Processor (step 358). This causes the Conditional Processor to send a STATUS flag or message to the Requesting Processor. Upon receipt of the STATUS flag, the Requesting Processor fetches the current VALUE of the variable from its local memory (step 360), The Requesting Processor will then perform a procedure equivalent Jo steps 312 and 314 as previously described.
The RTDM procedure thus permits an extremely flexible data base management system that uniquely provides or improved performance in a real-time distributed processing system. Processing speed is enhanced by the fact that each application program uses absolute addresses for all references to memory in its processor, and the RTDM procedure similarly uses absolute addresses into the Source Processor for a variable when obtaining a current copy of the 39 15. PD-7200 variable's VALUE. Maintainability of the system is enhanced by the use of a master symbol table containing references to the absolute address of each program statement referring to each variable. Reliability is enhanced by completely specifying a request for the current VALUE of a variable and storing that request in each pertinent processor. Moreover, system communications overhead and local memory requirements are reduced by only storing in each processor copies of those variables actually used in the processor.
While a wide variety of other procedures and additional procedures can be used in the invention, it should be understood that changes can be made without departing from the spirit or scope of the invention.
Thus, this invention is not to be limited to the specific embodiment discussed and illustrated herein, but rather by the following claims.
Claims (16)
1. In a system having local processors each connected to a local memory, a communications channel between the local processors, and a data base of a multiplicity of data variables distributed over the local memories, an improvement to a method of operating a Distributed Data Base Management System (DDBMS) by executing at the local processors local programs, which are referencing the data variables within the data base, and originating each data variable at an originating one of the local processors, the improvement to the method of operating a DDBMS
comprising:
first locally storing in each local memory an original of each data variable which is originated by the associated local processor;
second locally storing in each local memory a copy, obtained across the communication channel, of each data variable not originated by the associated local processor which each data variable is at any time referenced by the associated local processor;
WHEREIN both the first and second locally storing of each data variable is at an absolute address, meaning an address designation of the local processor which does originate the data variable in addition to an address in local memory at which the data variable is first locally stored;
referencing, responsive to local program executing on each local processor which local program makes references to data variables, each data variable only at the absolute address of said data variable supplying, responsive to said referencing, each data variable from the associated memory of the local processor making reference, regardless that the data variable should be the original or the copy;
executing a procedure within each local processor, called by the local program executing therein, for updating the copy of a data variable stored within the associated local memory by obtaining the original of the data variable across the communication channel.
comprising:
first locally storing in each local memory an original of each data variable which is originated by the associated local processor;
second locally storing in each local memory a copy, obtained across the communication channel, of each data variable not originated by the associated local processor which each data variable is at any time referenced by the associated local processor;
WHEREIN both the first and second locally storing of each data variable is at an absolute address, meaning an address designation of the local processor which does originate the data variable in addition to an address in local memory at which the data variable is first locally stored;
referencing, responsive to local program executing on each local processor which local program makes references to data variables, each data variable only at the absolute address of said data variable supplying, responsive to said referencing, each data variable from the associated memory of the local processor making reference, regardless that the data variable should be the original or the copy;
executing a procedure within each local processor, called by the local program executing therein, for updating the copy of a data variable stored within the associated local memory by obtaining the original of the data variable across the communication channel.
2. The improvement to the method of operating a DDBMS
of claim 1 wherein said executing a procedure further comprises:
selectively executing said procedure conditionally upon the occurrence of a designated condition at a designated one of said local processors, including at the local processor executing the procedure or at the local processor which does uniquely originate the data variable.
of claim 1 wherein said executing a procedure further comprises:
selectively executing said procedure conditionally upon the occurrence of a designated condition at a designated one of said local processors, including at the local processor executing the procedure or at the local processor which does uniquely originate the data variable.
3. The improvement to the method of operating a DDBMS
of claim 1 wherein said execution of said procedure further comprises:
executing a procedure at a local program specifiable rate.
of claim 1 wherein said execution of said procedure further comprises:
executing a procedure at a local program specifiable rate.
4. The improvement to the method of operating a DDBMS
of claim 1 which is further comprising, as a last step following said executing a procedure:
time stamping the updated local copy of the data variable obtained by the executing a procedure.
of claim 1 which is further comprising, as a last step following said executing a procedure:
time stamping the updated local copy of the data variable obtained by the executing a procedure.
5. The improvement to the method of operating a DDBMS
of claim 1 which is further comprising, as a last step following said executing a procedure:
acknowledging to a designated one local processor, which designated one local processor may be any of the local processors, that updating of the local copy of the data variable has occurred.
of claim 1 which is further comprising, as a last step following said executing a procedure:
acknowledging to a designated one local processor, which designated one local processor may be any of the local processors, that updating of the local copy of the data variable has occurred.
6. The improvement to the method of operating a DDBMS
of claim 1 wherein said executing a procedure further comprises:
executing said procedure within each local processor, called by the local program executed therein, for updating the local. copy of a specified data variable at a designated one of said local processors, which designated one of said local processors may be any local processor including the local processor executing the procedure or the local processor which does originate the data variable.
of claim 1 wherein said executing a procedure further comprises:
executing said procedure within each local processor, called by the local program executed therein, for updating the local. copy of a specified data variable at a designated one of said local processors, which designated one of said local processors may be any local processor including the local processor executing the procedure or the local processor which does originate the data variable.
7. In a system having a main processor local processing nodes each having a local processor and a local memory connected to said local processor, a communications channel interconnecting the main processor and all local processing nodes, and a data base of variables distributed over the local memories of all the local processing nodes;
a method of operating the system as a Distributed Data Base Management System (DDBMS) for the purposes of minimizing the size of each memory by having as variables stored therein only those originated and/or referenced by the associated local processor, and minimizing communications on the communications channel of variables referenced for use by local processors through satisfying processor references from local memory, otherwise updating locally stored variable values across the communications bus responsive to local processor execution of an update procedure;
the method of operating a DDBMS having prerequisite steps performed at compile time before run time, and steps performed at run time;
the method of operating a DDBMS comprising:
executing, by said main processor communicating with the local processing nodes across the communications channel, at compile time before run time a Block Builder procedure comprising generating a variable symbol table in the main processor which lists for all variables used throughout the DDBMS 1) a variable name, and 2) an absolute address of the variable which absolute address contains both the identity of the single local processing node which does originate the variable value plus the location within the local memory of said single local processing node wherein said variable value will be stored, further allocating storage for each variable in the local memory of 1) the local processing node which does originate the value of each variable, and 2) all other local processing nodes which reference each variable, for all variables used throughout the DDBMS, further causing each said other local processing nodes which reference each variable to make a Requesting Task Request to the local processing node which does originate the value of the variable in order that the variable value becomes stored in the local memory of each other local processing node which will reference the variable; and executing, by the local processor of each local processing node communicating with other local processing nodes across the communications channel, at run time a Real Time Data Management (RTDM) procedure for the updating of data variable values, said RTDM procedure comprising requesting, responsive to a user program executed by a local processor making reference to a variable, the value of the variable at its absolute address, WHEREIN IF the local processor making reference is within that single local processing node which originates the variable value THEN supplying the value of the variable to the local processor making reference from the associated local memory ELSE IF the local processor making reference is not within that local processing node which originates the variable value THEN supplying the value of the variable to the local processor making reference from the memory of the local processing node which does originate the value of the variable by communicating the value across the communications channel.
a method of operating the system as a Distributed Data Base Management System (DDBMS) for the purposes of minimizing the size of each memory by having as variables stored therein only those originated and/or referenced by the associated local processor, and minimizing communications on the communications channel of variables referenced for use by local processors through satisfying processor references from local memory, otherwise updating locally stored variable values across the communications bus responsive to local processor execution of an update procedure;
the method of operating a DDBMS having prerequisite steps performed at compile time before run time, and steps performed at run time;
the method of operating a DDBMS comprising:
executing, by said main processor communicating with the local processing nodes across the communications channel, at compile time before run time a Block Builder procedure comprising generating a variable symbol table in the main processor which lists for all variables used throughout the DDBMS 1) a variable name, and 2) an absolute address of the variable which absolute address contains both the identity of the single local processing node which does originate the variable value plus the location within the local memory of said single local processing node wherein said variable value will be stored, further allocating storage for each variable in the local memory of 1) the local processing node which does originate the value of each variable, and 2) all other local processing nodes which reference each variable, for all variables used throughout the DDBMS, further causing each said other local processing nodes which reference each variable to make a Requesting Task Request to the local processing node which does originate the value of the variable in order that the variable value becomes stored in the local memory of each other local processing node which will reference the variable; and executing, by the local processor of each local processing node communicating with other local processing nodes across the communications channel, at run time a Real Time Data Management (RTDM) procedure for the updating of data variable values, said RTDM procedure comprising requesting, responsive to a user program executed by a local processor making reference to a variable, the value of the variable at its absolute address, WHEREIN IF the local processor making reference is within that single local processing node which originates the variable value THEN supplying the value of the variable to the local processor making reference from the associated local memory ELSE IF the local processor making reference is not within that local processing node which originates the variable value THEN supplying the value of the variable to the local processor making reference from the memory of the local processing node which does originate the value of the variable by communicating the value across the communications channel.
8. The method of operating a DDBMS of claim 7 wherein within said RTDM procedure said requesting is further comprising:
requesting conditionally upon an occurrence of a designated condition at a designated one of the processing nodes, occurrence of the designated condition being determined IF the local processor making reference is within the designated one of the processing nodes THEN determining the designated condition internally within the local processor making reference ELSE IF the local processor making reference is not within the designated one of the processing nodes THEN
determining the designated condition by communication between said local processor making reference and the designated one of the processing nodes across said communications channel.
requesting conditionally upon an occurrence of a designated condition at a designated one of the processing nodes, occurrence of the designated condition being determined IF the local processor making reference is within the designated one of the processing nodes THEN determining the designated condition internally within the local processor making reference ELSE IF the local processor making reference is not within the designated one of the processing nodes THEN
determining the designated condition by communication between said local processor making reference and the designated one of the processing nodes across said communications channel.
9. The method of operating a DDBMS of claim 7 wherein said requesting is further comprising:
requesting the value of the variable to be supplied at a designated rate;
and wherein said supplying is done at said designated rate.
requesting the value of the variable to be supplied at a designated rate;
and wherein said supplying is done at said designated rate.
10. The method of operating a DDBMS of claim 7 wherein said RTDM procedure is further comprising as a last step following said supplying:
time stamping at the local processor making reference the value of the variable received, whereby a check on the process of supplying the value of variables is made.
time stamping at the local processor making reference the value of the variable received, whereby a check on the process of supplying the value of variables is made.
11. The method of operating a DDBMS of claim 7 wherein said RTDM procedure is further comprising as a last step following said supplying:
acknowledging to a designated notification processor, which may be the local processor, the receipt of said variable value in response to said supplying.
acknowledging to a designated notification processor, which may be the local processor, the receipt of said variable value in response to said supplying.
12. In a system having a main processor local processing nodes each having a local processor and a local memory connected to said local processor, a communications channel interconnecting the main processor and all local processing nodes, and a data base of variables distributed over the local memories of all the local processing nodes;
a method of operating the system as a Distributed Data Base Management System (DDBMS) for the purposes of minimizing the size of each memory by having as variables stored therein only those originated and/or referenced by the associated local processor, and minimizing communications on the communications channel of variables referenced for use by local processors through satisfying processor references from local memory otherwise updating locally stored variable values across the communications bus responsive to local processor execution of an update procedure;
the method of operating a DDBMS having prerequisite steps performed at compile time before run time, and steps performed at run time;
the method of operating a DDBMS comprising:
executing, by said main processor communicating with the local processing nodes across the communications channel, at compile time before run time a Block Builder procedure comprising generating a variable symbol table in the main processor which lists for all variables used throughout the DDBMS 1) a variable name, and 2) an absolute address of the variable which absolute address contains both the identity of the single local processing node which does originate the variable value plus the location within the local memory of said single local processing node wherein said variable value will be stored, further allocating storage for each variable in the local memory of 1) the local processing node which does originate the value of each variable, and 2) all other local processing nodes which reference each variable, for all variables used throughout the DDBMS, further causing each said other local processing nodes which reference each variable to make a Requesting Task Request to the local processing node which does originate the value of the variable in order that the variable value becomes stored in the local memory of each other local processing node which will reference the variable; and executing, by the local processor of each local processing node communicating with other local processing nodes across the communications channel, at run time a Real Time Data Management (RTDM) procedure for the updating of data variable values, said RTDM procedure comprising requesting, responsive to a user program executed by a local processor making reference to a variable, the value of the variable at its absolute address be sent to a designated one destination local processor, which destination local processor may be identical to the local processor making reference;
IF the local processor making reference is within that local processing node which does originate the variable value THEN supplying the value of the variable to said destination processor, across said communications channel if necessary because the destination processor is not identical to the processor making reference, ELSE IF the local processor making reference is not within that local processing node which does originate the variable value THEN communicating said requesting across the communications channel to the local processing node which does originate the value of the variable AND supplying, from the memory of the single local processing node which does originate the value of the variable, the value of the variable to said destination processor, across said communications channel if the destination processor is not identical to that local processor within the local processing node.
a method of operating the system as a Distributed Data Base Management System (DDBMS) for the purposes of minimizing the size of each memory by having as variables stored therein only those originated and/or referenced by the associated local processor, and minimizing communications on the communications channel of variables referenced for use by local processors through satisfying processor references from local memory otherwise updating locally stored variable values across the communications bus responsive to local processor execution of an update procedure;
the method of operating a DDBMS having prerequisite steps performed at compile time before run time, and steps performed at run time;
the method of operating a DDBMS comprising:
executing, by said main processor communicating with the local processing nodes across the communications channel, at compile time before run time a Block Builder procedure comprising generating a variable symbol table in the main processor which lists for all variables used throughout the DDBMS 1) a variable name, and 2) an absolute address of the variable which absolute address contains both the identity of the single local processing node which does originate the variable value plus the location within the local memory of said single local processing node wherein said variable value will be stored, further allocating storage for each variable in the local memory of 1) the local processing node which does originate the value of each variable, and 2) all other local processing nodes which reference each variable, for all variables used throughout the DDBMS, further causing each said other local processing nodes which reference each variable to make a Requesting Task Request to the local processing node which does originate the value of the variable in order that the variable value becomes stored in the local memory of each other local processing node which will reference the variable; and executing, by the local processor of each local processing node communicating with other local processing nodes across the communications channel, at run time a Real Time Data Management (RTDM) procedure for the updating of data variable values, said RTDM procedure comprising requesting, responsive to a user program executed by a local processor making reference to a variable, the value of the variable at its absolute address be sent to a designated one destination local processor, which destination local processor may be identical to the local processor making reference;
IF the local processor making reference is within that local processing node which does originate the variable value THEN supplying the value of the variable to said destination processor, across said communications channel if necessary because the destination processor is not identical to the processor making reference, ELSE IF the local processor making reference is not within that local processing node which does originate the variable value THEN communicating said requesting across the communications channel to the local processing node which does originate the value of the variable AND supplying, from the memory of the single local processing node which does originate the value of the variable, the value of the variable to said destination processor, across said communications channel if the destination processor is not identical to that local processor within the local processing node.
13. The method of operating a DDBMS of claim 12 wherein said RTDM procedure is further comprising as a last step following said supplying:
time stamping at the local processor making reference the value of the variable received, whereby a check on the process of supplying the value of variables is made.
time stamping at the local processor making reference the value of the variable received, whereby a check on the process of supplying the value of variables is made.
14. The method of operating DDBMS of claim 12 wherein said requesting is further comprising:
requesting the value of the variable to be supplied at a designated rate;
and wherein said supplying is further comprising:
supplying at the designated rate.
requesting the value of the variable to be supplied at a designated rate;
and wherein said supplying is further comprising:
supplying at the designated rate.
15. The method of operating a DDBMS of claim 12 wherein said RTDM procedure said requesting is further comprising:
requesting conditionally upon the occurrence of a designated condition at a designated one of the processing nodes, said defined condition being determined IF the local processor making reference is within the designated one of the processing nodes THEN determining the designated condition internally within the local processor making reference ELSE IF
the local processor making reference is not within the designated one of the processing nodes THEN determining the designated condition by communication between the local processor making reference and the designated one of the plurality of processing nodes across the communications channel.
requesting conditionally upon the occurrence of a designated condition at a designated one of the processing nodes, said defined condition being determined IF the local processor making reference is within the designated one of the processing nodes THEN determining the designated condition internally within the local processor making reference ELSE IF
the local processor making reference is not within the designated one of the processing nodes THEN determining the designated condition by communication between the local processor making reference and the designated one of the plurality of processing nodes across the communications channel.
16. The method of operating a DDBMS of claim 12 wherein said RTDM procedure is further comprising as a last step following said supplying:
acknowledging to a designated notification processor, which may be the local processor making reference, the receipt of the variable value responsively to the supplying.
acknowledging to a designated notification processor, which may be the local processor making reference, the receipt of the variable value responsively to the supplying.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US585,003 | 1984-03-01 | ||
US06/585,003 US4635189A (en) | 1984-03-01 | 1984-03-01 | Real-time distributed data-base management system |
Publications (1)
Publication Number | Publication Date |
---|---|
CA1223968A true CA1223968A (en) | 1987-07-07 |
Family
ID=24339664
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CA000475497A Expired CA1223968A (en) | 1984-03-01 | 1985-02-28 | Real-time distributed data-base management system |
Country Status (8)
Country | Link |
---|---|
US (1) | US4635189A (en) |
EP (1) | EP0153856B1 (en) |
JP (1) | JPH0799514B2 (en) |
AU (1) | AU570774B2 (en) |
BR (1) | BR8501029A (en) |
CA (1) | CA1223968A (en) |
DE (1) | DE3583510D1 (en) |
FI (1) | FI90475C (en) |
Families Citing this family (118)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
SE467229B (en) * | 1983-08-19 | 1992-06-15 | Kurt Katzeff | DEVICE FOR CREATING AN INFORMATION AND / OR INSTRUCTION INTENDED TO BE INPUT INTO A COMPUTER'S SOFTWARE |
JPS6170654A (en) * | 1984-09-14 | 1986-04-11 | Hitachi Ltd | Resource control system of decentralized processing system |
US4769772A (en) * | 1985-02-28 | 1988-09-06 | Honeywell Bull, Inc. | Automated query optimization method using both global and parallel local optimizations for materialization access planning for distributed databases |
US4777589A (en) * | 1985-06-28 | 1988-10-11 | Hewlett-Packard Company | Direct input/output in a virtual memory system |
US5133066A (en) * | 1985-10-24 | 1992-07-21 | International Business Machines Corporation | Method for selecting multiple versions of data in a reduced record units text editing system |
JPH0789337B2 (en) * | 1985-10-30 | 1995-09-27 | 株式会社日立製作所 | Distributed file recovery method |
US5287537A (en) * | 1985-11-15 | 1994-02-15 | Data General Corporation | Distributed processing system having plural computers each using identical retaining information to identify another computer for executing a received command |
EP0239827B1 (en) * | 1986-04-02 | 1993-05-26 | Siemens Aktiengesellschaft | Method for the control of a common memory of a multiprocessor system comprising separate microprocessor systems |
US4858146A (en) * | 1986-08-13 | 1989-08-15 | The Babcock & Wilcox Company | Automated design of structures using a finite element database |
US4908746A (en) * | 1986-10-15 | 1990-03-13 | United States Data Corporation | Industrial control system |
NL8603193A (en) * | 1986-12-16 | 1988-07-18 | Hollandse Signaalapparaten Bv | DATABASE SYSTEM. |
AU601784B2 (en) * | 1986-12-18 | 1990-09-20 | Honeywell Bull Inc. | Data processing system having a bus command generated by one subsystem on behalf of another subsystem |
US5060150A (en) * | 1987-01-05 | 1991-10-22 | Motorola, Inc. | Process creation and termination monitors for use in a distributed message-based operating system |
US4897781A (en) * | 1987-02-13 | 1990-01-30 | International Business Machines Corporation | System and method for using cached data at a local node after re-opening a file at a remote node in a distributed networking environment |
US5381555A (en) * | 1987-05-18 | 1995-01-10 | The Larches Corporation | Method for designation of data in a data bank and extraction of data for use in a computer program |
JPS63289662A (en) * | 1987-05-22 | 1988-11-28 | Hitachi Ltd | Supporting system for basic work processing |
US5058002A (en) * | 1987-06-23 | 1991-10-15 | Mitsubishi Denki Kabushiki Kaisha | Page splitting method and apparatus for a database stored in a plurality of memory storage units |
US5220674A (en) * | 1987-07-17 | 1993-06-15 | Digital Equipment Corporation | Local area print server for requesting and storing required resource data and forwarding printer status message to selected destination |
JPS6432337A (en) * | 1987-07-29 | 1989-02-02 | Hitachi Ltd | Method for instructing influence of program change |
US4897834A (en) * | 1987-08-18 | 1990-01-30 | Allen-Bradley Company, Inc. | Bit oriented communications network |
US5005122A (en) * | 1987-09-08 | 1991-04-02 | Digital Equipment Corporation | Arrangement with cooperating management server node and network service node |
US5109515A (en) * | 1987-09-28 | 1992-04-28 | At&T Bell Laboratories | User and application program transparent resource sharing multiple computer interface architecture with kernel process level transfer of user requested services |
US5077658A (en) * | 1987-10-19 | 1991-12-31 | International Business Machines Corporation | Data access system for a file access processor |
US4855906A (en) * | 1987-10-23 | 1989-08-08 | Allen-Bradley Company, Inc. | System for handling unsolicited messages from lower-tier controllers |
US5239643A (en) * | 1987-11-30 | 1993-08-24 | International Business Machines Corporation | Method for reducing disk I/O accesses in a multi-processor clustered type data processing system |
US5008853A (en) * | 1987-12-02 | 1991-04-16 | Xerox Corporation | Representation of collaborative multi-user activities relative to shared structured data objects in a networked workstation environment |
US4853843A (en) * | 1987-12-18 | 1989-08-01 | Tektronix, Inc. | System for merging virtual partitions of a distributed database |
US5664177A (en) * | 1988-04-13 | 1997-09-02 | Digital Equipment Corporation | Data processing system having a data structure with a single, simple primitive |
US4864497A (en) * | 1988-04-13 | 1989-09-05 | Digital Equipment Corporation | Method of integrating software application programs using an attributive data model database |
US5079695A (en) * | 1988-04-25 | 1992-01-07 | Hewlett-Packard Company | Object management facility which includes a snapshot facility for providing data transfer between two objects |
US4953080A (en) * | 1988-04-25 | 1990-08-28 | Hewlett-Packard Company | Object management facility for maintaining data in a computer system |
US5438680A (en) * | 1988-04-29 | 1995-08-01 | Intellectual Properties And Technology, Inc. | Method and apparatus for enhancing concurrency in a parallel digital computer |
FR2631763B1 (en) * | 1988-05-18 | 1990-08-10 | Telemecanique Electrique | METHOD FOR THE TRANSMISSION OF INFORMATION BETWEEN ENTITIES SUITABLE FOR TRANSMITTING AND / OR RECEIVING INFORMATION |
US4965718A (en) * | 1988-09-29 | 1990-10-23 | International Business Machines Corporation | Data processing system incorporating a memory resident directive for synchronizing multiple tasks among plurality of processing elements by monitoring alternation of semaphore data |
US5423022A (en) * | 1988-10-03 | 1995-06-06 | General Signal Corporation | Method for adapting a relational database management system so that it can address foreign information |
US5109486A (en) * | 1989-01-06 | 1992-04-28 | Motorola, Inc. | Distributed computer system with network and resource status monitoring |
US5829002A (en) * | 1989-02-15 | 1998-10-27 | Priest; W. Curtiss | System for coordinating information transfer and retrieval |
US5101488A (en) * | 1989-05-02 | 1992-03-31 | Motorola, Inc. | Method for retrieving and updating data in a real-time data base system |
JPH032939A (en) * | 1989-05-30 | 1991-01-09 | Hitachi Ltd | Data control method |
US5291601A (en) * | 1989-06-01 | 1994-03-01 | Hewlett-Packard Company | Shared libraries implemented with linking program loader |
DE69032712T2 (en) * | 1989-06-14 | 1999-07-01 | Hitachi Ltd | HIERARCHICAL PRE-SEARCH TYPE DOCUMENT SEARCH METHOD, DEVICE THEREFOR, AND A MAGNETIC DISK ARRANGEMENT FOR THIS DEVICE |
US5220625A (en) * | 1989-06-14 | 1993-06-15 | Hitachi, Ltd. | Information search terminal and system |
US5339423A (en) * | 1989-06-16 | 1994-08-16 | International Business Machines Corporation | System for accessing objects external to an application using tables containing path definitions |
US5247676A (en) * | 1989-06-29 | 1993-09-21 | Digital Equipment Corporation | RPC based computer system using transparent callback and associated method |
US5249293A (en) * | 1989-06-27 | 1993-09-28 | Digital Equipment Corporation | Computer network providing transparent operation on a compute server and associated method |
US5430876A (en) * | 1989-06-27 | 1995-07-04 | Digital Equipment Corporation | Remote procedure callback system and method |
JP2837877B2 (en) * | 1989-07-04 | 1998-12-16 | キヤノン株式会社 | Communication device and communication method |
EP0953900A3 (en) * | 1989-07-21 | 2000-05-24 | Hewlett-Packard Company | Object based systems |
DE645685T1 (en) * | 1989-08-31 | 1995-11-09 | Yokogawa Electric Corp | Method for controlling a line computer for executing and relocating a translated program from a data storage collection. |
US5093911A (en) * | 1989-09-14 | 1992-03-03 | International Business Machines Corporation | Storage and retrieval system |
US5253361A (en) * | 1989-09-15 | 1993-10-12 | Emtek Health Care Systems, Inc. | System for accessing a row of time-dependent data by referring to a composite index table indicating page locations of linked row labels |
US5495610A (en) * | 1989-11-30 | 1996-02-27 | Seer Technologies, Inc. | Software distribution system to build and distribute a software release |
JPH0415839A (en) * | 1990-05-10 | 1992-01-21 | Toshiba Corp | Distributed data base control device |
US5212788A (en) * | 1990-05-22 | 1993-05-18 | Digital Equipment Corporation | System and method for consistent timestamping in distributed computer databases |
US5140644A (en) * | 1990-07-23 | 1992-08-18 | Hitachi, Ltd. | Character string retrieving system and method |
US5361199A (en) * | 1990-07-31 | 1994-11-01 | Texas Instruments Incorporated | Automated procurement system with multi-system data access |
AU1587592A (en) | 1991-03-18 | 1992-10-21 | Echelon Corporation | Networked variables |
DE69232169T2 (en) | 1991-03-18 | 2002-07-18 | Echelon Corp | PROGRAMMING LANGUAGE STRUCTURES FOR A NETWORK FOR TRANSMITTING, SCANING AND CONTROLLING INFORMATION |
US6493739B1 (en) | 1993-08-24 | 2002-12-10 | Echelon Corporation | Task scheduling in an event driven environment |
JP2922015B2 (en) * | 1991-05-27 | 1999-07-19 | 富士通株式会社 | Terminal DB latest management method |
US5333315A (en) * | 1991-06-27 | 1994-07-26 | Digital Equipment Corporation | System of device independent file directories using a tag between the directories and file descriptors that migrate with the files |
US5592664A (en) * | 1991-07-29 | 1997-01-07 | Borland International Inc. | Database server system with methods for alerting clients of occurrence of database server events of interest to the clients |
US5825865A (en) * | 1991-10-04 | 1998-10-20 | Motorola, Inc. | Temporary message routing and destination selection |
US5357630A (en) * | 1991-10-21 | 1994-10-18 | Motorola, Inc. | Name resolution method for a distributed data base management system |
US5261106A (en) * | 1991-12-13 | 1993-11-09 | S-Mos Systems, Inc. | Semaphore bypass |
US5339389A (en) * | 1991-12-31 | 1994-08-16 | International Business Machines Corporation | User selectable lock regions |
US5337407A (en) * | 1991-12-31 | 1994-08-09 | International Business Machines Corporation | Method and system for identifying users in a collaborative computer-based system |
US5339388A (en) * | 1991-12-31 | 1994-08-16 | International Business Machines Corporation | Cursor lock region |
US5914880A (en) * | 1992-05-16 | 1999-06-22 | Nippei Toyama Corporation | Method and apparatus for controlling a transfer machine |
JP3161861B2 (en) * | 1992-05-16 | 2001-04-25 | 株式会社日平トヤマ | Production system control method and production system control device |
US5355497A (en) * | 1992-06-10 | 1994-10-11 | Physiotronics Corporation | File directory structure generator and retrevial tool with document locator module mapping the directory structure of files to a real world hierarchical file structure |
ATE158119T1 (en) * | 1992-09-14 | 1997-09-15 | Landis & Gyr Tech Innovat | ROUND CONTROL PROCESS AND ROUND CONTROL RECEIVER FOR EXECUTION OF THE ROUND CONTROL PROCESS |
US5611048A (en) * | 1992-10-30 | 1997-03-11 | International Business Machines Corporation | Remote password administration for a computer network among a plurality of nodes sending a password update message to all nodes and updating on authorized nodes |
US5511196A (en) * | 1992-11-17 | 1996-04-23 | International Business Machines Corporation | Method and system in a data processing system for the enhancement of relationships between reference objects in an object oriented environment and a data object outside an object oriented environment |
SE500656C2 (en) * | 1992-12-08 | 1994-08-01 | Ellemtel Utvecklings Ab | Backup capture system in a distributed database |
SE500599C2 (en) * | 1992-12-08 | 1994-07-25 | Ellemtel Utvecklings Ab | Ways to optimize memory space in a database |
US5555412A (en) * | 1992-12-09 | 1996-09-10 | International Business Machines Corporation | Complier and method for alias checking in a complier |
US5515491A (en) * | 1992-12-31 | 1996-05-07 | International Business Machines Corporation | Method and system for managing communications within a collaborative data processing system |
US5896531A (en) * | 1993-02-26 | 1999-04-20 | International Business Machines Corporation | Method and system for managing environments with a data processing system |
US5787444A (en) * | 1993-03-15 | 1998-07-28 | International Business Machines Corp. | Method and apparatus for maintaining revision contol of a set of objects within a data processing system |
CA2097540C (en) * | 1993-06-01 | 1998-05-12 | William G. O'farrell | Accessing remote data objects in a distributed memory environment |
GB2297181B (en) * | 1993-09-24 | 1997-11-05 | Oracle Corp | Method and apparatus for data replication |
JP3361865B2 (en) * | 1993-12-13 | 2003-01-07 | 富士通株式会社 | Automatic setting method of static routing information and computer for automatically setting routing information |
US5721909A (en) * | 1994-03-30 | 1998-02-24 | Siemens Stromberg-Carlson | Distributed database architecture and distributed database management system for open network evolution |
US5835757A (en) * | 1994-03-30 | 1998-11-10 | Siemens Telecom Networks | Distributed database management system for servicing application requests in a telecommunications switching system |
US5687363A (en) * | 1994-03-30 | 1997-11-11 | Siemens Stromberg-Carlson | Distributed database architecture and distributed database management system for open network evolution |
JPH07281874A (en) * | 1994-04-15 | 1995-10-27 | Fuji Photo Film Co Ltd | Environment setting system |
US5546580A (en) * | 1994-04-15 | 1996-08-13 | Hewlett-Packard Company | Method and apparatus for coordinating concurrent updates to a medical information database |
US5694546A (en) * | 1994-05-31 | 1997-12-02 | Reisman; Richard R. | System for automatic unattended electronic information transport between a server and a client by a vendor provided transport software with a manifest list |
US6769009B1 (en) | 1994-05-31 | 2004-07-27 | Richard R. Reisman | Method and system for selecting a personalized set of information channels |
US5500852A (en) * | 1994-08-31 | 1996-03-19 | Echelon Corporation | Method and apparatus for network variable aliasing |
US5689705A (en) * | 1995-02-13 | 1997-11-18 | Pulte Home Corporation | System for facilitating home construction and sales |
US5757669A (en) * | 1995-05-31 | 1998-05-26 | Netscape Communications Corporation | Method and apparatus for workgroup information replication |
US7555458B1 (en) * | 1996-06-05 | 2009-06-30 | Fraud Control System.Com Corporation | Method of billing a purchase made over a computer network |
US8229844B2 (en) | 1996-06-05 | 2012-07-24 | Fraud Control Systems.Com Corporation | Method of billing a purchase made over a computer network |
US20030195847A1 (en) * | 1996-06-05 | 2003-10-16 | David Felger | Method of billing a purchase made over a computer network |
FI101847B1 (en) | 1996-09-19 | 1998-08-31 | Nokia Telecommunications Oy | Procedure for processing a subscriber database in a telephone exchange |
DE69710200T2 (en) * | 1996-09-24 | 2002-08-29 | Honeywell Inc | METHOD AND SYSTEM FOR MULTIFADENBUS ACCESS FOR DATA TRANSMISSION AND RECORDING IN A PROCESS CONTROL SYSTEM |
US5778323A (en) * | 1996-10-04 | 1998-07-07 | Motorola, Inc. | Method and apparatus for facilitating a recovery from a configuration error in a communication system |
US6728712B1 (en) * | 1997-11-25 | 2004-04-27 | International Business Machines Corporation | System for updating internet address changes |
GB2347183B (en) * | 1999-06-29 | 2001-02-07 | Fmc Corp | Flowline connector with subsea equipment package |
US6876991B1 (en) | 1999-11-08 | 2005-04-05 | Collaborative Decision Platforms, Llc. | System, method and computer program product for a collaborative decision platform |
US6778987B1 (en) | 1999-11-30 | 2004-08-17 | Centerboard, Inc. | System and methods for highly distributed wide-area data management of a network of data sources through a database interface |
US7062767B1 (en) * | 2000-09-05 | 2006-06-13 | Raza Microelectronics, Inc. | Method for coordinating information flow between components |
US6961728B2 (en) * | 2000-11-28 | 2005-11-01 | Centerboard, Inc. | System and methods for highly distributed wide-area data management of a network of data sources through a database interface |
DE10157539A1 (en) * | 2001-11-23 | 2003-06-05 | Siemens Ag | Engineering system and automation system |
US20030204547A1 (en) * | 2002-04-29 | 2003-10-30 | Kevin Davis | Technique for scheduling computer processes |
US7337351B2 (en) * | 2002-09-18 | 2008-02-26 | Netezza Corporation | Disk mirror architecture for database appliance with locally balanced regeneration |
WO2004027650A1 (en) | 2002-09-18 | 2004-04-01 | Netezza Corporation | Disk mirror architecture for database appliance |
US8028285B2 (en) | 2004-07-22 | 2011-09-27 | Computer Associates Think, Inc. | Heterogeneous job dashboard |
US8427667B2 (en) * | 2004-07-22 | 2013-04-23 | Ca, Inc. | System and method for filtering jobs |
US7984443B2 (en) * | 2004-07-22 | 2011-07-19 | Computer Associates Think, Inc. | System and method for normalizing job properties |
US7886296B2 (en) * | 2004-07-22 | 2011-02-08 | Computer Associates Think, Inc. | System and method for providing alerts for heterogeneous jobs |
US9600216B2 (en) | 2004-07-22 | 2017-03-21 | Ca, Inc. | System and method for managing jobs in heterogeneous environments |
CA2506303A1 (en) * | 2005-04-14 | 2005-09-15 | Rajesh Kapur | Method for validating system changes safely by use of a replicated system as a system testbed |
JP4038216B2 (en) * | 2005-05-10 | 2008-01-23 | ファナック株式会社 | Sequence program editing device |
US20080320459A1 (en) * | 2007-06-22 | 2008-12-25 | Morris Robert P | Method And Systems For Providing Concurrency Control For Addressable Entities |
EP2192460A1 (en) * | 2008-11-26 | 2010-06-02 | Siemens Aktiengesellschaft | Method for operating an automation device, automation device using the procedure and computer program to implement the procedure |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4215407A (en) * | 1972-08-22 | 1980-07-29 | Westinghouse Electric Corp. | Combined file and directory system for a process control digital computer system |
US4007450A (en) * | 1975-06-30 | 1977-02-08 | International Business Machines Corporation | Data sharing computer network |
GB2023314B (en) * | 1978-06-15 | 1982-10-06 | Ibm | Digital data processing systems |
US4333144A (en) * | 1980-02-05 | 1982-06-01 | The Bendix Corporation | Task communicator for multiple computer system |
US4412285A (en) * | 1981-04-01 | 1983-10-25 | Teradata Corporation | Multiprocessor intercommunication system and method |
US4432057A (en) * | 1981-11-27 | 1984-02-14 | International Business Machines Corporation | Method for the dynamic replication of data under distributed system control to control utilization of resources in a multiprocessing, distributed data base system |
DE3376590D1 (en) * | 1982-04-28 | 1988-06-16 | Int Computers Ltd | Data processing system |
-
1984
- 1984-03-01 US US06/585,003 patent/US4635189A/en not_active Expired - Fee Related
-
1985
- 1985-02-26 AU AU39174/85A patent/AU570774B2/en not_active Ceased
- 1985-02-26 DE DE8585301275T patent/DE3583510D1/en not_active Expired - Fee Related
- 1985-02-26 EP EP85301275A patent/EP0153856B1/en not_active Expired - Lifetime
- 1985-02-27 BR BR8501029A patent/BR8501029A/en not_active IP Right Cessation
- 1985-02-28 CA CA000475497A patent/CA1223968A/en not_active Expired
- 1985-02-28 FI FI850812A patent/FI90475C/en not_active IP Right Cessation
- 1985-03-01 JP JP60038962A patent/JPH0799514B2/en not_active Expired - Lifetime
Also Published As
Publication number | Publication date |
---|---|
JPS60209860A (en) | 1985-10-22 |
JPH0799514B2 (en) | 1995-10-25 |
EP0153856A2 (en) | 1985-09-04 |
FI90475C (en) | 1994-02-10 |
DE3583510D1 (en) | 1991-08-29 |
EP0153856B1 (en) | 1991-07-24 |
FI90475B (en) | 1993-10-29 |
BR8501029A (en) | 1985-10-29 |
FI850812A0 (en) | 1985-02-28 |
FI850812L (en) | 1985-09-02 |
US4635189A (en) | 1987-01-06 |
AU570774B2 (en) | 1988-03-24 |
EP0153856A3 (en) | 1987-07-29 |
AU3917485A (en) | 1985-09-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CA1223968A (en) | Real-time distributed data-base management system | |
EP0278316B1 (en) | Method and system for network management | |
US5664155A (en) | Dynamically assigning a dump space in a shared data facility to receive dumping information to be captured | |
US6249883B1 (en) | System and method for monitoring domain controllers | |
US5581765A (en) | System for combining a global object identifier with a local object address in a single object pointer | |
US6442568B1 (en) | Customer information control system application programming interface with transient data functions, in a loosely coupled data processing environment | |
US7024525B2 (en) | Distributed background track processing | |
US6363396B1 (en) | Object hashing with incremental changes | |
US5884308A (en) | Updating distributed data files using active token distributed at different times to different sites | |
US5943675A (en) | Change log historian system for memory shared by multiple workstations | |
US5781737A (en) | System for processing requests for notice of events | |
CA2047737A1 (en) | Object oriented distributed processing system | |
KR19980080307A (en) | How to Store Login Service Variables | |
US5768524A (en) | Method for processing requests for notice of events | |
US6119173A (en) | System and method for communications and process management in a distributed telecommunications switch | |
US5781736A (en) | Method for obtaining the state of network resources in a distributed computing environment by utilizing a provider associated with indicators of resource states | |
US5768523A (en) | Program product for processing requests for notice of events | |
US20020144020A1 (en) | Method for transparent, location-independent, remote procedure calls in a hetrogeneous network environment | |
EP0362971A2 (en) | Real-time distributed data-base management system | |
JPH01144152A (en) | Control of data processing system | |
EP0928442B1 (en) | System and method for providing multi-threaded bus access for data transmission and acquisition in a process control system | |
US6633922B1 (en) | Object access mechanism that dynamically switches between multiple distributed access models | |
JPH07319750A (en) | Cache management method for decentralized file system | |
AU747472B2 (en) | Method for creating a distributed object tree | |
AU690247C (en) | Data storage |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
MKEX | Expiry |