JPS6131500B2

JPS6131500B2 -

Info

Publication number: JPS6131500B2
Application number: JP56112395A
Authority: JP
Inventors: Aran Kaa Kurarensu; Ruisu Hadorusuton Robaato; Hooru Sutoritsukurando Jimii
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1980-10-06
Filing date: 1981-07-20
Publication date: 1986-07-21
Also published as: JPS5764861A; US4399504A

Description

【発明の詳細な説明】

本発明の技術分野本発明は、汎用コンピユータ・システムを１つ
又はそれ以上のプログラムの上で同時に動作させ
る装置に関する。更に具体的には、本発明は、１
つ又はそれ以上の中央電子複合体で実行中の異つ
たプログラムによつて共用されている資源へのア
クセスをダイナミツクに制御し、かつ上記資源の
保全性を維持するとともに、異つた中央電子複合
体の間で共用される制御パラメータの通信を最少
ならしめる装置に関する。背景の技術多くの作業ユニツト又はサブタスクが共通のレ
コードへアクセスする必要がある大型データ・ベ
ース・システムにおいては、データの保全性を維
持するため同時的アクセスを管理する必要があ
る。従来までのデータ共用方式の１つは、単一区画
内の２つ又はそれ以上のサブタスクにより、２つ
又はそれ以上のジヨブ・ステツプにより（複数の
区画）、及び任意数のユーザにより（クロスシス
テム共用方式）VSAMデータ・セツトを同時にア
クセス。IBM社から出版されたVSAMに関する手
引書によれば（例えば、G320−5774−01、
1979、95〜97頁）、読出し又は書込みのためにデ
ータ・セツトを開く多くのオプシヨンが可能であ
る。 VSAMクロス区画／領域共用方式において、
VSAMデータ・セツトが定義されるとき、オプシ
ヨンはDEFINE指令のSHARE OPTIONSパラメ
ータによつて定義される。最初のオプシヨンによ
つて、データ・セツトは、出力処理のために１人
のユーザによつてのみ開かれてよく（レコードを
更新し又は付加するため）、又は読出し動作のた
めにのみ複数のユーザによつて開かれてよい。こ
のオプシヨンによつて、完全な読出し及び書込み
の保全性が与えられる。第２のオプシヨンにおい
て、データ・セツトは出力処理のために１人のユ
ーザによつて開かれることができ、読取りだけの
処理のために複数人のユーザによつて開かれるこ
とができる。このオプシヨンにおいて、ユーザは
更新されつつあるレコードを読取ることができる
ので、書込保全性は実現されるが、読取保全性は
実現されない。第３のオプシヨンにおいて、デー
タ・セツトは読取り及び書込み動作のために任意
数のユーザによつて開かれることができ、保全性
（読取り又は書込み）はVSAMによつて実現され
ない。 VSAMクロス・システム共用方式では、第１オ
プシヨンによつて、データ・セツトは読取り及び
書込み動作について任意数のユーザによつて開か
れることができるが、保全性はVSAMによつて実
現されない。第２オプシヨンでは、データ・セツ
トは任意数のユーザによつて読取り及び書込み動
作について開かれることができるが、VSAMはそ
れぞれの直接処理要求のために新しいバツフアを
用意し、データ・セツトの保全性を維持するため
に、RESERVE及びRELEASEマクロがユーザに
よつて使用されなければならない。第１オプシヨンを除く上記オプシヨンのいずれ
においても、VSAMのユーザは、ENQ／DEQ又
はRESERVE／RELEASEマクロを使用して、デ
ータ・セツトの保全性を維持しなければならな
い。従来までのIBM IMS／VS製品において、その
ようなマクロの発生は、プログラム分離手段の機
能である（IMS／VS 第１版手引書、プログラ
ム番号5740−XX2、リリース1.5、IBM出版物
SH20−9145−０、3.12〜3.14頁参照）。しかし、
この手段を使用しては、異つた中央電子複合体
（CEC）上で動作を実行している複数人のユーザ
は、共通のデータへ同時にアクセスすることがで
きず、大型組織体によつてデータ・ベースを効果
的に使用しようとする場合の大きな障害となる。共通のデータへ複数の同時的アクセスを実行さ
せる従来までの方式は、米国特許出願第965810号
に記載されている。この特許出願は同時通報装置
に関する。外部エンキユー装置（EEF）５は、
それぞれのCPU及びコングルー・アンス・クラ
ス・（Congruence class）ごとに関心ビツトを有
する。関心ビツトのセツトは、CPUが対応する
コングルーアンス・クラスのデータ資源上でロツ
クを保持しているか、又はそれを待機しているこ
とを示す。それぞれのCPUは内部エンキユー装
置（IEF）を含み、このIEFはそれぞれのコング
ルーアンス・クラスごとにロツク・ビツトを有す
る。データ資源へのアクセス要求（リクエスト）
は、IEF内に対応するロツク・ビツトがセツトさ
れていれば、CPUによつて許されるが、上記ロ
ツク・ビツトがセツトされていなければ、アクセ
ス要求は先ずEEFへ、次いでEEFにおいてアク
セス要求のコングルーアンス・クラスに関心を有
する他のCPUへ通報されねばならない。上記米
国出願に説明されるシステムは実際上同時通報装
置であつて、同時アクセスを制御する構成は説明
されていない。更に、EEFは別個のハードウエ
ア装置又はCPUの１つに設けられる。EEFにお
ける故障は、CPU群といずれかのCPUによるデ
ータ資源アクセス要求の処理との間の通信を妨害
する。それぞれのCPUには、故障したCPU又は
EEFによつて後の回復動作のために設定された
ロツクを維持する手段は設けられていない。本発明の要約本発明の目的は、同一及び／又は異つた中央電
子複合体（CEC）の上に在る複数のユーザによ
つて、データ資源へのアクセスが同時になされる
のを制御する装置を提供することである。本発明の他の目的は、サブシステム、通信、ロ
ツク・マネジヤの故障から回復を可能ならしめる
ロツキング装置を提供することである。本発明の他の目的は、データ資源へ同時にアク
セスしているCEC群の間でロツク・データの通
信を最適化させるための通信プロトコルを提供す
ることである。本発明の他の目的は、マルチプログラミング及
びマルチプロセツサ環境において、複数のユーザ
の間でデータ、通信、及び計算資源を割当てるた
めの汎用コンピユータにおける制御装置を提供す
ることである。複数の中央電子複合体を含むコンピユータ・シ
ステムは、本発明を組込まれた場合、１つ又はそ
れ以上のプログラムを同時に処理することができ
る。１つ又はそれ以上の中央電子複合体の上で動
作しているプログラムによつて共用される資源へ
のアクセスは、上記複合体の間で共用制御パラメ
ータを最少限通知するだけで制御される。その制
御方法は次のとおりである。 (1) それぞれの資源コングルーアンス・クラスに
関して、各複合体の関心状態をそれぞれの複合
体の中に維持する。もし複合体が以前に或るコ
ングルーアンス・クラス内の資源に対してアク
セスを許したのであれば、その複合体はそのコ
ングルーアンス・クラスに関心を有する。 (2) 第１の複合体内で、資源キー及び資源コング
ルーアンス・クラスを有する資源に対してアク
セス・リクエストを発生する。 (3) アクセス・リクエストの資源コングルーアン
ス・クラスにおいて第１及び第２の複合体の関
心状態を決定する。 (4) アクセス・リクエストの資源コングルーアン
ス・クラスにおいて、第１複合体が関心を有し
第２複合体が関心を有しないことが決定される
と、第２複合体へ通知することなく、第１複合
体中でアクセス・リクエストを処理する。 (5) 第２複合体がアクセス・リクエストの資源コ
ングルーアンス・クラスに関心を有することが
決定されると、更に処理を行うためアクセス・
リクエストを第２複合体へ通知する。 (6) いずれの複合体もアクセス・リクエストの資
源コングルーアンス・クラスに関心を有しない
ことが決定されると、アクセス・リクエストの
資源コングルーアンス・クラスにおける第１複
合体の新しい関心状態を第２複合体へ通知し、
第１複合体の中でアクセス・リクエストを処理
する。 (7) アクセス・リクエストの処理は、選択的に資
源へのアクセスを許し、否定し、又は待機する
ことによつてなされる。資源名称及び資源コングルーアンス・クラスを
有する資源へのアクセス・リクエストを処理する
ため、中央電子複合体の動作は次のような特徴を
有する。 (1) アクセス・リクエストのコングルーアンス・
クラスに複合体が関心を有することが決定され
ると、以前にアクセスされかつ未だ解放されて
いないコングルーアンス・クラス内で全ての資
源の資源キーを有するコングルーアンス・クラ
ス・フアイルへアクセスし、アクセスが求めら
れた資源のロツク状態を決定するため、アクセ
ス・リクエストの資源キーを探索する。 (2) アクセス・リクエストの資源キーが無効ロツ
ク状態を有すると、資源へのアクセスを許し、
保持ロツク状態を有するコングルーアンス・ク
ラスへ資源キーを付加する。 (3) アクセス・リクエストの資源がアクセス・リ
クエストと両立する保持ロツク状態を有する
と、資源へのアクセスを許す。 (4) アクセス・リクエストの資源がアクセス・リ
クエストと両立しない保持ロツク状態を有する
と、選択的にアクセスを否定し、又は資源キー
のためのコングルーアンス・クラス・フアイル
へ待機アクセス状態を付加することによつて、
資源へのアクセスを許す。本発明を組込んだコンピユータ・システムにお
いて、資源キーを有する資源への先行するアクセ
ス要求は、第１の中央電子複合体を次のステツプ
に従つて動作させることによつて処理される。 (1) 同一の資源キーに対する他のアクセス要求に
ついてログされた保持ロツク状態が解放される
と、同一の資源キーのために待機されたアクセ
ス・リクエストが存在するかどうかを決定す
る。 (2) 第１の複合体によつてログされた待機アクセ
ス・リクエストが存在すると、先行するリクエ
ストへ資源へのアクセスを許し、待機アクセス
状態をクリアし、資源キーのためにコングルー
アンス・クラス・フアイルへ対応する保持ロツ
ク状態をログする。 (3) 第２複合体によつてログされた待機アクセ
ス・リクエストが存在すると、コングルーアン
ス・クラス・フアイルから待機アクセス状態を
クリアし、先行するアクセス・リクエストの資
源が利用可能であることを第２複合体へ通知す
る。実施例の説明本発明は、保全性を維持するとともに、故障か
らの回復を可能にしつつ、また記憶装置、通信手
段、計算装置などのコンピユータ資源を最適に使
用しながら、データ資源を共用する汎用コンピユ
ータを動作させるコンピユータ構成を提供する。米国特許出願第194483号において、包括的ハツ
シユ表を用いて共用データへアクセスする装置が
開示されている。更に上記出願において、故障時
点の間にロツクを保留し、故障に起因して矛盾を
有するに至つたデータへのアクセスを禁止し、か
つ回復を実行する装置が説明されている。本発明は、実際上汎用コンピユータ・システム
を動作させる資源ロツク・マネジヤ・モジユール
中に設けられる。資源ロツク・マネジヤ機能は、
次の手順を含む。 LOCK、UNLOCK、INQUIRY、INQRESP、
GHTUPD、GRANT、PTB、IDENT、QUIT、
VERIFY、PURGE、FAIL、RECONNECT。上記の手順は次のようなデータ・オブジエクト
（deta object）を使用する。 MCB マスタ制御ブロツク RRHT 資源ハツシユ表 GHT 包括ハツシユ表 RGHT 保留ロツク包括ハツシユ表 RHB 資源ヘツダー・ブロツク RLB 資源ロツク・ブロツク WHB 作業ユニツト・ブロツク SIDB サブシステム識別ブロツク ISL 識別サブシステム・リスト RLPL 資源ロツク・リクエスト・パラメータ・
リストこれらのデータ・オブジエクトは第２図に関連
して説明する。第２図は、IRLM６１，６２の構
成を示したものであり、各種のデータ共用及び故
障モードについて、これらデータ構造の間の関係
を説明するのに有用な図である。 RHB、RLB、WHB、SIDBは後で詳細に説明す
るように、それぞれのCECの中でダイナミツク
に構成される。図面の詳細な説明に入る前に、上記の手順を説
明しておく。 LOCK この手順は新しいロツク・リクエストのために
RLBを形成する。RLPLハツシユ値及び資源名称
を使用して、RHT−RHBを探索し、要求された
資源のためのRHBが存在するかどうかを決定す
る。包括的なロツク・リクエストを付与するた
め、IRLM制御ブロツクへ次のような変更がなさ
れる。１要求されたハツシユ値に対応するGHTエン
トリイにおいて、ロツクを付与するIRLMの関
心ビツトがオンにされる（既にオンになつてい
なければ）。２もしこのIRLMがGHTエントリイの私的使用
を有するならば、対応するRHTマスク私的使
用ビツトがオンにされる。３要求されたハツシユ値及び資源名称を含む
RHBが形成される（既に形成されていなけれ
ば）。RHB関心マスクは、どのIRLMが資源に
対してロツクを保持するかを示す。４ロツク保持手段の作業ユニツト識別情報を含
むWHBが形成される（既に形成されていなけ
れば）。WHBはリクエストしているIMS／VS
のSIDBへ接続される。５保持されたロツクを表わすためRLBが形成
される。RLBはロツクの保持された状態を含
む。RLBはRHB及びWHBへ接続される。 PTB この手順は、ロツク・リクエストが直ちに付与
されてよいが、他のIRLMとの通信を待機しなけ
ればならないか、IRLM又は通信リンクの故障に
よつて創出された事故のために拒絶されねばなら
ないかを決定する。この手順は次のようなIRLM共用モードを処理
する。１正常の共用モード＝双方のIRLMが実行中で
あり、相互に通信している。２ IRLM故障モード＝一方のIRLMが現在実行
していない。このIRLMは他のIRLMのために
暗黙的にロツクを保留している。このIRLM
は、他のIRLMの関心ビツトを含むGHTエント
リイへハツシユ値を入れた新しいRHBのため
に、ロツクを付与することはできない。３通信故障モード＝双方のIRLMは実行中であ
るが、相互に通信していない。IRLMは、通信
リンクの故障時に私的使用を有していたGHT
エントリイに対してのみロツクを付与すること
ができる。 INQUIRY この手順は、他のIRLMから送られた包括的な
ロツク照会リクエストを処理する。もし照会リク
エストが、このIRLMによつて保持されたロツク
と両立すれば、応答メツセージがリクエストを行
つたIRLMへ送られる。このメツセージは、
IRLMへロツクを付与してよい旨を通知する。そ
れは更に、IRLMが資源の上にロツクを現在保持
しているかどうかを通知する。もし照会が両立的
でなければ、RLBがその照会のために形成さ
れ、RHB待機連鎖の上に置かれる。非両立性を
生じた保持ロツクが解放されると、上記の応答メ
ツセージは照会を行つたIRLMへ戻され、今やロ
ツクを付与してよい旨を通知する。 INQRESP この手順は、包括的なロツク照会リクエストに
応答して受取られたメツセージを処理する。 UNLOCK この手順は、IMS／VSによつて出された
UNLOCKリクエストを処理する。UNLOCKリク
エストRLPLは、ロツク・トークン（LOCK手順
によつて戻されたRLBアドレス）、又はハツシユ
値、資源名称、解放されるべきロツクの作業ユニ
ツト識別情報を含む。 GRANT この手順はロツク・リクエストを受入れる。も
しリクエストがRHB待機連鎖上にあり、他の
IRLMからの照会でなければ、それはRHB保持連
鎖へ移動させられる。もしリクエストが照会リク
エストであれば、RLBは待機連鎖から除去され
かつ解放される。ロツクを受入れる旨のメツセー
ジが、照会したIRLMへ送られる。 GHTUPD この手順は、他のIRLMから受取られたメツセ
ージの内容に基づいてIRLMのGHTを更新する。 IDENT この手順はIMS／VS IDENTリクエストを処理
する。IDENTはIMS／VSをIRLMへ接続する。
IMS／VSは、他のIRLMリクエストを出す前に、
IDENTリクエストに出さねばならない。この手
順は、IMS／VSのためにSIDB（サブシステム識
別ブロツク）を形成する。双方のIRLMのISLは
更新され、IMS／VSがIDENTリクエストを出さ
れた特定のIRLMへ接続されていることを示す。
IDENTリクエストが出された時点で、IMS／VS
のためにロツクを明示的に保留する（QUIT
RETAIN）及び／又は暗黙的に保留する
（IRLM／システム／通信リンクの故障）ことと
なる以上の活動に起因して、IMS／VSのための
ISL中にエントリイが既に存在するかも知れな
い。 QUIT この手順はQUITリクエストを処理する。この
リクエストはRETAIN又はRELEASEを指定して
よい。RETAINは、そのリクエストを出した
IMS／VSによつて現在保持されている全てのロ
ツクを保留することを意味する。RELEASEは、
保持されている全てのロツク、又はこのIMS／
VSのために以前に保留された全てのロツクを解
放する（UNLOCK）ことを意味する。保持されたロツクは、WHBから関連したRLB
を除去し、ロツクを保持しているIMS／VSのISL
エントリイによつて指定された１つのダミー
WHBから、上記除去されたRLBを連鎖すること
によつて、保留されたロツクへ変換される。どのロツクが保留され又は解放されたかによつ
て、全てのWHB及びIMS／VSに関連したSIDBが
解放される。 VERIFY この手順はIRLM VERIFYリクエストを処理
する。VERIFYは、１つのIMS／VSが他のIMS／
VSの特定のデータ・ベースへのアクセスを共用
している時、上記他のIMS／VSを確実にIRLMへ
知らせるため、上記１つのIMS／VSによつて出
される。IRLMに知られていることは、IMS／VS
のためのエントリイがIRLM ISL中に存在するこ
とを意味する。ISLエントリイの存在は、IMS／
VSによつて保持されたロツクが依然として保持
又は保留されていることを確実にする。いずれかのIRLMに関連した全てのIMS／VS
は、双方のIRLMのISLにあるISLエントリイを含
むので、VERIFYリクエストを処理するため、他
のIRLMを通信する必要はない。 PURGE この手順はIRLM PURGEリクエストを処理す
る。PURGEはIMS／VS又はそれに代つて実行さ
れる回復プログラムによつて出される。PURGE
は、故障が起つたため非両立的状態に残された
IMS／VSデータ・ベースを訂正した後に出され
る。 PURGEリクエスト・メツセージは他のIRLM
へ送られる。他のIRLMによつても同じ論理が実
行される。 FAIL この手順は、他のIRLMとの通信を喪失させた
故障の検出を処理する。 RECONNECT この手順は、１つのIRLMと他のIRLMとの再
接続を処理する。この手順への入力は次のとおりである。１他のIRLMがこのIRLMとの以前の接続を記
憶しているかどうかの表示。２他のIRLMのGHTの内容。３他のIRLMのRGHTの内容。４他のIRLMのISLの内容。第１図は、DASD１３，１４に記憶されたデー
タへのアクセスを共用する複数のCEC１１，１
２を含む典型的システムを示す。それぞれの
CEC１１，１２において、多数のデータ記憶領
域及びプログラム領域を含む実アドレス又は仮想
アドレスのスペースが存在する。第１図におい
て、本発明に関連する部分は、上位オペレーテイ
ング・システム２１，２２、情報管理システム
（IMS）３１〜３４、バツフア・プール４１，４
４、データ・ベース回復制御（DBRC）システム
５１，５２、IMS資源ロツク・マネジヤ
（IRLM）６１，６２である。 IMS３１〜３４の各々は、取付ログ・テープ７
１〜７４の１つと通信することができる。CEC
１１，１２は通信制御装置２７（又はチヤネル間
アダプタ）によつて相互接続されており、共用の
DASD１３，１４及び制御データ・セツト５７を
介して柔軟結合されている。それぞれのCEC１１，１２はIBMシステム／
360又はIBMシステム／370の如き汎用中央処理ユ
ニツト、主記憶装置、仮想記憶装置、チヤネル及
び周辺装置を含む。IBMシステム／360又はIBM
システム／370のアーキテクチヤーは米国特許第
3400371号及びIBM社の出版物（例えば、IBM
Sytem／370 Principles of Operation、GA22−
7000−６）に解説されている。それぞれのCEC１１，１２はIBMシステム／
360又はIBMシステム／370オペレーテイング・シ
ステムの如き上位オペレーテイング・システム２
１，２２の制御の下で動作する。このようなオペ
レーテイング・システムはIBM社の出版物（例え
ば、出版物番号GC22−6534、GC28−0661、
GC20−1800）に説明されている。IMS31〜34は
それぞれの上位システム２１，２２の制御の下で
動作し、通信制御装置２７をインターフエイスす
るため、これらの上位システムを利用する。通信
制御装置２７は、例えばIBM3705通信制御装置で
あつてよい。本発明は、IBM社の出版物SH20−
9145−０に説明されるIBM IMS／VS（プログラ
ム製品番号5740−XX2）の使用効率を改善し、同
一又は異つたCEC上で動作を実行しているIMS３
１〜３４の間でDASD１３，１４上にあるデータ
を共用する新規な装置を提供することである。それぞれのCEC１１，１２にあるDBRCシステ
ム５１，５２は制御データ・セツト５７を共用す
る。制御データ・セツト５７は、IBM3350の如き
直接アクセス記憶装置におかれてよい。DBRCシ
ステムの例はIBM IMS／VSデータ・ベース回復
制御機能（プログラム番号5740−XX2）である。
これはIBM出版物SH35−0027−１に説明されて
おり、本発明にしたがう計算システムを動作させ
るため、関連出願に説明されているように変更さ
れる。第１図を参照して、２つのCEC１１，１２を
含む典型的計算システムの動作を説明する。故障
が存在しないものと仮定すると、１つ又はそれ以
上のアプリケーシヨン・プログラム（図示せず）
は、それぞれのCECにおいてマルチプログラミ
ング環境で動作を実行する。それぞれのCECは
IMS３１〜３４のいずれかの制御の下にある。 IMS３１の下で動作を実行しているアプリケー
シヨン作業ユニツトが、例えばDASD１３に存在
するデータ資源へのアクセスを要求する時、IMS
３１はロツク要求を発生し、線３５を介して
IRLM６１へ伝達する。ロツク要求は表１に示さ
れるように情報を含む。

【表】キー・フイールドは、アクセスが要求されるデ
ータ・ベース・レコード又は資源の名称を含む。
ハツシユ・フイールドは資源のハツシユ・クラス
（hash class）又はコングルーアンス・クラスを
含む。これらのクラスは、米国特許出願第965810
号に説明されるように、これまでに使用可能な多
くのハツシユ法の１つによつて決定される。状態
フイールドは、８つのロツク状態の１つを指定
し、データ資源が２つ以上の作業ユニツトによつ
てロツクされている時、結果の状態及び両立性
（compatibility）を決定するために使用される。
作業ユニツトが、最初のロツク要求の時とは違つ
た状態を指定して、２度目に資源をロツクする
時、データ資源が所与の作業ユニツトによつて、
２度以上ロツクされるのを許すために、ロツクが
最終的に保持される状態は、最初の状態によつて
付与された特権を失うことなく第２の状態の特権
を有するものでなければならない。これは非階層
的特権順序を許す。その順序では、それぞれの高
次の状態は先行する状態の全ての特権を必ずしも
含まない。同一の作業ユニツトによる同一の資源につい
て、ロツク要求の状態フイールドの値と、先行す
るロツク要求の状態値とは、第３の状態を得るた
め次のような結果状態マトリクスへ入れられる。
次いで、ロツク要求は第３状態へのリクエストと
してIRLM６１で処理される。

【表】２つの作業ユニツトが同一の資源へアクセスし
ている時、ロツク要求状態が両立するかどうかを
決定するため、次のようなマトリクスが使用され
る（Ｘは両立しないことを示す）。

【表】表１のロツク要求フオーマツトへ戻つて、
SIDBアドレス・フイールドは、システム識別ブ
ロツク中のメモリ・ロケーシヨンを指定し、後に
詳細に説明するように、IRLM６１の作業ヘツダ
ー・ブロツク（WHB）へアクセスするために使
用される。オプシヨン・フイールドは、ロツク要
求が条件つきであるか、無条件であるかを指定す
る。もし「条件つき」オプシヨンが指定され、資
源が前に非両立状態においてロツクされたことを
IRLMが決定すると（表３参照）、作業ユニツト
は、ロツクが付与され得ないことを通知される。
しかし、「無条件」オプシヨンが指定されたので
あれば、要求されたロツクは待機させられ、作業
ユニツトは、先行するロツクが解放されかつ待機
させられた要求が許容される時点を通知されるの
みである。ロツク要求を処理するに当つて、IRLM６１は
線２５、CEC２１、線２３、通信制御装置２
７、線２４、CEC２２、線２６を介してIRLM６
２と通信する。そのような通信が必要であるが無
用である条件は、ロツクを付与する構成及びステ
ツプとともに、後で詳細に説明する。 IMS３１へのロツクがIRLM６１によつて付与
されると、IMS３１は線８１を介してDASD１３
中の所望のデータへアクセスし、データをバツフ
ア・プール４１へ読出す。アプリケーシヨン作業
ユニツトがデータを処理している過程中約束され
た時点で、データはDASD１３へ書戻され、
IRLM６１はロツクの解放を通知される。このようにして、IMS３１〜３４はIRLM６
１，６２と協動し、DASD１３，１４上のデータ
へアクセスし、バツフア・プール４１〜４４中に
記憶されたデータ上で動作する。 IMS３１〜３４は、故障時の回復に備えて、取
付ログ・テープ７１〜７４上に全ての取引き
（transaction）のログを維持している。DBRC５
１，５２は制御データ・セツト５７へのアクセス
を共通にしており、システムの故障又はその他の
故障の場合に、後に詳細に説明するように、デー
タ・ベースの回復を制御するためIMS３１〜３４
と協動する。ここで第２図を参照すると、そこにはIRLM６
１の詳細が示される。IRLM６１は本発明に従う
コンピユータ・システムの動作中に使用される基
本データ・オブジエクトを限定する。資源ロツク要求パラメータ・リスト（RLPL）
１１０は、IRLM６１へリクエストを与えるため
IMS３１，３３によつて使用される。本実施例に
おいて、それは32ビツト資源ハツシユ値210、32
バイト資源名称、４バイトSIDBアドレス２１
１、８バイト作業ユニツト識別情報、１バイト要
求ロツク状態、オプシヨン・インデイケータ（条
件つき又は無条件）を含む。マスタ制御ブロツク（MCB）１１２は次の構
成要素及び連鎖へアドレス・ポインタ２０１〜２
０５，２６１を与える。RHT１１４、GHT１１
６、RGHT１１８、ISL１２０、SIDB１２２
（SIDB１２２，１２４、連鎖２１２の最切のも
の）、及びRLB１６１（他のIRLM６２からの要
求に対応する待機RLB１６１，１６５，１６
７、連鎖２６２〜２６３における最初のもの）。資源ハツシユ表（RHT）１１４は512個のエン
トリイを含む。それぞれのエントリイは８バイト
長であり、32ビツト・マスク（４バイト）及び対
応するRHTハツシユ・クラス（ハツシユ群又は
コングルーアンス・クラスとも呼ばれる）におけ
る最初のRHB１４０及び１４４に対する４バイ
ト・ポインタ（例えば２２０，２２２）を含む。
RHTビツト・マスク中の各ビツトは、GHT１１
６における16384個のエントリイの１つに対応
し、それがセツトされていれば、後に詳細に説明
するように私的使用インデイケータを示す。包括ハツシユ表（GHT）１１６は16384個のエ
ントリイを含む。それぞれのエントリイは１バイ
ト長であり、その各ビツトは１つのIRLM識別情
報（IRLMID）に対応する。しかし本実施例にお
いては、２個のビツトが使用される。１つのビツ
トはIRLM６１のためのIRLMID＝１に対応し、
他のビツトはIRLM６２のためのIRLMID＝２に
対応する。GHT１１６中のビツトがオンであれ
ば、それは対応するIRLMIDを有するIRLM６
１，６２が少なくとも１つの資源上でロツクを保
持し（及び／又は）待機していることを意味す
る。このロツクはGHT１１６のエントリイへ入
れられている。保留ロツク包括ハツシユ表（RGHT）１１８は
16384個のエントリイを含む。GHT１１６と同じ
ように、RGHT１１８中のそれぞれのエントリイ
は１バイト長であり、本実施例においては、２個
のビツト０及び１が使用される。ビツト０は
IRLM６１のためのIRLMID＝１に対応し、ビツ
ト１はIRLM６２のためのIRLMID＝２に対応す
る。RGHT１１８におけるエントリイ中のオンの
ビツトは、対応するIRLMIDを有するIRLM６
１，６２が少なくとも１つの資源上でロツクを保
持（及び／又は）待機していことを意味する。そ
のロツクは、IRLMが故障した（異常状態で終了
した）時点で、上記RGHTエントリイに対応する
GHTエントリイへ入れられたものである。ビツ
トがオンのRGHTエントリイへ入れられたロツク
に対しては、新しいロツク要求は付与されない。識別サブシステム・リスト（ISL）１２０は、
IDENT手順によつて限定されたエントリイのリ
ストである。それぞれのIRLM６１，６２はISL
１２０と同じものを含む。ISL１２０は双方の
IRLMに関連した全てのIMS３１〜３４を示す。
ISL１２０のエントリイは次のようである。 (1) ８バイトIMS３１〜３４の名称。 (2) IMS３１〜３４が接続される又は最後に接続
されていたIRLM６１，６２のIRLMID。 (3) １バイトの「QUIT RETAIN保留」マス
ク。その各ビツトは、GHTエントリイの場合
と同じように、IRLMへ割当てられ、このマス
クのビツトがオンであることは、明示
QUITRETAIN要求によつて、対応するIRLM
６１，６２がこのIMS３１〜３４のためにロツ
クを保留されていることを意味する。 (4) １バイトの「IRLM乃至通信故障保留」マス
ク（ISLFMSK）。その各ビツトは、GHTエン
トリイの場合と同じように、IRLMへ割当てら
れ、このマスクのビツトがオンであることは、
対応するIRLMがこのIMSのためのロツクを保
持していたこと、及びIRLM乃至システム乃至
通信故障が生じたことを意味する。 (5) ダミーのWHB１３０へ行く４バイト・ポイ
ンタ２２３。WHB１３０から保留ロツクRLB
１５６，１５３、連鎖２５１，２５２が接続さ
れる。これはQUIT RETAINの場合にのみ存
在する。即ち、後に詳細に説明するように、
QUIT要求が出された時、IMS３１〜３４が接
続されたIRLM６１，６２のISL１２０にのみ
存在する。 IMSサブシステム識別ブロツク（SIDB）１２
２，１２４は、IMS３１〜３４がIRLMへ通知さ
れた後、IRLM６１又は６２によつて構築され
る。IMSの作業ユニツトに対するWHBは、この
ブロツクから連鎖される。例えば、SIDB１２２
はWHB１３２へ連鎖され２１３、SIDB１２４は
WHB１３４及び１３６へ連鎖される２１４及び
２１５。それぞれの作業ユニツト・ブロツク（WHB）
１３２，１３４，１３６は、ロツクを保持し（及
び／又は）待機しているIMS作業ユニツトを表わ
し、WHBに関連した全ての保持及び待機RLBの
連鎖を含む。例えば、待機RLB１６６，１６
３，１６０及び保持RLB１５１，１５４はWHB
１３６へ連鎖される２３１，２３２，２３３，２
３４，２３５。保持RLB１５５，１５２，１５
０はWHB１３２へ連鎖される２４１，２４２，
２４３。資源ヘツダー・ブロツク（RHB）１４０，１
４２，１４４は、ロツクが要求され（及び／又
は）保持されている。それぞれの資源名称のため
に創出される。複数のハツシユ群の１つ（RHT
エントリイの１つに対応する）に属する全ての
RHBはRHB連鎖を形成する。それぞれのRHBは
次のようなエントリイを含む。 (1) 資源ハツシユ値（32ビツト）。 (2) 資源名称（32ビツト）。 (3) IRLM関心マスク。これはGHTエントリイの
場合と同じように使用される。このマスクのビ
ツトのオンは、対応するIRLMがこの資源上で
ロツクを現在保持していることを意味する。 (4) RHB連鎖ワード。これは同じRHTエントリ
イへ入れられるRHBの連鎖を維持するために
使用される。例えば、RHB１４０はRHB１４
２へ連鎖され２２１、RHT１１４中のエント
リイへ接続される２２０。RHB１４４はRHT
１１４中の異つたエントリイへ接続され２２
２。 (5) RHBをロツク保持RLB及びロツク待機RLB
の連鎖へつなぐ待機RLB連鎖ワード及び保持
RLB連鎖ワード。例えば、RHB１４０は、ロ
ツク保持RLB１５０〜１５１へ連鎖され、か
つロツク待機RLB１６０〜１６１へ連鎖され
る１６８。RHB１４２は、ロツク保持RLB１
５２〜１５４へ連鎖され１５７、かつロツク待
機RLB１６３，１６５へ連鎖される１６９。
RHB１４４は、ロツク保持RLB１５５，１５
６へ連鎖され１５８、かつロツク待機RLB１
６６，１６７へ連鎖される１７０。それぞれの資源ロツク・ブロツク（RLB）
は、ロツクの保持手段又はロツクを獲得するため
のリクエスト待機手段を表わしている。それぞれ
のRLBはロツク状態を含む。第２図のデータ構成は、例えば１つのIRLM６
１の典型的構成を表わし、他のIRLM６２につい
ても同様の構成が存在する。いくつかのデータ・
オブジエクトは同期を維持され（即ち、実質的に
同一）、従つて正常な処理過程で通信の遅延が生
じてもよい。これに該当するものはGHT、
RGHT、ISLなどである。 IMS資源ロツク・マネジヤIRLM６１，６２は
IMS３１〜３４のデータ共用機能によつて使用さ
れるロツク・サービスを与える。ロツク・サービ
スはIMSサブシステム、VTAM、システム間通信
リンク、MVSなどの故障時にロツクを保留する
ことを含む。保留されたロツクは、故障のために
矛循を有するかも知れないデータ・ベース
（DASD１３，１４）情報へのアクセスを禁止す
る。 IMS／VS共用データ環境におけるデータ・ベ
ース情報の保全性は、DL／Ｉデータ管理機能
（IMS３１〜３４の構成要素）、DBRC５１，５２
及びIRLM６１，６２の共同責任である。 DL／Ｉ（IMSの構成要素）はDASD１３，１
４へのアクセスを実行し、各種の故障が発生した
時、データ・ベースを回復乃至修復するために使
用される取引ログ・テープを維持する。 DBRC５１，５２はデータ・ベース・データ・
セツトの使用情報を保持する。この情報は、どの
IMS／VSサブシステムが現在各々のデータ・セ
ツトを使用しているかを示す。IMS３１〜３４
は、DASD１３，１４上でデータ・セツトを割当
てる時、DBRC５１，５２を呼出す。データ・セ
ツトを割当てる時、DBRC５１，５２は、現在デ
ータ・セツトを使用しているIMS３１〜３４の名
称を含むリストを、IMS３１〜３４へ戻す。IMS
３１〜３４は、IMS３１〜３４の名称リストを送
ることによつて、IRLM６１〜６２のサービス
（VERIFY）を呼出す。IRLMは、リスト中のそ
れぞれのIMS３１〜３４が現在IRLM６１〜６２
のサービスを使用しているかどうかを示す表示
を、IMS３１〜３４へ戻す。IRLM６１，６２の
サービスの使用は、IMSがIRLMを使用している
時故障が生じ、IRLMがそのロツクを保持してい
る場合が含まれる。IMS３１〜３４のいずれも
IRLM６１〜６２によつて知られていなければ、
IMS３１〜３４はデータ・セツトを割当てない。
これが必要である理由は、IRLM６１〜６２が
IMS３１〜３４の各々のためにロツクを保持する
のでなければ、データ・セツトの継続的使用が、
データの保全性を危険にするからである。前述したように、それぞれのIRLM６１，６２
は、IMS／VS識別サブシステム・リスト（ISL）
中に、２システム環境において２つのIRLMのい
ずれかへ現在接続されている全てのIMS３１〜３
４のリストを保持している。ISL１２０は、入力
リスト中のIMSサブシステム名称がISL１２０中
にあるかどうかを決定するため、VERIFYリクエ
ストを処理するために使用される。それぞれの
IRLM６１，６２はそこに接続されたIMS３１〜
３４のためのロツクを保持する。IRLM６１，６
２はGHT１１６及びRGHT１１８と同じものを
含む。 ISL１２０、GHT１１６、RGHT１１８はシス
テム間通信、サブシステム、及び／又はシステム
の故障時にロツクを保護する情報を与える。これ
については、関連出願に詳細に説明されている。今から図面を参照して、本発明の基本的構成及
び動作を典型的な場合について説明する。２つのCEC上で実行されている複数の作業ユ
ニツトにより共用されたデータ資源へ複数の同時
的アクセスを行うことは、それぞれのCECに特
別の資源ロツク・マネジヤ（IRLM）を設け、通
信量を最少にし、かつロツク・データを記憶する
ためそれぞれのCECで必要となるスペースを最
適に利用しながら制御することができる。上記の
IRLMは包括ハツシム表（GHT）を含み、この
GHTは、それぞれのコングルーアンス・クラス
におけるそれぞれのIRLMのための関心ビツト
と、資源ヘツダー・ブロツク（RHB）及び作業
ユニツト・ブロツク（WHB）に関連した保持資
源ロツク・ブロツク（held RLB）及び待機資源
ロツク・ブロツク（wait RLB）の連鎖のための
関心ビツトとを含んでいる。RHBは連鎖される
とともに資源ヘツダー表（RHT）へ接続され、
RHTはGHT中のそれぞれの対応するエントリイ
のために排他的使用ビツトを含む。WTBは、サ
ブシステム識別ブロツク（SIDB）へ接続され
る。WHBへ接続されないで、他のIRLMからのリ
クエストに関連している待機RLBは相互に連鎖
される。上記の構成におけるロツク要求について、次に
説明する。以下の説明において、IRLM６２に関
して第２図に示されるデータ構造は、「′」を付す
ることとする。従つて、IRLM６１のGHTは
GHT１１６であるから、IRLM６２のGHTは
GHT１１６′となる。ケース例えば、作業ユニツトのためにRLPL１１０を
IRLM６１へ与えることにより、IMS３１がデー
タ資源Ｎ１に対するロツクを要求したとする。こ
の場合、２つのIRLM６１，６２におけるハツシ
ユ・クラスＨ１のためのGHT１１６，１１６′の
エントリイは00であると仮定するRLB１５４ａ
がリクエストのために創出され、データ資源Ｎ１
のために連鎖１６９中に置かれる。PTB手順
は、Ｈ１のためにIRLM６１中でGHT１１６のエ
ントリイを10にセツトし、更新されたGHT１１
６のエントリイを通信制御装置２７を介して
IRLM６２へ送る。IRLM６２は、GHTUPD手順
を実行して、Ｈ１のためにGHT１１６′のエント
リイを10にセツトする。IRLM６１はＮ１のため
にIMS３１へロツクを付与し、要求されたデータ
資源のハツシユ・クラスＨ１のためにRHT１１
４中で私的使用ビツトをオンにセツトし、リクエ
ストのためのRLB１５４ａを待機連鎖１６９か
らRHBのための保持連鎖１５７へ移動させる。
IRLM６２において、RHT１１４′へのエントリ
イはなされず、RLBも創出されない。ケースケースによつて創出された条件が存在するも
のと仮定し、IMS３２によつてIRLM６２へのリ
クエストがなされたものと仮定する。サブケース
Ａにおいては、リクエストはケースと同じよ
うに同一のデータ資源Ｎ１のためになされる。サ
ブケースＢにおいては、同一のハツシユ・クラ
スＨ１を有する異つたデータ資源Ｎ２のためにな
される。サブケースＡ IRLM６２は、RLB１５４a′を創出し、それを
資源Ｎ１のRHB１４２′のための待機連鎖１６
９′中に置く。次いで、それはハツシユ・クラス
Ｈ１のためのGHT１１６′のエントリイを10から
11へ変更し、IRLM６１へGHT更新リクエストを
送り（GHTUPD手順）、かつ質問リクエストを送
る（PTB手順）。IRLM６１はIRLM６２の関心を
反映させるためそのGHTを更新する（GHT１１
６＝11）。更にそれは質問を処理する（INQUIRY
手順）。INQUIRY手順は、このサブケースＡに
おいて、ロツクがIRLM６１によつて付与された
データ資源Ｎ１についてリクエストがなされたこ
とを決定する。従つて、それは、このリクエスト
が前に付与されたロツクと両立する（両立状態）
かどうかを決定するため、保持RLB１５２〜１
５４にアクセスする。状態が両立的であるると仮
定すると、IRLM６１中の資源に対するRHB１４
２におけるIRLM関心マスク１９３は、IRLM６
２′の関心を示すためセツトされ、IRLM６２
は、それがロツクを付与することができる旨を通
知される。IRLM６２は、IRLM６１の関心を示
すため、その資源のためにRHB１４２′における
IRLM関心マスク１９３′をセツトし、RLB１５
４a′は待機RLB連鎖１６９′から保持RLB連鎖１
５７′へ移動させられ、IMS３２へロツクが付与
される。上記の状態が成立して、同一のデータ資源Ｎ１
を使用するためリクエストがIRLM６１へなされ
たものと仮定する。データ資源Ｎ１はIRLM６２
中に保持されているＮ１を先行するロツクと両立
しない状態を有している。IRLM６２′の関心ビ
ツトはGHT１１６中でオンであるから（Ｈ１に
ついてGHT１１６＝11）、IRLM６１は、名称Ｎ
１、ハツシユ・クラスＨ１、状態、及びオプシヨ
ン（無条件と仮定する）を指定してロツク・リク
エストをIRLM６２へ送る。RLB１６３が創出さ
れ、RHBのために待機連鎖１６９に置かれる。
IRLM６２において、RLB１６５′が創出され、
RHB１４２のための待機連鎖１６９へ加えられ
る。それはRHB１４２′のための保持連鎖１５
７′にあるRLB１５４′に対応するロツクと両立
しない状態の場合であるから、RLB１６５′は、
MCB１１２′へ接続された待機RLB連鎖へ加えら
れる（WHBではなく）。IRLM６２からIRLM６
１への応答はなされず（リクエストは無条件）、
正常な処理において、RLB１５４′の保持手段が
UNLOCKリクエストを出すまで、（UNLOCK手
順）、ロツク・リクエストは停止される。IRLM
６２はRLB１５４′を解放する。RHB１４２′の
ための保持連鎖１５７′中に他のRLB′が存在しな
いか、RLB１６５′がRHB１４２′のための待機
連鎖１６９′の最上部にあり、かつRHB１４２′
のための保持連鎖１５７′中にあるRLBと両立す
る状態であると仮定すれば、RLB１６５′が解放
され、それがデータ資源Ｎ１のために前に要求さ
れたロツクを付与することができる旨をIRLM６
１へ知らせる。RLB１６５′が唯一の待機RLBで
あり、RHB１４２′のための保持RLBが存在しな
ければ、RHB１４２′も解放される。更に、
IRLM６２はGHT１１６′にあるＨ１のための関
心ビツトをリセツトし（Ｈ１についてGHT１１
６′＝10）、Ｈ１についてGHT１１６＝10をセツ
トするようにIRLM６１へ命ずる。ここで注意す
べきは、IRLM６２において保持RLB Ｎ１のた
めの保持連鎖へ加えられておらず、IRLM６１で
は加えられていることである。（即ち、RLB１６
５は、図示されるように、待機連鎖からRHB１
４２のための保持連鎖１５７へ動かされる）。こ
の状態において、ハツシユ群Ｈ１についてGHT
１１６＝GHT１１６′＝10であるから、IRLM６
１はデータ資源ハツシユ群Ｈ１を私的に使用する
ことができる。対応する関心ビツトはRHT１１
４＝１であり、RHT１１４′＝０である。サブケースＢこの例において、上記の状態が成立しているも
のとして、WHB１３６′の作業ユニツトのため
に、異つたデータ資源Ｎ２に対するロツク・リク
エストが、IMS３２によつてIRLM６２へなされ
る。データ資源Ｎ２は、前のリクエストと同じ
GHT１１６′のエントリイへハツシユ値Ｈ１を入
れられている。最初、データ資源Ｎ１，Ｎ２のハ
ツシユ群Ｈ１について、GHT１１６＝GHT１１
６′＝10である（IRLM６１は関心ビツトをオン
にされ、IRLM６２はオンにされていない）。
IRLM６２はＨ１のためにGHT１１６′＝11をセ
ツトし、待機RLB１５１a′をRHB１４０′（デー
タ資源Ｎ２のためのRHB）のための待機連鎖１
６８′へ加えWHB１３６′（図示されず）に関し
ては、GHT１１６を更新するためIRLM６１へリ
クエストを送り、かつハツシユ群Ｈ１のデータ資
源Ｎ２に対するロツク・リクエストを送る。 IRLM６１はGHT１１６を更新し（ハツシユ群
Ｈ１についてGHT１１６＝11）、RHT１１４中に
対応するマスク・ビツトをリセツトし（IRLM６
１はハツシユ群Ｈ１を私的に使用しないので）、
Ｎ２をキーとして有するRHBを求めて、ハツシ
ユ群Ｈ１に対応するRHT１１４へ接続された
RHB連鎖を探索する。IRLM６１においてデータ
資源Ｎ２のためのRHBが存在しないものと仮定
すると、IRLM６１はIRLM６２に応答して、ロ
ツクを付与することが可能であることを知らせ
る。IRLM６１はロツクされた資源を識別しな
い。次いで、IRLM６２はRLB１５１′を待機連鎖
１６８′からRHB１４０′のための保持連鎖１５
６′へ動かしロツクを付与する。第２図に示され
るように、今やRLB１５１′はWHB１３６′へ接
続された連鎖の中にある。２つの中央電子複合体（CEC）の上で動作し
ている複数の作業ユニツトによつて共用されたデ
ータ資源への複数の同時的アクセスは、最少の通
信を実行し、かつロツク・データを記憶するため
各複合体で必要とされるスペースを最適に利用し
つつ制御される。それが可能となるのは、各複合
体が資源ロツク・マネジヤ（IRLM）を有するか
らである。IRLMは、各コングルーアンス・クラ
スにおける各CECのIRLMに対する関心ビツトを
含む包括ハツシユ表（GHT）と、資源ヘツダ
ー・ブロツク（RHB）及び作業ユニツト・ブロ
ツク（WHB）に関連した「保持」及び「待機」
の資源ロツク・ブロツク（RLB）の連鎖とを含
む。RHBは連鎖されるとともに、資源ヘツダー
表（RHT）へ接続され、RHTは、GHT中のそれ
ぞれの対応するエントリイのために排他的使用ビ
ツトを含む。WHBは、システム識別ブロツク
（SIDB）へ接続される。WHBへ接続されない待
機RLB、即ち他のIRLMからのリクエストに関連
した待機RLBは相互に連鎖される。作業ユニツトによつてデータ資源へアクセスす
るための第1IRLMのリクエストは、第1IRLMが
コングルーアンス・クラスの排他的又は私的使用
を有するかどうかを、RHT／GHTから決定する
ことによつて処理される。もし排他的又は私的使
用を有すれば、リクエストは第1IRLM内で処理
される。もし排他的又は私的使用を有しておら
ず、第2IRLMがコングルーアンス・クラスに関
心を有すれば、第1IRLMへ通知が出され、第
1IRLMはそのリクエストを処理する。もしロツク・リクエストがいずれかのIRLMに
よつて以前に非両立状態へロツクされていないデ
ータ資源に対するものであれば、そのリクエスト
は許され、かつデータ資源のRHBに対するRLB
保持連鎖エントリイが第1IRLMの中で創出され
る。他方、もしロツク・リクエストがいずれかの
IRLMに保持されたデータ資源上のロツクと非両
立的であれば、RLBエントリイが、そのリクエ
ストのために、非両立的な保持RLBを有する
RHBの待機連鎖へ加えられる。通信及びロツク
維持処理を最適化するため、第2IRLMは第
1IRLMによつて付与された保持PLBを保存せ
ず、第1IRLMのために待機RLBを保存する。こ
うして、第2IRLMは、非両立的な保持ロツクが
解放される時点を第1IRLMへ知らせるようにさ
れる。産業上の応用性本発明は、マルチプロセシング／マルチプログ
ラミング環境において、データが複数の中央電子
複合体によつて共用されるコンピユータ・システ
ムに応用できる。本発明の装置は、同一又は異つ
たCEC上で動作している２つ以上の作業ユニツ
トによつて、両立しない同時的アクセスがなされ
る場合に、特定のデータ資源をロツクする。

【図面の簡単な説明】

第１図は本発明の装置を含む典型的コンピユー
タ・システムのブロツク図、第２図は第１図の資
源ロツク・マネジヤ６１，６２のブロツク図であ
る。１１，１２……CEC（中央電子複合体）、１
３，１４……DASD（直接アクセス記憶装置）、
２１，２２……上位オペレーテイング・システ
ム、２７……通信制御装置、３１，３２，３３，
３４……IMS（情報管理システム）、４１，４
２，４３，４４……バツフア・プール、５１，５
２……DBRC（データ・ベース回復制御システ
ム）、５７……制御データ・セツト、６１，６２
……IRLM（IMS資源ロツク・マネジヤ）、７１，
７２，７３，７４……取引ログ・テープ、１１０
……RLPL（資源ロツク・リクエスト・パラメー
タ・リスト）、１１２……MCB（マスタ制御ブロ
ツク）、１１４……RHT（資源ハツシユ表）、１
１６……GHT（包括ハツシユ表）、１１８……
RGHT（保留ロツク包括ハツシユ表）、１２０…
…ISL（識別サブシステム・リスト）、１２２，
１２４……SIDB（サブシステム識別ブロツク）、
１３０，１３２，１３４，１３６……WHB（作
業ユニツト・ブロツク）、１４０，１４２，１４
４……RHB（資源ヘツダー・ブロツク）、１５
０，１５１，１５２，１５３，１５４，１５５，
１５６，１６０，１６１，１６３，１６５，１６
６，１６７……RLB（資源ロツク・ブロツク）。

Claims

【特許請求の範囲】

１通信リンクによつて相互接続されかつ２つの
コングルーアンス・クラスに構成された資源へ共
通にアクセスする第１及び第２の中央電子複合体
を含むマルチプロセシング／マルチプログラミン
グ・コンピユータ・システムで動作する共用資源
ロツキング装置にして、上記中央電子複合体の
各々に設けられ上記コングルーアンス・クラスの
各々における各中央電子複合体の関心情報を記憶
する手段と、上記第１の中央電子複合体が私的使
用を有するコングルーアンス・クラスの資源が上
記第１の中央電子複合体によつてリクエストされ
たことに応答して上記第１の中央電子複合体の中
に維持されたロツク・レコードに基づいて選択的
にリクエストを付与し又は待機する手段と、上記
第２の中央電子複合体が関心を有するコングルー
アンス・クラスの資源が上記第１の中央電子複合
体によつてリクエストされたことに応答してリク
エストを上記第２の中央電子複合体へ通知し上記
第１又は第２の中央電子複合体の中に維持された
ロツク・レコードに基づいて選択的にリクエスト
を付与し又は待機する手段とを具備する共用資源
ロツキング装置。