JP2001236211A - Distributed system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To improve the efficiency of an install work by automatically extracting the version of a related program to be installed according to the version-up of a certain program. SOLUTION: An install work is operated at the time of initial install or any program update, and a specific change ID is applied to each work and stored as a program history. Then, in installing a new version, the history of the program of the version between the new version and the present version of the program is checked, and the other program having the same change ID as the change ID of the program and the version are extracted. Then, processing to extract the other program having the same change ID as the change ID of the extracted other program and the version is repeated by an install target extracting function 103, and the extracted program is used as the programs to be installed.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a distributed system having a version control device for easily extracting related programs when installing an upgraded program on a computer of the distributed system. .

[0002]

2. Description of the Related Art Large-scale distributed systems are developed by dividing the distributed machines into groups and distributing machine groups. In the development of one dispersing machine group as well, development is performed for each dispersing machine, and after the development is completed, the production starts, and after the production starts, the next dispersing machine is developed and put into production. These are repeated to construct a large-scale distributed system. In such a distributed system that is built step by step,
As the development of the dispersing machine and the dispersing machine group progresses, the program is evolved by improving the program in response to a defect, improving a function, changing specifications, and the like.

[0003] When programs of distributed machines (computers) are updated one after another, management of those versions is indispensable. That is, a sequential version is added to each of the programs, and generation management is performed together with the changed contents. Then, at the timing when the program is changed and the version is increased or when the version is increased by several versions, the program is installed in the computer and the version is gradually updated.

[0004] The installation based on the version control of such a program can be performed only by manual operation and judgment, but when the system becomes large-scale, the operation is not easy and judgment error occurs. In particular, in a distributed system such as a large-scale plant control, once production starts, modifications are prohibited until the next development, that is, the current version is maintained, and the program is developed to some extent including the program development for other computers in the distributed system. Installation is performed at the time of completion of the development. In this case, repeated version update for one program is often accompanied. Then, the opening of the version becomes large, and it has to be upgraded to the latest version of all programs. However,
In this case, the man-hours and costs related to the version upgrade become enormous. Also, even if you want to install only the higher version of the program, the installation manager and the development staff manually select the program related to the program, so if the versions are too far apart, The risk of functional deterioration due to selection failure also increases.

[0005] Techniques for addressing such a problem include:
For example, JP-A-11-305999 discloses a system for controlling installation using history management information including version information attached to each program. Japanese Patent Application Laid-Open No. H11-134178 discloses that, when an application program is updated, not only the program but also version information of a program related to the program is prepared so that the related program can be easily updated at the time of installation. A technique for performing this is disclosed.

[0006]

Problems to be Solved by the Invention
In the technique of 305999, when a certain program is updated, a program related to the program is not considered. In the technique of Japanese Patent Application Laid-Open No. H11-134178, related programs are considered, but the creator of the update program must check the related programs and their versions in advance and create dependency information. A heavy burden is inevitable, as system developers need to work together.

SUMMARY OF THE INVENTION An object of the present invention is to provide a program related to a newly installed program when a program having the same name and a different version as a program installed in a computer of a distributed system constructed stepwise is to be installed. The present invention is to provide a distributed system having a program version control device for automatically extracting all the files and installing the correct version accurately and efficiently.

[0008]

SUMMARY OF THE INVENTION According to the present invention, when a program on a distributed machine connected to a network is updated, another related program is extracted and updated simultaneously with the program update. A distributed system having a version control device, wherein for each program, a program ID for identifying the program
And the version of the program and a change I having a unique value given to the installation work when the program is installed at the time of initial installation of the program or at the time of updating any program.
D, a program history management file having at least D, and a new version of the program to be updated is given as a new program, the current program having the same program ID as the new program and being used on the distributed machine, and Current program acquisition means for acquiring the current version via a network, and when the first and second versions of one program are given, do nothing if the first version is larger than the second version, If the first version is smaller than the second version, another program having a change ID equal to the change ID of each of the programs having a version larger than the first version and lower than the first version is stored in the program history. The installation target program detected from the management file And related program extracting means for gram, as the first extraction process, said been working version acquired by the current program acquisition means first
The installation program is extracted by the related program extracting means with the new version as the second version, and in the second and subsequent extraction processes, each of the installation target programs extracted by the previous extraction process is extracted. , Same program ID
Is acquired by the working program extraction means, the version of the working program is set as the first version, and the extracted version of the installation target program is set as the second version and newly installed by the related program extraction means. A distributed system, characterized in that control means for controlling so as to repeat a process of extracting a target program until a new program to be installed is not newly extracted is provided in the version management device.

Further, according to the present invention, in the above-mentioned distributed system, each of the dispersing machines stores an active program and an active file transmitted when the active program acquisition means of the version management apparatus acquires the active version. When the program to be installed for updating the transmitted working file is transmitted, the program of the working file is converted into an executable file, and this and the working file currently used by the distribution machine are converted. Disclosed is a distributed system including a comparison unit for comparing, and a control unit for controlling to execute installation of an installation target program for updating when a comparison result obtained by the comparison unit matches.

[0010]

Embodiments of the present invention will be described below with reference to the drawings. FIG. 1 is a block diagram showing the overall configuration of a distributed processing system when the present invention is applied. In FIG. 1, a development network 2 is connected to development machines 2, 2,... For developing programs and a version control device 1 for managing programs. Take out, repair, and register. .. Are connected to the backbone network 4, and the networks of the respective disperser groups are connected to the dispersers 6, 6,.
... are connected. These dispersers mutually exchange information with the version control device 1 connected to the development network 3 via the disperser group network and the backbone network to which they are connected.

FIG. 1 is a block diagram showing a configuration example of a version control device according to the present invention, which is connected to a development network 3 via an input / output mechanism 106. The terminal device 107 is also connected via the input / output mechanism 106. When information related to program development from the development machine 2 is input from the input / output mechanism 106, the information is processed by the program management function 104, and the version of the base version to be modified by the developer with reference to the program history management file 101. The program is stored in the program source storage file 10
2 and is sent to the development machine via the input / output mechanism 106 and the network 3. When the developer sends the repair program via the network 3 and the input / output mechanism 106 as described above after the repair is completed, the program management function 104 determines the update and increases the version of the repair program by one. The history management file 101 is updated, and the modified source program is registered in the program source storage file 102.

When the installation manager inputs the program to be installed this time and the version of the program from the terminal device 107, the data is transmitted to the installation target extraction function 103 via the input / output control mechanism 106.
Is input to Upon receiving this data, the installation object extraction function 103 receives the program history management file 1
From 01, based on the version of the program to be installed this time and the version of the corresponding program that is actually running on the distribution machine to be installed (obtained via the network 3 and the input / output control mechanism 106), A program required for installation and a predetermined version are extracted from all the related programs, and the installation target program among them is registered in the installation target program storage file 105. This registration result is displayed on the terminal device 107 via the input / output control mechanism 106. When all the programs to be installed on one distribution machine are extracted and stored in the storage file 105, installation becomes possible. At the same time,
The accumulation file 105 also accumulates the currently running version of all the extracted programs to be installed this time.

FIG. 3 shows an example of a functional configuration relating to the installation management on the distribution machine side. The exchange of information with the network 5 is performed via the input / output mechanism 301. FIG.
When the program version acquisition process of the distribution machine is executed by the installation target extraction function 103, the currently running version editing function 302 is executed, and the names and the names of all programs registered in the execution format library 306 are displayed. The program version is extracted, edited into a telegram, and transmitted to the version management device 1 via the network.

The installation manager uses the terminal device 107 to install the program file 1 to be installed.
When the program stored in the program 05 is distributed to the distribution device, this information is input to the distribution device 6 via the network 5 and the input / output mechanism 301, and the program determination function 303
If the input program is determined to be the currently running program, the input program is stored in the currently running program reception file 305 that is to be installed this time. The program is stored in the installation target program reception file 304 this time.

When the determination function 303 determines that the distribution of the program from the version control device 1 has been completed, the program stored in the currently running program reception file 305 is sent to the executable program creating function 308, where the executable program is sent. Is created, and the program in the executable format is registered in the comparison executable format library 307. When all the registrations are completed, the program registered in the currently running executable library 306 and the executable program registered in the comparative executable library 307 are compared by the comparison determining function 309, and if all are equal, it is determined that they are equal. If it is determined, all the programs to be installed this time accumulated in the file 304 are set as the executable format by the executable format program creating function, and the executable format library 306
Register with. Further, the version of the program installed this time is stored together with the program registered in the executable format library 306. When the installation of these executable programs is completed normally, the comparison determining function 309 notifies the installation manager that the installation has been completed normally via the network.
Also, as a result of the comparison between the executable programs of the two libraries 306 and 307, if it is determined that at least one is not equal, the installation manager is notified that the installation has failed. Further, the comparison judging function 309 checks whether or not the program has been registered normally from the executable program creating function 308 to the executable library 306, and if the abnormality is determined, the comparison executable The corresponding program of the library 307 is replaced with the abnormal executable program and re-registered. At this time, the installation is terminated here, and the installation manager is notified that the installation has failed.

FIG. 4 shows the format of each data used in the processing of FIGS. FIG. 3A shows the dispersing machine 6.
In the data format for notifying the version management apparatus 1 of the version of the currently running program, a computer ID 401 indicating which distributed machine the information is, a program ID 402, and a version 403 of the running program registered in the distributed machine Consists of Computer ID 401
May be, for example, a device address of a dispersing machine. FIG. 4 (b)
Is a format of history information stored in the program history management file 101, which is a feature of the present invention, in addition to the program ID 411, the program version 412, and the address 414 on the source storage file 102 where the program is stored. It consists of a change ID 413. The change ID 413 is information to be added to a program that must be corrected at the same time when a program developer changes a certain program, and is added by a version manager in response to a report from the developer. This is an essential condition for a program modified in connection with a certain program to be easily identified later by a person other than the developer.

FIG. 4C shows a format of data in which the installation target program is extracted by the installation target extracting function 103 in FIG. 1, and the program is distributed to the target distribution machine in this format. This data format includes the computer ID 421 of the distributed machine, the program ID 422 to be installed this time, the current version 42
3, a modification section 424 for identifying whether the current version is installed or a currently running version, and a program source 425.

FIG. 4 (d) shows a data format that informs the version control apparatus 1 of whether the installation work has been completed normally as a result of installing the program on the distribution machine. And the computer ID 431 of the distributed machine, the installed program ID 432, the version 433 of the program, the modification category 434 of whether the program is an installation target program or a currently running program, and the determination of the installation result 4
35. The installation administrator refers to this information,
Finalize the result. If the result is a failure, by referring to the modification section 435, it is possible to immediately determine whether the program is an installation target program or a currently operating program.

FIG. 5 is a flowchart showing the processing of the installation target extraction function 103 in FIG. 1, whereby the target program can be extracted without fail. When the process starts (step 501), the ID and version of the currently operating program are fetched from the distribution machine in the data format shown in FIG. 4A (step 502), and the version of the program to be installed this time and step 5
02 (step 50).
3). As a result, if the version to be installed this time is smaller or equal, it is determined that the distribution machine has already been installed, and the process is completed. The program history management file 101 is searched using the ID as a key (step 504),
It is determined whether there is information of the program (step 5
05). As a result, the program history management file 101
If there is no ID and version of the program, the installation manager is notified that there is an abnormality (step 506). This is an important process that indicates whether the version of the program to be installed this time is erroneously input or whether the registration of the repair source is erroneous.

If there is information to be searched (YES in step 505), the computer ID, program ID, version, program source, and repair classification, which are information of the program to be installed this time, are shown in FIG. Edit according to the indicated format and store it in the installation target program accumulation file 105 (step 50).
7). Here, the program source is extracted from the program source storage file 102 based on the program source address 414 of the information retrieved from the history management file 101 having the format shown in FIG. In the refurbishment section, the fact that it is a refurbishment version is stored. Next, for the currently running program, data having the format shown in FIG. 4C is created and stored in the installation target accumulation file 105. At this time, as the repair category, the fact that the version is currently in operation is stored (step 508).

Next, in order to search for a related program from the currently installed version to the currently running version, first, the version of the program information stored in the file 105 is fetched into a work area on the memory.
The program version to be installed is n,
The version of the currently operating program is set to no (step 509). Until n ≦ n0, all other programs having the same change ID as the change ID 413 of the program information (having the format of FIG. 4B) searched in step 505 are extracted from the program history management file 101, and Store the program ID and version in the work area to reduce version n by one,
Is repeated (steps 510 to 512). As a result, for the target program, from the installed version to the version that is one larger than the currently running version, the related program having the same change ID, that is, all the program versions of the version after the currently running version were modified at the same time. All programs can be extracted.

However, this is not enough. Among the programs extracted in the process 511, there is a possibility that another program may be modified at the same time, so it is necessary to also extract all the related programs of the program extracted in the step 511. Therefore, when the loop process of steps 510 to 512 is completed, the same program (only the version is different) to be installed this time is set as searched, and the search is not performed again to improve the processing efficiency (step 513). . Then, a related program is extracted (step 514), and the installation target program extracting process ends.

FIG. 6 is a flowchart showing the details of the related program extraction processing in step 514 in FIG. 5. In the step 511 in FIG. Since they are stored in the area, the program ID is first sorted on the work area in descending order using the first key as the first key and the version as the second key (step 60).
1). Then, it is checked whether there is unsearched data in the work area (step 602). If not, the process ends. If there is, the program and the version are taken out in the sorted order (step 603), and it is checked whether the program has been searched (step 604). ). If the search has been completed, step 60
Returning to step 2, if the search has not been completed, the version of the program is compared with the version of the same program currently running (step 605). If the version is equal to or smaller than the version currently running, the program has been searched. (Step 606) and returns to Step 602. If it is larger, the program information retrieved from the work area is retrieved and retrieved from the program history management file 101 (Step 607), and the retrieved program information is stored in the installation target program storage file 105. Then, the currently running program information of the program is read from the distribution machine and stored in the same accumulation file 105 (step 609). Next, the version of the program information stored in the file 105 is fetched into the work area on the memory, and the version of the program read in step 607 is set to m, and the version of the program currently running is set to m0 (step 6).
10). Until m ≦ m0, another program having the same change ID as the change ID of the program information searched in step 607 is stored in the program history management file 10.
1 is repeated, and the program ID and version are stored in the work area and m is reduced by 1 (steps 611 to 613). As a result, FIG.
, All the related programs of the searched program are detected. When the process exits from the loop, the program is checked (step 614), and the process returns to step 601. By repeating the above, all programs and versions to be installed this time are extracted and stored in the installation target program storage file 105 in FIG.

FIG. 7 is an explanatory diagram of an example of processing according to the flow charts of FIGS. 5 and 6.
1.05 is to be installed. FIG. 7A shows the version of the currently operating program of the distribution machine 1, and FIG. 7B shows a configuration example of the program history management file 101. In this case, since the currently operating version of the program A is V1.02, the version V of the program A on the program history management table is
Change I from 1.05 to V1.04 and V1.03
Another program having the same change ID as D, that is, another program having the change IDs 10, 7, and 5, is extracted in the process of FIG. That is, V1.03 of program B (change ID = 10), V1.03 of program C (change ID)
= 7) is extracted, and information such as these programs and their versions are stored in the work area. At this point, Program A has a modified version of V1.05,
V1.02 is edited as the currently running version.

Next, since the currently running version of the program B is V1.01, the version of the program extracted in the processing of FIG. 5 is V1.03, so that the version of V1.03 and V1.02 of the program B is Another program having the same change ID as the change ID is extracted in the process of FIG. That is, the change ID of V1.03 of the program B
Is 10, but the same change ID is only the program A which is excluded from the search, and there is no related program here, but the change ID of V1.02 of the program B is 6
Therefore, V1.01 of the program C is extracted.
As a result, V1.0 of program B is stored in the work area.
3. V1.02 and V1.01 of the program C are stored. At this time, the program B is edited to have the modified version V1.03 and the currently running version V1.01. Further, since the currently running version of the program C is V1.00, another program having the same change ID as the change ID in the history of the program C of V1.02 and V1.01 in the program history management table is not available. It is extracted by the processing of FIG. In other words, the change ID of V1.02 of the program C is 7, but the same change ID is only the program that is not searched. The change ID of V1.01 of program C is 6,
The same change ID is only the program B which is not searched. Thus, new programs are not extracted in this example. At this point, the program C has V1.02 as the repaired version and V as the currently running version.
1.00 is edited. As described above, the version of the program required for installation is as shown in FIG.

[0026]

As described above, according to the present invention,
The program to be installed and the program related to the program to be installed can be automatically and completely extracted, and the installation of the correct version can be performed accurately and efficiently.

[Brief description of the drawings]

FIG. 1 is a block diagram illustrating a configuration example of a version management device that is a feature of the present invention.

FIG. 2 is an example of a distributed system of the present invention.

FIG. 3 is a diagram showing an entire flow of an installation management method in the apparatus of FIG. 2;

FIG. 4 is a diagram showing a format of data used in the apparatus of FIG. 2;

FIG. 5 is a diagram showing an extraction process of an installation target program in the apparatus of FIG. 2;

FIG. 6 is a flowchart of a related program extracting process in the apparatus of FIG. 2;

FIG. 7 is an explanatory diagram of an example of an installation target program extraction process.

[Explanation of symbols]

 DESCRIPTION OF SYMBOLS 1 Version control device 3 Network 101 Program history management file 102 Program source storage file 103 Installation target extraction function 104 Program management function 105 Installation target program storage file 107 Terminal device

 ──────────────────────────────────────────────────続 き Continued on the front page (72) Inventor Hiroyuki Yui 5-2-1, Omikacho, Hitachi City, Ibaraki Prefecture Inside Hitachi Information & Control Systems Co., Ltd. (72) Inventor Naoki Miwa 5, Omikamachi, Hitachi City, Ibaraki Prefecture No. 2 F-term (reference) in Hitachi, Ltd. Omika Works 5B045 AA00 BB12 BB28 BB47 HH02 JJ49 5B076 AC07

Claims (2)

[Claims] 1. A distributed system having a version control device for extracting a program related to a distributed machine connected to a network and updating the program at the same time when the program is updated. And for each program, a program ID for identifying the program, a version of the program, and an installation operation when the program is installed at the time of initial installation of the program or at the time of updating any program. A program history management file having at least a change ID having a unique value assigned to the program, and when a new version of the program to be updated is given as a new program, the program has the same program ID as the new program, and In use on the disperser Program acquisition means for acquiring a program for use and its current version via a network, and when given first and second versions of one program, if the first version is larger than the second version Do nothing and if the first version is less than the second version, change I equal to the change ID of each of the programs having a version greater than the first version and less than or equal to the first version.
A related program extracting unit that detects another program having a D from the program history management file and sets it as a program to be installed; and, as a first extraction process, the current version acquired by the current program acquiring unit is the first version The new version is used as the second version to extract the installation target program by the related program extraction means. In the second and subsequent extraction processes, each of the installation target programs extracted by the previous extraction process is The program having the same program ID is obtained by the active program extracting means, the version of the active program is set as the first version, and the version of the extracted installation target program is set as the second version. Control means for controlling a process of extracting a new program to be installed by the program extracting means until the new program to be installed is not newly extracted, and control means provided in the version control device. . 2. The distributed system according to claim 1, wherein each of the distributing apparatuses includes: a current file for storing a current program and a current program transmitted when the current program acquisition unit of the version management device acquires the current version. When the program to be installed for updating the transmitted working file is transmitted, the program of the working file is converted into an executable file, and this is compared with the executable file currently used in the distribution machine. 1. A distributed system, comprising: a comparing unit that performs a process of installing an installation target program for updating when a comparison result obtained by the unit matches.