JP3741581B2

JP3741581B2 - Distributed system

Info

Publication number: JP3741581B2
Application number: JP2000044016A
Authority: JP
Inventors: 博邦沼田; 博之油井; 直樹三和
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2000-02-22
Filing date: 2000-02-22
Publication date: 2006-02-01
Anticipated expiration: 2020-02-22
Also published as: JP2001236211A

Description

【０００１】
【発明の属する技術分野】
本発明は、分散システムの計算機へバージョンアップしたプログラムをインストールする時に、関連プログラムを容易に抽出できるようにするためのバージョン管理装置を備えた分散システムに関わるものである。
【０００２】
【従来の技術】
大規模な分散システムは、分散機をグループ分けし、分散機グループ単位に開発が行われている。１つの分散機グループの開発においても、各分散機単位に開発し、開発が終わって本番開始を迎え、本番開始後に次の分散機の開発を行い本番稼動させる。これらを繰り返し大規模な分散システムが構築されていく。
このように段階的に構築していく分散システムにおいて、分散機及び分散機グループの開発が進むとともに、不良対応、機能改善、仕様変更等に伴うプログラムの改善が行われ、プログラムは進化する。
【０００３】
分散機（計算機）のプログラムが次々と更新される場合には、それらのバージョンの管理が不可欠となる。即ち、プログラムの各々にシーケンシャルなバージョンを付加し、変更内容とともに世代管理を行っている。そしてプログラムが変更され、バージョンが上がったタイミング、または、数バージョン上がったタイミングで、計算機へインストールを実施し、除々にバージョンの最新化を行う。
【０００４】
このようなプログラムのバージョン管理に基づくインストールを、人手の作業と判断のみで行うこともできるが、システムが大規模になると作業も容易でなく、判断ミスも生じる。特に大規模なプラント制御等の分散システムにおいては、１度本番稼動すると、次の開発まで改造禁止、すなわち、現状バージョン維持とされ、分散システム内の他計算機用のプログラム開発も含めてある程度まとまった開発が終了した時点にインストールが行われるが、この場合には１つのプログラムに対する度重なるバージョン更新を伴うことが多い。そうするとバージョンの開きが大きくなり全てのプログラム最新版までバージョンアップせざるを得ない。ところが、これではバージョンアップに関わる工数及び費用が莫大となってしまう。また、高いバージョンの該当プログラムだけをインストールしようにも、該当プログラムに関連するプログラムを選択するのに、インストール管理者と開発担当者で手作業で実施しているため、バージョンがあまりにかけ離れると、選択もれによる機能劣化のリスクも増大する。
【０００５】
このような問題に対処する技術としては、例えば特開平１１−３０５９９９号に、各プログラムに付けられたバージョン情報を含む履歴管理情報を用いて、インストールを制御するシステムが開示されている。また、特開平１１−１３４１７８号には、あるアプリケーションプログラムの更新時に、当該プログラムだけでなくそのプログラムに関連するプログラムのバージョン情報も用意しておき、インストール時に関連プログラムの更新も容易に行えるようにする技術が開示されている。
【０００６】
【発明が解決しようとする課題】
前記した特開平１１−３０５９９９号の技術では、あるプログラムの更新にあたって、そのプログラムに関連するプログラムについては考慮されていない。また特開平１１−１３４１７８号の技術では、関連プログラムを考慮しているが、更新プログラム作成者が関連プログラムとそのバージョンを予め調べて依存関係情報を作成しておかねばならず、特に大規模分散システムの開発者は互いの連携作業を要するなど、大きな負担は避けられない。
【０００７】
本発明の目的は、段階的に構築される分散システムの計算機にインストールされているプログラムと同一名称でバージョンが異なるプログラムをインストールしようとするとき、その新たにインストールするプログラムと関連したプログラムを自動的にもれなく抽出し、正しいバージョンでインストールを正確にかつ効率よく行えるようにするための、プログラムのバージョン管理装置を備えた分散システムを提供することにある。
【０００８】
【課題を解決するための手段】
本発明は、ネットワークに接続された分散機上のプログラムを更新するときにそのプログラム更新に伴って関連する他プログラムを抽出して同時に更新できるようにするためのバージョン管理装置を備えた分散システムであって、
各プログラム毎に、当該プログラムを識別するためのプログラムＩＤと、当該プログラムのバージョンと、当該プログラムの初期インストール時あるいはいずれかのプログラム更新時に当該プログラムがインストールされた時にそのインストール作業に対して付与される固有の値を持つ変更ＩＤとを少なくとも有するプログラム履歴管理ファイルと、
更新しようとする新バージョンのプログラムが新プログラムとして与えられたときに、当該新プログラムと同一プログラムＩＤをもち且つ分散機上で使用中の現用プログラムとその現用バージョンとをネットワーク経由で取得する現用プログラム取得手段と、
１つのプログラムの第１及び第２バージョンが与えられたときに、もし第１バージョンの方が第２バージョンより大きいときは何もせず、もし第１バージョンの方が第２バージョンより小さいときは、第１バージョンより大きく第１バージョンもしくはそれ以下のバージョンをもつ当該プログラムの各々の前記変更ＩＤと等しい変更ＩＤをもつ他プログラムを前記プログラム履歴管理ファイルから検出してインストール対象プログラムとする関連プログラム抽出手段と、
第１回目の抽出処理として、前記現用プログラム取得手段により取得された現用バージョンを前記第１バージョンとし、前記新バージョンを前記第２バージョンとして前記関連プログラム抽出手段によりインストール対象プログラムを抽出し、第２回目以降の抽出処理においては、前回の抽出処理によって抽出されたインストール対象プログラムの各々に対し、同一プログラムＩＤをもつプログラムを前記現用プログラム抽出手段により取得してその現用プログラムのバージョンを前記第１のバージョンとし、前記抽出されたインストール対象プログラムのバージョンを前記第２バージョンとして前記関連プログラム抽出手段により新にインストール対象プログラムを抽出する、という処理をインストール対象プログラムが新たに抽出されなくなるまで繰り返すように制御する制御手段と、
を前記バージョン管理装置に設けたことを特徴とする分散システムを開示する。
【０００９】
更に本発明は、前記の分散システムにおいて、分散機の各々に、
前記バージョン管理装置の現用プログラム取得手段が現用プログラムとその現用バージョンを取得したときに送信した現用プログラムを格納する現用ファイルと、
その送信した現用ファイルを更新するためのインストール対象プログラムが送信されてきたときに前記現用ファイルのプログラムを実行形式ファイルに変換し、これと当該分散機で現用されている実行形式ファイルとを比較する比較手段と、
この手段による比較結果が一致したとき、更新のためのインストール対象プログラムのインストールを実行するように制御する制御手段と、
を設けたことを特徴とする分散システムを開示する。
【００１０】
【発明の実施の形態】
以下、本発明の実施の形態について図面により説明する。
図１は本発明が適用されると分散処理システムの全体構成を示すブロック図である。図１において、開発系ネットワーク３には、プログラムを開発するための開発機２、２…と、プログラムを管理するためのバージョン管理装置１が接続されており、開発系ネットワーク３を経由してプログラムの取り出し、改修、登録を行う。基幹ネットワーク４には、段階的に構築する分散機グループのネットワーク５、５…が接続され、各分散機グループのネットワークには分散機６、６…が接続されている。これらの分散機は、それぞれが接続されている分散機グループネットワーク及び基幹ネットワークを経由し、開発系ネットワーク３に接続されるバージョン管理装置１と相互に情報のやりとりを行う。
【００１１】
図１は、本発明になるバージョン管理装置の構成例を示すブロック図で、開発系ネットワーク３と入出力機構１０６を介して接続されている。また、端末装置１０７も入出力機構１０６を介して接続されている。開発機２からのプログラム開発に関する情報が入出力機構１０６から入力されると、これはプログラム管理機能１０４にて処理され、プログラム履歴管理ファイル１０１を参照して開発者の改修するベースとなるバージョンのプログラムをプログラムソース蓄積ファイル１０２から取り出し、入出力機構１０６、ネットワーク３経由で開発機へ送信する。開発者が改修完了後、前記と同様にネットワーク３及び入出力機構１０６経由で改修プログラムを送ってくると、プログラム管理機能１０４は更新を判断し、改修プログラムのバージョンを１つアップして、プログラム履歴管理ファイル１０１を更新するとともに、改修されたソースプログラムをプログラムソース蓄積ファイル１０２に登録する。
【００１２】
インストール管理者が端末装置１０７から、今回インストールを予定するプログラムとプログラムのバージョンを入力すると、このデータは入出力制御機構１０６を経由してインストール対象抽出機能１０３へ入力される。インストール対象抽出機能１０３は、このデータを受け取ると、プログラム履歴管理ファイル１０１から、今回インストール予定のプログラムのバージョンと、インストール対象の分散機で実際に稼動している対応プログラムのバージョン（ネットワーク３及び入出力制御機構１０６を経由して取得する）とを元にして、関連する全てのプログラムの中でインストールに必要なプログラムと所定のバージョンを抽出し、その中のインストール対象プログラムはインストール対象プログラム蓄積ファイル１０５に登録される。この登録結果は、入出力制御機構１０６を経由して端末装置１０７に表示される。１つの分散機へのインストール対象プログラムが全て抽出され、蓄積ファイル１０５に蓄積されると、インストールが可能になる。さらに前記と同時に、蓄積ファイル１０５へは、今回インストール予定の、抽出した全てのプログラムの現在稼動中バージョンのプログラムも蓄積される。
【００１３】
図３は、分散機側のインストール管理に関する機能構成例を示すもので、ネットワーク５との情報のやり取りは入出力機構３０１を介して行われる。図１のインストール対象抽出機能１０３で分散機のプログラムバージョン取得処理が実行されると、現在稼動中バージョン編集機能３０２が実行され、実行形式ライブラリ３０６に登録されているところの全てのプログラムの名称と各々のプログラムバージョンが取り出されて電文に編集され、ネットワーク経由でバージョン管理装置１に送信される。
【００１４】
インストール管理者が、端末装置１０７を使用して、インストール対象プログラム蓄積ファイル１０５に蓄積されたプログラムを分散機に配信すると、本情報は、ネットワーク５、入出力機構３０１を介して分散機６へ入力され、プログラム判定機能３０３により、入力されたプログラムが現在稼動中のプログラムと判定するとその入力プログラムを今回インストール対象となっている現在稼働中プログラム受信ファイル３０５に蓄積し、入力されたプログラムが今回インストール対象のプログラムと判定するとその入力プログラムを今回インストール対象プログラム受信ファイル３０４に蓄積する。
【００１５】
バージョン管理装置１からのプログラム配信が完了したことを判定機能３０３で判定すると、現在稼動中プログラム受信ファイル３０５に蓄積されたプログラムを実行形式プログラム作成機能３０８に送り、ここで実行形式プログラムを作成し、実行形式になったプログラムを比較用実行形式ライブラリ３０７に登録する。全て登録が完了すると、現在稼動している実行形式ライブラリ３０６に登録されているプログラムと比較用実行形式ライブラリ３０７に登録した実行形式プログラムとを比較判断機能３０９で比較し、全て比較して等しいと判断すると、ファイル３０４に蓄積された全ての今回インストール対象プログラムを実行形式プログラム作成機能により実行形式とし、実行形式ライブラリ３０６に登録する。さらに今回インストールしたプログラムのバージョンを実行形式ライブラリ３０６に登録したプログラムとともに記憶させる。そしてこれら実行形式としたプログラムのインストールが正常に完了すると、比較判断機能３０９は、インストール管理者へ正常にインストールが終了したことをネットワーク経由で知らせる。また、２つのライブラリ３０６、３０７の実行形式プログラムの比較の結果、１つでも等しくないと判断すると、インストールが失敗したことをインストール管理者に知らせる。さらに比較判断機能３０９は、実行形式プログラム作成機能３０８からプログラムを実行形式ライブラリ３０６へ登録するときにそれが正常に登録されたかをチェックし、異常判断を下すと、先に作成した比較用実行形式ライブラリ３０７の対応プログラムを異常となった実行形式プログラムに置き換えて再登録する。このときはここでインストール作業を打ち切り、インストールが失敗したことをインストール管理者に知らせる。
【００１６】
図４は図１、図３の処理のときに用いる各データのフォーマットである。同図（ａ）は、分散機６で現在稼動しているプログラムのバージョンをバージョン管理装置１に通知するデータのフォーマットで、どの分散機の情報なのかを示す計算機ＩＤ４０１と、プログラムＩＤ４０２と、分散機に登録され稼動中プログラムのバージョン４０３から成っている。計算機ＩＤ４０１は、例えば分散機の装置アドレスでもよい。図４（ｂ）は、プログラム履歴管理ファイル１０１に格納される履歴情報のフォーマットで、プログラムＩＤ４１１、プログラムのバージョン４１２、当該プログラムが格納されているソース蓄積ファイル１０２上のアドレス４１４の他に、本発明の特徴とする変更ＩＤ４１３から成っている。この変更ＩＤ４１３は、プログラム開発者があるプログラムを変更した時、同時に修正しなければならないプログラムに付加する情報であり、開発者の申告により、バージョン管理者が付けるものである。これは、あるプログラムに関連して修正したプログラムを、後になって当該開発担当者以外でも容易に識別できるための必須条件である。
【００１７】
図４（ｃ）は、図１のインストール対象抽出機能１０３にてインストール対象プログラムを抽出したデータのフォーマットで、このフォーマットでプログラムが対象分散機に配布される。このデータフォーマットは、分散機の計算機ＩＤ４２１、今回インストール対象のプログラムＩＤ４２２、今回の対象バージョン４２３、今回インストールするのか現在稼動中のバージョンであるのかを識別する改修区分４２４、及びプログラムソース４２５から成っている。
【００１８】
図４（ｄ）は、分散機に対しプログラムのインストールを実施した結果、正常にインストール作業が完了したか否かを当該分散機からバージョン管理装置１へ知らせるデータのフォーマットで、インストール作業を行って分散機の計算機ＩＤ４３１、インストールしたプログラムＩＤ４３２、そのプログラムのバージョン４３３、インストール対象プログラムか現在稼働中プログラムかの改修区分４３４、インストール結果の判定４３５から成る。インストール管理者は本情報を参照し、結果を最終判断する。結果失敗となった場合、改修区分４３５を参照することにより、今回インストール対象プログラムなのか、現在稼働中のプログラムなのかをすぐに判断できる。
【００１９】
図５は、図１のインストール対象抽出機能１０３の処理を示すフローチャートで、これにより対象プログラムをもれなく抽出することができる。処理が開始すると（ステップ５０１）、分散機から現在稼働中のプログラムＩＤとバージョンを図４（ａ）のデータフォーマットで取り込み（ステップ５０２）、今回インストールしようとするプログラムのバージョンとステップ５０２で得たバージョンとを比較する（ステップ５０３）。この結果、今回インストールするバージョンの方が小さいかまたは等しいときは当該分散機にはインストール済みと判断し、処理を終えるが、インストール予定バージョンの方が大きいと判断した場合は、今回インストール予定したプログラムＩＤをキーとしてプログラム履歴管理ファイル１０１を検索し（ステップ５０４）、そのプログラムの情報があるかを判定する（ステップ５０５）。この結果、プログラム履歴管理ファイル１０１に当該プログラムのＩＤ及びバージョンがなければ、インストール管理者に異常のあった旨を通知する（ステップ５０６）。これは、今回インストールするプログラムのバージョン入力の誤り、または、改修ソース登録を誤ったかを示すものであり、重要な処理である。
【００２０】
検索している情報があったときは（ステップ５０５でＹＥＳ）、今回インストールするプログラムの情報である計算機ＩＤ、プログラムＩＤ、バージョン、プログラムソース、及び、改修区分を図４（Ｃ）に示したフォーマットに従い編集し、インストール対象プログラム蓄積ファイル１０５に格納する（ステップ５０７）。ここでプログラムソースは、図４（ｂ）のフォーマットをもつ履歴管理ファイル１０１から検索した情報のプログラムソースアドレス４１４をもとに、プログラムソース蓄積ファイル１０２から取り出す。また、改修区分には改修バージョンであることを記憶させる。次に、現在稼働中プログラムについても図４（Ｃ）のフォーマットをもつデータを作成し、これをインストール対象蓄積ファイル１０５に格納する。このときの改修区分としては、現在稼働中バージョンであることを記憶させる（ステップ５０８）。
【００２１】
次に、今回インストールするバージョンから現在稼働中バージョンまでの関連プログラムを検索するために、まずファイル１０５に格納したプログラム情報のバージョンをメモリ上のワークエリアへ取り込み、インストールしようとするプログラムバージョンをｎ、現在稼働中のプログラムのバージョンをｎｏとする（ステップ５０９）。そしてｎ≦ｎ０となるまで、ステップ５０５で検索したプログラム情報（図４（ｂ）のフォーマットをもつ）の変更ＩＤ４１３と同一の変更ＩＤをもつ他プログラムをプログラム履歴管理ファイル１０１から全て抽出し、そのプログラムＩＤとバージョンをワークエリアに格納して、バージョンｎを１つ小さくする、という処理を繰り返す（ステップ５１０〜５１２）。これにより対象としているプログラムの、インストールバージョンから現在稼働中のよりも１大きいバージョンまでについて、同一変更ＩＤをもつ関連プログラム、即ち現在稼働中より後のバージョンの全てのプログラムバージョンと同時に改修を行ったプログラムが全て抽出できる。
【００２２】
しかし、これだけでは不十分である。処理５１１で抽出したプログラムの中には、更に他のプログラムを同時に改修している可能性があるため、ステップ５１１で抽出したプログラムの関連プログラムも全て抽出する必要がある。そのためステップ５１０〜５１２のループ処理が終わると、今回インストールするのと同じプログラム（バージョンのみが違う）を検索済みに設定し、これらを再度検索しないようにして処理効率の向上をはかる（ステップ５１３）。そして関連プログラム抽出を行い（ステップ５１４）、インストール対象プログラム抽出処理を終了する。
【００２３】
図６は、図５のステップ５１４に於る関連プログラム抽出処理の詳細を示すフローチャートで、インストール対象プログラムのいくつかのバージョンに関して同一変更ＩＤをもつプログラム情報が図５のステップ５１１でワークエリアに格納されているから、まずワークエリア上でプログラムＩＤを第１キー、バージョンを第２キーとして降順にソートする（ステップ６０１）。そしてワークエリア上に未検索データがあるかを調べ（ステップ６０２）、なければ終了するが、あればソート順にプログラムとバージョンを取り出し（ステップ６０３）、そのプログラムは検索済みかどうかを調べる（ステップ６０４）。検索済みであればステップ６０２へ戻り、検索未済みであれば、そのプログラムのバージョンと現在稼働中の同じプログラムのバージョンとを比較し（ステップ６０５）、現在稼働中バージョンと等しいか又は小さい場合は、そのプログラムを検索済みとし（ステップ６０６）、ステップ６０２へ戻るが、大きければワークエリアから取り出したプログラム情報をプログラム履歴管理ファイル１０１を検索して取り出し（ステップ６０７）、取り出したプログラム情報をインストール対象プログラム蓄積ファイル１０５に格納し（ステップ６０８）、また当該プログラムの現在稼働中プログラム情報を分散機から読み込んで同じ蓄積ファイル１０５に格納する（ステップ６０９）。次にファイル１０５に格納したプログラム情報のバージョンをメモリ上のワークエリアへ取り込み、ステップ６０７で読み込んだプログラムのバージョンをｍ、当該プログラムの現在稼働中のもののバージョンをｍ０とする（ステップ６１０）。続けてｍ≦ｍ０となるまで、ステップ６０７で検索したプログラム情報の変更ＩＤと同じ、変更ＩＤをもつ他のプログラムをプログラム履歴管理ファイル１０１から全て抽出し、そのプログラムＩＤとバージョンをワークエリアに格納してｍを１減らす、という処理を繰り返す（ステップ６１１〜６１３）。これにより、図５の処理で関連プログラムとして検出され、検索済みとされたプログラムの関連プログラムが全て検出される。こうして、ループから抜けると、当該プログラムを検査済みにし（ステップ６１４）、ステップ６０１へ戻る。以上を繰り返すことにより、今回インストールすべきプログラム及びバージョンが全て抽出され、図２のインストール対象プログラム蓄積ファイル１０５に格納される。
【００２４】
図７は、図５及び図６のフローによる処理例の説明図で、分散機１にプログラムＡのバージョンＶ１．０５をインストールしようとする場合である。同図（Ａ）は、分散機１の現在稼働中プログラムのバージョンを示し、図７（Ｂ）は、プログラム履歴管理ファイル１０１の構成例である。この場合には、プログラムＡの現在稼働中バージョンはＶ１．０２であるから、プログラム履歴管理テープル上のプログラムＡのバージョンＶ１．０５から、Ｖ１．０４及びＶ１．０３までの変更ＩＤと同一の変更ＩＤをもつ他のプログラムが、即ち変更ＩＤ１０、７、及び５をもつ他のプログラムが図５の処理で抽出される。即ち、プログラムＢのＶ１．０３（変更ＩＤ＝１０）、プログラムＣのＶ１．０３（変更ＩＤ＝７）が抽出され、ワークエリアには、これらのプログラム、そのバージョン等の情報が格納される。この時点で、プログラムＡは改修バージョンとしてＶ１．０５、現在稼働中バージョンとしてＶ１．０２が編集される。
【００２５】
次に、プログラムＢの現在稼働中バージョンはＶ１．０１であるから、図５の処理で取り出されたプログラムのバージョンはＶ１．０３なので、同プログラムＢのＶ１．０３及びＶ１．０２のもつ変更ＩＤと同一の変更ＩＤをもつ他プログラムが図６の処理で抽出されている。即ち、プログラムＢのＶ１．０３の変更ＩＤは１０であるが、これと同一の変更ＩＤは検索対象外となっているプログラムＡのみで、ここでは関連プログラムはないが、プログラムＢのＶ１．０２の変更ＩＤは６であるから、プログラムＣのＶ１．０１が抽出される。この結果、ワークエリアには、プログラムＢのＶ１．０３、プログラムＣのＶ１．０２、Ｖ１．０１が格納される。この時点で、プログラムＢは改修バージョンとしてＶ１．０３、現在稼働中バージョンとしてＶ１．０１が編集される。更に、プログラムＣについて、その現在稼働中バージョンはＶ１．００であるから、プログラム履歴管理テーブルのＶ１．０２及びＶ１．０１のプログラムＣの履歴中の変更ＩＤと同一の変更ＩＤをもつ他プログラムが図６の処理により抽出される。即ちプログラムＣのＶ１．０２の変更ＩＤは７であるがこれと同一の変更ＩＤは検索対象外となったプログラムのみである。またプログラムＣのＶ１．０１の変更ＩＤは６であるが、これと同一の変更ＩＤは検索対象外となったプログラムＢのみである。こうして新しいプログラムは本例では抽出されない。この時点で、プログラムＣは改修バージョンとしてＶ１．０２、現在稼働中バージョンとしてＶ１．００が編集される。以上のようにして、インストールに必要なプログラムのバージョンは、図７（Ｃ）に示すようになる。
【００２６】
【発明の効果】
以上説明したように、本発明によれば、インストールしようとするプログラムとインストールしようとするプログラムと関連したプログラムを自動的にもれなく抽出でき、正しいバージョンでインストールを正確にかつ効率よく行えるという効果がある。
【図面の簡単な説明】
【図１】本発明の特徴とするバージョン管理装置の構成例示すブロック図である。
【図２】本発明の分散システムの例である。
【図３】図２の装置におけるインストール管理方法の全体の流れを示す図である。
【図４】図２の装置で用いるデータのフォーマットを示す図である。
【図５】図２の装置におけるインストール対象プログラムの抽出処理を示す図である。
【図６】図２の装置における関連プログラム抽出処理のフローチャートである。
【図７】インストール対象プログラム抽出処理の例の説明図である。
【符号の説明】
１バージョン管理装置
３ネットワーク
１０１プログラム履歴管理ファイル
１０２プログラムソース蓄積ファイル
１０３インストール対象抽出機能
１０４プログラム管理機能
１０５インストール対象プログラム蓄積ファイル
１０７端末装置[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a distributed system including a version management device for enabling easy extraction of related programs when installing a version-up program on a computer of the distributed system.
[0002]
[Prior art]
In a large-scale distributed system, distributed machines are grouped and developed in units of distributed machine groups. In the development of one disperser group, each disperser is developed, and the development ends and the production starts. After the start of production, the next disperser is developed and put into production. A large-scale distributed system is constructed by repeating these steps.
In the distributed system constructed in stages as described above, the development of the disperser and the disperser group advances, and the program evolves due to the improvement of the program accompanying the defect handling, the function improvement, the specification change, and the like.
[0003]
When the program of the distributed machine (computer) is updated one after another, management of those versions becomes indispensable. That is, a sequential version is added to each program, and generation management is performed together with the changed contents. Then, when the program is changed and the version is upgraded or several versions are installed, the program is installed on the computer, and the version is gradually updated.
[0004]
Installation based on version management of such a program can be performed only by manual work and judgment. However, when the system becomes large-scale, the work is not easy and a judgment error occurs. Especially in a large-scale distributed system such as plant control, once it is in production, modification is prohibited until the next development, that is, the current version is maintained, and the program is developed to some extent, including the development of programs for other computers in the distributed system. Installation is performed at the end of development. In this case, frequent version updates for one program are often accompanied. Then, the opening of the version becomes large and you have to upgrade to the latest version of all programs. However, this requires enormous man-hours and costs for upgrading. Also, to install only the higher version of the corresponding program, the installation manager and the development staff manually select the program related to the corresponding program, so if the version is too far away, The risk of functional deterioration due to selection failure increases.
[0005]
As a technique for dealing with such a problem, for example, Japanese Patent Laid-Open No. 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. 11-134178 also prepares version information of not only the program but also a program related to the program when updating an application program so that the related program can be easily updated at the time of installation. Techniques to do this are disclosed.
[0006]
[Problems to be solved by the invention]
In the technique disclosed in Japanese Patent Laid-Open No. 11-305999, a program related to the program is not taken into consideration when updating the program. In the technique of Japanese Patent Application Laid-Open No. 11-134178, the related program is taken into consideration. However, the update program creator must check the related program and its version in advance to create dependency information, and particularly large-scale distribution. The system developers are unavoidably burdened with the need to collaborate with each other.
[0007]
An object of the present invention is to automatically install a program associated with a newly installed program when attempting to install a program having the same name and a different version as a program installed in a computer of a distributed system constructed in stages. It is an object of the present invention to provide a distributed system having a program version management device for extracting all the necessary information and performing installation accurately and efficiently with a correct version.
[0008]
[Means for Solving the Problems]
The present invention is a distributed system including a version management device for extracting a related other program and updating it at the same time when updating a program on a distributed machine connected to a network. There,
For each program, a program ID for identifying the program, the version of the program, and the installation work when the program is installed at the time of initial installation of the program or at the time of any program update are given. A program history management file having at least a change ID having a unique value;
When a new version 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 the current version are acquired via the network. Acquisition means;
Given the first and second versions of a program, do nothing if the first version is greater than the second version, and if the first version is less than the second version, Related program extracting means for detecting 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 having the first version or lower from the program history management file as an installation target program When,
As the first extraction process, the current version acquired by the current program acquisition unit is set as the first version, the new version is set as the second version, the installation target program is extracted by the related program extraction unit, In the extraction process after the first time, a program having the same program ID is obtained by the current program extraction means for each of the installation target programs extracted by the previous extraction process, and the version of the current program is obtained as the first program. A process for extracting a new installation target program by the related program extracting means using the extracted version of the installation target program as the second version is not newly extracted. And control means for controlling to repeat until,
Is disclosed in the version management apparatus.
[0009]
Furthermore, the present invention provides each of the dispersers in the above distributed system.
A working file for storing the working program transmitted when the working program obtaining means of the version management apparatus obtains the working program and its working version;
When an installation target program for updating the transmitted current file is transmitted, the program of the current file is converted into an executable format file, and this is compared with the executable format file currently used by the disperser. A comparison means;
Control means for controlling to execute installation of the installation target program for update when the comparison result by this means matches;
Disclosed is a distributed system.
[0010]
DETAILED DESCRIPTION OF THE INVENTION
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, development machines 2, 2... For developing a program and a version management device 1 for managing the program are connected to the development network 3, and the program is connected via the development network 3. Take out, modify, and register. .. Are connected to the backbone network 4 in stages, and distributed machines 6, 6... Are connected to the networks of each distributed machine group. These distributed machines exchange information with the version management apparatus 1 connected to the development network 3 via the distributed machine group network and the backbone network to which the distributed machines are connected.
[0011]
FIG. 1 is a block diagram showing a configuration example of a version management apparatus according to the present invention, which is connected to a development network 3 via an input / output mechanism 106. A terminal device 107 is also connected via an input / output mechanism 106. When information related to program development from the development machine 2 is input from the input / output mechanism 106, this is processed by the program management function 104, and the version of the version to be modified by the developer with reference to the program history management file 101 is read. The program is extracted from the program source storage file 102 and transmitted to the development machine via the input / output mechanism 106 and the network 3. When the developer completes the renovation and sends the refurbishment program via the network 3 and the input / output mechanism 106 in the same manner as described above, the program management function 104 determines the update and updates the refurbishment program version by one. The history management file 101 is updated, and the modified source program is registered in the program source storage file 102.
[0012]
When the installation manager inputs from the terminal device 107 the program to be installed this time and the version of the program, this data is input to the installation target extraction function 103 via the input / output control mechanism 106. Upon receiving this data, the installation target extraction function 103 receives, from the program history management file 101, the version of the program scheduled to be installed this time and the version of the corresponding program actually running on the distribution target installation machine (network 3 and input). The program and the predetermined version required for installation are extracted from all related programs based on the information obtained from the output control mechanism 106), and the installation target program therein is the installation target program storage file. 105 is registered. The registration result is displayed on the terminal device 107 via the input / output control mechanism 106. When all the installation target programs in one distributed machine are extracted and stored in the storage file 105, the installation can be performed. Further, at the same time, the currently running version of all extracted programs scheduled to be installed this time is also stored in the storage file 105.
[0013]
FIG. 3 shows an example of a functional configuration related to installation management on the distributed machine side, and exchange of information with the network 5 is performed via the input / output mechanism 301. When the distribution target program version acquisition process is executed by the installation target extraction function 103 in FIG. 1, the currently active version editing function 302 is executed, and the names of all programs registered in the execution format library 306 are displayed. Each program version is extracted, edited into a message, and transmitted to the version management apparatus 1 via the network.
[0014]
When the installation manager uses the terminal device 107 to distribute the program stored in the installation target program storage file 105 to the distributed machine, this information is input to the distributed machine 6 via the network 5 and the input / output mechanism 301. When the program determination function 303 determines that the input program is a currently operating program, the input program is stored in the currently operating program reception file 305 that is the current installation target, and the input program is installed this time. If the target program is determined, the input program is stored in the current installation target program reception file 304.
[0015]
When the determination function 303 determines that the program distribution from the version management apparatus 1 is completed, the program stored in the currently running program reception file 305 is sent to the execution format program creation function 308, where the execution format program is created. The program in the execution format is registered in the comparison execution format library 307. When all the registrations are completed, the program registered in the currently executed execution format library 306 and the execution format program registered in the comparison execution format library 307 are compared by the comparison determination function 309. When the determination is made, all the current installation target programs stored in the file 304 are converted into execution formats by the execution format program creation function and registered in the execution format library 306. Further, the version of the program installed this time is stored together with the program registered in the execution format library 306. When the installation of the program in the execution format is normally completed, the comparison / determination function 309 notifies the installation manager via the network that the installation has been completed normally. If it is determined that even one of the execution format programs of the two libraries 306 and 307 is not equal, the installation manager is informed that the installation has failed. Further, the comparison determination function 309 checks whether or not the program is registered normally when the program is registered in the execution format library 306 from the execution format program creation function 308. Replace the corresponding program in the library 307 with the executable program that has become abnormal, and re-register it. At this time, the installation operation is stopped here, and the installation manager is notified that the installation has failed.
[0016]
FIG. 4 shows the format of each data used in the processing of FIGS. FIG. 6A shows a data format for notifying the version management apparatus 1 of the version of the program currently running on the distribution machine 6, a computer ID 401 indicating which distribution machine information, a program ID 402, and a distribution It consists of version 403 of the program that is registered and running on the machine. The computer ID 401 may be a device address of a distributed machine, for example. FIG. 4B shows the format of history information stored in the program history management file 101. In addition to the program ID 411, the program version 412, and the address 414 on the source accumulation file 102 where the program is stored, It consists of a change ID 413 which is a feature of the invention. This change ID 413 is information added to a program that must be corrected at the same time when a program developer changes a program, and is given by the version manager by the developer's declaration. This is an indispensable condition for allowing a program modified in relation to a certain program to be easily identified later by a person other than the developer.
[0017]
FIG. 4C shows a data format in which the installation target program is extracted by the installation target extraction function 103 shown in FIG. 1, and the program is distributed to the target dispersion machines in this format. This data format includes a computer ID 421 of the distributed machine, a program ID 422 to be installed this time, a current version 423 to be installed, a modification category 424 for identifying whether the current installation is the currently installed version, and a program source 425. Yes.
[0018]
FIG. 4 (d) shows the result of installing the program in the data format informing the version management apparatus 1 from the distributed machine whether or not the installation work has been normally completed as a result of the program being installed on the distributed machine. It consists of a computer ID 431 of the distributed machine, an installed program ID 432, a version 433 of the program, a modification category 434 indicating whether the program is an installation target program or a currently running program, and an installation result determination 435. The installation manager refers to this information and makes a final decision on the result. If the result is a failure, it is possible to immediately determine whether the program is the current installation target program or the currently running program by referring to the modification category 435.
[0019]
FIG. 5 is a flowchart showing the processing of the installation target extraction function 103 shown in FIG. 1, and the target program can be extracted without fail. When processing is started (step 501), the currently running program ID and version are fetched from the disperser in the data format of FIG. 4A (step 502), and the version of the program to be installed this time and the version 502 are obtained. The version is compared (step 503). As a result, if the version to be installed this time is smaller or equal, it is determined that the installed on the distributed machine is finished, and the process is completed. If it is determined that the version to be installed is larger, the program that is scheduled to be installed this time The program history management file 101 is searched using the ID as a key (step 504), and it is determined whether there is information on the program (step 505). As a result, if the program history management file 101 does not have the ID and version of the program, the installation manager is notified of the abnormality (step 506). This indicates whether the version input of the program to be installed this time is wrong or the modification source registration is wrong, and is an important process.
[0020]
If there is information being searched (YES in step 505), the computer ID, program ID, version, program source, and modification classification, which are the information of the program to be installed this time, are in the format shown in FIG. Are edited and stored in the installation target program storage file 105 (step 507). 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 of FIG. Further, it is memorized that the modified version is the modified version. Next, data having the format shown in FIG. 4C is also created for the currently running program and stored in the installation target accumulation file 105. At this time, it is stored that the version is currently in operation (step 508).
[0021]
Next, in order to search for related programs from the version to be installed this time to the currently running version, first, the program information version stored in the file 105 is fetched into a work area on the memory, and the program version to be installed is set to n, The version of the currently running 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) retrieved in step 505 are extracted from the program history management file 101. The process of storing the program ID and version in the work area and reducing the 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 higher than the currently operating version, the related program with the same change ID, that is, all the program versions of the version later than the currently operating version were repaired at the same time. All programs can be extracted.
[0022]
However, this is not enough. Among the programs extracted in the process 511, there is a possibility that other programs may be modified at the same time. Therefore, it is necessary to extract all the related programs of the program extracted in the step 511. For this reason, when the loop processing of steps 510 to 512 is completed, the same program (only the version is different) that is installed this time is set as searched, and these are not searched again to improve the processing efficiency (step 513). . Then, related program extraction is performed (step 514), and the installation target program extraction processing is terminated.
[0023]
FIG. 6 is a flowchart showing details of the related program extraction process in step 514 of FIG. 5, and program information having the same change ID for several versions of the installation target program is stored in the work area in step 511 of FIG. Therefore, the program ID is first sorted in descending order on the work area with the program ID as the first key and the version as the second key (step 601). 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 version are extracted in the sort order (step 603), and it is checked whether the program has been searched (step 604). ). If the search has been completed, the process returns to step 602. If the search has not been completed, the version of the program is compared with the version of the same program currently in operation (step 605). The program is already searched (step 606), and the process returns to step 602. If it is larger, the program history management file 101 is searched for and extracted from the work area (step 607), and the extracted program information is installed. The program is stored in the program accumulation file 105 (step 608), and the currently running program information of the program is read from the disperser and stored in the same accumulation file 105 (step 609). Next, the version of the program information stored in the file 105 is taken into the work area on the memory, the version of the program read in step 607 is set to m, and the version of the program currently in operation is set to m0 (step 610). Then, until m ≦ m0, all other programs having the same change ID as the program information change ID searched in step 607 are extracted from the program history management file 101, and the program ID and version are stored in the work area. Then, the process of reducing m by 1 is repeated (steps 611 to 613). As a result, all the related programs detected as related programs in the process of FIG. 5 and searched for are detected. Thus, when exiting the loop, the program is inspected (step 614), and the process returns to step 601. By repeating the above, all the programs and versions to be installed this time are extracted and stored in the installation target program storage file 105 in FIG.
[0024]
FIG. 7 is an explanatory diagram of a processing example according to the flow of FIGS. 5 and 6, and shows a case where the version V1.05 of the program A is to be installed in the distributed machine 1. FIG. 7A shows the version of the currently running program of the distributed 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 program A is V1.02, the same change ID as the change ID from version V1.05 of program A on the program history management table to V1.04 and V1.03 Other programs having IDs, that is, other programs having change IDs 10, 7, and 5 are extracted in the process of FIG. That is, V1.03 (change ID = 10) of program B and V1.03 (change ID = 7) of program C are extracted, and information such as these programs and their versions are stored in the work area. At this time, the program A is edited with V1.05 as the modified version and V1.02 as the currently operating version.
[0025]
Next, since the currently operating version of program B is V1.01, the version of the program extracted in the process of FIG. 5 is V1.03, so the change IDs V1.03 and V1.02 of the program B have Other programs having the same change ID are extracted in the process of FIG. That is, the change ID of V1.03 of program B is 10, but the same change ID is only program A that is not subject to search, and there is no related program here, but V1.02 of program B Since the change ID is 6, V1.01 of program C is extracted. As a result, V1.03 of program B, V1.02 and V1.01 of program C are stored in the work area. At this point, the program B is edited as V1.03 as the modified version and V1.01 as the currently active version. Further, since the currently active version of 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 present. Extracted by the process of FIG. That is, the change ID of V1.02 of program C is 7, but the same change ID is only the program that is excluded from the search target. The change ID of program C V1.01 is 6, but the same change ID is only program B that is not subject to search. Thus, no new program is extracted in this example. At this time, the program C is edited with V1.02 as the modified version and V1.00 as the currently operating version. As described above, the version of the program necessary for installation is as shown in FIG.
[0026]
【The invention's effect】
As described above, according to the present invention, it is possible to automatically extract a program to be installed and a program related to the program to be installed, and there is an effect that the correct version can be installed accurately and efficiently. .
[Brief description of the drawings]
FIG. 1 is a block diagram illustrating a configuration example of a version management apparatus 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 overall flow of an installation management method in the apparatus of FIG. 2;
4 is a diagram showing a data format used in the apparatus of FIG. 2; FIG.
FIG. 5 is a diagram showing extraction processing of an installation target program in the apparatus of FIG. 2;
6 is a flowchart of related program extraction processing in the apparatus of FIG. 2;
FIG. 7 is an explanatory diagram of an example of installation target program extraction processing;
[Explanation of symbols]
DESCRIPTION OF SYMBOLS 1 Version management apparatus 3 Network 101 Program history management file 102 Program source accumulation file 103 Installation object extraction function 104 Program management function 105 Installation object program accumulation file 107 Terminal apparatus

Claims

ネットワークに接続された分散機上のプログラムを更新するときにそのプログラム更新に伴って関連する他プログラムを抽出して同時に更新できるようにするためのバージョン管理装置を備えた分散システムであって、
各プログラム毎に、当該プログラムを識別するためのプログラムＩＤと、当該プログラムのバージョンと、当該プログラムの初期インストール時あるいはいずれかのプログラム更新時に当該プログラムがインストールされた時にそのインストール作業に対して付与される固有の値を持つ変更ＩＤとを少なくとも有するプログラム履歴管理ファイルと、
更新しようとする新バージョンのプログラムが新プログラムとして与えられたときに、当該新プログラムと同一プログラムＩＤをもち且つ分散機上で使用中の現用プログラムとその現用バージョンとをネットワーク経由で取得する現用プログラム取得手段と、
１つのプログラムの第１及び第２バージョンが与えられたときに、もし第１バージョンの方が第２バージョンより大きいときは何もせず、もし第１バージョンの方が第２バージョンより小さいときは、第１バージョンより大きく第１バージョンもしくはそれ以下のバージョンをもつ当該プログラムの各々の前記変更ＩＤと等しい変更ＩＤをもつ他プログラムを前記プログラム履歴管理ファイルから検出してインストール対象プログラムとする関連プログラム抽出手段と、
第１回目の抽出処理として、前記現用プログラム取得手段により取得された現用バージョンを前記第１バージョンとし、前記新バージョンを前記第２バージョンとして前記関連プログラム抽出手段によりインストール対象プログラムを抽出し、第２回目以降の抽出処理においては、前回の抽出処理によって抽出されたインストール対象プログラムの各々に対し、同一プログラムＩＤをもつプログラムを前記現用プログラム抽出手段により取得してその現用プログラムのバージョンを前記第１のバージョンとし、前記抽出されたインストール対象プログラムのバージョンを前記第２バージョンとして前記関連プログラム抽出手段により新にインストール対象プログラムを抽出する、という処理をインストール対象プログラムが新たに抽出されなくなるまで繰り返すように制御する制御手段と、
を前記バージョン管理装置に設けたことを特徴とする分散システム。A distributed system comprising a version management device for extracting other related programs along with the program update when updating a program on a distributed machine connected to a network,
For each program, a program ID for identifying the program, the version of the program, and the installation work when the program is installed at the time of initial installation of the program or at the time of any program update are given. A program history management file having at least a change ID having a unique value;
When a new version 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 the current version are acquired via the network. Acquisition means;
Given the first and second versions of a program, do nothing if the first version is greater than the second version, and if the first version is less than the second version, Related program extracting means for detecting 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 having the first version or lower from the program history management file as an installation target program When,
As the first extraction process, the current version acquired by the current program acquisition unit is set as the first version, the new version is set as the second version, the installation target program is extracted by the related program extraction unit, In the extraction process after the first time, a program having the same program ID is obtained by the current program extraction means for each of the installation target programs extracted by the previous extraction process, and the version of the current program is obtained as the first program. A process for extracting a new installation target program by the related program extracting means using the extracted version of the installation target program as the second version is not newly extracted. And control means for controlling to repeat until,
Is provided in the version management apparatus.

請求項１の分散システムにおいて、分散機の各々に、
前記バージョン管理装置の現用プログラム取得手段が現用プログラムとその現用バージョンを取得したときに送信した現用プログラムを格納する現用ファイルと、
その送信した現用ファイルを更新するためのインストール対象プログラムが送信されてきたときに前記現用ファイルのプログラムを実行形式ファイルに変換し、これと当該分散機で現用されている実行形式ファイルとを比較する比較手段と、
この手段による比較結果が一致したとき、更新のためのインストール対象プログラムのインストールを実行するように制御する制御手段と、
を設けたことを特徴とする分散システム。The distributed system of claim 1, wherein each of the dispersers is
A working file for storing the working program transmitted when the working program obtaining means of the version management apparatus obtains the working program and its working version;
When an installation target program for updating the transmitted current file is transmitted, the program of the current file is converted into an executable format file, and this is compared with the executable format file currently used by the disperser. A comparison means;
Control means for controlling to execute installation of the installation target program for update when the comparison result by this means matches;
A distributed system characterized by providing