JP2001034488A - 共有リソース管理システムおよび共有リソース管理方法 - Google Patents

Abstract

(57)【要約】 【課題】 本発明は、汎用ＯＳ上で実現するアプリケー
ションソフトの利用可能な範囲内で汎用ＯＳが提供する
共有リソースの有効利用を図る共有リソース管理システ
ムおよび共有リソース管理方法を提供することを課題と
する。 【解決手段】 特定のアプリケーションソフトにおける
共有リソースの捕捉処理、接続／接続解除処理、および
解放処理を一元的に管理する手段と、共有リソースの利
用状況を把握する手段と、当該アプリケーションソフト
の設計の際に規定される共有リソースの利用条件と当該
把握した共有リソースの利用状況の相互比較を基にリソ
ース利用の面での適切な障害検出および障害対処を実行
する手段を設ける。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、共有リソース管理
技術に係り、特に汎用ＯＳ（ＯｐｅｒａｔｉｎｇＳｙｓ
ｔｅｍ：オペレーティングシステム）上で実現するアプ
リケーションソフトの利用可能な範囲内で汎用ＯＳが提
供する共有リソースの有効利用を図る共有リソース管理
システムおよび共有リソース管理方法に関する。

【０００２】

【従来の技術】従来、汎用ＯＳ上で実現するアプリケー
ション・ソフトを開発場合、開発する時点で汎用ＯＳか
ら提供される共有リソースを有効に利用した設計を行う
ことが一般的であった。

【０００３】

【発明が解決しようとする課題】しかしながら、従来技
術は、汎用ＯＳ上で実現するアプリケーション・ソフト
を開発する時点で、汎用ＯＳから提供される共有リソー
スの有効利用を目的とした設計がなされるが、動作環境
の個別の事情（システムの運用状況）などにより生じる
設計とのギャップにより、必要リソース不足による捕捉
不能状態、共有リソースの過剰捕捉による全体量の不足
などの弊害が運用環境にて発生することがあるが、設計
へのフィード・バックを含め、発生しうる弊害を防止し
たり、解消するための仕組みは、ＯＳレベルでの利用量
上限の制約によるガード以外に存在せず、共有リソース
の有効利用を追求・実現する標準的な仕組みはないとい
う問題点があった。

【０００４】本発明は斯かる問題点を鑑みてなされたも
のであり、その目的とするところは、汎用ＯＳ上で実現
するアプリケーションソフトの利用可能な範囲内で汎用
ＯＳが提供する共有リソースの有効利用を図る共有リソ
ース管理システムおよび共有リソース管理方法を提供す
る点にある。

【０００５】

【課題を解決するための手段】請求項１に記載の発明の
要旨は、汎用ＯＳ上で実現するアプリケーションソフト
の利用可能な範囲内で汎用ＯＳが提供する共有リソース
の有効利用を図る共有リソース管理システムであって、
特定のアプリケーションソフトにおける共有リソースの
捕捉処理、接続／接続解除処理、および解放処理を一元
的に管理する手段と、汎用ＯＳが提供する前記共有リソ
ースの利用状況を把握する手段と、アプリケーションソ
フトの設計の際に規定される共有リソースの利用条件と
当該把握した共有リソースの利用状況の相互比較を基に
リソース利用の面での適切な障害検出および障害対処を
実行する手段を有することを特徴とする共有リソース管
理システムに存する。また、請求項２に記載の発明の要
旨は、汎用ＯＳが提供する前記共有リソースの利用状況
を統計データとして蓄積する手段を有することを特徴と
する請求項１に記載の共有リソース管理システムに存す
る。また、請求項３に記載の発明の要旨は、汎用ＯＳが
提供する前記共有リソースの利用効率を判定基準として
設計の妥当性を検討してアプリケーションソフトの設計
にフィード・バックする手段を有することを特徴とする
請求項１または２に記載の共有リソース管理システムに
存する。また、請求項４に記載の発明の要旨は、汎用Ｏ
Ｓが提供する前記共有リソースの利用状況を統計的に整
理して設計の妥当性の吟味およびフィード・バックを実
行する手段を有することを特徴とする請求項１乃至３の
いずれか一項に記載の共有リソース管理システムに存す
る。また、請求項５に記載の発明の要旨は、前記共有リ
ソースとは、アプリケーションソフトとプロセスとの間
で共用が可能であって、当該アプリケーションソフトの
任意の利用に供されるリソースであることを特徴とする
請求項１乃至４のいずれか一項に記載の共有リソース管
理システムに存する。また、請求項６に記載の発明の要
旨は、アプリケーションソフトの設計時に規定される共
有リソース利用条件を格納する共有メモリ利用規定デー
タベースを有することを特徴とする請求項１乃至５のい
ずれか一項に記載の共有リソース管理システムに存す
る。また、請求項７に記載の発明の要旨は、システム稼
動時の前記共有リソースの利用状況を管理するためのデ
ータベースであって、現時点において利用されている前
記共有リソース上の領域ごとに利用状態、利用者情報、
利用サイズ、領域確保時間、操作開始時間、操作終了時
間を管理する共有メモリ利用状況ＤＢを有することを特
徴とする請求項１乃至５のいずれか一項に記載の共有リ
ソース管理システムに存する。また、請求項８に記載の
発明の要旨は、共有メモリ利用中に発生した障害、およ
び、当障害への対処を記録するためのデータベースであ
る共有メモリ操作障害状況ＤＢを有することを特徴とす
る請求項１乃至５のいずれか一項に記載の共有リソース
管理システムに存する。また、請求項９に記載の発明の
要旨は、前記共有メモリ利用状況ＤＢが管理する情報を
基に統計情報を管理するためのデータベースであって、
前記共有リソースについて共有リソース種別ごとの延べ
利用量および延べ確保回数を管理するとともに、用途ご
との領域保持期間、用途ごとの操作期間、用途ごとの延
べ利用量、用途ごとの確保回数、用途ごとの操作試行
数、用途ごとの操作障害発生数の少なくともいずれかを
管理する共有メモリ操作統計情報ＤＢを有することを特
徴とする請求項１乃至５のいずれか一項に記載の共有リ
ソース管理システムに存する。また、請求項１０に記載
の発明の要旨は、前記共有リソース内の特定領域の確保
・接続・接続解除・解放処理を実行する共有リソース操
作手段を有することを特徴とする請求項１乃至５のいず
れか一項に記載の共有リソース管理システムに存する。
また、請求項１１に記載の発明の要旨は、前記共有リソ
ース操作手段は、ユーザ・プロセスの一要素として実装
され、ユーザ・プロセスからの要求に応じて前記共有リ
ソースの操作を実施する機能、および前記共有リソース
の操作の過程で必要に応じてＯＳチューニング情報、共
有メモリ利用規定ＤＢ、共有メモリ利用状況ＤＢ、共有
メモリ操作障害状況ＤＢ、共有メモリ操作統計情報ＤＢ
のそれぞれにアクセスし、情報を操作する機能、処理中
に検出した障害および論理矛盾について自律メッセージ
を用いて保守者に報告する機能を有していることを特徴
とする請求項１１に記載の共有リソース管理システムに
存する。また、請求項１２に記載の発明の要旨は、前記
共有リソースの操作に関連する統計情報の編集・通知処
理を実行する管理系プロセスであって、保守者の要求に
従い前記共有メモリ操作統計情報ＤＢにて管理する統計
情報を抽出するとともに、必要に応じて加工したうえで
所定の帳票に編集し報告する統計情報収集・編集手段を
有することを特徴とする請求項１乃至５のいずれか一項
に記載の共有リソース管理システムに存する。また、請
求項１３に記載の発明の要旨は、汎用ＯＳ上で実現する
アプリケーションソフトの利用可能な範囲内で汎用ＯＳ
が提供する共有リソースの有効利用を図る共有リソース
管理方法であって、特定のアプリケーションソフトにお
ける共有リソースの捕捉処理、接続／接続解除処理、お
よび解放処理を一元的に管理する工程と、汎用ＯＳが提
供する前記共有リソースの利用状況を把握する工程と、
アプリケーションソフトの設計の際に規定される共有リ
ソースの利用条件と当該把握した共有リソースの利用状
況の相互比較を基にリソース利用の面での適切な障害検
出および障害対処を実行する工程を有することを特徴と
する共有リソース管理方法に存する。また、請求項１４
に記載の発明の要旨は、汎用ＯＳが提供する前記共有リ
ソースの利用状況を統計データとして蓄積する工程を有
することを特徴とする請求項１３に記載の共有リソース
管理方法に存する。また、請求項１５に記載の発明の要
旨は、汎用ＯＳが提供する前記共有リソースの利用効率
を判定基準として設計の妥当性を検討してアプリケーシ
ョンソフトの設計にフィード・バックする工程を有する
ことを特徴とする請求項１３または１４に記載の共有リ
ソース管理方法に存する。また、請求項１６に記載の発
明の要旨は、汎用ＯＳが提供する前記共有リソースの利
用状況を統計的に整理して設計の妥当性の吟味およびフ
ィード・バックを実行する工程を有することを特徴とす
る請求項１３乃至１５のいずれか一項に記載の共有リソ
ース管理方法に存する。

【０００６】

【発明の実施の形態】以下に示す各実施の形態の第１の
特徴は、汎用ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅ
ｍ：オペレーティングシステム）上で実現するアプリケ
ーションソフトにおける共有リソースの捕捉処理、接続
／接続解除処理、および解放処理を一元的に管理する手
段と、共有リソースの利用状況を把握する手段と、当該
アプリケーションソフトの設計の際に規定される共有リ
ソースの利用条件と当該把握した共有リソースの利用状
況の相互比較を基にリソース利用の面での適切な障害検
出および障害対処を実行する手段を設けることにより、
汎用ＯＳ上で実現するアプリケーションソフトの利用可
能な範囲内で汎用ＯＳが提供する共有リソースの有効利
用を実現できることにある。そして第２の特徴は、共有
リソースの利用状況を統計データとして蓄積する手段
と、共有リソースの利用効率を判定基準として設計の妥
当性を検討して当該設計にフィード・バックする手段を
設けることにより、共有リソースの利用状況を統計的に
整理して設計の妥当性の吟味およびフィード・バックで
きることにある。なお、本発明の操作対象とする共有リ
ソースとは、汎用ＯＳにより利用量が管理・制限される
が、アプリケーションソフト・プロセスにて共用が可能
であり、かつ、アプリケーションソフトの任意の利用に
供される共有リソースを意味する。具体的な共有リソー
スしては、メッセージ・キューや共有メモリが挙げられ
るが、これに特に限定されるものではない。以下、本発
明の実施の形態を図面に基づいて詳細に説明する。

【０００７】（第１の実施の形態）図１は、本発明の第
１の実施の形態に係る共有リソース管理システム３０を
説明するための原理図である。図１において、１はＯＳ
チューニング情報、２は共有メモリ利用規定ＤＢ、３は
共有メモリ利用状況ＤＢ、４は共有メモリ操作障害状況
ＤＢ、５は共有メモリ操作統計情報ＤＢ、１０は汎用Ｏ
Ｓ（基本ソフトウェア）、１１は共有リソース操作手
段、１２は統計情報収集・編集手段、１３は動作状態監
視手段、３０は共有リソース管理システムを示してい
る。図１を参照すると、本実施の形態の共有リソース管
理システム３０は、ＯＳチューニング情報１、共有メモ
リ利用規定ＤＢ２、共有メモリ利用状況ＤＢ３、共有メ
モリ操作障害状況ＤＢ４、共有メモリ操作統計情報ＤＢ
５、汎用ＯＳ１０（基本ソフトウェア、例えば、ＵＮＩ
Ｘ）、共有リソース操作手段１１、統計情報収集・編集
手段１２、動作状態監視手段１３を備えている。

【０００８】本実施の形態の共有リソースとしては、汎
用ＯＳ１０を経由してユーザプロセス（アプリケーショ
ンソフト）が確保・利用できる資源であって、具体的に
は、ＣＰＵ、メモリ、ＩＯＰ（Ｉ／Ｏプロセッサ）、お
よび、２次記憶装置（ハードディスクなど）をイメージ
する。特に汎用ＯＳ１０の代表であるＵＮＩＸには、
「ＩＰＣ（Ｉｎｔｅｒ−Ｐｒｏｃｅｓｓ Ｃｏｍｍｕｎ
ｉｃａｔｉｏｎ）」という機能が具備されており、ユー
ザプロセスの任意にて利用可能な資源の利用形態が存在
する。本実施の形態は、共有リソース利用の計画と現実
のすり合わせのために有効な情報を管理・分析する仕組
み（ソフト的なコンポーネント）を対象としており、特
定の共有リソースを対象としたものではないが、少なく
とも、上記ＩＰＣ機能に関連するリソースは、発明の操
作対象となる。

【０００９】本実施の形態では、複数のユーザ・プロセ
スにて特定の目的のために確保・利用されるメモリを共
有メモリとして用いている。以下に共有メモリの確保の
手順について説明する。まず、共有メモリにおける領域
の確保について説明する。本実施の形態では、ユーザ・
プロセスは、ある特定の条件（領域の識別情報、確保サ
イズ、確保の条件）とともに、まず、領域の確保を実施
する。領域は、必要に応じて物理メモリにマッピングさ
れる（実際のメモリアクセスが発生した時点で物理メモ
リにマッピングされる）仮想の領域となる。また、ユー
ザ・プロセスが領域を確保しようとした際、当該領域が
「確保済み」である場合は、指定した確保の条件によ
り、正常と認識されたり、異常と認識されたりする。例
えば、排他的な確保を指示した場合、「確保済み」の状
態は、異常として扱う。

【００１０】次に、共有メモリにおける領域へのアクセ
ス（アタッチ）・利用の開始について説明する。本実施
の形態では、既に確保された領域に対して、実際の操作
（メモリアクセス）を実施するために、まず、領域への
アクセスを実施する。また、アクセスしようとした領域
が存在しない場合は、異常として扱う。また、ユーザ・
プロセスは、領域にアクセスすることにより、アクセス
のために必要な情報（メモリアドレス）を取得すること
ができる。

【００１１】次に、共有メモリにおける領域の切り放し
（デタッチ）・利用の終了について説明する。本実施の
形態では、ユーザ・プロセスの処理の状況に応じて、当
該領域の操作が不要になった時点で、切り放しの処理を
実施する。当該切り放しの処理は、処理を発行したユー
ザ・プロセスが、当該領域との関連を断ち切るための手
段であり、領域をシステム返却するものではなく、別の
ユーザ・プロセスが（同一の目的で）利用していること
も想定される。

【００１２】最後に、共有メモリにおける領域の開放に
ついて説明する。本実施の形態では、当該領域の必要性
がなくなった時点で、システムへの資源の返却を目的と
した解放処理が実施する。当該解放処理は、ユーザ・プ
ロセスの責任範囲であり、利用者がいなくなったことを
前提に実施する。

【００１３】以上説明したように本実施の形態では、共
有メモリに対する確保、利用開始・終了、解放が完全に
独立した手順で実行されることとなる。

【００１４】ＯＳチューニング情報１は、汎用ＯＳ１０
のチューニング情報であり、ＯＳレベルでの共有リソー
スの利用条件を規定するものであり、アプリケーション
ソフトが共有リソースを利用する際の絶対的な制約とな
る。

【００１５】共有メモリ利用規定ＤＢ２は、アプリケー
ションソフトの設計時に規定される共有リソース利用条
件を格納するデータベースである。共有メモリ利用規定
ＤＢ２に格納される情報として、共有リソース種別、用
途、論理キー、利用下限サイズ、利用上限サイズ、利用
資格、自動解放の要否を管理する。ここで、共有リソー
ス種別とは、汎用ＯＳ１０が提供する共有リソースの管
理区分、例えば、メッセージ・キューや共有メモリなど
に相当するものである。また、用途とは、アプリケーシ
ョンソフトが意図する共有リソースの利用目的であり、
基本的には、用途ごとに必要な量だけ共有リソース内の
特定領域を捕捉することとなる。また、論理キーとは、
共有リソースの利用対象領域を特定するためにアプリケ
ーションソフトが利用する静的な情報である。通常、共
有リソース中の領域は汎用ＯＳ１０が動的に確保するた
め、論理キーは、汎用ＯＳ１０により動的に確保された
領域に対し一意に割り当てられた物理キーと対応づけら
れる。また、利用下限サイズは、共有リソースの利用対
象領域を運用するための必要最低限のサイズ（下限サイ
ズ）に設定されている。このため、当該下限サイズを下
回る大きさの領域確保処理は禁止されることになる。ま
た、利用上限サイズは、共有リソースの利用対象領域を
運用するために許容される最大限のサイズ（上限サイ
ズ）に設定されている。このため、当該上限サイズを上
回る大きさの領域確保処理は禁止される。また、利用資
格とは、当該領域を利用するアプリケーションソフトを
限定するために規定される情報であり、利用する際に条
件が満たされないアプリケーションソフトの操作処理
は、禁止される。また、自動解放の要否とは、当該領域
のユーザが存在せず領域のみ存在する状態において、共
有リソース管理システム３０が当該領域を自動的に解放
すべきか否かを規定する情報となる。

【００１６】共有メモリ利用状況ＤＢ３は、システム稼
動時の共有リソースの利用状況を管理するためのデータ
ベースである。現時点において利用されている共有リソ
ース上の領域ごとに利用状態、利用者情報、利用サイ
ズ、領域確保時間、操作開始時間、操作終了時間を管理
する機能を有している。ここで、利用状態とは、領域確
保済み、操作中、操作済み（未解放）のいずれかの状態
を現状態として表すものである。また、ユーザ情報と
は、当該領域を現在利用しているものの特定情報（例え
ば、利用の主体をプロセスとした場合のプロセス名やプ
ロセスＩＤ）を意味する。また、利用サイズとは、当該
領域の現サイズを表すものである。また、領域確保時間
とは、共有リソース内に当該領域を確保した日時を意味
する。また、操作開始時間とは、当該領域の最初のユー
ザが操作を開始した日時を意味する。また、操作終了時
間とは、当該領域の最後のユーザが操作を完了した日時
を意味する。

【００１７】共有メモリ操作障害状況ＤＢ４は、共有メ
モリ利用中に発生した障害、および、当障害への対処を
記録するためのデータベースである。

【００１８】共有メモリ操作統計情報ＤＢ５は、共有メ
モリ利用状況ＤＢ３が管理する情報を基に統計情報を管
理するためのデータベースである。具体的には、共有リ
ソース管理システム３０にて操作する共有リソースにつ
いて、共有リソース種別ごとの延べ利用量および延べ確
保回数を管理するとともに、用途ごとの領域保持期間
（累積）、用途ごとの操作期間（累積）、用途ごとの延
べ利用量、用途ごとの確保回数、用途ごとの操作試行数
（累積）、および用途ごとの操作障害発生数（累積）を
管理する機能を有している。

【００１９】共有リソース操作手段１１は、共有リソー
ス内の特定領域の確保・接続・接続解除・解放処理を実
行するプロセスである。共有リソース操作手段１１は、
独立した存在ではなく、ユーザ・プロセスの一要素とし
て実装され、ユーザ・プロセスからの要求に応じて共有
リソースの操作を実施する機能、および共有リソースの
操作の過程で、必要に応じてＯＳチューニング情報１、
共有メモリ利用規定ＤＢ２、共有メモリ利用状況ＤＢ
３、共有メモリ操作障害状況ＤＢ４、共有メモリ操作統
計情報ＤＢ５のそれぞれにアクセスし、情報を操作する
機能、処理中に検出した障害および論理矛盾について自
律メッセージを用いて保守者に報告する機能を有してい
る。

【００２０】統計情報収集・編集手段１２は、共有リソ
ースの操作に関連する統計情報の編集・通知処理を実行
する管理系プロセスである。具体的には、保守者の要求
に従い、共有メモリ操作統計情報ＤＢ５にて管理する統
計情報を抽出し、また必要に応じて加工したうえで、所
定の帳票に編集し報告する。加工される情報は、共有リ
ソース種別ごとの平均利用量（＝延べ利用量／延べ確保
回数）、用途ごとの平均利用量（＝延べ利用量／確保回
数）、用途ごとの利用率（＝操作期間×１００／領域保
持期間）、用途ごとの障害率（＝操作障害発生数×１０
０／操作試行数）とする。

【００２１】動作状態監視手段１３は、共有リソース管
理システム３０の動作状態を監視する管理系プロセスで
あって、定期的に共有リソースの操作状況を監視する機
能、障害の発生状況をモニタする機能、自動解放対象の
領域でありながら未解放状態にある領域を検出して解放
する機能を有している。

【００２２】次に共有リソース管理システム３０の動作
（共有リソース管理方法）について説明する。上記共有
リソース管理システム３０における共有リソース操作手
段１１に関連する動作は、ユーザ・プロセスからの要求
に応じて、領域確保、領域への接続、領域との接続解
除、領域解放の４つに分類できる。この４つの動作を、
それぞれ、図２、図３、図４、図５のフローチャートを
用いて説明する。

【００２３】初めに、領域確保の動作について説明す
る。図２は領域確保の動作を説明するためのフローチャ
ートである。図２を参照すると、本実施の形態では、ま
ず、入力情報として、共有リソース種別、用途、ユーザ
の想定する利用サイズを要求条件として受け取り、共有
メモリ利用規定ＤＢ２より関連情報を抽出（ステップＳ
２００）して相互比較することにより、要求条件の妥当
性を吟味（ステップＳ２０１）する。要求条件に問題が
ある場合（ステップＳ２０１’の「あり」）は、問題の状
況を共有メモリ操作障害状況ＤＢ４に記録（ステップＳ
２１０）し、必要に応じて自律メッセージを出力（ステ
ップＳ２１１）した後、要求拒否の状態で処理を終了す
る（ステップＳ２１２）。要求条件に問題がない場合
（ステップＳ２０１’の「なし」）は、当該領域の存在を
確認（ステップＳ２０２）し、存在しなければ（ステッ
プＳ２０２’の「しない」）、汎用ＯＳ１０が提供するＡ
ＰＩを利用し、新規に領域を確保（ステップＳ２０３）
する。確保処理成功時（ステップＳ２０３’の「成功」）
は、確保実績を共有メモリ利用状況ＤＢ３と共有メモリ
操作統計情報ＤＢ５に記録し（ステップＳ２０４）、確
保完了の状態で処理を終了（ステップＳ２０５）する。
確保処理が失敗した場合（ステップＳ２０３’の「失
敗」）は、問題の状況を共有メモリ操作障害状況ＤＢ４
に記録（ステップＳ２０７）し、必要に応じて自律メッ
セージを出力（ステップＳ２０８）した後、確保失敗の
状態で処理を終了（ステップＳ２０９）する。所定の領
域が既に存在する場合（ステップＳ２０２’の「す
る」）は、領域確保は実施せずに、領域既存の状態で処
理を終了（ステップＳ２０６）する。

【００２４】次に、領域への接続の動作について説明す
る。図３は領域への接続の動作を説明するためのフロー
チャートである。図３を参照すると、本実施の形態で
は、まず、入力情報として、共有リソース種別、用途、
ユーザの想定する利用サイズを要求条件として受け取
り、共有メモリ利用規定ＤＢ２より関連情報を抽出（ス
テップＳ３００）して相互比較することにより、要求条
件の妥当性を吟味（ステップＳ３０１）する。要求条件
に問題がある場合（ステップＳ３０１’の「あり」）は、
問題の状況を共有メモリ操作障害状況ＤＢ４と共有メモ
リ操作統計情報ＤＢ５に記録（ステップＳ３１１）し、
必要に応じて自律メッセージを出力（ステップＳ３１
２）した後、要求拒否の状態で処理を終了（ステップＳ
３１３）する。要求条件に問題がない場合（ステップＳ
３０１’の「なし」）は、当該領域の存在を確認し（ステ
ップＳ３０２）、存在しない場合（ステップＳ３０２’
の「しない」）は、問題の状況を共有メモリ操作障害状況
ＤＢ４と共有メモリ操作統計情報ＤＢ５に記録（ステッ
プＳ３０６）し、領域なしの状態で処理を終了（ステッ
プＳ３０７）する。領域が存在する場合（ステップＳ３
０２’の「する」）は、汎用ＯＳ１０が提供するＡＰＩを
利用し、領域への接続を実施（ステップＳ３０３）す
る。接続成功時（ステップＳ３０３’の「成功」）は、接
続実績を共有メモリ利用状況ＤＢ３と共有メモリ操作統
計情報ＤＢ５に記録（ステップＳ３０４）し、接続完了
の状態で処理を終了（ステップＳ３０５）する。接続処
理が失敗した場合（ステップＳ３０３’の「失敗」）は、
問題の状況を共有メモリ操作障害状況ＤＢ４と共有メモ
リ操作統計情報ＤＢ５に記録（ステップＳ３０８）し、
必要に応じて自律メッセージを出力（ステップＳ３０
９）した後、接続失敗の状態で処理を終了（ステップＳ
３１０）する。

【００２５】次に、領域との接続解除の動作について説
明する。図４は領域との接続解除の動作を説明するため
のフローチャートである。図４を参照すると、本実施の
形態では、まず、入力情報として、共有リソース種別、
用途、ユーザの想定する利用サイズを要求条件として受
け取り、共有メモリ利用規定ＤＢ２より関連情報を抽出
（ステップＳ４００）して相互比較することにより、要
求条件の妥当性を吟味（ステップＳ４０１）する。要求
条件に問題がある場合（ステップＳ４０１’の「あり」）
は、問題の状況を共有メモリ操作障害状況ＤＢ４と共有
メモリ操作統計情報ＤＢ５に記録（ステップＳ４１１）
し、必要に応じて自律メッセージを出力（ステップＳ４
１２）した後、要求拒否の状態で処理を終了（ステップ
Ｓ４１３）する。要求条件に問題がない場合（ステップ
Ｓ４０１’の「なし」）は、当該領域の存在を確認（ステ
ップＳ４０２）し、存在しない場合（ステップＳ４０
２’の「しない」）は、問題の状況を共有メモリ操作障害
状況ＤＢ４と共有メモリ操作統計情報ＤＢ５に記録（ス
テップＳ４０６）し、領域なしの状態で処理を終了（ス
テップＳ４０７）する。領域が存在する場合（ステップ
Ｓ４０２’の「する」）は、汎用ＯＳ１０が提供するＡＰ
Ｉを利用し、領域への接続の解除を実施（ステップＳ４
０３）する。解除成功時（ステップＳ４０３’の「成
功」）は、解除実績を共有メモリ利用状況ＤＢ３と共有
メモリ操作統計情報ＤＢ５に記録（ステップＳ４０４）
し、解除完了の状態で処理を終了（ステップＳ４０５）
する。解除処理が失敗した場合（ステップＳ４０３’の
「失敗」）は、問題の状況を共有メモリ操作障害状況ＤＢ
４と共有メモリ操作統計情報ＤＢ５に記録（ステップＳ
４０８）し、必要に応じて自律メッセージを出力（ステ
ップＳ４０９）した後、解除失敗の状態で処理を終了
（ステップＳ４１０）する。

【００２６】次に、領域解放の動作について説明する。
図５は領域解放の動作を説明するためのフローチャート
である。図５を参照すると、本実施の形態では、まず、
入力情報として、共有リソース種別、用途、ユーザの想
定する利用サイズを要求条件として受け取り、共有メモ
リ利用規定ＤＢ２より関連情報を抽出（ステップＳ５０
０）して相互比較することにより、要求条件の妥当性を
吟味（ステップＳ５０１）する。要求条件に問題がある
場合（ステップＳ５０１’の「あり」）は、問題の状況を
共有メモリ操作障害状況ＤＢ４に記録（ステップＳ５１
０）し、必要に応じて自律メッセージを出力（ステップ
Ｓ５１１）した後、要求拒否の状態で処理を終了（ステ
ップＳ５１２）する。要求条件に問題がない場合（ステ
ップＳ５０１’の「なし」）は、当該領域の存在を確認
（ステップＳ５０２）し、存在しなければ（ステップＳ
５０２’の「なし」）、領域なしの状態で処理を終了（ス
テップＳ５０６）する。

【００２７】領域が存在する場合（ステップＳ５０２’
の「する」）は、汎用ＯＳ１０が提供するＡＰＩを利用し
領域を解放（ステップＳ５０３）する。解放処理成功時
（ステップＳ５０３’の「成功」）は、解放実績を共有メ
モリ利用状況ＤＢ３と共有メモリ操作統計情報ＤＢ５に
記録（ステップＳ５０４）し、解放完了の状態で処理を
終了（ステップＳ５０５）する。解放処理が失敗した場
合（ステップＳ５０３’の「失敗」）は、問題の状況を共
有メモリ操作障害状況ＤＢ４に記録（ステップＳ５０
７）し、必要に応じて自律メッセージを出力（ステップ
Ｓ５０８）した後、解放失敗の状態で処理を終了（ステ
ップＳ５０９）する。

【００２８】次に、図１の共有リソース管理システム３
０における統計情報収集・編集手段１２に関連する動作
を図６のフローチャートを用いて説明する。図６は統計
情報収集・編集手段１２の動作を説明するためのフロー
チャートである。図６を参照すると、本実施の形態で
は、まず、入力情報として、報告対象情報種別（ただ
し、全部という指定も想定する）、報告指定時間（ただ
し、即時という指定も想定する）、報告様式（ただし、
報告用の帳票が複数ある場合を想定する）を要求条件と
して受け取り、要求の妥当性を吟味（ステップＳ６０
１）する。要求条件に問題がある場合（ステップＳ６０
１’の「あり」）は、問題の状況を共有メモリ操作障害状
況ＤＢ４に記録（ステップＳ６０６）し、必要に応じて
自律メッセージを出力（ステップＳ６０７）した後、要
求拒否の状態で処理を終了（ステップＳ６０８）する。
要求条件に問題がない場合（ステップＳ６０１’の「な
し」）は、報告指定時間を確認し、即時報告でない場合
（ステップＳ６０１”の「しない」）は、汎用ＯＳ１０が
提供するタイマ機能を利用して処理を予約（ステップＳ
６０５）し、所定の状態で処理を終了（ステップＳ６０
５’）する。即時報告の場合（ステップＳ６０１”の
「する」）は、共有メモリ操作統計情報ＤＢ５にアクセス
し、共有メモリ操作統計情報ＤＢ５から統計情報を抽出
（ステップＳ６０１'''）するとともに、情報の加工を
実施（ステップＳ６０２）する。その後、指定された帳
票もしくはデフォルトの帳票を編集（ステップＳ６０
３）し、結果を出力（ステップＳ６０４）し、所定の状
態で処理を終了（ステップＳ６０４’）する。

【００２９】次に、図１の共有リソース管理システム３
０における動作状態監視手段１３に関連する動作を図７
のフローチャートを用いて説明する。図７は、動作状態
監視手段１３の動作を説明するためのフローチャートで
ある。図７に規定する動作は、周期的に起動されること
を前提とする。図７を参照すると、本実施の形態では、
まず、共有メモリ操作障害状況ＤＢ４にアクセスし前回
調査時以降の障害情報を抽出（ステップＳ７０１）す
る。次いで、抽出された障害状況を分析（ステップＳ７
０２）し、報告が必要と判断した場合（ステップＳ７０
２’「要」）、自律メッセージを用いて保守者に報告（ス
テップＳ７０３）する。さらに、共有メモリ利用規定Ｄ
Ｂ２と共有メモリ利用状況ＤＢ３にアクセスし、「自動
解放が必要でかつ現在未解放の状態である」条件に合致
するリソース情報を抽出（ステップＳ７０４）する。抽
出した情報を基にそれぞれのリソースにアクセスして領
域の存在を確認し、存在する場合は自動解放を実施（ス
テップＳ７０５）する。

【００３０】以上説明したように本実施の形態によれ
ば、以下に掲げる効果を奏する。まず第１の効果は、ア
プリケーションソフトレベルで共有リソースの利用を制
御することにより、利用効率を向上させるとともに、Ｏ
Ｓレベルでの弊害の発生を回避できることである。そし
て第２の効果は、共有リソースの利用状況を統計的に整
理することにより、設計の妥当性の吟味およびフィード
・バックできることである。

【００３１】（第２の実施の形態）本発明は、上記第１
の実施の形態の他、システム動作環境のシミュレータな
どに適用することで、共有リソースの利用をシミュレー
トし統計情報を収集・分析し、設計時点での既定値の精
度を向上させることにも有効である。

【００３２】なお、本発明の操作対象とする共有リソー
スとは、汎用ＯＳにより利用量が管理・制限されるが、
アプリケーションソフト・プロセスにて共用が可能であ
り、かつ、アプリケーションソフトの任意の利用に供さ
れる共有リソースを意味する。具体的な共有リソースし
ては、メッセージ・キューや共有メモリが挙げられる
が、これに特に限定されるものではない。また、本発明
が上記各実施の形態に限定されず、本発明の技術思想の
範囲内において、各実施の形態は適宜変更され得ること
は明らかである。また上記構成部材の数、位置、形状等
は上記実施の形態に限定されず、本発明を実施する上で
好適な数、位置、形状等にすることができる。また、各
図において、同一構成要素には同一符号を付している。

【００３３】

【発明の効果】本発明は以上のように構成されているの
で、以下に掲げる効果を奏する。まず第１の効果は、ア
プリケーションレベルで共有リソースの利用を制御する
ことにより、利用効率を向上させるとともに、ＯＳレベ
ルでの弊害の発生を回避できることである。そして第２
の効果は、共有リソースの利用状況を統計的に整理する
ことにより、設計の妥当性の吟味およびフィード・バッ
クできることである。

【図面の簡単な説明】

【図１】本発明の第１の実施の形態に係る共有リソース
管理システムを説明するための原理図である。

【図２】領域確保の動作を説明するためのフローチャー
トである。

【図３】領域への接続の動作を説明するためのフローチ
ャートである。

【図４】領域との接続解除の動作を説明するためのフロ
ーチャートである。

【図５】領域解放の動作を説明するためのフローチャー
トである。

【図６】統計情報収集・編集手段の動作を説明するため
のフローチャートである。

【図７】動作状態監視手段の動作を説明するためのフロ
ーチャートである。

【符号の説明】

１…ＯＳチューニング情報 ２…共有メモリ利用規定ＤＢ ３…共有メモリ利用状況ＤＢ ４…共有メモリ操作障害状況ＤＢ ５…共有メモリ操作統計情報ＤＢ １０…汎用ＯＳ（基本ソフトウェア） １１…共有リソース操作手段 １２…統計情報収集・編集手段 １３…動作状態監視手段 ３０…共有リソース管理システム

Claims (16)

【特許請求の範囲】
1. 【請求項１】 汎用ＯＳ上で実現するアプリケーション
   ソフトの利用可能な範囲内で汎用ＯＳが提供する共有リ
   ソースの有効利用を図る共有リソース管理システムであ
   って、 特定のアプリケーションソフトにおける共有リソースの
   捕捉処理、接続／接続解除処理、および解放処理を一元
   的に管理する手段と、 汎用ＯＳが提供する前記共有リソースの利用状況を把握
   する手段と、 アプリケーションソフトの設計の際に規定される共有リ
   ソースの利用条件と当該把握した共有リソースの利用状
   況の相互比較を基にリソース利用の面での適切な障害検
   出および障害対処を実行する手段を有することを特徴と
   する共有リソース管理システム。
2. 【請求項２】 汎用ＯＳが提供する前記共有リソースの
   利用状況を統計データとして蓄積する手段を有すること
   を特徴とする請求項１に記載の共有リソース管理システ
   ム。
3. 【請求項３】 汎用ＯＳが提供する前記共有リソースの
   利用効率を判定基準として設計の妥当性を検討してアプ
   リケーションソフトの設計にフィード・バックする手段
   を有することを特徴とする請求項１または２に記載の共
   有リソース管理システム。
4. 【請求項４】 汎用ＯＳが提供する前記共有リソースの
   利用状況を統計的に整理して設計の妥当性の吟味および
   フィード・バックを実行する手段を有することを特徴と
   する請求項１乃至３のいずれか一項に記載の共有リソー
   ス管理システム。
5. 【請求項５】 前記共有リソースとは、アプリケーショ
   ンソフトとプロセスとの間で共用が可能であって、当該
   アプリケーションソフトの任意の利用に供されるリソー
   スであることを特徴とする請求項１乃至４のいずれか一
   項に記載の共有リソース管理システム。
6. 【請求項６】 アプリケーションソフトの設計時に規定
   される共有リソース利用条件を格納する共有メモリ利用
   規定データベースを有することを特徴とする請求項１乃
   至５のいずれか一項に記載の共有リソース管理システ
   ム。
7. 【請求項７】 システム稼動時の前記共有リソースの利
   用状況を管理するためのデータベースであって、現時点
   において利用されている前記共有リソース上の領域ごと
   に利用状態、利用者情報、利用サイズ、領域確保時間、
   操作開始時間、操作終了時間を管理する共有メモリ利用
   状況ＤＢを有することを特徴とする請求項１乃至５のい
   ずれか一項に記載の共有リソース管理システム。
8. 【請求項８】 共有メモリ利用中に発生した障害、およ
   び、当障害への対処を記録するためのデータベースであ
   る共有メモリ操作障害状況ＤＢを有することを特徴とす
   る請求項１乃至５のいずれか一項に記載の共有リソース
   管理システム。
9. 【請求項９】 前記共有メモリ利用状況ＤＢが管理する
   情報を基に統計情報を管理するためのデータベースであ
   って、前記共有リソースについて共有リソース種別ごと
   の延べ利用量および延べ確保回数を管理するとともに、
   用途ごとの領域保持期間、用途ごとの操作期間、用途ご
   との延べ利用量、用途ごとの確保回数、用途ごとの操作
   試行数、用途ごとの操作障害発生数の少なくともいずれ
   かを管理する共有メモリ操作統計情報ＤＢを有すること
   を特徴とする請求項１乃至５のいずれか一項に記載の共
   有リソース管理システム。
10. 【請求項１０】 前記共有リソース内の特定領域の確保
    ・接続・接続解除・解放処理を実行する共有リソース操
    作手段を有することを特徴とする請求項１乃至５のいず
    れか一項に記載の共有リソース管理システム。
11. 【請求項１１】 前記共有リソース操作手段は、ユーザ
    ・プロセスの一要素として実装され、ユーザ・プロセス
    からの要求に応じて前記共有リソースの操作を実施する
    機能、および前記共有リソースの操作の過程で必要に応
    じてＯＳチューニング情報、共有メモリ利用規定ＤＢ、
    共有メモリ利用状況ＤＢ、共有メモリ操作障害状況Ｄ
    Ｂ、共有メモリ操作統計情報ＤＢのそれぞれにアクセス
    し、情報を操作する機能、処理中に検出した障害および
    論理矛盾について自律メッセージを用いて保守者に報告
    する機能を有していることを特徴とする請求項１１に記
    載の共有リソース管理システム。
12. 【請求項１２】 前記共有リソースの操作に関連する統
    計情報の編集・通知処理を実行する管理系プロセスであ
    って、保守者の要求に従い前記共有メモリ操作統計情報
    ＤＢにて管理する統計情報を抽出するとともに、必要に
    応じて加工したうえで所定の帳票に編集し報告する統計
    情報収集・編集手段を有することを特徴とする請求項１
    乃至５のいずれか一項に記載の共有リソース管理システ
    ム。
13. 【請求項１３】 汎用ＯＳ上で実現するアプリケーショ
    ンソフトの利用可能な範囲内で汎用ＯＳが提供する共有
    リソースの有効利用を図る共有リソース管理方法であっ
    て、 特定のアプリケーションソフトにおける共有リソースの
    捕捉処理、接続／接続解除処理、および解放処理を一元
    的に管理する工程と、 汎用ＯＳが提供する前記共有リソースの利用状況を把握
    する工程と、 アプリケーションソフトの設計の際に規定される共有リ
    ソースの利用条件と当該把握した共有リソースの利用状
    況の相互比較を基にリソース利用の面での適切な障害検
    出および障害対処を実行する工程を有することを特徴と
    する共有リソース管理方法。
14. 【請求項１４】 汎用ＯＳが提供する前記共有リソース
    の利用状況を統計データとして蓄積する工程を有するこ
    とを特徴とする請求項１３に記載の共有リソース管理方
    法。
15. 【請求項１５】 汎用ＯＳが提供する前記共有リソース
    の利用効率を判定基準として設計の妥当性を検討してア
    プリケーションソフトの設計にフィード・バックする工
    程を有することを特徴とする請求項１３または１４に記
    載の共有リソース管理方法。
16. 【請求項１６】 汎用ＯＳが提供する前記共有リソース
    の利用状況を統計的に整理して設計の妥当性の吟味およ
    びフィード・バックを実行する工程を有することを特徴
    とする請求項１３乃至１５のいずれか一項に記載の共有
    リソース管理方法。