JP2000267869A - リソース異常制御方法、リソース異常制御装置、コンピュータシステムおよび記録媒体 - Google Patents

Abstract

(57)【要約】 【課題】 コンピュータシステムに搭載されるソフトウ
ェアにおいて、リソースの管理および異常制御に関する
処理を集約化したリソース異常制御方法、リソース異常
制御装置、コンピュータシステムおよび記録媒体を提供
する。 【解決手段】 リソース管理プログラム２３とリソース
異常制御プログラム２４とを設け、各アプリケーション
からのリソース確保の要請に対してはリソース確保処理
部２３ｄでリソースの確保を行い、各アプリケーション
からのリソース異常に関する問い合わせに対しては、リ
ソース異常制御部２４においてリソース状態テーブル２
４ａに記憶された情報を当該アプリケーション側に提供
する。これにより、処理の冒頭で１回だけリソース異常
制御プログラムに対して問い合わせを行うことでリソー
ス異常の場合には異常処理に移行することができ、各ア
プリケーションの開発においてリソース異常に関する判
定を行う部分を盛り込む必要がなくなる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、コンピュータシス
テムにおいて使用されるリソースに異常が発生した場
合、このリソース異常に対する制御を行うリソース異常
制御方法、リソース異常制御装置、コンピュータシステ
ムおよび記憶媒体に関する。

【０００２】

【従来の技術】図６は、コンピュータシステムに搭載さ
れるソフトウェアの一例として、従来の交換機ソフトウ
ェアの構成を示したものである。同図に示すように、交
換機ソフトウェアは、システム全体を統括・制御する基
本プログラムであるＯＳ１Ａと、ＯＳ以外のソフトウェ
アであって交換処理に纏わる種々の動作を機能分担して
実行するアプリケーション２Ａとに大別される。アプリ
ケーション２Ａは、交換機において通信処理時の実動作
を制御する呼処理プログラム２０Ａと、呼処理を行うた
めの事前データの設定、解除、表示、通信に関する状態
情報を表示する保守運用プログラム２１Ａと、交換機の
システム状態を制御するシステム管理プログラム２２Ａ
とから構成される。

【０００３】これらのアプリケーションプログラムは、
各処理の実行開始時に必要なリソース（一般に、交換シ
ステムでは、トランク、トランザクション等、呼処理で
特定の呼や接続に占有されることなく共通に使用される
装置、メモリ類を総称してリソースと呼ぶ）を確保し
て、所定の処理を実行する。このリソースの確保および
リソース異常が発生しているか否かの判定、リソース異
常時の対応処理（異常処理という）等、リソースに関す
る処理は、各アプリケーションプログラム毎に別個に行
われるとともに、各プログラムの至る箇所で行われてい
た。

【０００４】このような状況を図７に示す具体例で説明
する。同図は、利用者が電話をかける際に受話器を上げ
ることによって、発呼信号が送信され、ダイヤルトーン
（発信音）が受話器から聞こえるまでの呼処理プログラ
ム２０Ａの動作シーケンスを示すフローチャートであ
る。まず、利用者が受話器を上げる（Ｓ１００）と、割
り込みが発生する（Ｓ１０１）。そして、タスクが生成
されているかどうかが判断される（Ｓ１０２）。例え
ば、交換機の収容人数（同時に電話交換を受け付けるこ
とができる利用者数）が１００００人であるものとする
と、本利用者が１０００１人目の利用者である場合、リ
ソース不足となりタスクを生成することができず（Ｓ１
０２；ＮＯ）、異常処理に移行する（Ｓ１０３）。一
方、タスクが生成されている場合（Ｓ１０２；ＹＥＳ）
には、そのタスクが取得される（Ｓ１０４）。

【０００５】次に、交換機のＣＰＵに対する輻輳（ＣＰ
Ｕ輻輳という）が発生しているか否かが判断される（Ｓ
１０５）。ＣＰＵ輻輳が発生していると判断される（Ｓ
１０５；ＹＥＳ）と異常処理に移行する（Ｓ１０６）。
一方、ＣＰＵ輻輳が発生していないと判断される（Ｓ１
０５；ＮＯ）と、ダイヤルトーンを利用者側に送るため
のハードウェア資源（ＤＴハードという）に空きがある
か否かが判断される（Ｓ１０７）。ＤＴハードに空きが
ないと判断される（Ｓ１０７；ＮＯ）と、異常処理に移
行する（Ｓ１０８）。一方、ＤＴハードに空きがあると
判断される（Ｓ１０７；ＹＥＳ）と、リソース管理部２
３においてＤＴハードが確保（リソースが設定）される
（Ｓ１０９）。

【０００６】次に、通話路スイッチ（ＳＷハードとい
う）に故障が発生しているか否かが判断される（Ｓ１１
０）。このハード故障が検出されると（Ｓ１１０；ＹＥ
Ｓ）、異常処理に移行する（Ｓ１１１）。ハード故障が
検出されなければ（Ｓ１１０；ＮＯ）、ＳＷハードへの
パスが設定されることでリソースが確保され（Ｓ１１
２）、一連のタスクが終了する（Ｓ１１３）。

【０００７】

【発明が解決しようとする課題】このように、交換機の
アプリケーションでは、通常、各処理を実行していく過
程においてリソースが必要となった時点で当該リソース
が確保される。そして、上述のアプリケーションの分類
においては、各アプリケーションで使用されるリソース
を管理する機構が独立して設けられる場合もあったが、
リソース異常に対応するためのリソース管理は行われて
おらず、また、各アプリケーション間で連携したリソー
スの管理も実行されていなかった。

【０００８】したがって、交換機ソフトウェアを開発す
る際には、次のような問題点があった。まず、各アプリ
ケーションにおいてリソースを確保する処理毎にリソー
ス異常時の対応処理を組み込んでいく形態が採用されて
いたため、異常処理に関するモジュールの開発量が膨大
なものとなっていた。一般に、交換機ソフトウェアの開
発においては、まず、正常な処理ロジックについて検討
し、設計を進める方法が採用される。一方、異常ルート
の検討は、この正常なロジックの検討がほぼ終了してか
ら開始される。そして、この正常なロジックが決まった
時点で開発スタッフを増員して詳細な検討に入り、異常
ルートの検討は開発するグループ内で閉じて行われる。
したがって、異常な事象が起こる可能性がある場合、そ
れぞれのルートに異常処理を組みんでいく開発スタイル
となっていた。

【０００９】通常、交換機ソフトウェアではメインルー
トに比べて、このメインルートから分岐する分岐ルート
の数は莫大なものとなる。したがって、この分岐ルート
に異常処理に関するモジュールを盛り込む場合、ソース
プログラムのサイズが飛躍的に増大してコーディング量
が増えるとともに、バグの潜む可能性が高くなり、しか
もそのバグの発見が大変である。このため、全体として
開発工数が嵩む結果となっていた。また、コーディング
されたプログラムは別途実機レベルでの試験を実施する
必要があり、この試験では特異な状況や故障の場合でも
試験対象とされ、試験項目数および試験稼働の増大につ
ながっていた。

【００１０】そこで、本発明はこのような課題に着目し
てなされたもので、コンピュータシステムにおいて使用
されるリソースの管理および異常制御に関する処理を集
約化したリソース異常制御方法、リソース異常制御装
置、コンピュータシステムおよび記録媒体を提供するこ
とを目的とするものである。

【００１１】

【課題を解決するための手段】上記目的を達成するため
に、第１発明のリソース異常制御方法は、コンピュータ
システムにおいて使用される種々のリソースの異常に対
する制御を行うリソース異常制御方法において、リソー
スに対する異常が発生していると判定された場合、その
旨を記憶するリソース異常記憶過程と、前記いずれか複
数のリソースに対する複数の識別情報を伴って、該リソ
ースの異常状態を問い合わせる過程と、この問い合わせ
に応答して、前記リソース異常記憶過程で記憶され、か
つ、前記識別情報に対応する情報を提供するリソース異
常情報提供過程とを有することを特徴とするものであ
る。

【００１２】第２発明のリソース異常制御方法は、上記
第１発明のリソース異常制御方法において、前記リソー
スの状態を示すリソース情報を取得する過程と、取得し
たリソース情報を分析して、前記リソースに対する異常
が発生しているか否かを判定するリソース情報分析過程
とを有することを特徴とするものである。

【００１３】第３発明のリソース異常制御方法は、上記
第２発明のリソース異常制御方法において、所定の処理
を実行するアプリケーションからの要請に基づいてリソ
ースが確保された場合、該アプリケーションによって実
行されるプロセスに対する識別子と、確保されたリソー
スの種別とを対応付けて記憶するリソース管理過程と、
前記リソース情報分析過程でリソースに対する異常が発
生していると判定された場合、前記リソース管理過程に
おいて記憶された情報に基づいて該リソースを使用して
いるプロセスを抽出し、抽出されたプロセスに対して該
リソースの異常を回避するための指示を与えるリソース
正常化処理過程とを有することを特徴とするものであ
る。

【００１４】第４発明のリソース異常制御方法は、上記
第３発明のリソース異常制御方法において、前記リソー
ス正常化処理過程では、リソース異常と判定されたリソ
ースを使用しているプロセスに対して初期化の指示を与
えることを特徴とするものである。

【００１５】第５発明のリソース異常制御装置は、上記
第１〜第４発明のいずれかのリソース異常制御方法を実
行することを特徴とするものである。第６発明のコンピ
ュータシステムは、上記第５発明のリソース異常制御装
置を含むことを特徴とするものである。第７発明の記録
媒体は、上記第１〜第４のいずれかに記載のリソース異
常制御方法を実行するプログラムを記録したものであ
る。なお、このプログラムをＦＤ、ＣＤ−ＲＯＭ、テー
プメディア、ＤＶＤ−ＲＡＭ等の記録媒体に格納して頒
布する（ネットワーク経由でこのプログラムを配信した
り、ダウンロードする行為も含む）ことによっても本発
明を実施することができる。

【００１６】

【発明の実施の形態】この発明の好ましい実施の形態に
ついて、以下、添付図面を参照しつつ詳細に説明する。 １．実施形態の構成 １．１．ソフトウェア構成 図１は、本実施形態に係る交換機のソフトウェア構成を
示す図である。同図に示すように、本交換機に搭載され
るソフトウェアは、既述の図６に示す交換機ソフトウェ
アと同様、ＯＳ１Ｂと、呼処理プログラム２０Ｂ、保守
運用プログラム２１Ｂ、システム管理プログラム２２Ｂ
とを含むアプリケーション２Ｂとから構成される。

【００１７】さらに、アプリケーション２Ｂは、交換機
内で使用されるリソース情報（ハードウェア設備数、ハ
ードウェアの状態情報、論理情報の設備数、状態情報）
の管理を行うリソース管理プログラム２３と、このリソ
ース管理プログラム２３、またはＯＳ１Ｂの内部で管理
されるリソースの異常発生時および回復時に通知される
情報を分析・制御するリソース異常制御プログラム２４
とを備える。

【００１８】このように、従来、交換機ソフトウェアに
おいて、呼処理プログラム２０Ｂ、保守運用プログラム
２１Ｂ、システム管理プログラム２２Ｂで個別に管理さ
れていたリソース情報がリソース管理プログラム２３に
括り出され、当該プログラムにリソース情報を管理する
機構が集約化されている。そして、このリソース管理プ
ログラム２３において異常が検出された場合、リソース
異常制御プログラム２４にその旨が通知される。このリ
ソース異常制御プログラム２４は、後述するように、リ
ソース管理プログラム２３およびＯＳ１Ｂから通知され
たリソース情報を、ハードウェア関連、ＯＳ関連、アプ
リケーション関連といったように関連するリソース群に
まとめて保持する。

【００１９】１．２．ハードウェア構成 図２は、本実施形態に係る交換機の主要部のハードウェ
ア構成を示す図である。同図に示すように、本実施形態
の交換機は、システム全体を統括・制御して各プログラ
ムに実行指令を与えるＣＰＵ１００ａ、プログラムが展
開されるＲＡＭ１００ｂ、所定の制御プログラム等が格
納されたＲＯＭ１００ｃ、所定のデータおよびプログラ
ムが格納されたＨＤＤ（ハードディスク装置）１００ｄ
を含む中央処理系装置１００と、時分割通話路装置や中
継者線信号接続装置等を含む通話路系装置１０１と、加
入者線インタフェース装置等を含む加入者系装置１０２
と、サービストランク装置、課金情報受信装置等を含む
付帯系装置１０３とを備えて構成され、これらの装置が
バス１０４を介して相互に接続されている。

【００２０】上述の各アプリケーションプログラムは、
ＲＡＭ１００ｂに展開され常時記憶・保持されており、
ＣＰＵ１００ａの指令に基づいて各プログラムに記述さ
れた種々のルーチンが実行される。また、本交換機で
は、リソース異常が検出された場合でも、ＣＰＵ１００
ａから通話路系装置１０１、加入者系装置１０２、付帯
系装置１０３に向けた指令により、交換動作への障害を
最小限に抑える処理が可能なフォールトトレラントシス
テム（fault tolerant system）が採用されている。

【００２１】１．３．リソース管理およびリソース異常
制御プログラムのモジュール構成 図３は、リソース管理プログラム２３、およびリソース
異常制御プログラム２４のモジュール構成を模式化して
表現したものである。まず、リソース管理プログラム２
３はそのモジュール構成において、リソース情報を取得
してリソース異常分析部２３ｂに供給するリソース状態
情報取得部２３ａと、与えられたリソース情報に基づき
リソース異常が発生しているか否かの分析を行うリソー
ス異常分析部２３ｂと、リソースの異常が検出された場
合、そのリソースを正常な状態に戻す処理を行うリソー
ス正常化処理部２３ｃと、アプリケーション２Ｂ（図３
においては、図１の場合と異なり、リソース管理プログ
ラム２３およびリソース異常制御プログラム２４を除
く）からの要請に基づきリソースの確保処理を行い、当
該アプリケーションに対してリソースが確保できたかど
うかを通知するリソース確保処理部２３ｄと、確保され
たリソースの種別とそのリソースを使用するプロセスの
ＩＤが記録されたリソース管理リスト２３ｅとを備え
る。

【００２２】一方、リソース異常制御プログラム２４
は、ハードウェア状態情報、ＯＳリソース状態情報、ア
プリケーション状態情報からなるリソース状態テーブル
２４ａを備える。アプリケーション２は、リソース異常
制御プログラム２４に対してリソース異常に関する問い
合わせを行い、リソース異常に関する情報がアプリケー
ションに提供される。ここで、「ハードウェア状態情
報」とは、ハードウェアの故障、工事中（交換機に新た
な装置を付加する場合等）、スタンバイ（装置の待機中
／稼働中）等の状態を示す情報であり、「ＯＳリソース
の状態情報」とは、タスク遷移状態、タスクリソースの
空き塞がり、負荷のかかり具合等を示す情報であり、
「アプリケーションリソースの状態情報」とはリソース
の最大限界、リソースの使用中判定を行うための情報で
ある。

【００２３】２．実施形態の動作 続いて、このようなソフトウェアおよびハードウェアが
搭載された交換機におけるリソース異常制御に関する動
作について説明する。 ２．１．動作の概要 まず、呼処理、保守運用、システム管理の各アプリケー
ションは、処理を実行する最初の過程でリソース異常制
御プログラム２４にアクセスし、自身のアプリケーショ
ンの処理を実行する上で必要となるリソースに異常が発
生していないかどうかを、必要となるリソースの識別情
報を送信して問い合わせる。この結果、リソース異常な
しと判定されると、当該アプリケーションの処理を最後
まで実行する一方、必要とするリソースの少なくとも１
つに異常があると判定されると、処理の終了もしくはリ
ソース異常が回避されるまで処理を中断する。

【００２４】また、リソース状態が異常になった場合、
リソース管理プログラム２３はその旨をリソース異常制
御プログラム２４に通知する。これを受けてリソース異
常制御プログラム２４は、リソース異常に関するアプリ
ケーションからの問い合わせを仲介するインタフェース
（リソース状態テーブル２４ａ）に対してリソース異常
を設定する。そして、リソース正常化処理部２３ｃは、
リソース異常を回避するため、このリソースを使用して
いるアプリケーションを強制的に終了させる処理を行
う。例えば、ある特定の呼に対するプロセスを初期化す
ることで、当該プロセスによって使用されているリソー
スを解放する「１コールイニシャライズ」等の処理が実
行される。

【００２５】２．２．具体的な動作 続いて、具体的な動作例について、呼処理プログラム２
０Ｂの動作シーケンスを示す図４のフローチャートに基
づいて説明する。なお、同図は、既述の従来例の動作を
示す図７と対比させて表現したものである。まず、利用
者が受話器を上げると（Ｓ１）、割り込みが発生する
（Ｓ２）。呼処理プログラム２０Ｂは、必要なリソース
（タスクの生成、ＤＴハードの設定、ＳＷハードのパス
設定）の識別情報を伴って、これらのリソースの確保が
可能であるかどうかの問い合わせをリソース異常制御プ
ログラム２４に対して行う（Ｓ３）。リソース異常制御
プログラム２４は、リソース状態テーブル２４ａに記憶
された情報を参照して、呼処理プログラム２０Ｂの必要
とするリソースに異常が発生しているか否かの情報を提
供する。

【００２６】これを受けて、呼処理プログラム２０Ｂ
は、必要とするリソースのいずれか１つでも異常がある
旨の情報が供給された場合（Ｓ３；ＮＯ）、異常処理に
移行する（Ｓ４）。一方、必要とするリソースのすべて
が正常である旨の通知がされた場合（Ｓ３；ＹＥＳ）に
は、リソース管理プログラム２３に対してリソースの確
保を要請する。すなわち、まず、タスクを取得して（Ｓ
５）、ＤＴハードが確保されてリソースが設定される
（Ｓ６）。さらに、ＳＷハードへのパスが設定されリソ
ースが確保され、タスクが終了する（Ｓ８）。

【００２７】図５は、上記図４に示すシーケンスにおい
て、必要とするリソースが正常であると確認された後、
実際にリソースを確保する場面におけるリソース管理プ
ログラム２３とリソース異常制御プログラム２４の動作
を示したものである。まず、呼処理プログラム２０Ｂか
らＤＴハードリソースの確保が要求される（Ｓ１０）
と、リソース管理プログラム２３は、ＤＴハードがシス
テム搭載数の最大に達したか否かを判断して（Ｓ１
１）、ＤＴハードの空きがない場合（Ｓ１１；ＹＥＳ）
には、その旨をリソース異常制御プログラム２４側に通
知することで、リソース状態テーブル２４ａにその旨が
記憶される（Ｓ１２）。一方、最大数に達していない場
合（Ｓ１１；ＮＯ）には、呼処理プログラム２０ＢにＤ
Ｔハードリソースの確保が完了した旨を通知する（Ｓ１
３）。

【００２８】３．実施形態の効果 （１）呼処理、保守運用、システム管理の各アプリケー
ションは、処理の冒頭で１回だけリソース異常制御プロ
グラムに対して問い合わせを行うことにより、必要とす
るリソースに異常が発生しているか否かを判断して、リ
ソース異常の場合には異常処理に移行することができ
る。 （２）したがって、従来のように各アプリケーション毎
に任意の箇所でリソース異常の判定を行う場合と比べて
処理が一本化され、各アプリケーションの開発におい
て、リソース異常に関する判定を行う部分を盛り込む必
要がなくなり、リソース異常に関する部分の検討ポイン
ト数が削減されることと相俟って、全体の開発工数が大
幅に削減される。 （３）これに関連して、対象交換機の機種変更やバージ
ョンアップに対する異常処理部の修正個所を最小限にす
ることができ、ソフトウェア生産工程における作業能率
が向上する。 （４）さらに、交換機ソフトウェアの試験を実行するた
めの試験稼働に要する時間も大幅に削減される。

【００２９】４．変形例 本発明は、上記実施形態に限定されるものではなく、例
えば以下のように種々の変形が可能である。 （１）本実施形態では、リソース管理部でリソース異常
分析を行いリソース異常と判定された場合の処理（上記
実施形態では、１コールイニシャライズ）を実行する指
令を発行することとしたが、この異常分析とリソース正
常化処理をリソース異常制御部で行うようにしてもよ
い。 （２）本実施形態では、交換機を例に挙げて説明した
が、交換機以外のコンピュータシステムに対しても本実
施形態に係るリソース異常制御方法を適用することがで
きる。

【００３０】

【発明の効果】以上詳細に説明したように、この発明に
よれば、コンピュータシステムに搭載されるソフトウェ
アにおいて、リソース情報を管理してリソースの異常処
理を集約化することで、各プログラム毎にリソース管理
およびリソース異常に対する処理を盛り込む必要がなく
なる。

【図面の簡単な説明】

【図１】本実施形態にかかる交換機ソフトウェアの構造
を示す図である。

【図２】本実施形態にかかる交換機の主要部のハードウ
ェア構成を示す図である。

【図３】本実施形態にかかる交換機ソフトウェアにおい
て、リソース管理部とリソース異常制御部の構成を中心
に表現したものである。

【図４】本実施形態のリソース異常制御方法を用いた場
合の具体例を示すフローチャートである。

【図５】本実施形態のリソース異常制御方法を用いた場
合のリソース管理部とリソース異常制御部との相互動作
を示すフローチャートである。

【図６】交換機における従来のソフトウェア構造を示す
図である。

【図７】従来の呼処理プログラムにおける異常処理の動
作を示すフローチャートである。

【符号の説明】

１Ａ，１Ｂ ＯＳ ２Ａ，２Ｂ アプリケーション ２０Ａ，２０Ｂ 呼処理プログラム ２１Ａ，２１Ｂ 保守運用プログラム ２２Ａ，２２Ｂ システム管理プログラム ２３ リソース管理プログラム ２３ａ リソース状態情報取得部 ２３ｂ リソース異常分析部 ２３ｃ リソース正常化処理部 ２３ｄ リソース確保処理部 ２３ｅ リソース管理リスト ２４ リソース異常制御プログラム ２４ａ リソース状態テーブル

───────────────────────────────────────────────────── フロントページの続き (72)発明者 田村 善嗣 東京都港区港南一丁目９番１号 エヌ・テ ィ・ティ・コミュニケーションウェア株式 会社内 Ｆターム(参考） 5B098 AA05 GA02 GA06 GB05 GD02 GD03 GD07 GD12 GD14 GD21 5K026 AA03 CC07 FF02 GG14 5K051 AA10 EE01

Claims (7)

【特許請求の範囲】
1. 【請求項１】 コンピュータシステムにおいて使用され
   る種々のリソースの異常に対する制御を行うリソース異
   常制御方法において、 リソースに対する異常が発生していると判定された場
   合、その旨を記憶するリソース異常記憶過程と、 前記いずれか複数のリソースに対する複数の識別情報を
   伴って、該リソースの異常状態を問い合わせる過程と、 この問い合わせに応答して、前記リソース異常記憶過程
   で記憶され、かつ、前記識別情報に対応する情報を提供
   するリソース異常情報提供過程とを有することを特徴と
   するリソース異常制御方法。
2. 【請求項２】 請求項１に記載のリソース異常制御方法
   において、 前記リソースの状態を示すリソース情報を取得する過程
   と、 取得したリソース情報を分析して、前記リソースに対す
   る異常が発生しているか否かを判定するリソース情報分
   析過程とを有することを特徴とするリソース異常制御方
   法。
3. 【請求項３】 請求項２に記載のリソース異常制御方法
   において、 所定の処理を実行するアプリケーションからの要請に基
   づいてリソースが確保された場合、該アプリケーション
   によって実行されるプロセスに対する識別子と、確保さ
   れたリソースの種別とを対応付けて記憶するリソース管
   理過程と、 前記リソース情報分析過程でリソースに対する異常が発
   生していると判定された場合、前記リソース管理過程に
   おいて記憶された情報に基づいて該リソースを使用して
   いるプロセスを抽出し、抽出されたプロセスに対して該
   リソースの異常を回避するための指示を与えるリソース
   正常化処理過程とを有することを特徴とするリソース異
   常制御方法。
4. 【請求項４】 請求項３に記載のリソース異常制御方法
   において、 前記リソース正常化処理過程では、リソース異常と判定
   されたリソースを使用しているプロセスに対して初期化
   の指示を与えることを特徴とするリソース異常制御方
   法。
5. 【請求項５】 請求項１〜４のいずれかに記載のリソー
   ス異常制御方法を実行することを特徴とするリソース異
   常制御装置。
6. 【請求項６】 請求項５に記載のリソース異常制御装置
   を含むことを特徴とするコンピュータシステム。
7. 【請求項７】 請求項１〜４のいずれかに記載のリソー
   ス異常制御方法を実行するプログラムを記録した記録媒
   体。