JPH04213148A - On-line distributed program exchanging system - Google Patents

Abstract

PURPOSE:To exchange a program to a new version in an on-line while holding the continuity of a processing as plural programs which altogether operate a processing while mutually transmitting and receiving messages through a network as an object. CONSTITUTION:A program 121 is exchanged to a new version 123, the version number of the program is added to a transmitted message 142. Then, when the message is inputted to a program 122 of a present version, the version number of the program is compared with the version number added to the message. Then, when they are disagree, the present version is exchanged to a program 123 of the new version, and then the message is inputted to the new version.

Description

[Detailed description of the invention]

0001

[Field of Industrial Application] The present invention relates to a distributed program replacement method while online, targeting a group of programs that are distributed among a plurality of information processing devices and perform processing in cooperation with each other while communicating messages with each other. .

0002

[Prior Art] As a conventional method for exchanging programs during online operation, for example, the published patent publication (Publication No. Hei 2-1396930) ``Online Task Replacement Device''
There is. In this device, the task to be replaced is first loaded as a temporary task, and the task replacement management device monitors the status of the online task to be replaced, and when the task is waiting for a startup request, the above We use a method of exchanging temporary tasks and replacement tasks.

0003

[Problems to be Solved by the Invention] In an online information service system that delivers financial and stock market information to user terminals in real time, or an online transaction processing system that controls bank terminals, etc., system holidays/ There has been a demand for all-day operation, and for this reason, there has been a demand for computer systems to operate 24 hours a day. Also,
In order to improve services, business programs are frequently updated. With these needs as a background, there has been a demand for programs to be replaced during version upgrades while online without stopping the system.

On the other hand, with the recent development of computer technology and communication technology, the number of systems employing a distributed configuration in which a plurality of computers are connected through a communication network is rapidly increasing. The above-mentioned online information service systems and online transaction processing systems are also undergoing a transition from the conventional centralized system configuration to a distributed system configuration.

[0005] Due to the above-mentioned request for program replacement while online and the need for system decentralization, there has been a demand for program replacement while online, assuming a distributed system.

The conventional program replacement method described above is based on the premise that the target program is a program within a single computer. Therefore, in a distributed system, if you try to apply conventional online program swapping to programs that proceed with processing while communicating messages with each other, the versions of the programs will not be consistent when swapping. As a result, there was a problem that continuity of processing was not guaranteed. This problem is illustrated in Figure 2 and Figure 1.
6 will be used for explanation.

FIG. 2 shows an example of the configuration of a distributed processing system. In the system, subsystems 1, 2, and 3 distributed by region are connected to each other by wide area lines 11, 12, and 13. In each subsystem, the information processing devices 21, 22, 23, 24, 25, and 26 are, for example, FDs.
DI (Fiber Distributed Data
High-speed LAN (Loca
1 Area Network) 41 and its LAN control devices 51, 52, 53, 54, 55, and 56. The information processing device 21 includes a line control device 31 for connecting lines with other subsystems, and the information processing devices 24, 25, and 26 include terminals 81, 82.
, . . . , 89 are connected to terminal line control devices 34, 35, and 36 for controlling the lines 71, 72, . . . , 79. Furthermore, each information processing device has disks 91, 92, . . . , 9 for storing program load modules and business databases.
6 is connected.

FIG. 16 shows information processing devices 25 and 22 in FIG.
Programs 121 and 122 (Pro
This shows a case where programs 123 and 124 (represented as Prog1' and Prog2') of new versions are replaced. Prog1 receives inquiry messages received from terminal groups 84, 85, 86 via terminal line control device 35 and lines 74, 75, 76.
It receives the message, edits it into a database inquiry message for Prog2, and sends it. Prog2 receives the database inquiry message, retrieves the data from disk 92, edits it into a response message, and sends it back to Prog1, which is the source of the inquiry. Prog1 is prog2
Edit the message from the terminal for the terminal screen and send it to the terminal that made the inquiry. In the above processing, the formats of database inquiries and response messages between Prog1 and Prog2 must be mutually agreed upon in advance. Also, depending on the program version,
It is common for mats to change as well.

[0009] Now, assume that the programs are replaced independently in each information processing device using the conventional replacement method. In that case, the processes of Prog1 and Prog2 are replaced asynchronously, so depending on the timing, only Prog2 is replaced with the new version, as shown in Figure 2.
There is a possibility that log1 remains the old version. At this time, Prog1 sends an inquiry message from terminal 85.
(■ in Figure 15) and receive the old version of the message.
If you send an inquiry message to Prog2 in the same format (■ in Figure 15), since prog2 on the receiving side is a newer version, the message format may be incorrect and the message may not be processed properly. This problem arises ((2) in FIG. 16. It is assumed that the message format from the terminal does not change). In particular, if the traffic from the terminal is high, errors such as the above due to format differences may occur.
occurs frequently, causing trouble to many terminals.

An object of the present invention is to solve the above problems and provide a method for replacing programs in a distributed system without affecting online operations.

[0011]

[Means for Solving the Problems] In order to solve the above-mentioned problems, the present invention provides a system in which a plurality of information processing apparatuses connected through a communication network each update a new version of a program that is online.
means for loading a version program into an information processing device; a means for managing and storing program version numbers for each information processing device; In a system in which at least two or more programs proceed with processing while exchanging messages with each other, each information processing device adds the version of the program to the output message of the online program. add a version number and send the message to the communication network.
When the message is received, the version number added to the message and the version of the program that received the message are displayed.
Compare the version numbers to determine whether replacement is necessary. If replacement is necessary, replace the receiving program with the new version using the above replacement means, and the new version of the program receives the above received message. and processed

0
012].

[Operation] According to the present invention, it is possible to replace a program that is online in at least one of the distributed systems, and the version number of the sending program is added to the message sent from the program to the communication network. It is possible to check the consistency of the version numbers between the programs, and if the versions are not consistent between the programs, the consistency of the versions can be restored by replacing the receiving program. , messages at the time of replacement can be processed by the new version of the program without being discarded.

[0013]

[Example] An overview of the present invention will be explained using FIG. 1, and FIG.
- Details of the embodiment will be described using FIG. 15.

FIG. 1 is a diagram showing the program replacement method of the present invention in the same system/software configuration as shown in FIG. 16. That is, the information processing devices 25 and 22 have programs 121 and 122 (each with a version number of 1).
0, and will be expressed as Prog1{10} and Prog2{10}. Here, the numbers in { } indicate the version number of the program. ) have been loaded and are performing online processing. Prog1{10} is the terminal line 74, 75, 7
Prog2 receives an inquiry sent from the terminal via 6 and terminal line control device 35, and sends the inquiry via LAN41 to Prog2.
{10} is requested to search for data, and a response message is sent back to the terminal that made the inquiry. A method for replacing these two programs with new version programs 125 and 126 stored on disks 96 and 92 will be described below.

First, the new version programs 125 and 126 are loaded into the information processing devices 25 and 22 in advance (■■ in FIG. 1). The loaded new version program will be assigned a version number of 11 and will be represented as Prog1 {11} and Prog2 {11}, respectively. Next, an inquiry message from the terminal
At the time when the message is received (■ in Figure 1), prog1{10}
Replace with the new version (■ in Figure 1), and check the received messages.
The data is passed to Prog1 {11} (■ in Figure 1). Prog
1 {11} creates an inquiry message 142 to Prog2 {11} and sends it to the LAN 41 (see
), at this time, the version number of Prog1{11} (=
11) is also set in the header section 141 of the message 142. The information processing device 22 takes in this inquiry message from the LAN, and before passing it on to Prog2 {10}, it checks the version number added to the message and the version number of Prog2 {10}, which is the delivery destination. Compare (■ in Figure 1). In this case, the program version number (=10) is smaller than the message version number (=11), so it is replaced with a new version Prog2 {11} that has the same version number (see Figure 1). ■), and hand over the received message (■ in Figure 1).

[0016] New version program Prog2{11
} searches the disk for the requested data,
Create a response message 144 and send the inquiry source Pr.
Reply to og1{11} via LAN (in Figure 1 (
10)). At this time as well, the version number of the program is set in the message header 143. This message is fetched from the LAN by the information processing device 25, and similarly to the information processing device 22 described above, the version number of Prog1{11} and the version number added to the message are compared and checked. After that, it is handed over to Prog1 {11} ((11) in FIG. 1). Prog1 {11} edits the received response message from Prog2 {11} for display on the terminal and sends it back to the terminal that made the inquiry (
(12) in Figure 1).

[0017] Through the above processing, it is possible to match the program versions at the message sender and receiver, and moreover, the message will not be lost when the program is replaced.

Next, details of the embodiment will be explained.

FIG. 3 is a diagram showing the software configuration within the information processing devices 21 to 26, including the terminal line control device 3i and the LA.
Message transmission/reception processing via the N control device 5i and transaction reception queues 111 to 11 of received messages
3, a communication management module 101 that performs registration processing for the user program (hereinafter referred to as UP)
am (abbreviated as am)) 114 to 115 when retrieving a message from the transaction receiving queue.
A message reception request processing module 102 that determines whether it is necessary to replace with a new version or restore to an old version, and execute replacement/recovery processing if necessary; - a message transmission request processing module 103 that sets the version number of the transmission request source program in the message and sends it to the information processing device or terminal via the communication management module 101; a program registration processing module 104 that performs registration processing; a replacement/recovery instruction processing module 105 that performs program replacement and recovery instruction processing when replacement fails; disk 9;
The load module in i is registered in the above registration processing module 10.
A file management module 106 that searches data in the disk 9i in response to a request from UP 114 to UP 115, a terminal line control device 3i, and a LAN.
A sending/receiving buffer 109 provided for sending and receiving messages with the control device 5i, a program version management table 107 for storing and managing program version numbers and task numbers registered in the information processing device, and information. Task management table 1 for storing and managing information indicating whether replacement/recovery is necessary for tasks registered in the processing device
08, Transaction reception queue-111, 112, 1
Receive wait flags 117, 118, 119 for storing the presence or absence of a receive wait UP every 13, and task control in the information processing device, terminal line control device, and L
The OS (Operation System) that performs startup/interrupt processing of the AN control device
rating system) 113.

FIG. 4 is a diagram showing the structure of the program version management table 107. In the system of this embodiment, programs in each information processing device are managed by associating program numbers with each other according to their business contents, and the program version management table also has entries 151 and 151 for each program number. 152 and 153 are provided, and for each entry, an area 131 for setting a program number, an area 131 for setting a program number, an area 131 for setting the old version, current version, and new version.
For each version, registration flags 132, 135, 138 indicate whether the version is registered as a task or not.
, areas 133, 136 for setting version numbers,
139, and an area 134 for setting the task number.
It consists of 137 and 140.

FIG. 5 is a diagram showing the structure of the task management table 108, in which entries 171,
172 and 173 are provided, and for each entry,
Area 161 for setting a task number, area 162 for setting a program number, area 163 for setting a replacement instruction flag indicating whether or not replacement to a new version is necessary.
It also includes an area 164 for setting a restoration instruction flag indicating whether restoration to the previous version is necessary.

FIG. 6 is a diagram showing the processing flow of the program registration processing module (104 in FIG. 3). This process is started from the console, etc. for each information processing device when performing a program replacement, and the parameters at startup include the program number and the program number of the program to which a new version is to be registered. Load module file name,
There is. When the program is started with these parameters as arguments, it first refers to the program version management table 107 for the specified program number and checks the current version registration flag 135 (process 201 in FIG. 6).
. If the flag is reset and the current version is unregistered, it means a new registration.The load module is read from the specified file and registered as a task in the OS, and the program version is The registration flag 135 of the management table is set, the version number 136 is set to "1", and the task number notified from the OS is set in the area 137 (process 202). Next, in the task management table 108, access the entry corresponding to the task number of the task registered above, and
61 and area 162 (process 203), the registered task is activated (process 204), and the process ends.

If the current version has already been registered in the above process 201, in order to check the registration status of the new version, area 1 of the program version management table is
38 is checked (process 205). If the flag has been reset and the new version has not been registered, the load module is read from the specified file and registered as a task in the OS, and the registration flag 138 of the program version management table is , the version number 139 is set to the current version number 136 plus one, and the task number is set in the area 140 (process 206). Then, for the registered task, a task management table registration process having the same contents as the process 203 described above is performed (process 207), and the process ends.

[0024] In the above process 205, if a new version has already been registered, it is determined that the new version is to be re-registered, and the OS is instructed to delete the task registration for the new version that has already been registered. At the same time, the load module is also read from the specified file, registered as a task in the OS, the task number is set in area 140 of the program version management table (process 208), and process 207 is executed. After execution, end the process.

[0025] Through the program registration process described above, online business processing starts immediately for a new program, but for programs whose current version is already running, the new version is only registered as a task. ,
Replacement has not yet taken place. The above new version registration process must be performed for each information processing device for all programs to be replaced, but the above registration process is not necessary for UPs that do not require version upgrades. Not necessary. Furthermore, there are no particular restrictions on the order of registering a new version or the timing of starting the program registration process, and the process can be performed offline. Furthermore, there is also a method of activating the program registration processing module of another information processing apparatus by remotely activating it from the console of one information processing apparatus via a LAN.

Now, in the information processing devices 22 and 25,
Prog1{10} and Prog2{10} are already in operation, and the new version Prog1{11} is installed by the above program registration process in each information processing device.
The following embodiment will be described assuming that and Prog2{11} are registered.

FIG. 7 is a diagram showing the processing flow of the replacement/restoration instruction processing module. This process is started, for example, from the console when instructing replacement to a new version of the program or when instructing recovery, which will be described later, and the parameter at startup is whether to replace or restore. There are instructions to be displayed and the program number of the program to be replaced/restored.

When this process is started, the content of the instruction is first checked (process 211), and in the case of a replacement instruction, the program management table 107 is referred to for the program specified by the program number of the argument. It is checked whether the new version registration flag 138 (see FIG. 4) is set (process 212). If it is registered, the replacement instruction flag 163 (see Figure 5) is set for the entry in the task management table 108 specified by the current version's task number 137 to instruct the online program to be replaced. (Process 213), the process ends. On the other hand, if the registration flag is not set, only the version numbers of the current version and the previous version are incremented (+1), and the program version is
Areas 133 and 136 of the version management table are each incremented (process 214), and the process ends. Next, in the above process 211, if the instruction content is a recovery instruction, the process proceeds to a recovery instruction flag setting process of process 215, which will be explained later.

In this embodiment, it is assumed that the above replacement instruction process is performed on Prog1{10} in the information processing device 25.

Next, messages sent and received between programs in this system, including messages sent and received from terminals,
The format of the page is shown in FIG. The message consists of a header section 220 and a body section 228. The header section is the message
Area 221 for setting the length ML of the message, source terminal/
Area 222 for setting the address SA of the information processing device
, an area 223 for setting the address of the destination terminal/information processing device, an area 224 for setting the communication type TYPE indicating whether the message is an inquiry or a response, an area 225 for setting the inquiry source task number INQ_TN, which will be described later. Area 226 to set the transaction code TCD indicating the type of message, area 227 to set the version number VER of the sender UP of this message, and area 228 to set the message body DATA. It shows that it consists of In addition, in the case of a message from a terminal, the terminal number consistently assigned within the system is set in the SA, and a code indicating a "terminal message" is set in the TCD. It is assumed that the information is sent from the terminal, and no values are set for other information.

Next, message reception processing in the communication management module 101 when a message is received from the terminal 8i will be explained with reference to FIG. Terminal line control device 3i
When the message is received from the terminal line, the information processing device 2
The message is transferred to the sending/receiving buffer 109 in i, and the address and message length are notified to the OS. Upon receiving the notification, the OS activates message reception processing within the communication management module 101. In the message reception process, it is first determined whether the message was received from the terminal line or from the LA.
Check whether it is from N (process 231). In the case of reception from a terminal line, the TCD (226 in FIG. 8) in the header of the received message is read (process 232) and registered in the transaction reception queue (process 233). Here, the transaction reception queue is a first-in, first-out queue for each TCD. Registration in the transaction reception queue means registration in the queue specified by the TCD of the received message.
This is the process of registering a control block in which the send/receive buffer address and message length of the received message are set at the end of the message. Next, in order to check whether there is any UP that has already issued a reception request to the transaction reception queue of the TCD and is waiting, the reception waiting flag (117, 118, 119 in FIG. 3) is checked (processing 23
4) If there is no waiting UP, terminate the process as is, and if there is a waiting UP, start the corresponding UP (
Process 235) End the process. On the other hand, in the above process 231, when a message is received from the LAN, the TYPE (communication type) in the message header is checked to determine whether it is an inquiry message or a response message (process 236). If the message is an inquiry message, the process advances to step 232. If it is a response message, a response waiting UP activation process is performed (process 237), and the process ends.

Next, using FIG. 10, the information processing device 25
The processing flow of Prog1{10}, which is the UP in the following, will be explained. When this program is started, it first performs initial processing such as initializing the table to be used (process 251).
) After that, it specifies TCD="terminal message" and the area for storing the received message, and links to the message reception request module (process 252).

Message reception request processing module (FIG. 3)
102) executes the processing shown in FIG. That is, the transaction reception queue is checked for the TCD specified by the UP to determine whether a message waiting to be processed is registered in the queue (process 261).
, 262). If it is not registered, the reception waiting flag corresponding to the transaction reception queue is set, the transaction enters a WAIT state (process 263), and waits until activated by the communication management module. On the other hand, if the message of the specified TCD is registered in the transaction reception queue, the task management table 108 is referred to based on the task number of the UP issuing the reception request, and the replacement instruction flag ( 163 in FIG. 5) is set (processing 264). If the replacement instruction flag is set, the task management table 108
The program number of the receiving request source UP is obtained from UP, and the task number of the new version (140 in FIG. 4) is read from the program version management table 107 to start the task (process 271). It is checked whether or not it was successful (processing 272). If the startup is successful, the OS is requested to delete the task registration for the old version program (process 273), and then the replacement instruction flag 163 is reset for the new version task management table (process 274). Old version information in the program version management table (areas 132 and 13 in Figure 4)
3, 134) to the current version information (Fig. 4 area 135,
136, 137), you can also update the current version information to the new version.
After rewriting with the version information (areas 138, 139, 140 in Figure 4), the new version information is cleared (processing 276).
, ends the processing of the reception request source UP which is currently in operation and has become an old version due to replacement (process 276).

According to the above process, a program for which a replacement instruction has been issued can be replaced with a new version when a message is received from the terminal/LAN. In the case of this embodiment, Prog1{10 in the information processing device 22
} will be replaced by the new version of Prog1 {11} and started. In addition, program replacement is based on the version number of the received message and the U that issued the reception request.
This is also done when the version numbers of P do not match. This will be explained later. Also, error recovery processing (processing 279 to 284) when starting the new version fails in processing 271 and restoration processing to the old version (processing 265, 291 to 294) will be explained later. do.

Now, the new version of Pr
og1 {11} executes the process shown in Figure 10 as in the old version, but the format of the inquiry message for Prog2 {11} is different from the old version. do.

When Prog1 {11} is activated, it first performs initial processing (processing 251), specifies TCD="terminal message" and an area for storing received messages, and issues a message reception request processing module. - link to the file (process 252).

In the message reception request processing module,
After performing processes 261 to 266 in FIG. 11 above, since the message is from a terminal, the process proceeds to process 268, where the message registered at the head of the transaction reception queue is retrieved (process 268), and the UP specification is sent. Copy the received message from the receive buffer to the area (process 269).
, releases the receive buffer (process 270), and returns to UP.

When Prog1 {11} receives a message from the terminal using the message reception request processing module, it creates an inquiry message to Prog2 {11} based on the data part. (Figure 10 process 253),
Specify the information processing device 22 as the DA, the code indicating "terminal inquiry" as the TCD, "inquiry" as the communication type, and the address and length of the inquiry message created above to send a message. link to the page transmission request processing module (process 254).

FIG. 13 shows the message transmission request processing module.
3 is a diagram showing the processing flow of the file (103 in FIG. 3). First, it is determined from the destination specified by the UP whether the transmission is to be sent to another information processing device via the LAN or to a terminal (process 301). 109), allocate a free buffer from (
Process 302), send a message from the specified area of UP.
copy the file to the buffer secured above (process 303),
ML (message length) is the length of the message including the header, SA (source address) is the address of the information processing device, and DA (destination address) is the destination information processing device. address, and TYPE (communication type) is U.
The communication type specified by P and the TCD specified by UP are set in the TCD (process 304), and the program number 162 is determined by referring to the task management table 108 from the task number of the transmission request source UP. Based on this, program version management table 10 is created.
The version number of the transmission request source UP is obtained from the current version information of No. 7 and set in the VER in the message header (process 305). Through this process, the version number of the source UP can be transmitted to the destination information processing device. Next, it is checked whether the communication type is "inquiry" or "response" (process 306). For inquiries, send request source UP
The task number is set in INQ_TN in the message header (process 307). This is information necessary to recognize which task inquiry the response message is for when a response message is returned. Next, start the LAN transmission process in the communication management module (
Process 308) To wait for a response message, the transmission request source U
W with P task number and timeout time as parameters
An AIT request is issued to the OS (process 309). This WA
The IT state continues until it is activated by the OS at time-out or by message reception processing within the communication management module when a response message is received. Note that the processes after the timeout check process 310 (processes 311 to 319) and the message transmission request process to the terminal (
Processes 320 to 322) will be explained later.

The inquiry message sent to the LAN by the message transmission request processing module described above is taken into the LAN control device of the destination information processing device, transferred to the transmission/reception buffer, and sent to the communication management module. The message reception process (processes 231, 236, 232, 233, 234, 235) of FIG. 9 explained earlier is started.
is registered in the transaction reception queue according to the TCD in the message header, and if the UP
If it exists, it will be activated. The above Prog1{11
} inquiry message is also taken in by the information processing device 22 and sent to T by the message reception process within the communication management module.
It is registered in the transaction reception queue with CD="terminal inquiry". In addition, the VE in the header of this inquiry message
"11", which is the version number of the source Prog1{11}, is set in R.

Now, it is assumed that Prog2 {10}, which receives the inquiry message from Prog1 {11}, is executing the process shown in FIG. In other words, after initial startup, initial processing specific to the business is performed (processing 3).
31) Specify "terminal inquiry" as the TCD and the received message storage area, and send the message to the message reception request processing module (process 332).

[0042] In the message reception request processing module,
As shown in FIG. 11 above, checking the transaction reception queue of the TCD specified by the UP, checking the replacement instruction flag and recovery instruction flag in the task management table,
Then, check the line type (processes 261 and 26).
2, 264, 265, 266). In the case of Prog2 {10}, the replacement instruction flag and the recovery instruction flag are not set and the message is received from the LAN, so the process proceeds to version consistency check processing 267.

[0043] Version consistency check refers to checking the version number VER (227 in Figure 8) set in the header of the received message and the version number (prog_VER) of the receiving request source UP. ) is a comparison check. If VER is larger than Prog_VER, it means that the version of the UP that sent the message is newer than that of the UP that requested the message, and therefore,
It is also necessary to replace the receiving side UP with a new version. On the other hand, VER is Prog_VE
If it is smaller than R, the version of the message source UP is
This means that the version of the receiving UP is older than the receiving UP, and therefore it is necessary to perform restoration processing to return the receiving UP to the previous version. Also, VER and Prog_VE
If R matches, replacement/recovery processing is not necessary.
The aforementioned processes 268, 269, and 270 are executed.

Now, in the case of this embodiment, Prog2{10}
The version of (=10) is the VE of the inquiry message.
Since it is smaller than R (=11), it is necessary to replace it.

[0045] If it is necessary to replace with a new version, first check whether the new version is registered (
Processing 277). If the new version is not registered, the current version will be changed to the new version. The system number (133, 136 in FIG. 4) is incremented by 1 (process 279), and the process proceeds to the above-mentioned process 268, where the process of passing the received message to the UP is executed. On the other hand, if a new version is registered, such as Prog2{10}, processes 271 to 276 are executed to compare the current version and the new version, in the same way as when the replacement instruction flag is set. - Replace John.

Now, the new version of Prog2{11} started by the above replacement process executes the process shown in FIG. 14 like the old version, but Prog1{1}
It is assumed that the method of analyzing the inquiry message from 1}, the method of searching for data, and the format of the response message are different from the previous version.

When Prog2 {11} is activated, it executes process 331 and then links to the message reception request processing module in order to take in the inquiry message (process 332).

[0048] In the message reception request processing module,
Processes 261, 262, 264, 265 in FIG. 11 described above,
After executing H.266, the version number set in the header of the received message and the version of the UP that requested the reception are
The consistency between the version numbers is checked (process 267). Prog2 {11}, which is the source of the reception request, is already the new version, and the program version number (=11) and the VER (=11) in the message header match, so the process advances to process 268 and the reception is completed. The message is transferred to the UP (processes 268-270).

With the above processing, the inquiry message from Prog1 {11} (version number = 11), which has been replaced with a new version, is sent to Prog2 {11} (version number = 11), which has also been replaced with a new version. - version number=11).

Prog2 {11} reads the disk 9 via the file management module 106 based on the inquiry message passed from the message reception request processing module.
2 (processing 333), and Prog1{1
1}, create a response message in a predetermined format (process 334), and send the inquiry source information processing device as the DA and the "terminal inquiry response" as the TCD.
Also, specify "response" as the communication type,
A link is made to the transmission request processing module (335). Here, if you want to send a response message, send an inquiry message.
Inquiry source task number I set in the header section of the page
NQ_TN is also specified at the time of transmission request. Further, the address of the destination information processing device can be obtained from the SA (source address) in the header of the inquiry message.

In the message transmission request processing module linked from Prog2{11}, processing 30 in FIG.
1 to 306 are executed and the communication type is "response", so
Inquiry source task number INQ specified by UP when requesting transmission
Set _TN in the header of the inquiry message (processing 3
15) Again, in order to send a message to the destination address specified by the UP, the communication management module starts sending processing (process 316) and returns to the sending request source UP.

When Prog2 {11} completes the response message transmission request process, it returns to process 332 to accept the next inquiry.

The response message sent by Prog2 {11} is taken in by the information processing device 25 via the LAN 41 and the LAN control device 55, and starts the processing of the communication management module shown in FIG. In the case of receiving a response message, the process proceeds to process 237 after processes 231 and 236, and the U that is in the WAIT state waiting for the response message is
Request the OS to start P. The task number of the UP to be activated can be determined from the inquiry source task number INQ_TN set in the header of the response message.

Now, in the message sending request processing, the WA
Prog1{11}, which has been in the IT state (309 in FIG. 13), is activated in the reception process within the communication management module in response to the above-mentioned response message.

After activation, it is checked whether the activation factor is due to a timeout (processing 310). In case of timeout, error return is performed (process 319). If the activation factor is the reception of a response message, it is checked whether the received message is a replacement failure message, which will be described later (process 311). If it is not a replacement failure message, the UP copies the response message to the area specified at the time of the inquiry request (processing 312), and releases the reception buffer (processing 31).
3) and returns normally to UP (processing 314).

Now, Prog1 {11} checks the return code from the message transmission request processing module to determine whether the response message has been normally received (process 255 in FIG. 10). If it is normal, the response message passed from the message transmission request processing module is edited again for display on the terminal (process 256), the terminal from which the inquiry is specified is specified, and the message transmission request processing is executed. Link to the module (process 257). On the other hand, if the return code from the inquiry sending request process is an error return, a message informing that fact is edited for display on the terminal (process 258), and the message is sent by specifying the terminal from which the inquiry is made. Link to the request processing module (process 257).

[0057] In the message transmission request processing module,
Since the destination is a terminal line, processes 301 to 3 in Figure 13
20, performs buffer copying of the transmission message specified by the UP (process 321), starts terminal line transmission processing in the communication management module (process 322), and sends the transmission request source. Return to UP.

[0058] When the transmission request to the terminal is completed, Prog1
{11} In order to accept inquiries from the next terminal,
Return to process 252.

By the processing described above, a program distributed among a plurality of information processing devices can be replaced with a new version without interrupting the flow of processing.

Next, as a countermeasure against an abnormality, a recovery process will be described when the new version fails to start, that is, when the check in process 272 in FIG. 11 shows that the start fails.

First, it is checked whether the activation of the new version is due to a replacement instruction (process 279). In the case of activation due to a replacement instruction, other programs remain at their current versions. Therefore, it is sufficient to leave the current version of the program for which the replacement instruction has been given, and there is no need for recovery processing such as the recovery processing described later. in particular,
The task control table of the current version of the program to be replaced.
For the bull, the replacement instruction flag (163 in FIG. 5) is reset (process 284), and the process returns to process 261.

On the other hand, if the cause of starting the new version is a mismatch between the version numbers of the received message and the message reception request source UP, the message source UP has already updated the new version. It has been replaced by
John disagrees. In this case, it is necessary to restore the message source UP to its original version, and a replacement failure message is sent back to the source information processing device to notify that. Specifically, first, a transmission buffer is secured (process 280), and the exchange failure message shown in FIG.
(processing 281). In Figure 15, PROG_V
ER is the version number of the current version of the program whose replacement failed. Also, regarding the header of this message, set "replacement failure" to TCD and INQ_TN
(inquiry source UP task number), INQ_TN set in the header of the inquiry message, and TYP
Set “Response” to E (communication type). Next, after releasing the buffer in which the received message is stored (process 282), the communication management module starts the transmission process in order to return the created replacement failure message to the information processing device that made the inquiry. (process 283), process 261
Return to

According to the above processing, for example, in the information processing device 22, a new version of Prog2
11} fails, a replacement failure message will be sent to the information processing device 25 into which Prog1{11} is loaded. Further, the value of PROG_VER in the replacement failure message at this time becomes "10".

Now, when the above rewrite failure message is taken into the information processing device, response waiting UP is activated by the message reception process of the communication management module (FIG. 9).
231, 236, 237).

[0065] The activated UP is in the WAIT state in the inquiry message transmission request processing module, but
Upon reception of the replacement failure message, it is activated from the WAIT state and executes processes 310 and 311 in FIG. Since the received message is a replacement failure message, in order to restore to the old version, access the task management table of the relevant UP and set the restoration instruction flag (1 in Figure 5).
64) (processing 317) and sends a replacement failure message.
(Processing 31)
8), error return (process 319).

[0066] If the message sending request processing module returns an error regarding the inquiry message,
For example, as in Prog1 whose processing is shown in FIG. 12, an error message sent to the terminal is edited (processing 258) and sent to the terminal (processing 257). Here, the replacement failure message
When receiving the program, it only sets the instruction flag, and does not immediately restore the old version of the program at that point. The actual recovery occurs when an inquiry from the next terminal is received. For example, Prog1{11} is T
After specifying "terminal message" as a CD and linking to the message reception request processing module, the information processing device 25 receives an inquiry message from the terminal 84 via the terminal line control device 35. shall be. At this time, the message reception process in the communication management module activates the above-mentioned reception waiting Prog1 {11}, and after processes 261, 262, and 264 in the message reception request process of FIG. 11 are executed. , the above recovery instruction flag is checked (processing 2
65). As a result of the check, if the restoration instruction flag is set, the old version restoration process shown in FIG. 11-b is executed. That is, access the program management table, check the task number of the old version, and start it (processing 2).
91). Next, the recovery instruction flag in the task management table is reset (process 292), and the new version registration flag, version number,
And the task number (138, 139, 140 in FIG. 4), the registration flag of the current version, the version number, and
Rewrite the current version's registration flag, version number, and task number (135, 136, 137 in Figure 4) with the old version's task number (135, 136, 137 in Figure 4). After rewriting the registration flag, version number, and task number (132, 133, and 134 in Figure 4), the old version information is cleared (process 293) and the termination process of the currently running program is executed. Perform (process 294)
.

With the above processing, even if replacing Prog2{11} with the new version fails, Prog1 will be restored from the new version to the old version, so the version change between both programs will be maintained. John's integrity will be preserved.

Finally, consider the case where the replacement is successful, but a failure occurs in the new version program immediately thereafter. In this case, it becomes necessary to take measures such as reverting to the previous version that was working correctly.

For example, Prog1{10} and Prog2
After {10} becomes the new version, Prog1{11
} or Prog2{10}, and it is assumed that a bug is discovered in either program, and both programs have to be returned to their previous versions. In this case, Prog1{1
1} first, restore it to the old version. Therefore,
Regarding Prog1 {11} of the information processing device 25, a recovery instruction and a program number are specified from the console, and the above replacement/recovery instruction processing module is activated. When the replacement/recovery instruction processing module is started, it accesses the program version management table based on the specified program number and retrieves the task number (
134 in FIG. 4), accesses the entry in the task management table corresponding to the task number, and sets its recovery instruction flag (process 215 in FIG. 7). Pro
Similar to the above-mentioned replacement, g1{11} is restored to the old version Prog1{10} during the reception request process for a message from the terminal. That is, in process 265 of the message reception request processing module in FIG. 11, the recovery instruction flag is checked, and if the flag is set, processes 291 to 294 in FIG. 11} returns to the old version.

[0070] Next, Prog1 that returned to the old version
10} sends an inquiry message to the new version of Prog2 {11} and waits for a response. At this time, the version number VER after restoration (=10) is set in the version number VER in the header of the inquiry message. In response to this inquiry message, the message reception request processing module performs a version consistency check in process 267 and detects that the number of the received message is smaller than the version number of the program. do. the result,
The old version startup process of processes 291 to 294 in FIG. 11-b is executed, and Prog2{11} and Prog1{10}
It is possible to return to the same version of Prog2{10} and match the version numbers of both.

[0071]

According to the present invention, a plurality of programs distributed in a plurality of information processing devices can be replaced without stopping online business processing, and the continuity of processing can be guaranteed. Therefore, even in a system where program updates occur frequently, the operating rate of the system can be improved compared to the conventional system, and the quality of service to end users can also be improved.

Furthermore, in the present invention, instead of setting a replacement instruction in a message and transmitting it to other programs, the receiving side determines whether or not replacement is necessary based on the version number that is always set in the message. to judge. Therefore, even if the messages sent and received between programs are lost at the time of replacement, the replacement will be realized when the next message is received. Furthermore, even if messages are transferred redundantly due to a failure in the communication network, the replacement will not be performed multiple times, unlike when a replacement instruction is set in a message. Therefore, it is possible to realize more reliable program replacement that is resistant to communication network failures.

[Brief explanation of the drawing]

[Figure 1] Diagram showing an overview of the present invention

[Figure 2] Configuration diagram of a distributed processing system suitable for applying the present invention

[Figure 3] Software configuration diagram within the information processing device

[Figure 4] Configuration diagram of program version management table

[Figure 5] Configuration diagram of task management table

[Figure 6] Flowchart of program registration processing module
to

[Figure 7] Flowchart of replacement/recovery processing module

[Figure 8] Format of messages sent and received between programs
mat

[Figure 9] Flowchart of message reception processing within the communication management module

[Figure 10] Flowchart of user program

[Figure 11
] Flowchart of message reception request processing module

[Figure 12] Flowchart of message reception request processing module

[Figure 13] Flow of message transmission request processing module
chart

[Figure 14] Flowchart of user program

[Figure 15
] Format of replacement failure message

[Figure 16] Problems with the conventional program replacement method

[Explanation of symbols]

Prog1...User program 1 Prog2...User program 2 ML...Message length SA...Source address DA...Destination address TYPE...Communication type INQ_TN... Inquiry source task number TCD...Transaction code VER...Version number DATA...Message body

Claims (5)

[Claims] Claim 1: One or more information processing devices are connected to each other via a communication network, and a plurality of programs loaded in each information processing device cooperate with each other while sending and receiving messages via a communication medium. In a distributed processing system that proceeds with processing, the information processing device has a means for loading a new version of a program that is online into the information processing device, and a method for assigning a version number of the program to each information processing device. It has means for managing and storing, and means for replacing one of the online programs with the new version of the loaded program, and each information processing device receives the output message of the online program. , adds the version number of the program and sends it to the communication network, and when receiving a message from the communication network, receives the version number added to the message and the message. The version numbers of the programs are compared to determine whether replacement is necessary. If replacement is necessary, the receiving program is replaced with the new version by the replacement means, and the received message is transferred to the new version. 1. An online distributed program replacement method, characterized in that a John program receives and processes the information. Claim 2: In the online distributed program replacement method according to claim 1, a bar added to a message is provided.
1. An online distributed program replacement method, characterized in that, if the version number is greater than the version number of the program that receives the message, it is determined that replacement with a new version is necessary. [Claim 3] In the online distributed program replacement method according to claim 1, when one of the plurality of programs is
For programs that do not need to be updated, do not load the new version, and if the version number added to the message does not match the version number of the program that does not need to be replaced. An online distributed program replacement method is characterized in that the version number of the program that does not require replacement is matched with the version number added to the message. 4. In the online distributed program replacement method according to claim 1, even after replacing the new version, the old version of the program is loaded as is, and the version added to the message is not changed. If the replacement to the new version fails by comparing the version number of the program that receives the message, a replacement failure message is created and the program that sends the message 1. An online distributed program replacement method, characterized in that, upon receiving a replacement failure message, a message sending source program is restored to an old version of the program. 5. In the online distributed program replacement method according to claim 1, the old version of the program is loaded as is even after the new version is replaced, and the version added to the message is not changed. If the version number is smaller than the version number of the program that receives the message, it is determined that restoration to the old version is necessary, and the program is restored to the old version. How to replace online distributed programs.