JPH0296839A - Ｔｐキューレポジトリ用シングルキー式索引ファイル - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 （産業上の利用分野） 本発明は一般に分散演算に関し、さらに詳しくはトラン
ザクション処理（ＴＰ）に関する。特に本発明は、デー
タ処理タスクまたはトランザクション用の一連の要求を
保持するキュー（待ち行列）をサーチする方法に関する
。

（従来の技術） キューは、データプロセッサによって行われるべきタス
クなど、システム内でサービス（処理）を待っている一
列状の項目である。キューには、エントリの一部の特性
に従ってキュー内のエントリを順序付ける待ち合わせ規
則が付属されている。

−ｉ的な待ち合わせ規則には、優先順位、先入れ先出し
くＦＩＦＯ）、及び後入れ先だしくＬＩＰＯ）が含まれ
る。

データ処理タスク用のサービスキューでは一般に、優先
順位とＦＩＦＯ規則との複合方式を採用している。低い
優先順位の要求の後に入れられても高い優先順位の要求
の方が先に処理されるように、タスクにそれぞれの優先
レベルが割り当てられる。但し、同じ優先レベルのタス
クはＦＩＦＯベースで処理される。

一部のサービスキューでは、タスクが処理されている間
キューの先頭にタスクを置いておき、タスクの処理が完
了した後そのタスクをキューから取り出すのが望ましい
。タスクが首尾よく処理されないと、その処理はサービ
スキューから取り出される前に、“エラーキュー”に移
される。一般に、サービスキューは非揮発性つまり永久
型メモリ内に保持されているので、部分的なシステム故
障が発生した場合、故障時に実行されていたタスクのレ
コードとまだ実行されていないタスクのレコードが残さ
れている。中断されたタスクの結果は、タスクが完了し
たかどうか、中間地点から再スタートできるかどうか、
あるいは中間結果を廃棄した後初めから再スタートしな
ければならないかどうか、を検査して判定することがで
きる。次いで、キューに残っているタスクも実行できる
。

゛キー索引ファイル”として知られる非常に有用なデー
タ構造は、データレコードへのランダム及び逐次両方の
アクセスを与えるキューとして編成されている。データ
レコードは“−次キー”によって順序付けられた一次索
引構造内に記憶され、代替キーによって順序付けられた
代替索引構造を通じても検索できる。代替データ構造は
データレコードを含まず、その代わりにデータレコード
への適切なポインタを含んでいる。キー索引ファイルを
管理するソフトウェア機構は一般に、２つのレコードが
同一のキーを持つのを可能とするオプションを与えてい
る；この場合には、先入れ先出し順序で検索できるよう
にレコードが記↑αつまり索引付けされる。このため、
サービスキューは、−次キーとして優先順位番号を用い
たキー索引ファイルとして実施されていた。

（発明が解決しようとする課題） データ処理のアプリケーション、特に分散演算では、一
般に固有の識別番号がコンピュータシステムによって実
行される各タスクまたはトランザクションに割り当てら
れている。またこのようなシステムにおいては、−組の
プロセッサから別の一組のプロセンサへタスクデータを
転送するのに、キューが一般に使われている。多くのア
プリケーションで、あるタスクの処理は別のタスクのタ
スクデータにアクセスできること、例えばタスク間でデ
ータを共有したり、タスク実行の優先順位を変更したり
、あるいは不要になったタスクを取り消したりできるこ
とが望ましい。指定されたタスクをサービスキューでサ
ーチするためには、サービスキューを、−次キーとして
タスク優先レベルを用い、代替キーとしてタスク識別番
号（ＴＤ）を用いたキー索引アアイルとし得る。しかし
、２つのキーを用いると、タスクがキューに挿入された
りまたはそこから取り出される毎に代替キーの索引を更
新する必要があるため、メモリアクセス速度が減少する
。

（課題を解決するための手段） タスクキューはシングルキー式索引ファイルとして構成
され、キーは優先レベルを示す最上位部と、タスクのキ
ュー内へのロードによって順序付けられた下位部とを有
する。キュー内のある与えられたタスクレコードの場合
、キーの下位部はそれぞれのタスク識別子から判定でき
る。キーの下位部は、タスクの発生された現在日付とデ
ータプロセッサの内部２４時間クロックの表示とを含む
“時間スタンプで、またタスク識別番号は、システムが
同時に異なるタスクを発生可能な複数のプロセンサを有
する場合、上記の時間スタンプにノード番号を付加する
ことによって形成されるのが好ましい。このシングルキ
ーのフォーマットは、同じ優先順位を持つレコードのブ
ロック内で、キーの下位部に関して連続的なキュー内レ
コードの内部順序付けを生しる。このため、キュー内の
各タスクレコード毎のキーとタスク識別番号との間の関
係から、要求されたタスク識別番号を持つレコードをす
ばやくサーチすることができる。

キー索引ファイルへアクセスするための通常のメモリ管
理機構が、キューをサーチするのに使える。キューはま
ず、ランダムつまり“キーネキスト”アクセスによって
サーチされる。要求されたキーの下位部は、所望なタス
ク識別番号から求められた下位部と必ず等しい。キーの
優先順位フィールドが、最高の優先順位にまずセットさ
れる。

要求されたキーの下位部がレコードの対応フィールドと
合致しないと、キーの優先順位フィールドは、各“キー
ネキスト”アクセス後少なくとも１レベル変えられる。

ランダムアクセスは、要求されたキーの下位部がレコー
ドの対応フィールドと合致するまで続けられる。要求さ
れたタスクの識別番号がレコードのタスク識別フィール
ドと合致したら、それが所望のレコードである。要求さ
れたタスクの識別番号がレコードのタスク識別フィール
ドと合致しなかったら、サーチは逐次つまり“ネキスト
レコード”アクセスによって続けられる。逐次サーチ中
にキーが変わったら、“キーネキスト”アクセスによっ
てサーチが続けられる。

サーチ処理は、所望のレコードが見つかるか、あるいは
ファイルの終わりに達するまで続けられる。

これは、まずキーの合致をサーチし、その後キー合致し
たレコードについてタスク識別番号との合致をサーチす
ることと同等である。

発明のその他の目的及び利点は、以下の詳細な説明と添
付の図面を参照することによって明かとなろう。

（実施例） 発明の各種の変形及び代替の態様を取り得るが、その特
定の実施例を例示として図面に示し、以下詳しく説明す
る。しかしもちろん、発明はここに開示する特定の態様
に限られず、逆に発明は特許請求の範囲に限定される発
明の精神及び範囲内に入る全ての変更、同等及び代替物
を包含するものである。

第１図を参照すると、全体が１０で表わされ、本発明の
各種特徴を具備したトランザクション処理システムのブ
ロック図が示しである。トランザクションは、単位とし
て実行されるかあるいは全く実行されない一連のオペレ
ーションである。すなわち、“クラッシュ５などの部分
的なシステム故障が生じた後、システムが再スタートさ
れる場合、データベースはクラッシュによって中断され
たトランザクションの更新を含まないが、クラッシュの
前に完了された全トランザクションの更新全てを含む。

トランザクションは一般に、１つの−７１（ｃｏｎ−ｓ
ｉｓＬｅｎｔ　）状態から別の一貫状態へデータベース
を変換する必要のある一組のオペレーションを含んでい
る。このため、データベースの各−貫状態は、自然界の
トランザクションつまり実在物をモデル化したオブジェ
クトの容認状態を表す場合がある。例えば会計上のトラ
ンザクションシステムでは、第１勘定の借方記入と第２
勘定の貸方記入が共に、１つの容認状態から別の容認状
態へ勘定の状態を変換するように行われねばならない。

従って、システムの１クラツシユ”後、かかる勘定は、
第１の勘定が借方記入されたが、第２の勘定が貸方記入
されていない矛盾状態となるべきでない。こうなると、
両勘定の貸借が合わなくなるからである。

一組のデータ処理のオペレーションをトランザクション
として定義するため、それらのオペレ−ジョンは、“回
復ユニット”を開始及び終了させる特別の命令によって
区切られた回復ユニット内の一組のプログラム命令を実
行することによって行われる。これらの命令は、データ
ベースを編成し、回復ユニット内の命令によるデータベ
ースの更新全てが同時に行われたように現れる方法でデ
ータベースのアクセスを制御するメモリつまりデータベ
ース管理機構によって認識される。この点ハ基本レベル
において、データベースがレコードまたはファイルへの
各スイッチまたはポインタによって定義され、１つのス
イッチまたはポインタを１回の“アトミック”オペレー
ションで変えることによって全ての更新を同時に行える
ことから生じる。このため、所望の変更はまず、システ
ム内におけるオブジェクトの状態の永久レコードについ
て同時に全て切り換えまたは置換可能な、代替または複
製のデータベースレコードに対してなされる。

広範囲のオペレーションを有する“回復ユニット”が周
知で、市販されているので、コンピュータのプログラマ
は、データベースを一貫して更新するのに使われる内部
機構に関して懸念する必要はない。例えば代表的な“回
復ユニット”機構は、米国マサチューセッツ州０１７５
４、メイナード所在のデジタル・エクイソブメント社か
ら市販されているレコード管理サービス（ＲＭＳ）ソフ
トウェアの１回復ユニットジャーナル（動作記録）″機
能である。

トランザクション処理の“回復ユニット”機能が特定の
アプリケーションで重要でないとしても、トランザクシ
ョン処理の手法によってアプリケーションに与えられる
構造と編成が、アプリケーションソフトウェア及びアプ
リケーションデータベースの使用と保守を容易にするこ
とがある。つまり、データ処理のオペレーションを個々
のトランザクションへ細分することで、システムによっ
て管理されるオペレーション及びデータが一貫した状態
に保たれる。また、データ処理のオペレーションが個々
の単位に細分されるため、トランザクションを定義する
プログラミングを変えずに、システムの構成を拡張また
は変更可能である。

一般にトランザクション処理は、システムが中から多数
のユーザを同時にサポートしなければならなかったり、
データ処理のオペレーションが同−組のデータファイル
またはデータベースを用いるトランザクションに細分さ
れていたり、さらにデータ処理のオペレーションが予め
定義された構造化作業を含む場合に、時分割またはバ・
７チ処理などの択一方式よりも好ましい。トランザクシ
ョン処理は、例えばインベントリ　（在庫）システム、
予約システム、及びその他のデータベース管理システム
において有用である。

ユーザは一般に、端末に表示された書式に情報を入力す
ることによって、トランザクション処理システムでのト
ランザクションを開始する。この目的のため、第１図の
システムＩＱは５つの画像表示端末１１〜１５を含んで
いる。システム１０が情報を処理して、アプリケーショ
ンデータベース１６内の１つ以上のファイルと対話する
。

トランザクション処理システムの性能は、データベース
及び演算機能と別個に、端末及びメニュー機能を実行す
ることによって向上可能である。

例えば第１図に示すように、システム１０はアプリケー
ジタンデータベース及び演算プロセス１８と別個に、端
末及びメニュープロセス１７を有する。端末及びメニュ
ー機能を制御するプロセス１７がトランザクション処理
システムの“フロントエンド”と称され、データベース
及び演算プロセス１８が同システムの“バンクエンド”
と称される。

端末及びメニュープロセス１７とアプリケージタンデー
タベース及び演算プロセス１８は、別個のデータプロセ
ッサによっと実施することもできるし、あるいは多重処
理環境をサポートするオペレーティングシステムを備え
た単一のデータプロセッサによって実施することもでき
る。単一ブロセソサを用いたシステム１０は“単一ノー
ド１システムと称され、１つより多いデータベース・ノ
サを有するシステムは“多重ノード”システムまたはネ
ットワークと称される。多重ノードシステムでは、端末
及びメニュープロセス１７を１つのコンピュータまたは
一組のコンピュータにインストールし、アプリケーショ
ンデータベース及び演算プロセス１８を別の１つのコン
ピュータまたは別の一組のコンピュータにインストール
することによって、システムの性能及び資源共用が改善
される。

システム１０の性能をさらに向上させるため、端末及び
メニュープロセス１７によって与えられるデータは、“
タスクキュー”１９を介してアプリケーションデータベ
ース及び演算プロセス１８に伝送される。システム性能
は特に、データの検索とデータの据置処理、高いアプリ
ケーションの利用性及びトランザクションの持続性を必
要とするトランザクション処理のアプリケーションにお
いて改善される。このようなアプリケーションの例は、
勤務交替時間だけの非常に短い時間中にシステムに入力
されるタイムカードデータの処理である。このようなア
プリケーションでは、各データ項目の処理がシステムの
全体性能に即座に悪影響を及ぼすことがあるので、以後
の処理のためデータを検索してからそれをタスクキュー
１９内に記ｉｔできることが有用である。この種の処理
は、データの検索とデータの処理が同期されていないた
め、“非同期処理”としても知られでいる。

タスクキュー１９は、端末及びメニュープロセス１７が
アプリケーションデータベース及び演算プロセス１８を
実施する１つ以上のプロセッサと別個な少なくとも１つ
のプロセッサによって実施される場合に、システムの利
用性を高める。つまりこのような分散環境では、１つ以
上のバンクエンドプロセッサが故障しても、１つ以上の
フロントエンドプロセッサはタスクキュー１９にタスク
を提出することによって処理を続けられる。

１つ以上のバックエンドプロセッサが新たなタスクへの
割当に利用可能なとき、タスクキュー１９内のまだ割り
当てられていない次のタスクが待機タスク開始プログラ
ム２０によって割り当てられ、開始される。割当タスク
が完了すると、それはタスクキュー１９から取り出され
る。

タスクの完了は、そのタスクに関連したアプリケーショ
ンが首尾よ〈実施されたことを必ずしも意味しない。ア
プリケーションデータベース及び演算プロセス１６が処
理すべきデータ中におけるエラーの存在や、アプリケー
ションの実施を妨げるシステム１０内の故障を検出する
かもしれないからである。いずれの場合にも、待機タス
ク開始プログラム２０はタスクキュー１９からタスクを
取り出す前に、そのタスクのエラーコードをエラーキュ
ー２１内に入れる。またアプリケーションによっては、
それぞれのアプリケーションが正常に完了しなかった場
合、エラーデータの補正かあるいはシステム１０の補修
後にタスクが完了されるのを可能とするため、待機タス
ク開始プログラム２０がタスクデータの一部または全て
をタスクキュー１９からエラーキュー２１へ移すのが望
ましいこともある。エラーキュー２１内に入れられたエ
ラーコードは、例えばシステムオペレータ（図示せず）
によって定期的に調べられ、適切な補正措置が取られる
。

−ｆｌｕ的なトランザクション処理のアプリケーション
において、あるタスクの処理は別のタスクのデータにア
クセスできること、例えばタスク間でデータを共有した
り、タスク実行の優先順位を変更したり、さらに不要に
なったあるいは完了されないタスクを取り消したりでき
ることが望ましい。

このような１つのアプリケーションは、妥当な時間以内
に完了しないタスクや、データヘースＩ６へのアクセス
の矛盾する要求のためにデッドロック状態となったタス
クなど、異常なシステム状態に応答するシステムオペレ
ータまたはオペレーティングシステムによるタスクキュ
ー１９の管理である。この目的のため、各タスクまたは
トランザクションには、それがタスクキュー内に入れら
れる前に固有のタスク識別番号が割り当てられる。

異なるタスクには異なる優先順を割り当てるのが望まし
く、またタスクキュー内のタスクのｆ３先順位を変える
こともしばしば望ましいので、タスクキュー１９内にお
けるタスクの順序付けは、それらのタスク識別番号の順
序付けと異なることがある。このため、タスクキューを
シングルキー式索引ファイルとして編成し、優先順位に
よってタスクの正しい順序付けを得ようとする場合、タ
スク識別信号はシングルキーとして使えない。

要求されたタスク識別番号を持つタスクについてタスク
キューをサーチするには、タスク識別番号を代替キーと
して用い、タスクキュー１９を２キ一式索引ファイルと
して編成することもできる。

しかし、こうすると代替キー用の索引にアクセスしまた
それを更新する必要があるため、キュー入れ及びキュー
出しタスクのアクセス時間が大幅に増加する。

本発明によれば、シングルキー用のフォーマットとタス
ク識別番号用のフォーマットを一定の方法で選択すると
共に、要求されたタスク識別番号を持つタスクについて
キューをサーチするための新規なタスクキューサーチ機
構２２を用いることによって、シングルキー式索引ファ
イルが有効に使われる。以下、タスクキューサーチ機構
２２をさらに説明する。その動作は、タスクキューの好
ましい編成及び動作に関連してより容易に理解されよう
。

次に第２図を参照すると、タスクキュー（第１図の１９
）内に記憶されるタスクデータのレコード用の好ましい
フォーマットが示しである。端末及びメニュープロセス
１７がアプリケーションデータベース及び演算プロセス
（第１図の１８）によって実施されるべきトランザクシ
ョンのためのデータを収集するとその都度、端末及びメ
ニュープロセス１７は、タスクキュー１９内に入れられ
べき要求トランザクションつまりタスクについて“ＴＡ
ＳＫ　ＩＤ”　（タスク識別番号（ＩＤ＞）を生成する
。個々のタスクを一意的に識別するため、ＴＬＳＫ　１
０は時間と空間にわたって固有である。すなわち、端末
及びメニュープロセス１７によって異なる時点に発生さ
れる２つのタスクはいずれも必然的にそれぞれ異なるタ
スク識別番号を有し、また（例えば多重プロセンサシス
テムの異なるプロセッサで生成される結果）異なるプロ
セスが全く同一時点にそれぞれのタスクを生成したとじ
ても、タスク識別番号は異なるものとされる。

第２図に示したように、タスク識別番号の時間と空間に
わたる一意性は、システム内のクロ７クから信号発生さ
れたタスク生成の時刻３１と、タスクを生成したプロセ
ッサつまりノードの識別番号３２との連結からタスク識
別番号を形成することによって保証される。タスク生成
の時刻３１には現在の日、月及び年が含まれるので、タ
スク生成の時刻はアプリケーションデータベースのその
後の考えられるどんな用途においても固有となる。

各タスク毎にタスクキュー内に記憶されるタスクデータ
は、タスクによって要求されている各アプリケーション
プロセスの名前３３をさらに含む。

かかる名前がアプリケーションデータベース及び演算プ
ロセス１８によって認識されると、予め記憶されたルー
チンまたはアプリケーションプログラムが実行され、タ
スクによって要求されているトランザクションを行う。

各タスク毎にタスクキュー１９内に記憶されるタスクデ
ータはさらに、タスクによって要求されているトランザ
クションの実施のため、端末及びメニュープロセスエフ
によって収集されたタスクデータ３４を含むこともでき
る。アプリケーションデータベース及び演算プロセス１
８がタスクによって要求されているトランザクションを
実施するとき、場合によって端末及びメニュープロセス
１７によって収集された各タスクデータが、アプリケー
ションデータベースＩ６から読み取られたその他の入力
データと組み合わせられ入力データとして使われる。

端末及びメニュープロセス１７に影響を及ぼす部分的な
システム故障にもかかわらず、タスクキュー１９は第２
図のフォーマットのタスクデータを受は取ると見なされ
る。すなわち、タスクキュー１９は永久メモリ内にファ
イルとして編成され、任意の与えられたタスクに関する
全てのタスクデータを１回の１アトミツク”動作でタス
クキュー内へと書込可能としていると見なされる。この
点は例えば、米国マサチューセッツ州０１７５４、マナ
ード所在のデジタル・エクイップメント社から市販され
ているＲＭＳ　（レコード管理サービス）システムなど
、任意の数の通常のデータベース管理プログラムからな
る“回復ユニットジャーナル”機能を用いることによっ
て行える。この場合、タスクデータをデータキュー１９
内に書き込むためのプログラム命令は、１つの６回復ユ
ニット”内に含まれている。

次に第３図を参照すると、待機タスク開始プログラム（
第１図の２０）によって実施される手順のフローチャー
トが、全体を４０で示しである。

最初のステップ４１では、特段タスク開始プログラムが
タスクキュー１９を読み、キュー内の次タスクに関する
データを得る。（単一のアプリケーションプロセッサを
有するシステムでは、データがキューの先頭に現れる）
。ステップ４２では、タスクキューが空かどうかテスト
される。空の場合はステップ４３で、待機タスク開始プ
ログラムがある一定の時間遅延され、待機タスク開始プ
ログラムが再びタスクキューを読む前に、端末及びメニ
ュープロセス（第１図の１７）によってタスクキューが
満たされるのを可能とする。

タスクデータがキューから得られたら、待機タスク開始
プログラムがステップ４４を実施し、タスクデータ内の
名前（第２図の３３）のアプリケーションプロセスを呼
び出し、タスク識別番号とその他のタスクデータ（第２
図の３４）をアプリケーションプロセスに渡す。ステッ
プ４５で待機タスク開始プログラムは、アプリケーショ
ンプロセスが完了しているかどうかをチエツクする。完
了していないと、待機タスク開始プログラムはステップ
４６で、アプリケーションプロセッサが利用可能かどう
かをチエツクする。アプリケーションプロセッサが利用
可能でないと、ステップ４５力（再び行われる。利用可
能なら、タスクキュー内の次タスクのデータをステップ
４１で読み取ることができる。（単一ブロセソサシステ
ムでは、現プロセスが終るまで唯一のアプリケーション
プロセッサが利用可能とならないので、ステップ４６は
単一プロセッサシステムで行う必要がない）。

呼び出されたアプリケーションプロセスが完了したら、
待機タスク開始プログラム２０はステップ４７で、プロ
セスが鋳圧よく完了したかどうかを判定する。してない
と、首尾よく完了しなかったことを示すエラー状態コー
ドとタスク識別番号が、ステップ４８でエラーキュー２
１内に入れられる。

Ｈｊ＆にステップ４９で、完了したタスクがタスクキュ
ーから取り出され、タスク開始サイクルがステップ４６
から再び繰り返される。

単一のコンピュータまたはプロセッサがアプリケーショ
ンデータベース及び演算プロセス（第１図の１８）の全
てを行うようなシステム１０では、ステップ４４におい
て、呼び出されたアプリケーションプロセスが完了する
までその呼び出されたアプリケーションプロセスに実行
権を渡すサブルーチンコールを行うだけでよい。多数の
コンピュータまたはプロセッサが異なるアプリケーショ
ンプロセスを同時に実施するような多重プロセッサシス
テムでは、同時に発生するアプリケーションプロセス間
で衝突が生じないことを、システムが保証する必要があ
る。

“デッドロック”として知られる潜在的な衝突は、例え
ば、一対のプロセッサの各プロセッサが現在他方のプロ
セッサによって使われている資源を必要とするときに生
じ得る。この場合、デッドロックが解消されてから、ど
ちらのプロセッサもそれぞれの割当アプリケーションを
完了できなければならない。潜在的な衝突の他の原因は
、２つの同時に実施されているアプリケーションの正味
の結果が、一方のアプリケーションの特定ステップが他
方のアプリケーションの特定ステップの前または後に行
われることに依存している場合に生じる。このような場
合、システムは、タスクキュー１９にタスクが現れる順
序にだけ応じた一貫した結果を与えることが望ましい。

これらの衝突を処理する方法は数多く存在するが、特に
簡単な方法は待機タスク開始プログラム２０がキュー内
の次タスクを読み取ってそれを次の利用可能なアプリケ
ーションプロセッサへ送出するのを、前に呼び出された
タスクが制御権を掌握するまで、つまり必要になるかも
しれない全てのファイルを“オーブン”にするまで禁止
することである。言い換えれば、呼び出されたプロセス
が必要になるかもしれない全てのファイルを“オーブン
”にするまで、ステップ４４は完了されるべきでない。

次に第４図を参照すると、キー用の好ましいフォーマッ
トが示しである。キーは優先順位レベルと、先に第２図
に示したのと同じで、タスク識別番号の最上位部を形成
するタスク生成時刻３１とを含む。第４図のキーと第２
図のタスク識別番号との間の関係から、これらをタスク
キュー（第１図の１９）を形成するシングルキー式アク
セスファイルのデータレコードで重複させることができ
る。

次に第５図を参照すると、タスクキュー１９用の１つの
可能なフォーマ７）が示しである。キューは、例えばキ
ュー先頭のレコード６１と、キュー末尾のレコード６２
、及び多数の中間レコードを含む、順序付けられた一組
のレコードである。

図示の目的上、各レコードは表の形で連続的に並べて示
しであるが、レコードは永久メモリ内にこのように連続
的に配置されなくともよい。キュー内へ新たに入れられ
るレコードはキュー内にすでに存在するレコードより高
い優先順位を持つことがあるため、キュー内におけるデ
ータレコードの順序は、メモリアドレススペース内にお
けるデータレコードの順序と同じにするのは効率的でな
い。

周知のように、“二重リンク式リスト”などの断片化デ
ータ構造の方が、キューを実施するのにより効率的であ
る。二重リンク式リストとしてのキューの実施はよく知
られており、例えば、Ｌｅｖｙ　＆Ｅｃｋｈｏｕｓｅ　
Ｊｒ、のＣｏｍ　ｕｔｅｒ　Ｐｒｏ　ｒａｍｍｉｎ　Ａ
ｎｄＡｒｃｈｉｔｅｃｔｕｒｅ　Ｔｈｅ　ＢＡＸ　−１
１、デジクル・エクイップメント社、１９８０、ｐｐ、
１７８−１８８に詳しく記載されている。

第５図にさらに示されているように、各レコードは優先
順位フィールド、日付−時刻フィールド、“生成プロセ
ッサ”フィールド、メモリロックビットし、削除フラグ
Ｄ、“実行プロセッサフィールド、及びその他のデータ
フィールドつまりデータへのポインタを含む。

タスクレコード６１−６２は、優先順位値の降順でタス
クキュー１９内に入れられており、優先順位が同じとき
は、日付−時刻フィールドの値の降順によっている。こ
のため、高い優先順位のレベルの方が低い数値を持つ。

タスク識別番号フィールドの数値が各タスクレコードを
一意的に識別するが、レコードのキーフィールド内の数
値はそうではない。この点は、同じ優先順位を持ち、同
一時刻であるが異なるプロセッサによって生成された２
つのタスクを表しているレコード６３と６４を比較すれ
ば分かるであろう。

キュー先頭のエントリ６１は、最も低い１の優先順位値
と、１９８７年７月１４午後１時３５分に生成されたこ
とを示す日付−時刻フィールドを有する。日付−時刻フ
ィールドの最下位位置は、例えばさらにシステムの正確
なりロックサイクルを識別している。生成プロセッサフ
ィールドは、第ルコード６１によって表されるタスクが
システム内の番号１のプロセッサによって生成されたこ
とを示す１の数値を有する。ロックフラグＬは、そのタ
スクが現在実施されていることを示し、実行プロセッサ
フィールド内で識別された実行中のプロセッサだけが、
現在時点でタスクフィールド６１にアクセス可能なこと
を示している。さらに削除フラグＤのゼロの値は、実行
中のプロセッサがそのタスクをまだ完了していないこと
を示している。例えばレコード６５は、Ｏの値のロック
フラグＬと、１つの値の削除フラグＤと、３つの値の実
行プロセッサフィールドとを有し、番号３のプロセッサ
がそのレコードに関するタスクの処理を完了しており、
レコードはキューから削除できることを示している。

第５図に示したのと同様な内部編成が、前記したＲＡＭ
機構などキー索引ファイルへアクセスするための通常の
メモリ管理機構によって、各レコードがタスクキューエ
９内へ挿入され及びそこから削除された場合に生じる。

特に、キュー内におけるレコードの順序はそれぞれのキ
ーフィールドの値に依存し、レコード６３と６４のよう
に、同じキーフィールドを有する任意の２つのレコード
はＦＩＦＯベースでキューへの挿入及びそこからの削除
がなされる。

ＲＭＳ機構などの通常の機構は、レコードへアクセスす
るための唯一の優先順位があれば、フラグのロックと削
除を管理し、プロセッサまたはアプリケーションのトラ
ックを保持するためのレコードのロック及び削除を与え
られる。そのため、キー索引ファイルを管理する機構を
呼び出すそれぞれ高水準言語の命令を実行することによ
って、エントリはキュー内へ挿入でき、またキューから
削除できる。ＲＭＳなとの機構は例えば、キュー内の次
レコードを得る場合、ロックされているレコードをスキ
ップする。キー索引レコードへアクセスするだめのこれ
らの標準的な機能には、例えば、キーによって索引ファ
イルを読み取り、要求されたキーと合致した第１のレコ
ードを戻すか、あるいは要求されたキーと合致するキー
フィールドを持つレコードが存在しなかったら、合致す
るレコードが存在するかもしれない後続ファイル内の次
ルコートヘと進むＲＥＡＤ　ＢＹ　ＫＥＹ　ＮＥＸＴ処
理が含まれる。すなわち、ＲＥＡＤ　ＢＹ　ＫＥＹ　Ｎ
ＥＸＴ処理は、要求されたキーとレコードのキーフィー
ルド内の値との間における合致の試みに基づいて、ファ
イルへのランダムアクセスを行う。またキー索引ファイ
ルを管理する通常の機構は、ＲＥＡＤ　ＮＥＸＴなどの
処理も与え、これは索引ファイルを読み取り、ＲＥＡＤ
　ＢＹ　ＫＥＹ　ＮＥＸＴまはＲＥＡＤ　ＮＥＸＴ処理
のいずれかで最も最近戻されたレコードの後に続く次の
レコードを戻す。すなわちＲＥＡＤ　ＮＥＸＴはキー索
引ファイルに対する逐次アクセスを与える。

キーとタスク識別番号との間の関係から、第６図に全体
を７０で示したフローチャートに例示した手順を用いる
ことによって、要求されたタスク識別番号を持つレコー
ドについてキューを極めて迅速にサーチすることができ
る。最初のステップ７１で、キューはその先頭から、要
求されたタスク識別番号の日付−時刻フィールドと合致
する日付−時刻フィールドを持つ次レコードがサーチさ
れる。ステップ７２で検出されるように、このサーチ中
ファイルの終わりに達すると、ステップ７３でリターン
コードが’ＮＯＴ　ＰＯＵＮＤ　　（見つからず）″に
セットされ、サーチは成功せずに完了する。ステップ７
２でファイルの終わりが検出されないと、合致したタス
ク識別番号を持つ可能性のあるレコードが見つかったこ
とになる。正確な合致は、そのレコードのタスク識別フ
ィールドが要求されたタスク識別番号と正確に合致する
かどうかを、ステップ７４で判定することによってチエ
ツクされる。第５図に示した特定のフォーマットでは、
レコードの生成プロセッサフィールドが要求されたタス
ク識別番号の最下位部にあるプロセッサ識別番号と合致
するかどうかをチエツクするだけで、ステップ７４を実
施できる。合致すれば、ステップ７５でリターンコード
がＦＯＵＮＤ　　（見つかった）”にセントされ、サー
チは成功して完了する。ステップ７４で合致が検出され
ないと、実行ループはステップ７１に戻り、キューのサ
ーチを続ける。

キューは、キーが昇順または降順で配列された索引ファ
イルとして編成されているため、キューをサーチするス
テップ７１はキーでサーチすることによって非常に効率
的に実施できる。また、キー索引ファイルを管理するた
めの既存の機構が、そのサーチを行うための最適化手順
をすでに与えている。本発明の重要な特徴によれば、メ
モリ管理機構によって与えられるランダムアクセスと逐
次アクセスの画処理を用いて、キューのサーチが行われ
る。これを行うための手順を、下記のプログラムリスト
として例示する： １２０　　ＲＥＡＤ　　ＢＹ　　ＫＥＹ　　ＮＥＸＴ１
３０　　ＬＯＯＰ １４０　　　１Ｆ　　ＥＮＤ　　ＯＦ　　ＦＩＬＥ１５
０　　　　Ｔ　ＨＥ　Ｎ １６０　　　　　　ＥＸＩＴ　ＬＯＯＰ　ＡＮＤ　ＲＥ
ＴＵＲＮ（ＮＯＴ　ＦＯＵＮＤ’）１７０　　　　ＥＮ
ＤＩＰ １９０　　　　ＴＨＥＮ ２１０　　　　　　　ＲＥＡＤ　　ＢＹ　　ＫＥＹ　　
ＮＥＸＴ２２０　　　　ＥＬＳＥ ２３０　　　　　　　ＩＦ　ＲＥＣＯＲＤ、ＤＡＴＥ　
ＴＩＭＥ　ＦＩＥＬＤＫＥＹ　　ＲＥＱ、ＤＡＴＥ　　
ＴＩとＥ　　ＦＩＥＬＤ２４０　　　　　　　Ｔ　ＨＥ
　Ｎ Ｐ［０１？ｒ７Ｙ” ＴＩ（ＥＮ ＥＸＩＴ　ＬＯＯＰ　　ＡＮＤ　ｌ？ＥＴＵＲＮ（’　
ＮＯＴ　ＦＯ［ＩＮＤ’）ＥＬＳＥ ＩＮＣＲＥＭＥＮＴ　　ＫＥＹ　　ＲＥＱ、ＰＲＩＯＲ
ＩＴＹ　　ＦＩＥＬＤＲＥＡＤ　　ＢＹ　　ＫＥＹ　　
ＮＥＸＴＮＤＩＰ ＥＬＳＥ ＩＦ　　ＲＥＣＯｆ？Ｄ、ＴＡＳＫ　　１０　　ＦＩＥ
ＬＤ＝ＴＡＳＫ　　１０　　ＲＥＱ３４０　　　　　Ｔ
　ＩＩ　Ｅ　Ｎ ３５０　　　　　　　ＥＸＩＴ　ＬＯＯＰ　ＡＮＤ　Ｉ
？ＥＴＩＪＲＮ（”　ＦＯＵＮＤ”）３６０　　　　Ｅ
ＬＳＥ ３７０　　　　　　　　　　　ＲＥＡＤ　　ＮＥＸＴ３
８０　　　　　ＥＮＤＩＦ ３９０　　　　ＥＮＤＩＰ ４００　　　ＥＮＤＩＦ ４１０　ＥＮＤ　　ＬＯＯＰ 上記プログラムリストの動作は、第７図に全体を８０で
示した対応するフローチャートから明かとなろう。概略
すれば、この手順はキーについて可能性のある最も高い
優先順位を想定することによって始まる。要求キーの日
付−時刻フィールドは、必ず要求されたタスク識別番号
の日付−時刻フィールドとされる。次いで要求キーを用
い、キューがランダムアクセス方式で読まれる。合致す
るキーを持つレコードが見つからないと、戻されたレコ
ードの優先順位フィールドに基づいてキーの優先順位が
下げられ、ファイルが再び読まれる。

この動作は、合致するキーを持つレコードが見つかるか
、あるいはファイルの終わりに達するまで、可能性のあ
る優先順位レベルを通じてステップまたはスッキブしな
がら繰り返される。合致するキーを持つレコードが見つ
かると、要求されたタスク識別番号がレコードの識別番
号フィールドと比較される。合致すれば、所望のレコー
ドが見つかったことになる。合致しないと、今度は逐次
アクセスによって、識別番号が合致するかあるいはキー
がもはや合致しなくなるまで、サーチが続けられる。

フローチャート８０の最初のステップ８１で、要求キー
の優先順位フィールドが可能性のある最も高い優先順位
にセントされ、また要求キーの日付−時刻フィールドが
要求された“ＴＡＳＫ　１０　（タスク識別番号）”の
日付−時刻フィールドにセットされる。次にステップ８
２で、キューがまず“にＥＹ　ＮＥＸＴ　（キーネキス
ト）“処理で読まれる。

ステップ８３でファイルの終わりが検出されたら、ステ
ップ８４でリターンコードが“ＮＯＴ　ＦＯＵＮＤ（見
つからず）１にセットされ、サーチは成功せずに完了す
る。

ステップ８３でファイルの終わりが検出されないと、ス
テップ８５でファイルから読み取られたレコードの日付
−時刻フィールドが要求キーの日付−時刻フィールドと
比較される。レコードの日付−時刻フィールドの方が小
さいと、ステップ８６に示すように、要求キーの優先順
位フィールドをレコードの優先順位フィールドにセット
し直して、ランダムアクセスが継続される。言い換えれ
ば、ステ・ノブ８２で読み取られたレコードと同じ優先
順位を持つレコードについて、合致する日付−時刻フィ
ールドがまだ存在する可能性がある。

しかし、レコードの日付−時刻フィールドの方が要求キ
ーの日付−時刻フィールドより大きいと、キーの優先順
位フィールドと同じ優先順位フィールドを持つ合致レコ
ードをもはや見い出せる可能性がない。そのため、ステ
ップ８７で要求キーの優先順位フィールドが可能性のあ
る最も低い優先順位に等しければ、そのファイル中で合
致は見つからないので、ステップ８４でリターンコード
が１ＮＯＴ　ＦＯｌｌｌＪＤ　　（見つからず）″にセ
ントされ、サーチは成功せずに完了する。他方、ステッ
プ８７で要求キーの優先順位フィールドが可能性のある
最も低い優先順位に等しくなければ、ステップ８８で要
求キーの優先順位フィールドの優先順位値が１レベルイ
ンクレメントされ、ステップ８２でランダムアクセスに
よるサーチが続けられる。

ステップ８５でレコードの日付−時刻フィールドが要求
キーの日付−時刻フィールドに合致すれば、要求された
タスク識別番号がレコードの識別番号フィールドと合致
する可能性がある。これがステップ８９でテストされる
。合致しないと、実行はステップ９０にジャンプし、次
レコードを読み取ることによって逐次キューにアクセス
しながら、ステップ８３で実行が続けられる。ステ６７
１８９で合致すれば、所望のレコードが見つかったこと
となり、ステップ９１でリターンコードが“ＦＯＵＮＤ
　　（見つかった）”にセットされ、サーチは成功して
完了する。

（発明の効果） 以上において、シングルキー式索引ファイルとして構成
され、キーとタスク識別番号が、要求されたタスク識別
番号を持つタスクレコードを効率的に見つけるのにシン
グルキー式索引ファイルのランダムアクセス用の通常処
理が使えるような方法で関係付けられているタスクキュ
ーが開示された。従って、キュー入れ及びキュー出し動
作を遅くするような、代替キーとしてタスク識別番号を
用いる必要がない。タスクキューはトランザクション処
理のためのキューイング要求に特に通ずるが、本発明の
タスクキュー及びサーチ方法は、識別番号の割当後に各
タスクを識別したり、タスクの優先順位を変更するのが
望ましいキューイングアプリケーションにおいてとりわ
け有利である。

【図面の簡単な説明】

第１図は本発明によるタスクキュー編成及びタスクキュ
ーサーチ機構を具備したトランザクション処理システム
のブロック図；第２図は第１図のシステムで使われるタ
スクキュー内に記憶されるタスクレコード用の好ましい
フォーマットの図；第３図は第１図のタスクキューを処
理する待機タスク開始プログラムの動作を示すフローチ
ャート；第４図はタスク識別番号の好ましいフォーマッ
トの図；第５図はタスクキューの好ましいシングルキー
式索引ファイルを示す図；第６図は第５図のタスクキュ
ーをサーチし、要求されたタスク識別子を有するタスク
レコードを見い出す手順のフローチャート；及び第７図
は通常のキー索引ファイルサーチ機構を用いて、第５図
のタスクキューをサーチし要求されたタスク識別子を有
するタスクレコードを見い出す手順のフローチャートで
ある。 １０・・・データ処理システム、１６・・・アプリケー
ションデータベース、１８・・・アプリケーションプロ
セッサ手段、１９・・・メモリ装置（タスクキュー）、
２１・・・待機タスク開始手段（プログラム）、２２・
・・タスクキューサーチ手段（機構）、３１と３２・・
・識別子（３１；時間値、３２；プロセッサ指示）、３
１と５１・・・キー（５１；優先順位レベル）。

Claims (1)

1. 【特許請求の範囲】 １、データ処理システムにおけるメモリ装置で、該メモ
   リ装置がデータのキューを保持し、該キューが順序付け
   られた一組の多数の前記データのレコードからなり、該
   レコードの各々が別のレコードの識別子フィールドにお
   けるそれぞれの識別子と異なる各識別子を保持する識別
   子フィールドを含み、また前記レコードの各々が、優先
   順位のレベルを示す各最上位部とレコードにおける各識
   別子の所定の関数である下位部とを有するそれぞれのキ
   ー値を保持するキーフィールドも含み、前記キュー内に
   おける前記レコードの順序が前記キー値の順序付けによ
   って指定されるメモリ装置。 ２、各レコード内の前記識別子フィールドが、それぞれ
   のキー値の下位部を保持するサブフィールドを含む請求
   項１記載のメモリ装置。 ３、各レコードの識別子フィールド内に保持された前記
   識別子がそれぞれの時刻値を示す請求項１記載のメモリ
   装置。 ４、前記時刻値が日付と、２４時間フォーマットでの時
   刻とを含む請求項３記載のメモリ装置。 ５、前記識別子がさらに、前記データ処理システム内の
   プロセッサを示す識別番号を含む請求項３記載のメモリ
   装置。 ６、前記レコードがそれぞれのキーフィールド内に、同
   一のキー値を持つ異なるレコードを含む請求項１記載の
   メモリ装置。 ７、データ処理システム内のデータプロセッサを作動さ
   せ、要求された識別子を持つデータレコードについてキ
   ューをサーチする方法で、該キューが前記データ処理シ
   ステムのメモリ装置内に保持され、前記キューが前記メ
   モリ装置内に記憶され順序付けられた一組の多数のデー
   タレコードからなり、該レコードの各々が別のレコード
   の識別子フィールドにおけるそれぞれの識別子と異なる
   各識別子を保持する識別子フィールドを含み、また前記
   レコードの各々が、優先順位のレベルを示す各最上位部
   とレコードにおける各識別子の所定の関数である下位部
   とを有するそれぞれのキー値を保持するキーフィールド
   も含み、前記キュー内における前記レコードの順序が前
   記キー値の順序付けによって指定されるものにおいて： ａ）それぞれのキーフィールド内に、前記要求された識
   別子の前記所定の関数である下位部を有するレコードに
   ついて前記キューをサーチするステップ；及び ｂ）前記ステップａ）のサーチで見つかったレコードの
   各識別子フィールドにおける識別子が要求された識別子
   と同じであるかどうかを判定するステップ； を含む方法。 ８、前記サーチするステップａ）が、前記要求された識
   別子の前記所定の関数である下位部を有する要求キーを
   形成すること、及び該要求キーに応じて前記キューへラ
   ンダムにアクセスし、前記キューから次レコードを得る
   ことを含む請求項７記載の方法。 ９、前記ランダムなアクセスが、前記キュー内のうち要
   求キーと合致したキー値を持つ最初のレコードを戻すか
   、あるいは前記キューが要求キーと合致したキー値を持
   つレコードを有していないときは、合致するキー値を持
   つレコードがあると思われたものの後に続く前記キュー
   内の次レコードを戻すソフトウェア処理によって行われ
   る請求項８記載の方法。 １０、前記サーチするステップａ）が、前記要求キーの
   下位部を前記次レコードのキーフィールド内におけるキ
   ー値の下位部と比較し、前記次レコードがそれぞれのキ
   ーフィールド内に前記要求された識別子の前記所定の関
   数である下位部を有するレコードの１つであるかどうか
   を判定することを含む請求項９記載の方法。 １１、前記サーチするステップａ）がさらに、（１）前
   記要求されたキーの下位部が前記次レコードのキーフィ
   ールド内におけるキー値の下位部と合致しないこと、及
   び（２）前記次レコードが要求キーの変更前における要
   求キーの最上位部と同じであるキーフィールド内におけ
   るキー値の最上位部を持つべきであること、を前記比較
   が示したとき、前記要求キーの最上位部を優先順位の１
   レベルだけ変更し、該要求キーに応じて前記キューへ再
   びランダムにアクセスするステップを含む請求項１０記
   載の方法。 １２、前記サーチするステップａ）がさらに、（１）前
   記要求されたキーの下位部が前記次レコードのキーフィ
   ールド内におけるキー値の下位部と合致しないこと、及
   び（２）前記次レコードが要求キーの変更前における要
   求キーの最上位部と異なるキーフィールド内におけるキ
   ー値の最上位部を持つべきであること、を前記比較が示
   したとき、前記要求キーの最上位部を前記次レコードの
   キーフィールド内におけるキー値の最上位部にセットす
   ることによって要求キーを変更するステップを含む請求
   項１０記載の方法。 １３、前記サーチするステップａ）が、前記要求された
   識別子の前記所定の関数である下位部を含む部分を有し
   た要求キーに応じ、前記キューのランダムアクセスによ
   ってまず行われ、また要求された識別子が合致キーを持
   つレコードの識別子フィールドにおける識別子と異なる
   ことを前記判定するステップｂ）が判定したときは、前
   記キューの逐次アクセスによって行われ、前記キュー内
   の次レコードを逐次得る請求項７記載の方法。 １４、前記サーチするステップａ）がさらに、前記次レ
   コードのキーフィールド内におけるキー値の下位部を前
   記要求された識別子の予め定義された関数である下位部
   と比較し、前記次レコードのキーフィールド内における
   キー値の下位部が前記要求された識別子の前記所定の関
   数である下位部と異なるとき、前記次レコードが要求キ
   ーの変更前における要求キーの最上位部と同じであるキ
   ーフィールド内におけるキー値の最上位部を持つべきで
   あること、を前記比較が示した場合に、前記要求キーの
   最上位部を優先順位の１レベルだけ変更し、該要求キー
   に応じて前記キューへ再びランダムにアクセスすること
   を含む請求項１３記載の方法。 １５、前記サーチするステップａ）がさらに、前記次レ
   コードのキーフィールド内におけるキー値の下位部を前
   記要求された識別子の予め定義された関数である下位部
   と比較し、前記次レコードのキーフィールド内における
   キー値の下位部が前記要求された識別子の前記所定の関
   数である下位部と異なるとき、前記次レコードが要求キ
   ーの変更前における要求キーの最上位部と異なるキーフ
   ィールド内におけるキー値の最上位部を持つべきである
   こと、を前記比較が示した場合に、前記要求キーの最上
   位部を前記次レコードのキーフィールド内におけるキー
   値の最上位部にセットすることによって、要求キーの最
   上位部を変更することを含む請求項１３記載の方法。 １６、データ処理システムにおいて： タスクキューを保持する非揮発性のメモリ装置で、該キ
   ューがメモリ装置内に保持され順序付けられた一組の多
   数のタスクデータのレコードからなり、該レコードの各
   々が別のレコードの識別子フィールドにおけるそれぞれ
   の識別子と異なる各識別子を保持する識別子フィールド
   を含み、また前記レコードの各々が、優先順位のレベル
   を示す各最上位部とレコードにおける各識別子の所定の
   関数である下位部とを有するそれぞれのキー値を保持す
   るキーフィールドも含み、前記キュー内における前記レ
   コードの順序が前記キー値の順序付けによって指定され
   るメモリ装置； 前記タスクデータを用いてデータ処理のタスクを行うア
   プリケーションプロセッサ手段；キュー内のまだ開始さ
   れていない次タスク用のタスクデータについて前記キュ
   ーにアクセスし、前記アプリケーションプロセッサ手段
   を呼び出すことによってタスクを開始する待機タスク開
   始手段；及び 識別子フィールド内に要求された識別子を持つレコード
   について前記タスクキューをサーチするタスクキューサ
   ーチ手段で、前記要求された識別子の所定の関数である
   下位部をそれぞれのキーフィールド内に有するレコード
   を見い出す手段と、該レコードを見い出す手段によって
   見い出されたレコードが要求された識別子と同じ識別子
   を識別子フィールド内に有するかどうかを判定する手段
   とを含むタスクキューサーチ手段； の組合せからなるデータ処理システム。 １７、各レコード内の前記識別子フィールドが、それぞ
   れのキー値の下位部を保持するサブフィールドを含む請
   求項１６記載のデータ処理システム。 １８、前記識別子が日付と、２４時間フォーマットでの
   時刻とを含む請求項１６記載のデータ処理システム。 １９、前記レコードを見い出す手段が、最上位部と前記
   要求された識別子の所定の関数である下位部とを有する
   要求キーを形成する手段、前記要求キーに応じて前記キ
   ューへランダムにアクセスし、キュー内の次レコードを
   見い出す手段、及び該ランダムにアクセスする手段によ
   って見い出された次レコードが要求された識別子と異な
   る識別子を識別子フィールド内に有することを前記判定
   手段が判定したとき、前記キューに逐次アクセスしてキ
   ュー内の次レコードを見い出す手段を含む請求項１６記
   載のデータ処理システム。 ２０、前記レコードを見い出す手段がさらに、前記キュ
   ー内で見い出された各次レコードのキー値の下位部を前
   記要求された識別子の所定の関数と比較し、各次レコー
   ドのキー値の下位部が前記要求された識別子の所定の関
   数と異なることを前記比較が指示するのに応じて、要求
   キーの最上位部を前記各レコードの優先順位フィールド
   内の優先順位値にセットするか、あるいは要求キーの最
   上位部を変更する手段を含む請求項１９記載のデータ処
   理システム。