JPH11265278A

JPH11265278A - オペレーティングシステムの動的機能管理方法

Info

Publication number: JPH11265278A
Application number: JP6834698A
Authority: JP
Inventors: Yoshiyuki Baba; 儀之馬場; Naohito Sugai; 尚人菅井; Atsushi Setsutsu; 敦摂津
Original assignee: Mitsubishi Electric Corp
Current assignee: Mitsubishi Electric Corp
Priority date: 1998-03-18
Filing date: 1998-03-18
Publication date: 1999-09-28

Abstract

(57)【要約】【課題】機能分割された計算機のオペレーティングシ
ステム（以下、OS）のモジュールを動的に着脱して構成
する環境において、OSの機能変更及び計算機システムの
運転状況の変化に追従して、計算機システムにおいて生
じた事象に対する振舞いを動的に変更することを容易に
する。【解決手段】動的構成可能なOSにおいて、モジュール
のロード手段、モジュールのアンロード手段、ロードし
たモジュールを管理するモジュール管理手段、モジュー
ル内のハンドラを実行するハンドラ呼び出し手段、外部
のソフトウェアと連携してハンドラ実行手段及びモジュ
ールのロード／アンロード手段に対応するメンテナンス
手段を設けて、ハンドラ管理機構を実現する。これによ
り、計算機システムに生じた事象に対するハンドラを、
OSの機能変更と計算機システムの運転状況に応じて実行
できるようにしている。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、計算機のオペレ
ーティングシステム（以下、ＯＳという）技術に関し、
特に、ＯＳを機能分割して生成したモジュールを動的に
着脱して構成する環境において、ＯＳの機能変更及び計
算機システムの運転状況の変化に追従して、計算機シス
テムで生じた事象に対する振舞いを動的に変更するＯＳ
の機能変更方式に関する。

【０００２】

【従来の技術】図１６は、特開昭６２ー２４５４３６号
「オペレーティングシステムの機能拡張制御方式」に記
載されたのＯＳ機能拡張の実現方法を示したものであ
る。ここでは、ＯＳの機能拡張にあたって、読み書き可
能なメモリを有するコンピュータのＯＳの特定箇所に、
機能拡張用手段をあらかじめ組み込んでおき、この機能
拡張用手段を動作させることにより、機能拡張用モジュ
ールを制御するようにしている。具体的には、ＯＳ内部
に設けた機能ごとの実行ルーチンを表す領域に、機能実
行ルーチンの実行番地を設定することによって、ＯＳの
機能拡張を実現している。

【０００３】図１６において、(２０１)は計算機内の読
み書き可能なメモリ、(２０２)はメモリ(２０１)に読み
込まれたＯＳ、(２０４)はメモリ(２０１)に読み込まれ
たＯＳの機能拡張用モジュール、(２０３),(２０５)は
機能に対応した実行ルーチンである。このＯＳ(２０２)
には、特定箇所に個々の機能ごとにある特定番地の内容
の番地を呼び出す識別符号(しくみ)を組み込んだ機能実
行ルーチン(２０３)(機能拡張手段)を含めておき、この
ＯＳ(２０２)が読み込まれた時点では、個々の機能を示
すメモリ(２０３)の内容は、ＯＳ自体の機能を実行する
番地を示している。その後、機能拡張用モジュール(２
０４)が読み込まれ、ＯＳ(２０２)の内のメモリの内容
を書き換えることにより、ＯＳの機能拡張が実現され
る。また、書き換えたメモリ(２０３)の内容を元に戻す
ことにより拡張された機能を元に戻すこともできる。

【０００４】

【発明が解決しようとする課題】従来技術による機能拡
張は、以上のようにして実現されていたので、新しい機
能を追加拡張する場合には、追加機能をＯＳが知って、
その機能の実行ルーチンに対する領域を確保して管理し
なければならず、従って、あらかじめ想定されている機
能のものしか拡張することができないという問題点があ
った。

【０００５】また、実行ルーチンを呼び出す際には特定
機能毎に特定箇所を参照する必要があるが、機能拡張手
段の提供形態は１機能に対して１実行ルーチンと限定さ
れていたので、複数の実行ルーチンを扱うことができな
いという問題点があった。

【０００６】また、１機能を実現している実行ルーチン
内の処理を変更したり複数機能に共通の処理をある実行
ルーチンに組み入れようとすると、１実行ルーチン内に
本来の機能以外の機能を実現するための手続きが入る結
果となり、機能分割という点から見て好ましくないとい
う問題点があった。

【０００７】さらに、拡張機能の実行ルーチンの登録を
本来の実行ルーチンに戻す処理において、該処理の実行
タイミングが問題となり、安全に行えない場合が発生す
るという問題点があった。

【０００８】この発明は上記のような問題点を解消する
ためになされたもので、不特定多数の実行ルーチンの拡
張を想定した運用形態において、対象とする機能が必要
となった時点で対応する実行ルーチンを、数及び機能種
類による制限を受けることなく、ＯＳ及びアプリケーシ
ョンプログラムから呼び出すことを可能としたＯＳの動
的機能変更方法を提供することを目的とする。

【０００９】

【課題を解決するための手段】第１の発明に係わるＯＳ
の動的機能管理方法は、オペレーティングシステム(以
下、ＯＳという)基本構成部内に定義された事象処理モ
ジュール(以下、ハンドラという)を管理する第１のハン
ドラ管理領域と、動的ロードモジュールとして構成され
たハンドラを管理する第２のハンドラ管理領域を有する
ハンドラ管理機構を備え、前記ハンドラ管理機構はモジ
ュールのロード処理において、動的ロードモジュールを
主記憶上へロードし、該ロードモジュールに対応したハ
ンドラ管理領域を前記ハンドラ管理機構下に組み込むと
共に、該ロードモジュールのハンドラ管理領域内に定義
されているモジュール固有の初期化処理を実行すること
によって、該ロードモジュールの呼び出しを可能とした
ものである。

【００１０】第２の発明は第１の発明に係わるＯＳの動
的機能管理方法において、前記ハンドラ管理領域は各ハ
ンドラ対応に該ハンドラを管理する事象識別子を備え、
前記ハンドラ管理機構は計算機システムに事象が発生し
た際にハンドラ管理領域で管理されているハンドラを順
次検索して事象に対応するハンドラを実行するようにし
たものである。

【００１１】第３の発明は第１の発明に係わるＯＳの動
的機能管理方法において、前記ハンドラ管理領域は各ハ
ンドラ対応に該ハンドラを管理するフラグと事象識別子
を備え、前記ハンドラ管理機構は計算機システムに事象
が発生した際に前記フラグおよび事象識別子情報に基づ
いてハンドラ管理領域で管理されているハンドラの実行
/不実行を動的に行うようにしたものである。

【００１２】第４の発明は第１の発明に係わるＯＳの動
的機能管理方法において、前記ハンドラ管理領域は該ハ
ンドラ管理領域のリンク順序入れ替えのためのリンク優
先順位情報を備え、前記ハンドラ管理機構は該リンク優
先順位情報に基づいてハンドラの実行順序を制御するよ
うにしたものである。

【００１３】第５の発明は第１の発明に係わるＯＳの動
的機能管理方法において、プロセッサのアーキテクチャ
で定義された事象に対する記述および事象に対する振舞
いを前記動的ロードモジュールにて規定し、該動的ロー
ドモジュールを起動することでハンドラ管理機構内の事
象検出に関する情報を変更し、事象発生時におけるハン
ドラの切り替えを行うようにしたものである。

【００１４】第６の発明は第１の発明に係わるＯＳの動
的機能管理方法において、前記ハンドラ管理機構は該ハ
ンドラ管理機構外に備えられたソフトウェアからの呼び
出し手段を備え、ハンドラ管理機構で管理されているハ
ンドラをハンドラ管理機構外からソフトウェア呼び出し
するようにしたものである。

【００１５】第７の発明は第１の発明に係わるＯＳの動
的機能管理方法において、事象トレースを実行する機能
をハンドラとして実現し、計算機システムで発生した事
象の収集を行うようにしたものである。

【００１６】第８の発明は第１の発明に係わるＯＳの動
的機能管理方法において、事象トレースを実行する機
能、および計算機システムの状態制御を実行するための
機能をハンドラとして実現し、前記事象トレース実行ハ
ンドラで生成した事象トレース情報に基づいて計算機シ
ステムの状態を把握し、前記計算機システム状態制御ハ
ンドラをハンドラ管理機構外に備えられたソフトウェア
からソフトウェア呼び出しすることにより計算機システ
ムの状態制御を行うようにしたものである。

【００１７】第９の発明は第１の発明に係わるＯＳの動
的機能管理方法において、事象トレースを実行する機
能、および計算機システムの状態制御を実行するための
機能を各々ハンドラとして実現し、前記事象トレース実
行ハンドラで生成した事象トレース情報に基づいて計算
機システムの状態を把握し、前記ハンドラ管理機構は事
象トレース結果に基づいて前記フラグおよび事象識別子
情報を用いてハンドラ管理領域で管理されているハンド
ラの実行/不実行を動的に行うようにしたものである。

【００１８】第１０の発明は第１の発明に係わるＯＳの
動的機能管理方法において、ＯＳの動的構成変更を目的
として動的モジュールをアンロードする時に、該当モジ
ュール内に定義されているモジュール固有の後処理を実
行すると共に、前記ハンドラ管理機構から該モジュール
を取り外すことによって機能変更を行うようにしたもの
である。

【００１９】

【発明の実施の形態】実施の形態１.本発明の第１の実
施形態について、図１乃至図５に基づいて説明する。本
実施形態では、モジュールをロードしてＯＳを再構成す
る際に、ＯＳの機能変更とモジュールに含まれるハンド
ラをハンドラ管理機構に組み込む処理について説明す
る。図１は、本実施形態を実現するシステムの機能構成
図を示したものであり、以下の要素から構成されてい
る。１ＯＳ基本構成部本実施形態実現のための機能を有するＯＳである。２動的ロードモジュールＯＳ基本構成部に存在しない機能を拡張、もしくは機能
を変更するために動的にロードされる動的ロードモジュ
ール。３メンテナンス手段動的ロードモジュール（２）のロード／アンロード時及
び他から要求があった時に、動的ロードモジュールに含
まれている管理ルーチンを呼び出す(３１)。また、シス
テムの運転状況に対応するために、ハンドラ呼び出しの
是非を動的に管理する。４ロード手段動的ロードモジュールの動的ロード時に最初に実行し、
動的ロードモジュールをメモリ上にマッピングして、モ
ジュール管理手段（５）とメンテナンス手段（３）をモ
ジュール挿入モードで呼び出す((４２),(４３))。５モジュール管理手段動的ロードモジュール（２）に含まれるハンドラ管理領
域を管理(挿入／削除モード)する。６ハンドラ呼び出し手段計算機システムに生じた事象を解析し、本実施形態のハ
ンドラ管理機構に組み込まれていて、事象対処として必
要なハンドラを実行する(６１)。７アンロード手段動的ロードモジュール（２）の動的アンロード時に最初
に実行し、メンテナンス手段（３）とモジュール管理手
段（５）をモジュール削除モードで実行する((７３),
(７２))。また、ハンドラ管理領域がアンリンクされた
後に、動的ロードモジュール（２）が占有していたメモ
リをフリーにする。８アプリケーションプログラミングインタフェースアプリケーションプログラムがＯＳによって提供される
サービスを利用するためのインタフェースである。アプ
リケーションプログラミングインタフェースは、メンテ
ナンス手段（３）経由でハンドラ管理機構が提供するサ
ービスが利用可能になる。９アプリケーションプログラムＯＳ上で動作するアプリケーションプログラムである。
アプリケーションプログラミングインタフェース（８）
を用いて、本実施形態の特徴的なハンドラ管理機構が提
供するサービスを利用することができる。１０モジュール作成手段ハンドラ管理機構に組み込む動的ロードモジュールを作
成する手段である。ＯＳ基本構成部 (１) は、静的な最
小構成ＯＳであり、ＯＳ基本構成部 (１)には、動的に
動的ロードモジュール (２) が着脱されて、ＯＳの機能
変更が可能になっている。ＯＳの機能変更を行うための
手段として、ＯＳ基本構成部には、メンテナンス手段
(３) 、ロード手段 (４) 、アンロード手段 (７) 、モ
ジュール管理手段 (５) 、ハンドラ呼び出し手段 (６)
があり、これらは、本実施形態におけるハンドラ管理機
構実現要素である。

【００２０】図２は、本実施形態においてハンドラを管
理するためのデータ構造と、その使用形態を表したもの
である。本実施形態におけるハンドラ管理機構は、ＯＳ
基本構成部（１）におけるハンドラも統一的に扱うこと
ができ、図２は、その様子を表している。ＯＳ基本構成
部に含まれるハンドラ群は、ＯＳ基本構成部のデータ領
域に設けたＯＳ基本構成部内のハンドラ管理領域 (１０
１) で管理する。そして、動的ロードモジュール (２)
(図２参照)に含まれるハンドラ群は、ＯＳ基本構成部内
のハンドラ管理領域 (１０１) 内のメンバである動的ロ
ードモジュール管理領域 (１０２) が、動的ロードモジ
ュール内のハンドラ管理領域 (１１０) のアドレスを示
して管理する。複数の動的ロードモジュールが組み込ま
れる運転状態では、動的ロードモジュール内のハンドラ
管理領域をリンク結合し、その先頭エントリを動的ロー
ドモジュール管理領域 (１０２) で示して管理する。計
算機システムの運転状態がＯＳ基本構成部のみの動作
で、動的ロードモジュールが組み込まれていない場合
は、動的ロードモジュール管理領域の内容はアドレスと
しての無効情報(ー1等)で区別する。ＯＳのロード手段
(４) は、動的ロードモジュールを記憶媒体から読み出
し、メモリ上にマッピングする。ロード手段において、
動的ロードモジュールを媒体から読み出してメモリ上へ
マッピングする処理については説明を省略するが、メモ
リ上へのマッピング後、マッピングした動的ロードモジ
ュールのテキスト部とデータ部の先頭アドレスが公開さ
れる。ロード手段に続いて処理を行うモジュール管理手
段(５)は、先の処理で公開されたテキスト部のアドレス
を、メモリマッピング後のハンドラのアドレスを解決す
るための情報として使用可能となるように、動的ロード
モジュール(２)内のハンドラ管理領域 (１１０)中のメ
ンバ（１１６）に格納する。この後、メンテナンス手段
(３)が、モジュールに含まれるモジュール固有の管理
ルーチンを実行する。管理ルーチンの実行は、動的に組
み込んだモジュールが提供する機能を活性化させるため
の初期化のタイミングを与えるものである。このように
して、モジュールの動的ロード時に、ＯＳ機能を変更す
ると共に動的ロードモジュール内のハンドラ管理領域
（１１０）をＯＳのハンドラ管理機構に組み込む。これ
により、計算機システム内で生じた事象を解析した後
に、ハンドラ呼び出し手段 (６)が所望のハンドラを実
行することが可能になる。

【００２１】以下に、実施の形態１の動作について詳し
く説明する。まず、静的なＯＳ基本構成部に含まれるハ
ンドラを対象にしたハンドラの管理部について説明す
る。ＯＳ基本構成部 (１) 内には、静的なＯＳ基本構成
部内のハンドラを管理するＯＳ基本構成部内のハンドラ
管理領域 (１０１) が存在する。ＯＳ基本構成部内のハ
ンドラ管理領域（１０１）のメンバには、動的ロードモ
ジュール管理領域 (１０２) 、バージョン情報 (１０
３)、モジュール識別子(１０４)、管理ルーチンのアド
レス (１０５)、フラグ (１０６) 、事象識別子 (１０
７) 、ハンドラのアドレス (１０８) 、ハンドラ管理領
域終端子 (１０９) がある。図３は、これらの各メンバ
をアクセスする手段とアクセス形態について示したもの
である。動的ロードモジュール管理領域 (１０２) は、
動的にロードしたモジュールが存在する場合に、その動
的ロードモジュール内のハンドラ管理領域 (１１０) の
アドレスを格納し、存在しない場合は無効なアドレス情
報(ー１等)を格納する。バージョン情報 (１０３) は、
ＯＳ基本構成部（１）内のハンドラ管理領域 (１０１)
の解釈に影響する。モジュール識別子（１０４）は、モ
ジュールの機能を表すための識別子を格納する。管理ル
ーチンのアドレス（１０５)は、ハンドラに関係した機
能を制御する管理ルーチンの存在場所を示している。本
実施形態では、管理ルーチンに対して、ハンドラに関係
した機能の初期化／後処理を行う手続きの提供を要求し
ている。フラグ (１０６) 、事象識別子 (１０７) 、ハ
ンドラのアドレス (１０８) は、ハンドラ１つに対し
て、１組ずつ割り当てられるハンドラ管理情報であり、
フラグ (１０６) は、対応するハンドラを呼び出す必要
の有無を表し、事象識別子(１０７) は、対応するハン
ドラを呼び出す環境を数値化して表している。また、ハ
ンドラのアドレス (１０８) は、対応するハンドラのア
ドレス情報を表している。ＯＳ基本構成部内のハンドラ
管理領域内のハンドラ管理領域終端子 (１０９)は、Ｏ
Ｓ基本構成部内のハンドラ管理領域 (１０１) の終端を
知らせるための情報として機能する。

【００２２】次に、モジュール作成手段 (１０) が生成
する動的ロードモジュールに含まれるハンドラを対象に
したハンドラの管理領域について説明する。動的ロード
モジュール（２）のデータ部の先頭には、本実施形態で
特徴をなす動的ロードモジュール内のハンドラ管理領域
(１１０)を設ける。このような動的ロードモジュール
を作成する手段として、モジュール作成手段 (１０) が
あるが、これは自動生成するツールで実現しても良く、
ユーザ記述を多く必要とするアセンブラで実現しても構
わない。動的ロードモジュール内のハンドラ管理領域
（１１０）のメンバには、次のモジュール内のハンドラ
管理領域 (１１１)、前のモジュール内のハンドラ管理
領域 (１１２)、バージョン情報(１１３)、モジュール
識別子(１１４)、リンクの優先順位(１１５)、テキスト
部のアドレス(１１６)、管理ルーチンのアドレス(１１
７)、フラグ(１１８)、事象識別子(１１９)、動的ロー
ドモジュール内のハンドラのアドレス(１２０)、ハンド
ラ管理領域終端子(１２１) の情報が含まれる。図４
は、これらの各メンバをアクセスする手段とアクセス形
態について示した図である。次のモジュール内のハンド
ラ管理領域(１１１)は、動的にロードされたモジュール
が複数存在する時は、ハンドラ管理機構が次に管理対象
とする動的ロードモジュール内のハンドラ管理領域(１
１０)を示す。リンク結合された最後の動的ロードエン
トリでは、動的ロードモジュールの終端子(１３０)に示
すように、無効なアドレス情報(ー１等)で終端を表す。
前のモジュール内のハンドラ管理領域（１１２）は、動
的にロードされたモジュールが複数存在する時は、ハン
ドラ管理機構が前に管理対象としている動的ロードモジ
ュール内のハンドラ管理領域 (１１０)を示し、複数の
ハンドラ管理領域がリンク結合された最初のエントリで
はＯＳ基本構成部内のハンドラ管理領域(１０１)を示
す。バージョン情報(１１３)、モジュール識別子(１１
４)、フラグ(１１８)、事象識別子(１１９)、ハンドラ
管理領域終端子(１２１)は、ＯＳ基本構成部内のハンド
ラ管理領域(１０１)における同種メンバの働きと同じで
ある。リンクの優先順位(１１５)は、ハンドラ管理機構
が次のモジュール内のハンドラ管理領域 (１１１)と前
のモジュール内のハンドラ管理領域 (１１２)を用いて
動的ロードモジュール内のハンドラ管理領域 (１１０)
をリンク結合する場合の挿入位置に影響する。テキスト
部のアドレス(１１６)は、ロード手段 (４)によってメ
モリ上へマッピングされた後のテキスト部の先頭アドレ
スが、モジュール管理手段 (５) によって格納される。
管理ルーチンのアドレス(１１７)は、動的ロードモジュ
ールが提供する機能の制御を行うルーチンのアドレスを
示すが、これはモジュールのテキスト部の先頭からの相
対アドレスをモジュール作成時に設定しておく。動的ロ
ードモジュール内のハンドラのアドレス(１２０)は、ロ
ードモジュールに含まれるハンドラのアドレスを示す
が、これはモジュールのテキスト部の先頭からの相対ア
ドレスをモジュール作成時に設定しておく。

【００２３】以下に、上記の機能とデータ構造を有した
ＯＳのハンドラ管理機構において、ＯＳの動的構成と共
にＯＳの機能変更を行う方法を図５に基づいて説明す
る。ステップ１５０は、ロード手段（４）によって動的
ロードモジュールをマッピングする処理である。ロード
手段（４）は、動的に拡張する機能の実現手続き及び機
能に関係したハンドラから成る動的ロードモジュールを
２次記憶装置から読み出して主記憶装置(メモリ)上に展
開し、これをＯＳが扱うアドレスにマッピングして実行
可能状態にする。ロードモジュールの読み出しとマッピ
ング処理については説明を省略するが、マッピング後の
アドレス情報を本実施形態に特徴的なモジュール管理手
段 (５)が得られるように、マッピングしたテキスト部
とデータ部のアドレスをＯＳの大域変数等に設定して公
開する。ステップ１５１は、モジュール管理手段 (５)
が、ステップ１５０の処理でマッピングしたアドレス情
報からハンドラのアドレスを導くための処理である。本
実施の形態では、動的ロードモジュールのデータ部の先
頭部に、モジュールに含まれるハンドラを管理すること
を目的とした動的ロードモジュール内の管理領域(１１
０) を設定している。モジュール管理手段（５）は、公
開されたマッピング後のデータ部のアドレス情報から動
的ロードモジュール内のハンドラ管理領域のアドレスを
知り、バージョン情報を確認し、テキスト部のアドレス
(１１６) 領域にマッピング後のテキスト部の先頭アド
レスを設定する。これにより、動的ロードモジュール内
の管理ルーチン及びハンドラのアドレスが求まるように
なる。ステップ１５２は、モジュール管理手段 (５)
が、ステップ１５０の処理でマッピングした動的ロード
モジュールに含まれるハンドラを、本実施形態によるハ
ンドラ管理機構に組み込む処理である。動的ロードモジ
ュールのハンドラは、モジュール内のハンドラ管理領域
に登録されている。従って、ここでは、このハンドラ管
理領域をＯＳのハンドラ管理機構に組み込む。本処理
は、リンクの優先順位(１１５)情報を元にして、ハンド
ラ管理領域の挿入位置を決定し、本ハンドラ管理領域内
メンバである次のモジュール内のハンドラ管理領域(１
１１)と前のモジュール内のハンドラ管理領域(１１２)
及び、ハンドラ管理機構での前エントリにおける次のモ
ジュール内のハンドラ管理領域(１１１)(またはＯＳ基
本構成部内のハンドラ管理領域内メンバの動的ロードモ
ジュール管理領域（１０２))と、存在するならば後モジ
ュールにおける前のモジュール内のハンドラ管理領域
(１１２)にリンク結合を形成するための情報を設定す
る。ステップ１５３では、メンテナンス手段 (３）が組
み込んだモジュール固有の初期化処理を行う。ここで
は、モジュール毎に登録された管理ルーチンを初期化モ
ード(引数で区別：例えば０)で実行する。管理ルーチン
のアドレスは、管理ルーチンのアドレス(１１７)(モジ
ュール先頭からの相対アドレス)とテキスト部のアドレ
ス(１１６)を用いて求める。ステップ１５４は、ステッ
プ１５３の初期化処理の結果を確認する処理である。初
期化処理が異常終了時(例えば管理ルーチン実行の戻り
値が負)、ステップ１５５のエラー処理へ移る。ステッ
プ１５５は、モジュール組み込み時の初期化処理がエラ
ー終了した時のエラー処理である。エラー処理では、例
えばモジュールの組み込みを中止して、動的ロードモジ
ュールをアンロードする。モジュールのアンロード処理
の実施の形態については、実施の形態９に記載する。

【００２４】以上のように本実施形態によれば、動的ロ
ードモジュール（ハンドラ）を管理するためにハンドラ
管理領域を備え、ハンドラ管理領域には他の動的ロード
モジュールをリンクするためのリンク情報と該ハンドラ
のエントリアドレス情報、および該ハンドラを初期化し
使用可能とするための初期化ルーチンアドレスを登録す
るようにし、動的ロードモジュールを主記憶上にロード
した後、該ロードモジュールに対するハンドラ管理領域
を互いにリンク接続し、初期化ルーチンによってモジュ
ールのイニシャライズ処理を行って管理領域中の所定メ
ンバ情報を設定し使用可能な状態にしているので、ロー
ドモジュールの機能変更や着脱を容易に行うことができ
る。また、事象発生時に実行すべきハンドラを一括して
管理することができる。さらに、ハンドラ管理領域を予
めモジュール内に用意するようにしたので、その都度Ｏ
Ｓが該管理領域を確保する必要がなくなり、モジュール
機能追加を意識する必要がなくなるという効果がある。

【００２５】実施の形態２．次に、本発明の第２の実施
形態について図６、図７に基づいて説明する。本実施形
態では計算機システムにおいて、何かしらの事象が発生
した際に、ハンドラ管理機構によって管理されている事
象に対応するハンドラの実行処理について説明する。本
実施形態で扱う事象の範囲は、プロセッサ処理における
例外、プロセッサ処理に対する割り込み、ソフトウェア
定義である。これらの事象が起きた場合、事象検出部
（１０００）がハンドラ呼び出し手段（６）を呼び出す
（１０００１）。事象検出部（１０００）は、プロセッ
サ上の事象検出部（１００１）とソフトウェア定義の事
象検出部（１００２）から成る。このうちプロセッサ上
の事象検出部（１００１）はプロセッサへの事象発生後
に、事象種に対応したハンドラを呼び出すことを自動化
させるものとしてプロセッサアーキテクチャで規定され
ているもので、通常のＯＳでも利用している。事象検出
部は、事象を解析して（プロセッサ処理におけるトラッ
プ等、事象検出時にしか事象種が判別できないものは事
象検出時に事象種を得る)、計算機システムで統一的に
扱う事象識別子を求めて、ハンドラ呼び出し手段（６）
を実行する。ハンドラ呼び出し手段は、次に、求めた事
象識別子とハンドラ管理機構で管理しているハンドラ管
理領域中の事象識別子に従って整合性検査を行ない、対
応するハンドラを探し、実行する。

【００２６】通常、プロセッサアーキテクチャで規定さ
れているプロセッサ処理における例外とプロセッサ処理
に対する割り込みの事象は、プロセッサ上の事象検出部
（１０００）で検出され、対応するハンドラを自動的に
呼び出すように構成されているが、この時のハンドラ呼
び出し手続きは、普通のソフトウェア呼び出し手続きと
は異なっている。即ち、事象が生じる直前迄実行してい
たプログラムを中断してハンドラ呼び出しを行うので、
ハンドラの実行終了後に中断されているプログラムの継
続実行が可能になるように、プログラム処理で用いるプ
ロセッサのレジスタを退避した後、対応するハンドラに
対してソフトウェア呼び出しを実行する。一方、ソフト
ウェア定義の事象を検出した後のハンドラ実行では、普
通のソフトウェア呼び出し手続きと同様の方法によって
ハンドラを実行する。

【００２７】本実施の形態では、事象検出部がハンドラ
呼び出し手段（６）を、まず最初に呼び出す。以下に、
ハンドラの実行手順を図７の処理の流れに沿って説明す
る。ステップ３００では、プログラムで用いるプロセッ
サのレジスタをメモリ等に退避する。ステップ３１０で
は、計算機システム内で生じた事象を解析して、特定し
た事象種を計算機システム内で一意に扱える数値に変換
する。事象種を表す数値は、対応するハンドラを検索す
る処理におけるキーとなる。尚、プロセッサ処理におけ
るトラップ等のように、生じた事象種が事象検出時にの
み判明できるものについては、ハンドラ呼び出し手段
（６）の呼び出し時の引数で事象種を伝える。ステップ
３２０では、処理対象とするハンドラ管理領域が存在す
るかどうかを確認する。最初の対象は、ＯＳ基本構成部
内のハンドラ管理領域 (１０１) である。次回目以降
は、動的ロードモジュール内のハンドラ管理領域 (１１
０) を検索対象にする。処理対象にするハンドラ管理領
域が存在しない場合は（ー１等無効アドレスを示してい
る場合)、終了する。ステップ３３０では、ハンドラ管
理領域に登録されているハンドラが、コールすべきもの
かどうかを判断する。この判断は、ステップ３１０の処
理で特定した事象種を表す数値とハンドラ管理領域内の
事象識別子値の比較によって行う。登録情報について比
較を行い、一致する場合はステップ３４０の処理へ移
り、その他の場合はステップ３５０の処理に移る。ステ
ップ３４０では、ハンドラを実行する。ハンドラのアド
レスは、ハンドラ管理領域に含まれているモジュールの
テキスト部のアドレス (ＯＳ基本構成部ではダミーとし
て０)と動的ロードモジュール内のハンドラのアドレス
(オフセットアドレス情報)を元に絶対アドレスを求め
る。ハンドラ実行時には、引数としてイベント種値を渡
すが、ハンドラはこれを参照しなくても良い。ステップ
３５０では、ハンドラ管理領域内で次に登録されている
ハンドラの存在をチェックする。現在処理中のハンドラ
管理領域で次のハンドラ登録がされていない(フラグが
終端子情報であるー１を示している)場合は、ステップ
３６０の処理に移り、それ以外の場合はステップ３３０
の処理に戻る。本実施形態ではこの様にして、１つの事
象に対して、モジュール内で複数に（分割）したハンド
ラを呼び出すことが可能になっている。ステップ３６０
では、ハンドラ管理領域内メンバの次のモジュール内の
ハンドラ管理領域 (１１１) が示している次のモジュー
ル内のハンドラ管理領域を処理対象とし、ステップ３２
０の処理に戻る。ステップ３７０は、ステップ３００で
退避したレジスタ情報の復元処理を行う。

【００２８】以上のように本実施形態によれば、ハンド
ラ管理領域に事象識別子を備えるようにし、発生した事
象の解析結果に対応して数値情報を割り当て、ハンドラ
の呼び出し手段は該数値情報と事象識別情報間における
整合性を確認し、該当するハンドラを呼び出すようにし
たので、発生事象に適合した適切なハンドラ処理を実現
できる。また、発生事象に対して機能分割して構成され
た複数のハンドラを実行させることが可能になる。

【００２９】実施の形態３.次に、本発明の第３の実施
形態について図８に基づいて説明する。本実施形態で
は、計算機システムの運転状況等に応じて、ハンドラの
実施を変更する場合の処理について説明する。ハンドラ
実行の制御は、ハンドラ管理領域内に存在するハンドラ
毎に割り当てたフラグと事象識別子の設定で行う。

【００３０】以下に、動作について詳細に説明する。ハ
ンドラ管理領域内のフラグ(１０６)は、ハンドラ呼び出
し手段(６)におけるハンドラ実行処理に作用する。以下
が、フラグによるハンドラ実行処理制御ルールである。 (a) フラグがハンドラ呼び出し有効を示している場合に
は、ハンドラを呼び出す。 (b) フラグが事象識別子比較ルールを示している場合に
は、ルールに基づく事象識別子比較を行って、実行が必
要と判断した場合にハンドラを呼び出す。ハンドラの呼び出し判断手順の処理の流れは、図８に示
す通りである。これは図７に示したハンドラの実行手順
処理の流れにおいて、ステップ３２０以降からステップ
３５０迄の処理が異なっている。以下、異なる部分につ
いてのみ説明する。ステップ３２１では、ハンドラ管理
領域に登録されているハンドラをフラグに基づいてコー
ルすべきかどうか判断する。登録情報について判断を行
い、フラグが実行不要を示していた場合はステップ３５
０の処理に移り、その他の場合はステップ３３１の処理
に移る。ステップ３３１では、ステップ３２１で処理対
象にしたハンドラについて、ハンドラ管理領域内のフラ
グによる制御ルールと事象識別子を元に、コールすべき
かどうかを判断する。ハンドラ実行処理制御ルール(a)
の場合は、ステップ３１０での事象解析結果の事象種値
が登録されている事象種と一致する場合にステップ３４
０の処理へ移り、その他の場合はステップ３５０の処理
に移る。フラグ制御ルール(b)の場合には、ルールに基
づいて判断を行い、コールすべきと判断した場合にステ
ップ３４０の処理へ移り、その他の場合はステップ３５
０の処理に移る。フラグ制御ルール(b)としては、例え
ば数値の大小比較であったり、ビットパターン比較など
が相当する。ステップ３４０では、ハンドラを実行す
る。ハンドラ実行時には、引数としてイベント種値を渡
すが、ハンドラは必ずしもこれを用いなくても良い。ス
テップ３５０では、次に登録されているハンドラの存在
をチェックする。現在処理中のハンドラ管理領域内に次
のハンドラ登録が存在しない(フラグが終端子情報(ー
１)を示している)場合は、ステップ３６０の処理に移
り、それ以外の場合はステップ３２１の処理に戻る。

【００３１】以上のように本実施形態によれば、ハンド
ラ管理領域に事象識別子に加え、フラグを備えるように
したので、ハンドラの呼び出し制御が可能になるという
効果がある。また、発生した事象をもとにシステム状態
を解析してフラグ情報に反映させることにより、計算機
システムの運転状況に対応したハンドラ呼び出しを実現
することができるという効果がある。

【００３２】実施の形態４.次に、本発明の第４の実施
形態について図９に基づいて説明する。本実施形態で
は、ある事象に対応するハンドラが複数のモジュールに
存在し、そのハンドラの実行順序が問題となる状況にお
いて、複数モジュールに存在するハンドラの実行順序を
規定する場合の処理について説明する。ハンドラ呼び出
し手段(６)はハンドラの実行に際して、リンク管理して
いるハンドラの管理領域を順番にたどり、事象種に対応
したハンドラを探して実行する。従って、ハンドラ管理
領域のリンク管理の順番が、複数モジュールに存在する
ハンドラの実行順序になる。このために、動的ロードモ
ジュール内のハンドラ管理領域をリンク管理挿入時に位
置決めするために使用する情報として、ハンドラ管理領
域にリンクの優先順位(１１５) が存在する。また、ハ
ンドラが登録されているハンドラ管理領域のリンク管理
順序を変更することで、ハンドラ実行順序を入れ換える
ことが可能となる。もし、後づけしたモジュールに登録
されているハンドラを静的なＯＳ基本構成部に登録され
ているハンドラよりも先に実行させたい場合には、後づ
けするモジュール内のハンドラ管理領域内にＯＳ基本構
成部内での記述と同様のハンドラエントリを設け、モジ
ュール機能の初期化処理でＯＳ基本構成部のハンドラ管
理領域の該当ハンドラのフラグ(１０６)を用いて基本構
成部の呼び出しを無効化する。

【００３３】以下に、動作について詳しく説明する。図
９は、モジュールに含まれるハンドラ管理領域の順序入
れ換えによって、ハンドラの実行順序を変更する処理の
流れを表したものである。まず、ステップ４００では、
実行順序を入れ換える相手側ハンドラが含まれるモジュ
ールがＯＳ基本構成部 (１) 内に含まれているかどうか
を調べ、含まれている場合はステップ４１１の処理へ移
り、含まれていない場合はステップ４０１の処理へ移
る。ステップ４０１では、本実施の形態によるハンドラ
の実行がリンク管理順で行われ、且つ、このリンク管理
をリンクの優先順位 (１１５)情報に基づいて行うこと
で、リンクの優先順位情報を変更する側のモジュールを
決める。ステップ４０２では、リンクの優先順位を変更
するモジュールに関して、ハンドラ管理領域を用いたハ
ンドラ管理機構から取り外す。ステップ４０３では、ス
テップ４０２で取り外したハンドラ管理領域内のメンバ
であるリンクの優先順位情報を変更する。ステップ４０
４では、リンクの優先順位を変更したハンドラの管理領
域を再びハンドラ管理機構に組み込む。一方、ＯＳ基本
構成部外のハンドラを基本構成部内のハンドラより先に
実行させたい場合には、ステップ４１１で、順序を入れ
換えるＯＳ基本構成部内のハンドラ情報を自モジュール
で先に実行したいハンドラ情報の後に加える。ステップ
４１２では、ＯＳ基本構成部内の該当ハンドラの呼び出
しをフラグ（１０９）を用いて抑止する。例えば、ステ
ップ４１１とステップ４１２の処理は、モジュールの動
的ロード時における初期化処理（実施形態１記載の方
法）で実施することができる。また、計算機の運転状況
に応じて、管理ルーチンを呼び出して実施することも可
能である。管理ルーチンの呼び出しに関しては、実施の
形態６に記載する。

【００３４】以上のように本実施形態によれば、ハンド
ラ管理領域にハンドラ管理領域のリンク情報を備え、発
生事象に対応した複数のハンドラを優先順位を付けて呼
び出すようにしたので、特に、順序性が求められる処理
に対しても適切な対応ができるという効果がある

【００３５】実施の形態５．次に本発明の第５の実施形
態について、図１０、図１１に基づいて説明する。実施
の形態１〜４では計算機システム内で事象が発生した後
に、事象検出部（１０００）が一括してハンドラ呼び出
し手段（６）を呼び出す方法によるハンドラ実行につい
て取り上げてきた。そこでは、事象検出部（１０００）
とハンドラ呼び出し手段（６）がＯＳ基本構成部
（１）に組み込まれていることを前提としていた。しか
しながら、新しい事象検出部と新しいハンドラ呼び出し
手段を動的ロードモジュールで提供することも可能であ
り、これによって、例えばプロセッサへの事象発生に対
する振舞いを別種のものに規定することが可能となる。
このように、本実施形態は、１．プロセッサ上の事象検出部（１００１）を変更する
ことで、プロセッサアーキテクチャで規定されているが
ＯＳが当初扱っていなかった例外等の事象に対して、そ
れらを扱う機能モジュールの動的ロードと共に該当する
ハンドラの呼び出しを可能とする。また、特定の割り込
みや例外を、特定のハンドラ呼び出し手段の利用に結び
つけることを可能とする。２．ハンドラ呼び出し手段を変更することで、計算機シ
ステムを連続運転しつつ、ハンドラ管理機構が管理する
ハンドラ管理領域の解釈の仕方を変更してハンドラ呼び
出しルールを動的に変更するといったことを可能とする
ものである。

【００３６】以下に、プロセッサへの事象発生に対する
振舞いを別種のものに規定する手順について説明する。
新しい事象検出部をシステムに組み込むためには、動的
ロードモジュールにより、プロセッサ上の事象に対する
振舞いを規定するプロセッサの事象検出部（１００１）
の情報とこれを有効化させるための手続きを提供する。
ここでプロセッサの事象検出部は、プロセッサアーキテ
チャで規定されている事象が発生した場合に、事象種に
対応したハンドラを自動的に呼び出すことを実現させる
ものである。プロセッサの事象検出部におけるハンドラ
呼び出し情報は、プロセッサアーキテクチャ固有の形態
になっており、ハンドラのアドレスであったり、ハンド
ラの呼び出し命令であったりする。本実施の形態では、
プロセッサの事象検出部を変更するための情報を、以下
のどちらかの方法で与える。（a）新しいプロセッサの事象検出部を現在使用中のも
のと取替える手続きを、動的ロードモジュールで提供す
る。（b）新しいプロセッサの事象検出部情報を現在使用中
のプロセッサの事象検出部に反映させるための手続き
を、動的ロードモジュールで提供する。尚、プロセッサの事象検出部を新しい内容に変更する手
続きは、(a)、(b)共にモジュール固有の管理ルーチン
(初期化処理時に実行)として提供する。両方法の採用基
準は、事象検出部が再配置可能であるか否かという点
と、新しい事象検出部を有効化する処理の複雑さを考慮
して決定する。

【００３７】以下に、本実施形態の詳細処理を図１０に
示す処理の流れに沿って説明する。ステップ５００は、
プロセッサの事象検出部を提供する動的ロードモジュー
ルを読み込む処理である。ここでは、実施の形態１に記
載のステップ１５０からステップ１５２までの処理を行
う。プロセッサアーキテクチャ固有のプロセッサの事象
検出部に変更を施す方法は、先述した（a）と（b）の２
通りがある。プロセッサの事象検出部が再配置可能な場
合は（a）の方法を用いる。例えば図１１に示す様にモ
ジュールの中にプロセッサの事象検出部を作成し、これ
を使用することでプロセッサの事象対処法を変更するこ
とができる。尚、図１１のプロセッサの事象発生時対処
法変更モジュール（５１０）は、プロセッサへの事象発
生に対する振舞を変更するモジュールの構成の１例を表
わしており、点線より上部はテキスト部、点線より下部
はデータ部である。プロセッサの事象検出部（５１１）
は、プロセッサへの事象発生時の振舞を規定する情報で
あるが、テキスト空間に配置される必要があるため、プ
ロセッサの事象検出部はプロセッサが実行可能な命令か
ら構成されている。プロセッサの事象検出部において、
事象種に対応したハンドラを呼び出す方法はプロセッサ
アーキテクチャ固有であるが、プロセッサの事象検出部
テキスト内で、生じた事象種に応じたオフセット位置に
ある命令が実行されるというプロセッサアーキテクチャ
の例を取り上げている。従って、事象種に応じたオフセ
ット位置にハンドラ呼び出し手段（５１２）命令を設定
しておく。別種のプロセッサアーキテクチャで、事象種
から導かれるオフセット位置にある情報が、ハンドラの
アドレスであると解釈するものでは、該当位置にハンド
ラのアドレスを設定しておく必要がある。また、ハンド
ラ呼び出し手段（５１２）では、ソフトウェア処理で破
壊されるプロセッサのレジスタの退避と生じた事象種の
特定を行なった後、実施の形態２に記載したハンドラの
実行方法と同様な方法によって所望のハンドラを呼び出
し可能にする。動的ロードモジュールが新しいハンドラ
呼び出し手段（５１２）を提供し、これを用いるように
すれば、ハンドラ呼び出しルールに変更することができ
たり、ハンドラ管理領域の情報解釈を変更することが可
能になる。ステップ５０１では、プロセッサの事象検出
部を新しい内容に変更する。これは管理ルーチン（５１
３）が、モジュールの初期化処理を目的として実行する
ものである。プロセッサの事象検出部が再配置可能なプ
ロセッサアーキテクチャでは（a）の方法を用いるが、
これはプロセッサの事象発生時対処法変更モジュール
（５１０）で提供したプロセッサの事象検出部（５１
１）を活性化する。例えば、プロセッサの制御レジスタ
に新しいプロセッサの事象検出部の先頭アドレスを設定
する。また、プロセッサの事象検出部を配置するアドレ
スがプロセッサアーキテクチャで固定的に規定されてい
て再配置できない場合には、（b）の方法を用いるが、
これは新しいハンドラ呼び出し手段の実行手続きを規定
された固定場所に埋めることで実現する。尚、本ステッ
プの処理では、プロセッサの事象発生時対処法変更モジ
ュール（５１０）をアンロードする時に元の情報を必要
に応じて復元できるように、前プロセッサの事象検出部
の情報（５１４）と前ソフトウェア定義の事象発生時の
対象法情報（５１５）を退避しておく。

【００３８】以上のように本実施形態によれば、ハンド
ラ管理領域で規定されているプロッセサの事象に対する
振舞いやハンドラの呼び出すルールを動的ロードモジュ
ールで定義、変更できるようにしたので、計算機システ
ムの機能拡張に対応しても柔軟に対応できるという効果
がある。

【００３９】実施の形態６．本実施形態について、図１
２に基づいて説明する。実施の形態１〜５は、何らかの
事象の発生が引金となるハンドラの実行を扱ってきた。
これに対して本実施形態では、ハンドラ管理機構外ソフ
トウェアが任意のタイミングでハンドラ管理機構下のハ
ンドラを実行する手続きを実現させる方法について説明
する。ハンドラ管理機構外ソフトウェアが、ハンドラ管
理機構下にあるハンドラを利用する方法には、以下の方
法がある。（a）関数呼び出し型関数呼び出しによる形態で、ハンドラを実行する。 (a1）ＯＳ層のプログラムがハンドラ管理機構下のハン
ドラを実行する手続きは、メンテナンス手段（３）経由
で実現する（３１）。 (a2) アプリケーション層のプログラムがハンドラ管理
機構下のハンドラを実行する手続きは、アプリケーショ
ンプログラミングインタフェース（８）を用いて、メン
テナンス手段（３）経由で実現する（８１）。（b) スレッド実行型ハンドラ管理機構下のハンドラをＯＳのマルチスレッド
処理におけるプロセッサのスケジューリング対象スレッ
ドとして起動しておき、メッセージ／セマフォ／シグナ
ル等のスレッド間通信機構を用いて、ハンドラ管理機構
外ソフトウェアと連携させる。スレッド間通信機構は他
の動的ロードモジュールによって実現されても構わな
い。 (b1) ＯＳ層のプログラムがスレッド間通信機構を用い
て、スレッド実行中のハンドラと連携する。（８３） (b2) アプリケーション層のプログラムがスレッド間通
信機構に関するアプリケーションプログラミングインタ
フェースを用いて、スレッド実行中のハンドラと連携す
る。（８２）以下に、ハンドラをソフトウェア処理と連携させる処理
の流れを図１２に基づいて説明する。ステップ５００か
らステップ６０３迄の処理は、ハンドラをハンドラ管理
機構外ソフトウェアから利用するための準備処理であ
る。ステップ５００では、モジュールを動的にロードす
る。ここでは、実施の形態１に記載の処理のステップ１
５０からステップ１５２までの処理を行う。ステップ６
０１からステップ６０３では、モジュール内の管理ルー
チン実行による初期化処理を表している。ステップ６０
１では、ハンドラ管理機構外ソフトウェアと連携させる
方法が、スレッド実行型か関数呼び出し型かで区別して
いる。スレッド実行型の場合はステップ６０２の処理へ
移り、関数呼び出し型の場合はそのまま終了する。ステ
ップ６０２では、ハンドラをプロセッサのスケジューリ
ング対象になるスレッドとして起動して、システムに常
駐させる。ステップ６０３では、ハンドラをスレッドと
して起動した親スレッドの処理を終了し、起動されたス
レッド（ハンドラ）はＡの処理へ移る。ステップ６０４
からステップ６０６迄の処理は、スレッド実行型の場合
の処理を表わしている。スレッドとして実行中のハンド
ラは無限ループ処理で、ハンドラ固有の処理をステップ
６０６で実行する。ステップ６０４では、処理を進める
ことを許可する指令（イベント発生）待ちである。アプ
リケーションプログラムとの連携は、メッセージ／セマ
フォ／シグナル等のスレッド間通信機構を用いて行う。
ステップ６０５では、同期処理で伝えられた指令が終了
であるかどうかをチェックし、終了でない場合にはステ
ップ６０６の処理へ移る。ステップ６０６では、ハンド
ラ固有の処理を行う。ハンドラ固有の処理を終了後、ス
テップ６０４へ戻り、イベント発生待ちとなる。ステッ
プ６１０からステップ６１７は、スレッド実行型での利
用手続きと関数呼び出し型での利用時の流れである。ス
レッド実行型では他スレッドとしてシステムに常駐して
いるハンドラに指令をスレッド間通信機能で送り、関数
呼び出し型ではソフトウェア呼び出しの延長でハンドラ
を実行する。ステップ６１０では、ハンドラを呼び出そ
うとするソフトウェアが、ＯＳかアプリケーションプロ
グラムであるかを判別している。アプリケーションプロ
グラムが使用する場合はステップ６１１へ移り、ＯＳが
使用する場合はステップ６１２へ移る。ステップ６１１
では、アプリケーションプログラムがハンドラを呼び出
すために、アプリケーションプリグラムインタフェース
（８）を用いる処理を表している。ステップ６１２で
は、ハンドラをソフトウェア処理と連携させる実現方法
が、スレッド実行型か関数呼び出し型かで処理を変えて
いる。これは、呼び出しプログラムが用いたインタフェ
ース種に基づいて判断する。関数呼び出し型ではステッ
プ６１３へ移り、スレッド実行型ではステップ６１８へ
移る。ステップ６１３は、メンテナンス手段（３）の処
理で、ハンドラ管理機構下のハンドラを利用するにあた
って、ハンドラ実行の旨、ハンドラが含まれるモジュー
ルの識別子、モジュール内でのハンドラの登録番号、
ハンドラ実行時の引数を解釈し、ハンドラ呼び出し手段
を実行する（３４）。モジュール内でのハンドラの登録
番号は、ハンドラ管理領域に登録された順番を適用する
が、０番は管理ルーチンに割り振り、次の１番から昇順
の番号を用いる。ステップ６１４では、ハンドラ呼び出
し手段が目的のハンドラを検索する処理を表している。
ステップ６１５では、ユーザが実行を指定したハンドラ
が見つかったかどうかで処理を変えている。ハンドラが
見つかった場合はステップ６１６へ、ハンドラが見つか
らなかった場合はステップ６１７の処理に移る。ステッ
プ６１６では、ハンドラを実行してハンドラ固有の処理
を行う。ステップ６１７では、呼び出しプログラムに戻
る。ＯＳが呼び出していた場合はＯＳの呼び出し手続き
後へ、アプリケーションが呼び出していた場合にはアプ
リケーションが使用したアプリケーションプログラミン
グインタフェースに戻る。ステップ６１８では、プロセ
ッサのスケジューリング対象のスレッドとして常駐して
いるハンドラに、スレッド間通信機構を用いて動作指示
を送る。

【００４０】以上のように本実施形態によれば、ソフト
ウェア呼び出しによりＯＳ上のアプリケーションプログ
ラムからコールできるようにしたので、ハンドラの実行
手続きを事象の発生を待つことなく任意のタミングによ
って起動することができるという効果がある。また、ア
プリケーションプログラムとハンドラ提供機能の連携処
理が可能となるため、一層きめの細かい処理を実現でき
るという効果がある。

【００４１】実施の形態７.次に本発明の第７の実施形
態について、図１３に基づいて説明する。計算機システ
ムの挙動を把握するうえで、計算機システム内で生じた
事象をトレースすることは有効である。本実施形態で
は、事象トレースを行う機能をハンドラとして実現さ
せ、事象トレース機能をモジュール独立させることを可
能にしている。事象トレースを行うハンドラは、実施の
形態１に記載の方法でハンドラ管理機構下に組み込み、
実施の形態２及び３記載の方法によって所望の事象が生
じた時に実行するようにする。

【００４２】以下に、本実施の形態の詳細処理を図１３
について説明する。ステップ５００からステップ７０２
では、ＯＳの動的再構成時に実行する初期化処理を表し
ている。ステップ５００では、事象トレース機能を実現
するモジュールを動的にロードする。ここでは、実施の
形態１に記載の処理の、ステップ１５０からステップ１
５２までの処理を行う。ステップ７０１とステップ７０
２は、モジュールロード直後に、モジュール内の管理ル
ーチンで行うべき処理である。ステップ７０１では、ト
レースデータを記録する領域を確保する。トレースデー
タの記録は、事象発生時に行うが、この処理は短時間で
終了し、かつ待ちが生じてはいけない。このために、ト
レースデータをメモリに記録するが、この時にメモリを
リングバッファ形式で用いる等の記録方法を採用する。
記録したトレースデータの参照は、記録処理とは別タイ
ミングで行うが、参照にあたってトレースデータが上書
きされて失われないようにトレース領域のサイズと参照
頻度を考慮する。尚、トレースデータ書き込み領域は、
動的ロードモジュールのデータ領域を用いても良い。ス
テップ７０２では、確保した事象トレースデータ記録領
域の初期化を行う。例えば、事象トレースデータ記録領
域に、事象発生時刻とイベント種別を記録するだけで
も、記録場所と記録領域のサイズを意識しなければなら
い。本実施の形態では、記録場所と記録領域のサイズ等
の管理データを設定する。ステップ７１０では、トレー
スを行う事象種の設定処理を行う。例えば、事象トレー
スハンドラの呼び出しをハンドラ管理領域内のフラグに
よって抑止すれば、事象トレース機能を抑止することが
できる。また、ハンドラ管理領域内のフラグで呼び出し
ルールを示した上で事象識別子を注目する事象種を示す
様にすることで、選択的に事象トレースハンドラを実行
することが可能になるので、注目する事象のトレースデ
ータのみを生成することが可能になる。本実施の形態で
は、トレースを制御するフラグ及び事象識別子の変更を
事象トレース機能モジュールに含める管理ルーチンの実
行で可能とし、この管理ルーチンを実施の形態６による
方法でハンドラ管理機構外部のソフトウェアから実行す
ることで、トレースを行う事象種を変更可能にしてい
る。ステップ７２０からステップ７２２では、事象をト
レースするハンドラの処理である。ステップ７２０で
は、生じた事象が事象トレースハンドラを呼び出すべき
事象かどうか判断している。事象をトレースするハンド
ラの呼び出しは、実施の形態３で記載した方法のハンド
ラ管理領域内のフラグと事象識別子を事象解析後の事象
種情報と照らし合わせることで、選択的なハンドラ実行
手続きを用いている。例えば、フラグでルールを示した
場合で、数値化された事象種が大きさによって意味付け
したものであれば、一定数値を境にハンドラを呼び出す
ようにする。或いは、数値化した事象種値に２進値表現
で意味付けした情報があれば、論理積や排他的論理和の
真偽結果でハンドラを呼び出すようにする。ステップ７
２０では、事象トレースデータ記録領域内の書き込み場
所を取得する。ステップ７２１では、事象データを書き
込む。例えば、データ長、時間、事象種を書き込む。ス
テップ７２２では、次回のトレースデータ書き込み場所
を示す情報を設定する。

【００４３】以上のように本実施形態によれば、事象発
生時に、本来のハンドラの他に事象トレースハンドラを
呼び出すことができ、本来のハンドラのコード内に事象
トレース機能を有したコードを埋め込む必要がないの
で、両ハンドラ（両モジュール）の作成が別々に行なえ
る。また、計算機システム内で生じた事象をロギングす
ることができるので、このログから計算機システムの運
転状況を把握することが可能になる。また、計算機シス
テムで生じた事象を収集する手段をハンドラ形式で実現
させるようにしたので、事象収集機能実現コードをＯＳ
コード内に分散させることなく、まとめて１モジュール
で実現できるという効果がある。また、事象収集機能実
現コードの拡張を容易に行えるという効果がある。

【００４４】実施の形態８.次に本発明の第８の実施形
態について、図１４に基づいて説明する。本実施の形態
は、計算機システムの運転制御機能をモジュール独立さ
せて実現させ、別モジュールで実現している事象トレー
ス機能と協調して計算機システムの運転制御を行うこと
を可能としたものである。計算機システムの状態把握機
能は、動的ロードモジュールで拡張するＯＳレイヤで実
現しても良く、また通常にロードして実行するアプリケ
ーションプログラムレイヤで実現しても構わない。計算
機システムの運転形態変更機能は、変更指示自体は両レ
イヤにおけるプログラムで発行できるが、運転形態変更
処理内容がＯＳによって保護されるものでは、処理内容
を例えばハンドラとして実現してハンドラ管理機構下に
登録する形態で行う必要がある。

【００４５】以下に、本実施形態における計算機システ
ムの状態把握機能の詳細処理について図１４に示した処
理の流れに沿って説明する。ステップ８００では、新た
に書き込まれた事象トレースデータが存在するかどうか
をチェックし、存在すればその情報に基づいて計算機シ
ステムの状態把握を行う。例えば、ある種の例外処理が
頻繁に発生していたり、ある機能が正常に動作していな
い等の情報から不具合箇所を知る。事象トレースデータ
の取得方法については説明を省略するが、機能モジュー
ル間でアクセスが可能な領域にトレースデータが存在す
る場合には直接参照すれば良いし、事象トレース機能モ
ジュールがトレースデータを提供するインタフェースを
提供していればそれを用いれば良い。ステップ８０１で
は、ステップ８００で把握した状況が何らかのアクショ
ンが必要かどうかを判断する。アクションが必要な場合
はステップ８０２へ移り、そうでない場合はステップ８
０３へ移る。ステップ８０２では、前ステップで把握し
た状況に応じて計算機システムの運転形態を制御する。
例えば、実施の形態３記載の手法を用いてハンドラ実行
を抑制したり、実施の形態６記載の手法を用いて回復処
理を行うハンドラや運転形態を変更するハンドラを実行
する。更に、機能モジュールを入れ替えたり、機能しな
いモジュールを取り外して縮退運転することを目的に、
ＯＳを動的再構成する等の処置を行う。ステップ８０３
では、処理を終了するかどうかをチェックする。例え
ば、ステップ８００の処理で他に事象トレースデータが
存在していた場合、処理を継続するためにステップ８０
０へ戻る。

【００４６】本実施形態によれば、事象データの収集、
および収集情報に基づく計算機システムの状態把握をハ
ンドラとして実現し、計算機システムの運転制御プログ
ラムをハンドラ管理機構外からソフトウエア呼び出しす
るようにしたので、計算機の運転形態を容易に制御する
ことができるという効果がある。また、事象データの収
集、および収集情報に基づく計算機システムの状態把握
をハンドラとして実現し、計算機システムの状態結果に
基づいてハンドラの実行/不実行を動的に制御するよう
にしたので、計算機の運転形態を容易に制御することが
できるという効果がある。

【００４７】実施の形態９.次に本発明の第９の実施形
態について、図１５に基づいて説明する。本実施の形態
では、ＯＳに組み込まれているモジュールをアンロード
してＯＳを再構成する際に、ＯＳの機能変更とアンロー
ドするモジュールに含まれるハンドラをハンドラ管理機
構から取り外す手順について説明する。アンロード処理
では、まず、メンテナンス手段（３）がアンロードする
モジュールに含まれる管理ルーチンを後処理モードで実
行する。その後、モジュール管理手段（５）が対象モジ
ュールのデータ部の動的ロードモジュール管理領域（１
０２）をハンドラ管理機構のリンク管理下から外す。最
後に、アンロード手段（７）が、マッピングしていた動
的ロードモジュール（２）をアンマップする。

【００４８】以下に、本実施形態の詳細処理について、
図１５を用いて説明する。ステップ９００では、モジュ
ール毎に登録されている管理ルーチンを後処理モード
(引数で区別：例えばー１)で実行する。管理ルーチンの
アドレスは、ハンドラ管理領域内の管理ルーチンのアド
レス（１１７）（モジュール先頭からの相対アドレス）
とテキスト部のアドレス（１１６）を用いて求める。こ
こで行う後処理では、本モジュールに関係する機能を使
用しているタスクやスレッドに中断情報を渡したり、本
モジュールが操作した資源を本モジュールが組み込まれ
る前の状態に戻したり、本モジュールが操作した資源を
システム規定の初期状態に戻す処理を行う。ステップ９
０１では、モジュール管理手段（５）が、ハンドラの管
理機構におけるハンドラ管理領域のリンク管理からアン
ロードするモジュールのハンドラ管理領域を取り外すこ
とによって、システムに登録されているハンドラを無効
化する。この時、前後のハンドラ管理領域のリンク関係
を正しく保たせる。ステップ９０２では、マッピングさ
れているモジュールのテキストとデータをアンマップす
る。

【００４９】本実施形態によれば、動的ロードモジュー
ルの取り外し時にモジュール固有の後処理の実施とハン
ドラの取り外しを行うようにしたので、モジュール取り
外し処理による機能変更を容易、かつ安全に行えるとい
う効果がある。

【発明の効果】この発明は、以上説明したようにして構
成されているので、以下に記載されるような効果が得ら
れる。

【００５０】第１の発明によれば、ハンドラ管理機構が
ＯＳ基本構成部内に定義されたハンドラ及び動的モジュ
ールとして構成されたハンドラを管理するハンドラ管理
領域を用いて動的ロードモジュールの組み込みを行うよ
うにしたので、ハンドラ管理領域のみの変更により、モ
ジュール組み込み、および機能変更を容易に行えるとい
う効果がある。

【００５１】第２の発明によれば、ハンドラ管理領域に
事象識別子を備えるようにし、１つの事象に対して複数
のハンドラを管理できるようにしたので、ある事象に対
して機能分割して構成された複数のハンドラを実行させ
ることが可能になる。

【００５２】第３の発明によれば、ハンドラ管理領域に
事象識別子に加えてフラグを備えるようにしたので、ハ
ンドラの呼び出し制御が可能となり、計算機システムの
運転状況に対応してハンドラを呼び出すことができる。

【００５３】第４の発明によれば、ハンドラ管理領域に
ハンドラ管理領域のリンク情報を備え、１つの事象に対
して複数のハンドラを優先順位に従って呼び出すように
したので、順序性が求められる処理に対しても適切な対
応ができるという効果がある。

【００５４】第５の発明によれば、プロッセサの事象に
対する振舞いや事象発生後にハンドラを呼び出すルール
を動的ロードモジュールで定義、変更できるようにした
ので、計算機システムの機能拡張に対応して柔軟に対応
できるという効果がある。

【００５５】第６の発明によれば、ハンドラの実行手続
きをソフトウェア呼び出しによりコールできるようにし
たので、事象の発生を待つことなくＯＳ上のソフトウェ
アから任意のタイミングでハンドラを利用することがで
きるという効果がある。

【００５６】第７の発明によれば、計算機システムで生
じた事象を収集する手段をハンドラ形式で実現させるよ
うにしたので、事象収集機能実現コードをＯＳコード内
に分散させることなく、まとめて１モジュールで実現で
きるという効果がある。また、事象収集機能実現コード
の拡張を容易に行えるという効果がある。

【００５７】第８の発明によれば、事象データの収集、
および収集情報に基づく計算機システムの状態把握をハ
ンドラとして実現し、計算機システムの運転制御プログ
ラムをハンドラ管理機構外からソフトウエア呼び出しす
るようにしたので、計算機の運転形態を容易に制御する
ことができるという効果がある。

【００５８】第９の発明によれば、事象データの収集、
および収集情報に基づく計算機システムの状態把握をハ
ンドラとして実現し、計算機システムの状態結果に基づ
いてハンドラの実行/不実行を動的に制御するようにし
たので、計算機の運転形態を容易に制御することができ
るという効果がある。

【００５９】第１０の発明によれば、動的ロードモジュ
ールの取り外し時にモジュール固有の後処理の実施とハ
ンドラの取り外しを行うようにしたので、モジュール取
り外し処理による機能変更が容易に行えるという効果が
ある。

【図面の簡単な説明】

【図１】本発明の第１の実施形態におけるシステム構
成を示す図である。

【図２】本発明の第１の実施形態におけるハンドラ管
理領域のデータ構造と使用形態を示す図である。

【図３】本発明の第１の実施形態におけるＯＳ基本構
成部の管理領域のメンバ設定を示す図である。

【図４】本発明の第１の実施形態における動的ロード
モジュールのハンドラ管理領域のメンバ設定を示す図で
ある。

【図５】本発明の第１の実施形態における動的ロード
モジュールのロード手順を示す図である。

【図６】本発明の第２の実施形態におけるシステム構
成を示す図である。

【図７】本発明の第２の実施形態におけるハンドラの
実行手順を示す図である。

【図８】本発明の第３の実施形態におけるハンドラの
選択的実行手順を示す図である。

【図９】本発明の第４の実施形態におけるハンドラの
実行順序を変更する手順を示す図である。

【図１０】本発明の第５の実施形態におけるプロセッ
サへの事象発生に対する振舞を変更する手順を示す図で
ある。

【図１１】本発明の第５の実施形態におけるプロセッ
サ処理の振舞を変更するモジュールの構成を示す図であ
る。

【図１２】本発明の第６の実施形態における動的ロー
ドモジュールで確証されるプログラムを他ソフトウェア
処理と連携させる手順を示す図である。

【図１３】本発明の第７の実施形態における事象トレ
ースを行う手順を示す図である。

【図１４】本発明の第８の実施形態における運転制御
手順を示す図である。

【図１５】本発明の第９の実施形態におけるモジュー
ルのアンロード手順を示す図である。

【図１６】従来の機能拡張方式を示す図である。

【符号の説明】

１ＯＳ基本構成部、２動的ロードモジュール、３
メンテナンス手段、４ロード手段、５モジュール管理
手段、６ハンドラ呼び出し手段、７アンロード手
段、、８アプリケーションプログラミングインタフェ
ース、９アプリケーションプログラム、１０モジュ
ール作成手段、１０１ＯＳ基本構成部内のハンドラ管
理領域、１０２動的ロードモジュール管理領域、１０
３バージョン情報、１０４モジュール識別子、１０
５管理ルーチンのアドレス、１０６フラグ、１０７
事象識別子、１０８ハンドラのアドレス、１０９
ハンドラ管理領域終端子、１１０動的ロードモジュー
ル内のハンドラ管理領域１１１次のモジュール内のハンドラ管理領域、１１２
前のモジュール内のハンドラ管理領域、１１３バー
ジョン情報、１１４モジュール識別子、１１５リンク
の優先順位、１１６テキスト部のアドレス、１１７
管理ルーチンのアドレス、１１８フラグ、１１９事
象識別子、１２０動的ロードモジュール内のハンドラ
のアドレス、１２１ハンドラ管理領域終端子、１３０
動的ロードモジュールの終端子。

Claims

【特許請求の範囲】

【請求項１】オペレーティングシステム(以下、ＯＳ
という)基本構成部内に定義された事象処理モジュール
(以下、ハンドラという)を管理する第１のハンドラ管理
領域と、動的ロードモジュールとして構成されたハンド
ラを管理する第２のハンドラ管理領域を有するハンドラ
管理機構を備え、前記ハンドラ管理機構はモジュールのロード処理におい
て、動的ロードモジュールを主記憶上へロードし、該ロードモジュールに対応したハンドラ管理領域を前記
ハンドラ管理機構下に組み込むと共に、該ロードモジュールのハンドラ管理領域内に定義されて
いるモジュール固有の初期化処理を実行することによっ
て、以降、該ロードモジュールの呼び出しを可能とする
ようにしたことを特徴とするＯＳの動的機能管理方法。
【請求項２】前記ハンドラ管理領域は各ハンドラ対応
に該ハンドラを管理する事象識別子を備え、前記ハンドラ管理機構は計算機システムに事象が発生し
た際にハンドラ管理領域で管理されているハンドラを順
次検索して事象に対応するハンドラを実行するようにし
たことを特徴とする請求項１記載のＯＳの動的機能管理
方法。
【請求項３】前記ハンドラ管理領域は各ハンドラ対応
に該ハンドラを管理するフラグと事象識別子を備え、前記ハンドラ管理機構は計算機システムに事象が発生し
た際に前記フラグおよび事象識別子情報に基づいてハン
ドラ管理領域で管理されているハンドラの実行/不実行
を動的に行うようにしたことを特徴とする請求項１記載
のＯＳの動的機能管理方法。
【請求項４】前記ハンドラ管理領域は該ハンドラ管理
領域のリンク順序入れ替えのためのリンク優先順位情報
を備え、前記ハンドラ管理機構は該リンク優先順位情報に基づい
てハンドラの実行順序を制御するようにしたことを特徴
とする請求項１記載のＯＳの動的機能管理方法。
【請求項５】プロセッサのアーキテクチャで定義され
た事象に対する記述および事象に対する振舞いを前記動
的ロードモジュールにて規定し、該動的ロードモジュールを起動することでハンドラ管理
機構内の事象検出に関する情報を変更し、事象発生時におけるハンドラの切り替えを行うようにし
たことを特徴とする請求項１記載のＯＳの動的機能管理
方法。
【請求項６】前記ハンドラ管理機構は該ハンドラ管理
機構外に備えられたソフトウェアからの呼び出し手段を
備え、ハンドラ管理機構で管理されているハンドラをハンドラ
管理機構外からソフトウェア呼び出しするようにしたこ
とを特徴とする請求項１記載のＯＳの動的機能管理方
法。
【請求項７】事象トレースを実行する機能をハンドラ
として実現し、計算機システムで発生した事象の収集を
行うようにしたことを特徴とする請求項１記載のＯＳの
動的機能管理方法。
【請求項８】事象トレースを実行する機能、および計
算機システムの状態制御を実行するための機能をハンド
ラとして実現し、前記事象トレース実行ハンドラで生成した事象トレース
情報に基づいて計算機システムの状態を把握し、前記計算機システム状態制御ハンドラをハンドラ管理機
構外に備えられたソフトウェアからソフトウェア呼び出
しすることにより計算機システムの状態制御を行うよう
にしたことを特徴とする請求項１記載のＯＳの動的機能
管理方法。
【請求項９】事象トレースを実行する機能、および計
算機システムの状態制御を実行するための機能を各々ハ
ンドラとして実現し、前記事象トレース実行ハンドラで生成した事象トレース
情報に基づいて計算機システムの状態を把握し、前記ハンドラ管理機構は事象トレース結果に基づいて前
記フラグおよび事象識別子情報を用いてハンドラ管理領
域で管理されているハンドラの実行/不実行を動的に行
うようにしたことを特徴とする請求項１記載のＯＳの動
的機能管理方法。
【請求項１０】ＯＳの動的構成変更を目的として動的
モジュールをアンロードする時に、該当モジュール内に
定義されているモジュール固有の後処理を実行すると共
に、前記ハンドラ管理機構から該モジュールを取り外す
ことによって機能変更を行うようにしたことを特徴とす
る請求項１記載のＯＳの動的機能管理方法。