JPH0895771A

JPH0895771A - サ−ビス処理システム

Info

Publication number: JPH0895771A
Application number: JP22707594A
Authority: JP
Inventors: Kenichi Ito; 健一伊藤
Original assignee: N T T DATA TSUSHIN KK; NTT Data Communications Systems Corp
Current assignee: N T T DATA TSUSHIN KK; NTT Data Group Corp
Priority date: 1994-09-21
Filing date: 1994-09-21
Publication date: 1996-04-12
Anticipated expiration: 2018-08-18
Also published as: JP3437284B2

Abstract

(57)【要約】【目的】サービスプロセスを停止、消滅させないでプ
ログラムを入れ替えることができる構成のサービス処理
システムを提供する。【構成】プログラムを分割した複数のモジュールを外
部記憶装置３にファイルしておき、所要のモジュールを
ローダ１２１でメインメモリ１２にロードする。その
際、各モジュールに対するサービスプロセスの利用状況
を表すフラグ及び当該モジュールに対する入替え要求の
有無を表すフラグをモジュール単位にモジュール管理テ
ーブル（ＭＭＴ）１２３に設定する。モジュール制御ル
ーチン（ＭＭＲ）１２４は、モジュール入替えを行う際
に、そのモジュールを走行するサービスプロセスを他の
モジュールに移動させるが、移動前後のモジュールに入
替え要求が発生しているときは、移動前に当該プロセス
を休止させ、モジュ−ル入替え後プロセス移動可能な状
態になった時点で当該プロセスの休止解除を行う。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、メモリにロードされた
プログラムに従って所定のサービスプロセスを実行する
サービス処理システムに関し、特に、上記プログラムの
入替え技術に係る。

【０００２】

【従来の技術】従来、コンピュータを用いて種々のサー
ビスプロセスを実行するサービス処理システムにおい
て、プログラムの部分変更が必要になった場合は、プロ
セス停止型とプロセス継続型のいずれかの手法を用いて
当該プログラムの入替えを行っていた。ここに、プロセ
ス停止型の手法は、走行中のサービスプロセスを一旦終
了させ、記憶媒体及びメモリ上のプログラムを変更した
後に当該プロセスを再度起動する方法である。一方、プ
ロセス継続型の手法は、サービスプロセスを継続させた
ままメモリ上のデータ（テキスト領域、データ領域）の
ある位置、即ちメモリアドレスを直接指定して変更する
方法であり、パッチにより修正を行う点に特徴がある。
この場合、変更データは、マシン語レベルで記述する必
要がある。また、同時に記憶媒体のデータも同様に変更
する必要がある。これは、サービスプロセスが終了して
メモリ解放された後に再度起動されるときは、当該記憶
媒体からプログラムがロードされるためである。

【０００３】

【発明が解決しようとする課題】ところで、従来のサー
ビス処理システムにおいて、上述の手法を用いてプログ
ラムの入替えを行う場合には、以下のような問題が生じ
ていた。

【０００４】（１）プロセス停止型この方法では、走行中のサービスプロセスを一旦終了す
るため、当該プロセスが保持している資源やその状態を
引き継ぐのが困難となる問題があった。例えば、通信回
線の状態や、プロセスの状態を保持するためには何らか
のファイルに終了時点の情報をファイル化する必要があ
り、そのための特殊処理や記憶領域を用意しなければな
らなかった。また、サービスプロセスを適切に終了させ
る必要があるので、終了のタイミングが限定される問題
もあった。つまり、サービスプロセスを強制終了させる
とサービスそれ自体の中断となるため、一連のサービス
に区切りがついた時点でしか当該プロセスを終了させる
ことができなかった。さらに、サービスプロセスを一旦
終了させ、再起動させるため、プロセス終了処理、プロ
セス生成処理、初期化処理などの時間も必要となる。

【０００５】（２）プロセス継続型この方法では、修正データの作成をマシン語レベルで行
うため、修正個所の特定や修正データの作成に時間がか
かるという問題があった。また、修正データの関数間の
インタフェースミスやマシン語作成バグなどのチェック
による信頼性確認も人手で行う必要があった。また、実
メモリ空間を直接修正するため、修正サイズの制約があ
り、元のメモリ領域より大きいパッチが当てられないと
いう問題もあった。さらに、サービスプロセスの走行状
態が特定できないため、その走行状態によっては、プロ
グラムの変更前後で矛盾を生じる場合がある。例えば、
関数呼出を行っている途中で関数の戻りアドレスを変更
すると暴走してしまう。これを防ぐため、パッチ後に部
分的な初期化処理を施さなければならない場合もあっ
た。

【０００６】本発明の課題は、上記問題点に鑑み、サー
ビスプロセスを停止、消滅させないでプログラムを入れ
替えることができ、しかも修正データの作成を高品質且
つ短時間で行える構成のサービス処理システムを提供す
ることにある。

【０００７】

【課題を解決するための手段】本発明が提供するサービ
ス処理システムは、メモリにロードされたプログラムを
利用して所定のサービスプロセスを実行するサービス処
理システムにおいて、前記プログラムを分割した複数の
モジュールを格納するモジュール格納手段と、所要のモ
ジュールを前記モジュール格納手段より読み出して前記
メモリにロードするローダと、ロードされたモジュール
に対する前記サービスプロセスの利用状況を表すフラグ
及び当該モジュールに対する入替え要求の有無を表すフ
ラグをモジュール単位に設定するモジュール管理テーブ
ルと、前記モジュール管理テーブルに設定された各フラ
グの参照更新処理、前記ロードされたモジュール同士の
入替え制御、及び個々のモジュールを利用するサービス
プロセスの制御を行うモジュール制御手段と、前記ロー
ドされたモジュールと前記モジュール制御手段とのリン
クを行うリンク手段と、を有し、前記モジュール制御手
段は、前記メモリ上の一のモジュールを走行するサービ
スプロセスを前記リンク手段によりリンクされた他のモ
ジュールに移動させる際に、前記モジュール管理テーブ
ルに設定された各フラグを参照してモジュール入替えが
可能か否かを判定し、入替え可能状態のモジュールに対
してモジュール入替えを実行する構成であることを特徴
とする。

【０００８】なお、前記リンク手段は、例えば、各モジ
ュール内にあり他のモジュールから呼び出される関数に
ついて、その関数名とそれぞれの関数を含むモジュール
の位置情報とを対応付けて格納する関数管理テーブル
と、前記関数の呼出しに用いるモジュールの位置情報を
前記モジュール制御手段を呼び出すための割込情報に変
更する割込手段と、から成る。あるいは、前記モジュー
ル制御手段を呼び出す手続きを記述したダイナミックリ
ンクテーブルと、モジュール移動の際に前記ダイナミッ
クリンクテーブルを参照して前記モジュール制御手段と
のリンクを行うダイナミックリンカとから成る。

【０００９】また、前記モジュール管理テーブルには、
例えば当該モジュールが他のモジュールに呼び出されて
いる数を表す第１のフラグ、及び当該モジュールが他の
モジュールを呼び出している数を表す第２のフラグが少
なくとも設定され、前記モジュール制御手段は、前記サ
ービスプロセスが走行している第１のモジュールから当
該プロセスを第２のモジュールへ移動させる際に、第１
のモジュールに対応する第２のフラグに所定の数値を加
算し、第２のモジュールへのプロセス移動が可能なとき
は該第２のモジュールに対応する第１のフラグに所定の
数値を加算するとともに、当該プロセスを第２のモジュ
ールから第１のモジュールに戻す際に、第２のモジュー
ルに対応する第１のフラグから前記数値を減算し、第１
のモジュールへのプロセス移動が可能なときは該第１の
モジュールに対応する第２のフラグから前記数値を減算
する構成であることを特徴とする。なお、プロセス移動
が可能か否かの判定処理は、例えば前記モジュール管理
テーブルに、当該モジュールについての入替えが指示さ
れているか否かを表す第３のフラグをモジュール毎に設
定し、モジュール制御手段がプロセス移動を行う際に、
各モジュールに対応する第３のフラグを参照することに
より行う。

【００１０】更に、前記モジュール制御手段は、好まし
くは、モジュール入替え中、あるいは入替え要求が発生
しているモジュールに対する前記サービスプロセスをモ
ジュール入替え前に休止させ、モジュール入替えが終了
した時点で当該サービスプロセスの休止状態を解除する
構成とする。

【００１１】

【作用】本発明では、まず、プログラムを複数のモジュ
ールに分割してモジュール格納手段に格納しておき、必
要に応じて所要のモジュールをメモリにロードし、モジ
ュール単位にサービスプロセスからの利用状況及び入替
え要求の有無を把握する。利用状況を把握する手法とし
ては、サービスプロセスの持つプログラムカウンタの値
からそのプロセスの走行位置を把握する方法が知られて
いるが、この方法では、命令トレースなどを行う必要が
あるため、実行時のオーバーヘッドが多大になる欠点が
ある。そこで、本発明では、この手法に代えてモジュー
ル管理テーブルを設けるとともに、このモジュール管理
テーブルに、当該モジュールが他のモジュールに呼び出
されている数を示す第１のフラグ、及び当該モジュール
が他のモジュールを呼び出している数を示す第２のフラ
グを設定する。このようにすれば、第１のフラグの数値
が第２のフラグの数値よりも大きい場合は、少なくとも
当該モジュールの領域を走行中のサービスプロセスが存
在すること（走行中）を意味し、第１及び第２のフラグ
が同一数値でゼロ値でない場合は、当該モジュールの領
域を走行していたサービスプロセスが他のモジュールを
呼び出して走行していること（呼出中）を意味し、第１
及び第２のフラグが共にゼロ値の場合は、当該モジュー
ルの領域を走行しているサービスプロセス及び当該モジ
ュールから他のモジュールを呼び出して走行しているサ
ービスプロセスが存在しないこと（未使用）を意味する
ので、プロセス走行位置、即ちサービスプロセスからの
モジュールの利用状況をモジュール単位で容易に把握す
ることができる。

【００１２】また、入替え要求の有無の把握について
は、例えば前記モジュール管理テーブルに、当該モジュ
ールについての入替えが指示されているか否かを表す第
３のフラグをモジュール毎に設定する。このようにすれ
ば、モジュール制御手段がプロセス移動を行う際に第３
のフラグを参照することにより、移動前後のモジュール
がプロセス移動可能な状態になっているか否かの判定が
可能となる。

【００１３】ここで、サービスプロセスが走行している
モジュールを第１のモジュール、リンク手段によりリン
クされた当該プロセスの移動先のモジュールを第２のモ
ジュールとすると、モジュール制御手段は、第１のモジ
ュールを走行中のプロセスを第２のモジュールへ移動さ
せる際に、まず、第１のモジュールに対応する第２のフ
ラグに所定の数値を加算し、プロセス移動が可能な状態
であれば、第２のモジュールに対応する第１のフラグに
所定の数値を加算する。他方、当該処理を第２のモジュ
ールから第１のモジュールへ戻す際に、第２のモジュー
ルに対応する第１のフラグから前記数値を減算し、プロ
セス移動が可能な状態であれば、第１のモジュールに対
応する第２のフラグから前記数値を減算する。プロセス
移動ができないとき、例えばモジュール管理テーブルの
第３のフラグを参照した結果、いずれかのモジュールに
入替え要求が発生している場合、モジュール制御手段
は、モジュール入替え可能な条件が整うまで当該プロセ
スを休止状態（スリープ状態）とする。そして、各モジ
ュールについて入替えが可能状態となっているかを確認
し、入替えが可能状態にあればモジュール入替えを行っ
た後に当該プロセスの休止解除を行う。

【００１４】このように本発明では、各モジュールを走
行するプロセスが、モジュール入替えがあっても消滅し
ないので、当該プロセスが保持している資源やその状態
がそのまま移動先のモジュールに引き継がれる。また、
モジュール単位にプログラム入替えが行われるので、修
正データの作成に高級言語を使うことも可能となる。

【００１５】

【実施例】次に、図面を参照して本発明の実施例を詳細
に説明する。図１は、本発明の一実施例に係るサービス
処理システム構成図であり、符号１は所定のプログラム
に従ってサービスプロセスを実行するサービス処理装
置、２はキーボードやマウス等の入力装置、３はモジュ
ール管理ルーチン（ＭＭＲ）ファイル３１とプログラム
モジュールファイル３２を格納した外部記憶装置であ
る。

【００１６】サービス処理装置１は、装置内各部の制御
を行う中央処理装置１１と、上記制御に必要なデータや
プログラムを格納するメインメモリ１２とを有する。メ
インメモリ１２には、例えばローダ１２１、サービス処
理プログラム１２２、モジュール管理テーブル（ＭＭ
Ｔ）１２３、ＭＭＲ１２４、ダイナミックリンカ１２
５、及び関数管理テーブル（ＦＭＴ）１２６が格納され
ている。

【００１７】ローダ１２１は、入力装置２からのサービ
ス起動の指示入力により、当該サービスの実現に必要な
サービス処理プログラム１２２を外部記憶装置３のプロ
グラムモジュールファイル３２より読み出してメインメ
モリ１２上へロードする。その際、ロードされた各モジ
ュールに対応するＭＭＴエントリを作成する。また、入
力装置２からのモジュール入替え指示により、入替対象
となるモジュールを外部記憶装置３よりメインメモリ１
２上にロードする。ローダ１２１自身は、システム初期
化時にメインメモリ１２上に展開される。

【００１８】ＭＭＴ１２３は、メインメモリ１２上に展
開されているサービス処理プログラムの状態を管理する
テーブルであり、当該サービス処理プログラムを構成す
るモジュール名と、それぞれのモジュールの各種フラグ
と、入替え要求中にスリープ状態となったプロセスをキ
ューイングするスリープキューとが各々対応付けられて
いる。

【００１９】図２（ａ）は、このＭＭＴ１２３の具体例
であり、ｆｒａｇ１は、当該モジュールが呼び出された
数を示すフラグ（第１のフラグ）、ｆｒａｇ２は、当該
モジュールが他のモジュールを呼び出している数を示す
フラグ（第２のフラグ）、入替え要求ｆｒａｇは、当該
モジュールの入替えが指示されていることを示すフラグ
（第３のフラグ）である。また、入替え要求ｆｒａｇ
は、入替え要求なし（値０）、未使用の場合のみ入替え
可能（値１）、未使用及び呼出中に入替え可能（値２）
の３状態を表現する。このＭＭＴ１２３の内容は、前述
のように、ローダ１２１によるモジュールのローディン
グの際に作成され、サービスプロセス移動処理時及びモ
ジュール入替え処理時等に更新される。

【００２０】ＭＭＲ１２４は、個々のモジュールの利用
状況を管理・制御するためのルーチンプログラムである
（モジュール制御手段）。

【００２１】また、ＦＭＴ１２６は、ロードされたモジ
ュールとＭＭＲ１２４とのリンクに用いるテーブルであ
り、図２（ｂ）に示すように、各モジュール内にあり他
のモジュールから呼び出される関数（ｆｕｎｃ１，ｆｕ
ｎｃ２，・・・）について、その関数名とそれぞれの関
数の位置情報（モジュール内ｏｆｆｓｅｔ）を対応付け
て格納するものである。このＦＭＴ１２６は、各モジュ
ールがメインメモリ１２にローディングされる際、ロー
ダ１２１により作成される。

【００２２】なお、ＦＭＴ１２６に代えて、ダイナミッ
クリンカ１２５が有するダイナミックリンクテーブルを
利用することも可能である。即ち、ダイナミックリンク
機能を提供するコンパイラは、一つのサービスを記述し
た一つ以上のプログラムファイルから複数のロード可能
モジュールを生成する。このロード可能モジュールは、
アドレス解決を行う前の状態であり、これらの未解決の
アドレスは、実行する直前までにダイナミックリンカ１
２５によりアドレス解決が行われる。そのため、ロード
可能モジュールのアドレス解決が動的に行われるといえ
る。これにより、ダイナミックリンカ１２５とＭＭＲ１
２４にてプログラムを複数のモジュールとして管理でき
るため、修正データなどを作成した場合は、修正のある
モジュールだけを記憶媒体上で入れ替えれば良く、通信
回線を介して修正データを転送する場合や、記憶容量の
小さい媒体で修正データを運搬する場合に有利となる。

【００２３】次に、上記構成のサービス処理装置１にお
いて、メインメモリ１２上のサービス処理プログラム１
２２の一部、例えば第１のモジュール（以下、ｓ１と略
称する）を走行しているサービスプロセスを第２のモジ
ュール（以下、ｓ２と略称する）に移動させ、モジュー
ル入替え後にこれを戻す処理について説明する。

【００２４】この実施例では、モジュール間を移動する
関数の呼び出しの際に、ＭＭＲ１２４を呼び出すように
リンクを行う。つまり、ｓ１→ＭＭＲ→ｓ２のようにリ
ンクを行う。これを実現する方法は、上述のように、Ｆ
ＭＴ１２６の内容を参照し、ｓ１から他のモジュールの
関数を呼び出す箇所を、当該関数名及びその引数をもっ
てＭＭＲ１２４を呼び出すように変更する方法、あるい
は、ダイナミックリンクでのアドレス解決をモジュール
移動の度に行うようにし、ダイナミックリンカ１２５の
中でＭＭＲ１２４を呼び出す等の方法のいずれであって
も良い。

【００２５】以下、図３及び図４を参照してこのサービ
ス処理装置１における全体的な処理の流れを、ＭＭＲ１
２４の制御手順を中心に説明する。図３によれば、ま
ず、上記リンクによりｓ１からＭＭＲ１２４が呼び出さ
れる。ＭＭＲ１２４は、ｓ１が他のモジュールを呼び出
していることを示すため、ＭＭＴ１２３にある当該ｓ１
のｆｒａｇ２を”１”加算するとともに（Ｓ（処理ｓｔ
ｅｐ、以下同じ）１０１）、ｓ１に入替え要求が発生し
ているか否かを知るため、ＭＭＴ１２３にあるｓ１の入
替え要求ｆｒａｇを参照する（Ｓ１０２）。

【００２６】ここで、ｓ１に入替え要求が発生している
場合、つまりｓ１の実行中に、このｓ１と第３のモジュ
ールｓ’１（図１参照）との入替え要求が行われた場合
には、ｆｒａｇ１及びｆｒａｇ２を参照してｓ１の現在
の状態を調べ（Ｓ１０３）、「呼出中」であればｓ１の
入替え要求ｆｒａｇが”２”か否か、即ちｓ１が「未使
用及び呼出中に呼出可能」か否かを調べる（Ｓ１０
４）。ｓ１の入替え要求ｆｒａｇが”２”であれば排他
的にｓ１とｓ’１との入替え処理を行い（Ｓ１０５）、
入替え終了後はｓ１の入替え要求ｆｒａｇをクリア（Ｓ
１０６）するとともに、ＭＭＴ１２３及びＦＭＴ１２６
のｓ１に対応する内容をｓ’１の内容に更新する。その
後、ｓ１のスリープキューを休止解除する（Ｓ１０
７）。

【００２７】Ｓ１０２においてｓ１に入替え要求が発生
していない場合（Ｓ１０２）、ｓ１が「呼出中」ではな
く「走行中」の場合（Ｓ１０３）、あるいはｓ１につい
ての入替え処理が終了した場合（Ｓ１０７）は、ｓ１に
おいて呼び出す関数がどのモジュールにあるか、即ちＭ
ＭＲ１２４の引数にある関数名ｆｕｎｃ１からサービス
プロセスの移動先がどのモジュールになるかをＦＭＴ１
２６を検索して把握する。この実施例においては、関数
ｆｕｎｃ１がｓ２にあることを把握する（Ｓ１０８）。

【００２８】続いてｓ２に入替え要求が発生しているか
否かを知るため、ＭＭＴ１２３にあるｓ２の入替え要求
ｆｒａｇを参照する（Ｓ１０９）。ここで、ｓ２と第四
のモジュールｓ’２（図１参照）との入替え要求が発生
している場合には、ＭＭＴ１２３のｆｒａｇ１及びｆｒ
ａｇ２を参照してｓ２の現在の状態を調べ（Ｓ１１
０）、「走行中」のとき、あるいは「呼出中」であって
ｓ２の入替え要求ｆｒａｇが”２”でないときは（Ｓ１
１１）、ｓ２のスリープキューに登録し（Ｓ１１２）、
プロセスの休止解除を行って（Ｓ１１４）Ｓ１０９に戻
る。他方、ｓ２が「未使用」のとき、あるいは「呼出
中」であってｓ２の入替え要求ｆｒａｇが”２”のとき
は、排他的にｓ２とｓ’２との入替え処理を行い（Ｓ１
１５）、入替え終了後はｓ２の入替え要求ｆｒａｇをク
リア（Ｓ１１６）するとともに、ＭＭＴ１２３及びＦＭ
Ｔ１２６のｓ２に対応する内容をｓ’２の内容に更新す
る。その後、ｓ２のスリープキューを休止解除する（Ｓ
１１７）。

【００２９】Ｓ１０９においてｓ２に入替え要求が発生
していない場合、及びＳ１１７においてｓ２のスリープ
キューが休止解除された場合は、ｓ２の呼出が行われて
いることを示すため、ＭＭＴ１２３にあるｓ２のｆｒａ
ｇ１に”１”を加算する（Ｓ１１８）。その後、ｓ２に
ある関数ｆｕｎｃ１を呼び出し（Ｓ１１９）、制御を当
該関数ｆｕｎｃ１に移す。その後の処理手順を図４に示
す。

【００３０】図４を参照すると、ｆｕｎｃ１によるｓ２
の処理が終了すると、ｓ２を呼び出したＭＭＲ１２４に
制御が戻る。そこで、ｓ２の呼出が終了したことを示す
ため、ＭＭＲ１２４は、ＭＭＴ１２３にあるｓ２のｆｒ
ａｇ１を”１”減算する（Ｓ１２０）。

【００３１】次に、ｓ２に入替え要求が発生しているか
否かを調べる（Ｓ１２１）。ここで、入替え要求が発生
している場合は、ｓ２の実行中にｓ２の入替え要求が発
生したことを意味するので、ｓ２について前述のＳ１０
３〜Ｓ１０７と同様の処理を行う（Ｓ１２２〜Ｓ１２
６）。この場合、サービスプロセスは既にｓ２の実行を
終了しているので、入替え待ちの休止状態になることは
ない。また、ｓ２の実行中にｓ１の入替え要求が発生し
た場合には、Ｓ１２４〜Ｓ１２６の後に入替え処理を行
う。図示のフローチャートでは、プロセス休止処理は行
われないが、ｓ１を「呼出中」で入替えを行う場合に
は、プロセス休止処理を行うことも可能である。

【００３２】一方、Ｓ１２１においてｓ２に入替え要求
が発生していない場合、及びＳ１２２でｓ２が「呼出
中」の場合、あるいはＳ１２３においてｓ２の入替え要
求ｆｒａｇが”２”でない場合には、サービスプロセス
の移動先であるｓ１に入替え要求があるかを知るため
に、ＭＭＴ１２４にあるｓ１の入替え要求ｆｒａｇを参
照する（Ｓ１２７）。入替え要求が発生している場合に
は、前述のＳ１０３〜Ｓ１０７の処理を行う。この処理
の終了後、あるいはＳ１２７においてｓ１に入替え要求
が発生していない場合は、ｓ１からの呼出が終了したこ
とを示すため、ＭＭＴ１２３にあるｓ１のｆｒａｇ２か
ら”１”を減算し（Ｓ１３３）、ＭＭＲ１２４の呼出元
であるｓ１に制御を戻す（Ｓ１３４）。

【００３３】なお、上述のＳ１０５〜Ｓ１０７、Ｓ１２
４〜Ｓ１２６の処理においては、実際の入替えを行わ
ず、入替え待ちのプロセスを休止解除することにより、
この休止解除されたサービスプロセスが入替えを行うよ
うにすることもできる。このようにすれば、ＭＭＲ１２
４の制御手順を簡略にすることができる。この場合のフ
ローチャートを図５及び図６に示す。

【００３４】図５において、Ｓ２０１〜Ｓ２０３の処理
は、図３のＳ１０１〜Ｓ１０３の処理と同様であり、Ｓ
２０４においてｓ１の入替え要求ｆｒａｇが”２”のと
きは排他制御を行わずにｓ１のスリープキューを休止解
除する（Ｓ２０５）点が異なる。以後のＳ２０６〜Ｓ２
１７の処理は図３の場合と同様となる。図６の場合も、
図４の処理において、ｓ２の状態が「未使用」のとき、
あるいは「走行中」であるがｓ２の入替え要求ｆｒａｇ
が”２”のときは、排他制御を行わずにｓ２のスリープ
キューを休止解除する（Ｓ２２２）点、及び、ｓ１に入
替え要求が発生し、ｓ１の入替え要求ｆｒａｇが”２”
のときも排他制御を行わずにｓ１のスリープキューを休
止解除する（Ｓ１３２）点が異なり、その他は図４の他
の処理と同様となる。

【００３５】このように、本実施例のサービス処理シス
テムにおいては、サービスプロセスを停止、消滅させな
いでプログラムを入れ替えることができるので、当該プ
ロセスの保持している資源や状態の引き継ぎの問題を生
じさせることがない。また、プログラムの部分修正や追
加に直接関係ないモジュールについては、保守作業の影
響を受けることなくサービスプロセスを継続することが
可能となり、しかも、サービスプロセスからのモジュー
ルの利用状況を迅速に把握できるので、停止されるサー
ビスプロセスの停止時間が必要最小限に抑えられ、保守
によるサービス停止時間が少なくて済む利点がある。従
って、例えば２４時間連続のサービスを行う場合に、プ
ログラム保守作業によるサービス全体に対する影響を小
さくすることができる。また、プログラムの修正等をモ
ジュール単位に行う構成なので、修正データの作成に高
級言語を使うことが可能となり、しかも従来のような修
正サイズの制約もないので、短時間で高信頼性のプログ
ラム修正が可能となる。

【００３６】

【発明の効果】以上の説明から明らかなように、本発明
では、プログラムを複数のモジュールに分割し、それを
単位にして各サービスプロセスからの利用状況（走行
中、呼出中、未使用）及び入替え要求の有無を把握する
ようにしたので、サービスプロセス及び個々のモジュー
ルの状態に合わせたモジュール入替え及びプロセス移動
のタイミングを掴むことが極めて容易になり、プログラ
ムの変更前後で生じる矛盾が確実に排除されるという効
果がある。

【００３７】また、サービスプロセスからのモジュール
の利用状況及び入替え要求の有無を把握するために、モ
ジュール管理テーブルを設け、これに各種フラグを設定
して随時参照更新可能な構成にしたので、サービスプロ
セスが持つプログラムカウンタを用いる場合に比べてプ
ロセス走行位置の把握が容易となり、処理のオーバーヘ
ッドも格段に軽減される効果がある。

【００３８】また、プログラムの修正データを高級言語
で作成できるので、パッチによるマシン語レベルでの修
正に比べ、修正データの作成が短時間で行うことができ
る。この場合は、修正データの大きさの制約が少ないと
いう利点もある。これにより、プログラム修正に関する
時間的及び金銭的なコストを抑えることも可能となる。
更に、モジュールをダイナミックリンク機能を使用して
作成することもできるので、アドレス解決や関数間イン
タフェースの妥当性の検証を容易に行うことも可能とな
る。

【図面の簡単な説明】

【図１】本発明の一実施例に係るサービス処理システム
の構成図。

【図２】（ａ）は本実施例で用いるモジュール管理テー
ブル（ＭＭＴ）の内容説明図、（ｂ）は関数管理テーブ
ル（ＦＭＴ）の内容説明図。

【図３】本実施例におけるサービス処理装置の全体的な
処理手順を示すフローチャート。

【図４】図３の後続手順を示すフローチャート。

【図５】図３で示した処理の一部を簡略化した他の処理
手順を示すフローチャート。

【図６】図４で示した処理の一部を簡略化した他の処理
手順を示すフローチャート。

【符号の説明】

１サービス処理装置２入力装置３外部記憶装置３１モジュール管理ルーチンファイル３２プログラムモジュールファイル１１中央処理装置１２メインメモリ１２１ローダ１２２サービス処理プログラム１２３モジュール管理テーブル（ＭＭＴ）１２４モジュール制御ルーチン（ＭＭＲ）１２５ダイナミックリンカ１２６関数管理テーブル（ＦＭＴ）

Claims

【特許請求の範囲】

【請求項１】メモリにロードされたプログラムを利用
して所定のサービスプロセスを実行するサービス処理シ
ステムにおいて、前記プログラムを分割した複数のモジュールを格納する
モジュール格納手段と、所要のモジュールを前記モジュール格納手段より読み出
して前記メモリにロードするローダと、ロードされたモジュールに対する前記サービスプロセス
の利用状況を表すフラグ及び当該モジュールに対する入
替え要求の有無を表すフラグをモジュール単位に設定す
るモジュール管理テーブルと、前記モジュール管理テーブルに設定された各フラグの参
照更新処理、前記ロードされたモジュール同士の入替え
制御、及び個々のモジュールを利用するサービスプロセ
スの制御を行うモジュール制御手段と、前記ロードされたモジュールと前記モジュール制御手段
とのリンクを行うリンク手段と、を有し、前記モジュール制御手段は、前記メモリ上の一のモジュールを走行するサービスプロ
セスを、前記リンク手段によりリンクされた他のモジュ
ールへ移動させる際に、前記モジュール管理テーブルに
設定された各フラグを参照してモジュール入替えが可能
か否かを判定し、入替え可能状態のモジュールに対して
モジュール入替えを実行する構成であることを特徴とす
るサービス処理システム。
【請求項２】前記リンク手段は、前記各モジュール内にあり他のモジュールから呼び出さ
れる関数について、その関数名とそれぞれの関数を含む
モジュールの位置情報とを対応付けて格納する関数管理
テーブルと、前記関数の呼出しに用いるモジュールの位
置情報を前記モジュール制御手段を呼び出すための割込
情報に変更する割込手段と、から成ることを特徴とする
請求項１記載のサービス処理システム。
【請求項３】前記リンク手段は、前記モジュール制御手段を呼び出す手順を記録したダイ
ナミックリンクテーブルと、モジュール移動の際に前記
ダイナミックリンクテーブルの記録手順に従って当該モ
ジュールと前記モジュール制御手段とのリンクを行うダ
イナミックリンカと、から成ることを特徴とする請求項
１記載のサービス処理システム。
【請求項４】前記モジュール管理テーブルには、当該
モジュールが他のモジュールに呼び出されている数を表
す第１のフラグ、及び当該モジュールが他のモジュール
を呼び出している数を表す第２のフラグが少なくとも設
定され、前記モジュール制御手段は、前記サービスプロセスが走
行している第１のモジュールから前記リンク手段により
リンクされた第２のモジュールへ当該プロセスを移動さ
せる際に、第１のモジュールに対応する第２のフラグに
所定の数値を加算し、第２のモジュールへのプロセス移
動が可能なときは該第２のモジュールに対応する第１の
フラグに所定の数値を加算するとともに、当該プロセス
を第２のモジュールから第１のモジュールに戻す際に、
第２のモジュールに対応する第１のフラグから前記数値
を減算し、第１のモジュールへのプロセス移動が可能な
ときは該第１のモジュールに対応する第２のフラグから
前記数値を減算する構成であることを特徴とする請求項
２又は３記載のサービス処理システム。
【請求項５】前記モジュール制御手段は、モジュール入替え中、あるいは入替え要求が発生してい
るモジュールに対する前記サービスプロセスをモジュー
ル入替え前に休止させ、モジュール入替えが終了した時
点で当該サービスプロセスの休止状態を解除する構成で
あることを特徴とする請求項４記載のサービス処理シス
テム。