JP2001514778A

JP2001514778A - メッセージ・キューイング・ファシリティを含むネットワーク・トランザクションをメインフレームからインテリジェントな入出力装置にオフロードするシステム及び方法

Info

Publication number: JP2001514778A
Application number: JP53976698A
Authority: JP
Inventors: マーク・エム・ホイットニー
Original assignee: マーク・エム・ホイットニー
Priority date: 1997-03-13
Filing date: 1998-03-11
Publication date: 2001-09-11
Also published as: WO1998040850A3; EP1018074A4; US6141701A; WO1998040850A2; EP1018074A2

Abstract

(57)【要約】ストレージ・コントローラは、プロセッサとメモリとを有しており、コントローラは、対応するアドレスを有するＩ／Ｏコマンドを受け取る。コントローラ・メモリでは、ネットワーク上で情報を受信及び送信する通信スタックが提供される。更に、メッセージ・キュー・ファシリティ（ＭＱＦ）が提供され、通信スタックと協動して、メッセージ・キュー・バーブに応答する。ＭＱＦは、通信スタックに、キューをＭＱＦにおいて提供させ、また、ＭＱＦにおけるキューに情報を通信スタックに提供させる。更に、インターフェース・ロジックがコントローラ・メモリにおいて提供され、Ｉ／Ｏコマンドに応答して、Ｉ／Ｏコマンドが所定のコマンドの第１の組の中に入るかどうかを判断する。そうであれば、インターフェース・ロジックは、Ｉ／Ｏコマンドを対応するメッセージ・キュー・バーブ及びキューにマップして、ＭＱＦを呼び出す。このようにして、ＭＱＦは、通信スタックと協動して、バーブに対応する情報を送受信し、他方で、処理をストレージ・コントローラのコンピュータ・クライアント（例えば、メインフレーム）からオフロードする。

Description

【発明の詳細な説明】メッセージ・キューイング・ファシリティを含むネットワーク・トランザクションをメインフレームからインテリジェントな入出力装置にオフロードするシステム及び方法発明の背景１．発明の分野本発明は、メインフレーム処理における改良に関し、更に詳しくは、メッセージ・キューイング・ファシリティ（ＭＱＦ）を含むネットワーク・トランザクションをインテリジェントな入出力（Ｉ／Ｏ）装置にオフロードすることによって得られる動作効率に関する。２．関連技術の説明ここ数年にわたって、メッセージ指向（message oriented）のミドルウェア製品が、ヘテロジーニアス（異種）なコンピューティング環境の統合において本質的な役割を演じている。端的にいえば、メッセージ指向のミドルウェアによれば、異なるオペレーティング・システム、処理アーキテクチャ、データ・ストレージのフォーマット、ファイル・サブシステム、通信スタックなど、異なる処理特性を有するコンピューティング・システムの間での情報の交換が容易になる。ここでの内容に特に関連するのは、「メッセージ・キューイング・ファシリティ（ message queuing facilities）」（メッセージ待ち行列化機構、ＭＱＦ）として知られている一群の製品である。このようなシステムは、多く、市販されている。例としては、IBMのMQSeries、Digital Equipment Corp.のDEC Messaqe Queue 、XIPCのMomentum、Microsoft Corp.のFalconなどがある。メッセージ・キューイング・ファシリティは、キュー（待ち行列）を用いて相互の差異を隔離（insulate）又は抽象化（abstract）することによって、あるコンピューティング・システムにおけるアプリケーションが、別のコンピューティング・システムにおけるアプリケーションと通信するのを助ける。これらのシステムでは、アプリケーションが、メッセージをキューの上に配置、すなわち、プット (put)し、キューが、通信ネットワークを介して、その内容を別のアプリケーションのキューに伝送する。この別のアプリケーションは、そのキューから情報を取り外す、すなわち、ゲット（Get）し、それを処理する。更に詳しくは、送り側のアプリケーションは、キュー・マネジャ（ＭＱＦの要素）に「接続」（connect）し、キュー・マネジャのキュー定義を用いて、ローカルなキューを「開く」（open）。（「接続する」と「開く」とは、共に、MQse riesアプリケーション・プログラミング・インターフェース（ＡＰＩ）における実行可能な「バーブ（動詞）」である。）アプリケーションは、次に、メッセージをキューの上に「プット」することができる。メッセージを送る前に、ＭＱＦは、典型的には、メッセージを持続型ストレージ（persistent storage）に委託（コミット）する。典型的には、直接アクセス記憶装置（ＤＡＳＤ）に委託する。メッセージが持続型ストレージにいったん委託されると、ＭＱＦは、通信スタックを介して、メッセージを、受け手側の補助的及び遠隔ＭＱＦに送る。遠隔ＭＱＦは、メッセージを、持続型ストレージに委託し、肯定応答（ＡＣＫ）を送り手側のＭＱＦに送る。送り手側のキュー・マネジャに肯定応答が戻されることによって、送り手の持続型ストレージからそのメッセージを削除することが許される。メッセージは、受け手側のアプリケーションがその処理を終了したと指示するまで、遠隔ＭＱＦの持続型ストレージ上に留まる。遠隔ＭＱＦが受け手側のアプリケーションをトリガしなければならないかどうか、又は、受け手側がそれ自身でキューをポーリングするかどうかは、キューの定義が指示する。持続型ストレージを用いることにより、回復可能性が容易になる。（これは、「持続型キュー」として、知られている。）結果的に、受け手側のアプリケーションは、そのローカルなキュー（すなわち、送り手側のアプリケーションに関する遠隔キュー）において、メッセージについて告知され、送り手側のアプリケーションのように、そのローカルなキュー・マネジャに「接続」し、メッセージが現にその上に存在するキューを「開く」。そして、受け手側のアプリケーションは、「ゲット」又は「ブラウズ」というバーブを実行して、メッセージをキューから読み出す、又は、それを単に見ることができる。いずれのアプリケーションであってもそのキューの処理を終了すると、「閉じる」というバーブを生じ、キュー・マネジャから「切断」することは自由である。ＭＱＦによって用いられる持続型キュー・ストレージは、論理的には、インデクス付のシーケンシャルなデータ・セット・ファイルである。メッセージは、典型的には、ＦＩＦＯベースでキューに配置されるが、キュー・モデルは、ブラウジングのためのインデクス付アクセスや、キューの中のメッセージへの直接的なアクセスも許容する。ＭＱＦは、持続型メッセージ・キューを含むデータ・セットに対するファイル・マクロを実行する。例えば、MVS/OS390の環境では、アプリケーションが、マクロを実行して指名されたデータ・セットを開く。このオペレーティング・システムは、論理レコードに対するアプリケーションの要求を特定のディスク・モジュール上の特定の物理的位置にマップするのに用いられる制御ブロックの組を初期化する。この物理的位置は、ＭＣＨＲアドレスを用いて識別される（ＭＣＨＲフォーマットは既知である）。メッセージを持続型ストレージに記憶する際には、メインフレームに常駐するＭＱＦが、その持続型ストレージ装置と通信する。特に、ＭＱＦは、オペレーティング・システム・ソフトウェアに、例えばリード・データなどの所望のデータ及び所望の作用を識別する情報を含む一連のチャネル・コマンド・ワード（ＣＣＷ）を作成し初期化する。この一連のＣＣＷは、「チャネル・プログラム」である。ＣＣＷは、ディスク上のレコードのＭＣＨＲ位置と、リード・ライトされるデータの長さと、レコードがリード又はライトされるメインフレームのメモリ・アドレスとを含む。（ＣＣＷフォーマットと対応するチャネル・インターフェースとは既知である。）典型的なメインフレーム・システムは、持続型ストレージ・デバイスとしてＤＡＳＤを用いる。ＤＡＳＤは、データを記憶するのに用いられる不揮発性ストレージ・デバイスのＤＡＳＤに特定の配列と、ＤＡＳＤストレージ制御ユニット（ＤＳＴＣ）とを有する。ＤＳＴＣは、データをＣＣＷに特定の位置から検索したり、データをこれらの位置にライトしたりする様々なアルゴリズムを実行する。物理的には、ＤＳＴＣは、プロセッサとＲＡＭとを含む。ＲＡＭは、制御プログラムを保持するのに用いられ、また、キャッシュとして用いられる。ＤＳＴＣ機能に対する事実上の標準（デファクト・スタンダード）は、３３９０インターフェースである。ＤＳＴＣは、疎結合された（loosely-coupled）コンピューティング・クラスタにおけるＤＡＳＤの共有を容易にするのに用いられるのが典型的である「ロック・ファシリティ」を実現する。ロック・ファシリティは、クラスタ内の複数のコンピュータが同時にそれにアクセスしようとするときに、共有されているＤＡＳＤのシリアル化と調整の管理を助ける。ロックの細分性（granularity）は、実現ごとに変動するが、典型的には、レコード、データ・セット又はＤＡＳＤボリューム・レベルにある。物理的には、ＤＳＴＣは、複数のコンピュータがそれに付属されることを許容する複数の電気的インターフェースを有する。ＭＱＦは、多くのアプリケーションにとって有用であるが、現在のＭＱＦ及び関係のあるソフトウェアは、かなりのメインフレーム資源を用いる。関係するシステムが非常に効果である（例えば、トランザクションのレスポンス・タイム要求を維持するのに）とすると、ＭＱＦ及び関係のあるソフトウェアとに費やされるコンピューティング資源は、合計では、かなりの量となりうる。更に、現在のＭＱＦが有している、共有されたキューのサポートを可能にする機能は、あるとしても、限定されている。また、メインフレームは、オープン・システムに統合することが困難である。概要本発明の目的は、上述の及びそれ以外の課題を解決することである。本発明の別の目的は、コスト面で効率的な態様で、ＭＱＦ機能を提供することである。本発明の更に別の目的は、例えば、キューの共有可能性を提供することにより、ＭＱＦ機能を拡張することである。本発明の更に別の目的は、ＭＱＦをコンピュータからオフロードすることである。本発明の更に別の目的は、通信スタックを、又は、少なくともそのいくつかの要求を、コンピュータからオフロードすることである。本発明の更に別の目的は、オープン・システムのあるタイプのＩ／Ｏデバイスへの統合を容易にすることである。本発明の実施例では、ＭＱＦ及び関係のある処理が、メインフレームのプロセッサから改良型Ｉ／Ｏデバイスに移動される。改良型Ｉ／Ｏデバイスは、従来のＩ／Ｏ機能を実行するだけではなく、ＭＱＦソフトウェア、通信スタック及びそれ以外の新規なロジックを含む。改良型Ｉ／Ｏデバイス上のＭＱＦと通信スタックとは、従来型のものである。新規なロジックが、ＭＱＦソフトウェアへのインターフェースとして、効果的に機能する。特に、改良型Ｉ／Ｏデバイスは、プロセッサとメモリとを有するストレージ・コントローラを含む。このコントローラは、対応するアドレスを有するＩ／Ｏコマンドを受け取る。新規なロジックは、Ｉ／Ｏコマンドに応答して、Ｉ／Ｏコマンドが第１の組の所定のＩ／Ｏコマンドの中にあるかどうかを判断する。そうである場合には、ロジックは、Ｉ／Ｏコマンドを、対応するメッセージ・キュー・バーブ及びキューにマップして、ＭＱＦを呼び出す（invoke）。これから、ＭＱＦは、通信スタックと協動して、そのバーブに対応する情報の送受信をする。このロジックは、また、ストレージ・コントローラと相互作用している複数のクライアント・コンピュータの間でキューが共有されるように、共有されたキューを提供する能力を含んでいる。実施例によっては、Ｉ／Ｏコマンドの限定されたサイズのペイロードを受け取るＩ／Ｏ環境で動作するが、それよりも大きなサイズのペイロードを有するＭＱＦをサポートする。ある実施例では、これは、レコード・ポーリングを用いて達成される。このようにして、メインフレーム・コンピュータなどのクライアントが、アドレスを有するＩ／Ｏコマンドを、その上に常駐する通信スタックと、通信スタックと協動するＭＱＦと、ＭＱＦと協動するインターフェース・ロジックとを有するＩ／Ｏコントローラに送ることによって、ＭＱＦプロトコルに従って、メッセージを送受信することができる。インターフェース・ロジックは、Ｉ／ＯコマンドをＭＱＦバーブにマップし、そのバーブをＩ／Ｏコントローラに常駐するＭＱＦに発行する。Ｉ／Ｏコントローラに常駐するＭＱＦは、通信スタックに、ＭＱＦプロトコルによりＭＱＦバーブに対応するメッセージを送らせる。図面の簡単な説明図１は、本発明の好適実施例のアーキテクチャの図である。図２は、好適実施例のアドレス監視（address-watching）ロジックを図解する流れ図である。図３は、非共有キューへのプット（put）を処理する好適なロジックを図解する流れ図である。図４は、共有キューへのプットを処理する好適なロジックを図解する流れ図である。図５は、共有キューへのプットを処理する好適なロジックを図解する流れ図である。図６は、複数のプットを作業の１単位として処理する好適なロジックを図解する流れ図である。図７は、複数のプットを作業の１単位として処理する好適なロジックを図解する流れ図である。図８は、非共有キューへのゲット（Get）を処理する好適なロジックを図解する流れ図である。図９は、共有キューへのゲットを処理する好適なロジックを図解する流れ図である。図１０Ａ−Ｂは、複数のゲットを作業の１単位として処理する好適なロジックを図解する流れ図である。図１１Ａ−Ｂは、複数のゲットを作業の１単位として処理する好適なロジックを図解する流れ図である。図１２Ａ−Ｂは、複数のゲットを作業の１単位として処理する好適なロジックを図解する流れ図である。図１３は、キューの第１のメッセージへのブラウズを処理する好適なロジックを図解する流れ図である。図１４は、キューの次のメッセージへのブラウズを処理する好適なロジックを図解する流れ図である。図１５は、キューからブラウズされるメッセージを識別するカーソルを伴うブラウズを処理する好適なロジックを図解する流れ図である。図１６は、キューからの特定のメッセージのゲットのための識別及び選択を処理するのにカーソルを用いる好適なロジックを図解する流れ図である。図１７は、共有キューへのメッセージとそれからのデスクリプタのオプションを用いてゲットを処理する好適なロジックを図解する流れ図である。図１８は、共有キューへのメッセージとそれからのデスクリプタのオプションを用いてプットを処理する好適なロジックを図解する流れ図である。図１９は、好適実施例のキュー監視ロジックを図解する流れ図である。図２０は、好適実施例のキュー・ベースの制御インターフェースを図解する流れ図である。図２１は、従来技術によるＭＱＦメッセージの流れを図解する図である。図２２は、好適実施例によるＭＱＦメッセージの流れを図解する図である。詳細な説明本発明は、ネットワーク・トランザクションをインテリジェントなＩ／Ｏデバイスにオフロードするシステム及び方法を提供する。好適実施例は、特に、ＭＱＦ動作をメインフレーム・システムからオフロードすることに関する。高価なメインフレームのコンピューティング・サイクルを節約することに加え、この新規な構成によれば、クラスタにおける複数のメインフレームの間での共有されたキューなど、メインフレームのコンテキストにおけるＭＱＦの新規な使用が可能となる。更に、本発明のある実施例では、メインフレームとオープン・システムとを結びつけ、従来はメインフレームの中に密に含まれていた（tightly-housed）広範囲な動作情報が、より融通性のあるオープン・システムの中に選択的に写される(replicated)ことが可能になる。この密（タイト）な統合によって、動作システムと決定サポート・システムとが、日単位、週単位、月単位などのバッチ・ベースのフィードバック・ループではなく、リアルタイム・イベント・ベースのフィードバック・ループで動作することが可能になる。また、業務において命じられる際には、アプリケーションをメインフレーム環境からオープン・システムに移動させることも可能となる。好適実施例では、メインフレーム・ソフトウェアは、特定ファイルのＩ／ＯコマンドへのＭＱＦコールを、改良型Ｉ／Ｏデバイスの特定のファイル位置に翻訳する。改良型Ｉ／Ｏデバイスは、特定位置への動作を検出し、対応する動作を実行する。これらの対応する動作は、特定のＩ／Ｏ動作を、対応するＭＱＦ動作にマップし、改良型Ｉ／Ｏデバイスに常駐する対応するＭＱＦロジックを呼び出すことを含む。ＭＱＦロジックは、次に、改良型Ｉ／Ｏデバイス上に常駐する通信スタックを呼び出す。類似する動作が逆の方向に実行される。すなわち、ＭＱＦ動作が遠隔マシンから到着するときである。このようにして、ＭＱＦ動作と、対応するネットワーク処理とが、コンピューティング・サイクルが高価であるメインフレームから、コンピューティング・サイクルが相対的には実質的に安価である改良型Ｉ／Ｏデバイスに移動される。更に、この構成は、顕著なオーバヘッドを追加することはないが、その理由は、ＭＱＦ動作は、Ｉ／Ｏデバイスへのアクセスを既に要求しメッセージが持続型ストレージに記憶されるようにしているからである。図１は、本発明の好適実施例による改良型Ｉ／Ｏデバイス１００のハイレベルでのアーキテクチャ図を示している。この実施例は、ＩＢＭのＴＰＦメインフレーム・システムと特に関係を有する。Ｉ／Ｏデバイス１００は、好ましくは、ＤＳＴＣ１０２を含むＤＡＳＤである。ＤＳＴＣ１０２は、プロセッサとＲＡＭ（図示せず）とを含み、以下で述べる様々なルーチンを実行する。ＲＡＭは、様々な実行可能なロジックを記憶するのに用いられ、データを保持するキャッシュとしても用いられる。様々な実行可能なロジックには、ＤＡＳＤエンジン１０８、インターフェース・ロジック１０５、ＭＱＦ１０４及び通信スタック１１６が含まれる。インターフェース・ロジック１０５の好適実施例には、関連するテーブル１１０ａ、１１２ａ、１１８ａに加えて、アドレス監視ロジック１１０、マッピング・ロジック１１２及びキュー監視ロジック１１８が含まれる。ＤＳＴＣ１０２は、ＣＣＷを運ぶチャネル・インターフェース１０４を用いて、メインフレームと通信する。ＤＳＴＣは、ネットワーク接続１０６を用いてネットワーク（図示せず）と通信する。ネットワーク接続は、パケット又はセル・ベースでよい。ＤＡＳＤエンジン１０８は、重要な部分においては、チャネル・プログラム収集ロジック１０８ａ、チャネル・プログラム処理ロジック１０８ｂ及びロック・ファシリティ１０８ｃを含む。チャネル・プログラム収集ロジック１０８ａは、メインフレームと通信し、一方向において、メインフレームから一連のＣＣＷを集め、逆の方向において、一連のＣＣＷを送る役割を有している。ＣＣＷのこれらのシーケンスは、チャネル・プログラムに対応し、チャネル・プログラムは、メインフレームにおけるＳＶＣコールに対応する。ＳＶＣコールは、リード（ＦＩＮＤＣ）、ロックを伴うブロックされたリード（ＦＩＷＨＣ）、ブロックされたリード（ＦＩＮＷＣ）、ライト（ＦＩＬＥＣ）、ライト及びアンロック（ＦＩＬＵＣ）、アンロック（ＵＮＦＲＣ）などを含む。（ＴＰＦ環境は、レコード・ベースでロックすなわちホールドし、ブロックされたリードへの参照は、例えば、メインフレーム・アプリケーションが作用を行う状態を示し、従って、ブロックされたリードを用いて、メインフレーム・アプリケーションは、データが戻されるまで、ブロックされたすなわち待機状態に入る。様々なＳＶＣコール及び対応するチャネル・プログラムは既知であり、上では、便宜的にまとめられている。）チャネル・プログラム処理ロジック１０８ｂは、収集されたチャネル・プログラムに対応する機能を実現する。これは、例えば、ＩＢＭの３０９０機能に従う様々な形式のリード及びライトを実行するエンティティ（entity）である。ロック・ファシリティ１０８ｃは、チャネル・プログラムに対応するロックを実現するエンティティである。チャネル・プログラム収集ロジック１０８ａは、ロック・ファシリティ１０８ｃと協動して、収集されたチャネル・プログラムが有効であるかどうかを判断する。例えば、チャネル・プログラムがロックされたレコードに作用しようとする場合には、チャネル・プログラム収集ロジックは、メインフレームに、その要求は無効であると告知する。それ以外のＤＡＳＤエンジン・ロジックは、呼び出されない。同様に、チャネル・プログラム収集ロジックは、ロック状態が与えられたときに、任意の作用が有効であるかどうかを判断する。例えば、あるレコード上へのロックを要求したメインフレームだけが、そのレコードをアンロックすることを許可される。結果的なアンロックは、別のとき、例えば、データがレコードにライトされた後で生じるが、ロック・ファシリティ１０８ｃは、コマンドのプロプライエティ（propriety）すなわち有効性をテストするために最初にアクセスされる。同様に、チャネル・プログラム処理ロジック１０８ｂは、ロック・ファシリティ１０８ｃと協動し、それによって、適切なロックが、処理されているチャネル・プログラムに従って保持（ホールド）及び保持解除（アンホールド）なされるようにする。好適実施例では、チャネル・プログラム収集ロジック１０８ａとチャネル・プログラム処理ロジック１０８ｂとの間の制御の転送は、矛盾なく定義されている。例えば、それぞれは、ＤＳＴＣランタイム環境において別々にスケジュール可能なスレッドとして実現することができる。また、同じスレッドではあるが、２つの間には矛盾なく特定されるコールが備わっており、制御の流れを他方のロジックに再方向付けするようにパッチを当てることができるものとしても実現できる。制御メカニズムの転送は、特定のＤＳＴＣの実現に依存する。チャネル・プログラム収集ロジック１０８ａは、収集されたチャネル・プログラムのバッファされたコピーを維持する。このバッファされたコピーは、例えば、キャッシュ１２０に常駐するが、いずれの場合にも、ハンドル又はポインタを用いて一意的に位置を特定可能である。バッファされたコピーは、他のことに加えて、対応するチャネル・プログラム・コマンド（例えば、ＦＩＷＨＣ）、ＭＣＨＲアドレス、任意のデータの長さ及びデータ・ペイロードを示す情報を供給する。好適実施例では、アドレス監視ロジック１１０が、ＤＳＴＣ１０２によって受け取られたチャネル・プログラムのＭＣＨＲアドレスを能動的にモニタする。これは、いったんチャネル・プログラムが収集されたときに、好ましくは、チャネル・プログラム処理ロジック１０８ｂが呼び出される前に、アドレス監視ロジック１１０が呼び出されるように、制御の流れを再方向付けすることによってなされる。この再方向付けは、ある環境において適切なスケジュリング・プライオリティを設定することを通じて、又は、別の環境においてコール・アドレスをパッチすることによって達成されうる。いずれに場合においても、アドレス監視ロジック１１０は、ハンドル又はメインフレームから収集されたばかりのチャネル・プログラムの位置を指定するそれ以外の情報を用いて呼び出される。いったん呼び出されると、アドレス監視ロジック１１０は、現在のチャネル・プログラムにおいて呼び出されたＭＣＨＲアドレスが関心の対象であるか、すなわち、既知の関心のアドレスの組の中にあるかどうかを判断する。好適実施例では、アドレスの組は、オフロードされたＭＱＦキューに対して特にとっておかれたＭＣＨＲアドレスの範囲として実現される。アドレス監視ロジック１１０は、関心対象であるＭＣＨＲアドレスの状態を維持する内部アドレス監視ロジック状態テーブル１１０ａを有している。アドレス監視ロジック状態テーブル１１０ａは、マッピング・コンフィギュレーションとＭＣＨＲアドレスの状態とを保存し、処理をマッピング・ロジック１１２に適切に方向付ける。テーブル１１０ａのこれ以外の詳細な後に述べる。アドレスが関心対象ではない場合には、アドレス監視ロジック１１０は、それ以上の処理を行うことなく、制御を直ちにＤＡＳＤエンジン１０８に戻す。ＤＡＳＤエンジン１０８は、従って、自由に、収集されたチャネル・プログラムに対応するどのような作用でも実行することができる。この場合には、これらの作用は、物理的な持続型ストレージ要素１０９へのリード・ライトなどに対応する可能性が高い。アドレスが関心対象である場合には、アドレス監視ロジック１１０は、マッピング・ロジック１１２を呼び出す。マッピング・ロジック１１２は、以下で説明するように、様々な作用を実行し、ＭＱＦ１１４と相互作用する。結果的には処理が完了し、マッピング・ロジック１１２は、制御をアドレス監視ロジック１１０に戻し、更に、アドレス監視ロジック１１０は、制御をＤＡＳＤエンジン１０８に戻す。又は、マッピング・ロジック１１２は、制御を直接にＤＡＳＤエンジン１０８に戻す。関心対象であるアドレスは、好適実施例であるロジックによって用いられるようにとっておかれ、従って、制御がＤＡＳＤエンジン１０８に戻されると、物理的なストレージ要素１０９に関しては、無害（innocuous）の活動だけが結果的に生じる。しかし、従来型の処理アルゴリズムが呼び出される。従って、アドレス監視ロジック１１０とマッピング・ロジック１１２とによって収集され作用されたチャネル・プログラムがロック（ホールド）又はアンロック（アンホールド）動作を含む場合には、ロック・ファシリティ１０８ｃは、依然として、対応する作用を実行する、すなわち、与えられたＭＣＨＲレコードをロック又はアンロックする。ロック・ファシリティ１０８ｃのこの呼び出しは、ＤＡＳＤエンジン１０８の通常の制御の流れと処理との結果である。マッピング・ロジック１１２は、アドレス・ウォッチャ１１０によってトリガされると、ちょうど収集されたバッファされたチャネル・プログラムを解析し、これから、情報を、指名されたキューへのプット又はそれからのゲットなどの、対応するＭＱＦ作用にマップする。好適実施例では、特定の指名されたキューと特定のＭＱＦバーブとが、チャネル・プログラム・コマンド（例えば、ＦＩＬＥＣ）とＭＣＨＲアドレスとの組合せに基づいてマップされる。更に詳しくは、好適実施例では、指名されたキューは、複数のＭＣＨＲアドレスに対応する。これがなされる理由は、使用可能なチャネル・プログラム・コマンドの数が、サポートされるＭＱＦバーブの数よりも少ないからである。好適実施例では、キューが開かれる又は作られると、マッピング・ロジック１１２は、ＭＣＨＲアドレスをキューの名称（及び／又は、キューへのハンドル）にマップするテーブル・データ構造１１２ａを維持する。ＭＣＨＲアドレスは、改良型Ｉ／Ｏデバイス１００とメインフレームとの間の動作におけるキューを識別するのに用いられるが、ＭＱＦ１１４との相互作用の際には、テキスト的（te xtual）なキューの名称が用いられる。例えば、Example_qという与えられた指名されたキューは、複数の対応するＭＣＨＲアドレスを有することがありうる。例えば、１つのＭＣＨＲアドレスが４ＫＢ未満のプットに対して用いられ、別のものが４ＫＢより大きなプットに対して用いられ、また別のものが作業プットのユニットに用いられ、類似のゲットには別のものが用いられる、などである。これらの状態テーブルには、キュー・アドレス・マップ・ベクトルに加えて、オープン・キュー・ネーム、それらの既知の状態、それらの対応するＭＣＨＲアドレス、それらのＭＱＦ１１４キュー・ハンドルなどが含まれる。テーブルに記憶されている他の情報も、ここで説明する。関心対象であるそれぞれのＭＣＨＲは、アドレス監視ロジック１１０とキュー監視ロジック１１８との両方がＭＣＨＲ／キューの組合せを以下に処理するかに関してマッピング・ロジック１１２に指令するのに用いるアドレス・マップ・ベクトルを有している。キュー・アドレス・マップ・ベクトルは、ＭＣＨＲアドレスのー部である。このベクトルは、ＭＣＨＲアドレスを、ゲット・キュー若しくはプット・キュー、又は、作業キューのゲット・ユニットなどに対応するものとして定義する。関係するＭＱＦ動作と対応する指名されたキューとを識別した後で、マッピング・ロジック１１２は、対応するマッピング・ルーチンを呼び出す。これらのルーチンは、ＭＱＦ１１４との相互作用の際に、中間的な作用を実行する。ある場合には、中間的な作用は、チャネル・プログラムにおける情報を、対応するＭＱＦ作用に本質的にフォーマットし、別の場合には、中間的な作用は、ＭＱＦ１１４の機能を拡張する。マッピング・ロジック１１２は、ＭＱＦ１１４と協動する。好適実施例では、ＭＱＦは、市販されている既知のＩＢＭのＭＱＳｅｒｉｅｓである。マッピング・ロジック１１２は、対応する既知のＡＰＩを用いて、ＭＱＦ１１４と通信する。同様に、ＭＱＦは、既知の技術を用いて、好適実施例のロジックと通信する。ＭＱＦ１１４は、次に、通信スタック１１６と協動する。好適実施例では、マクロソフトＮＴ又はヒューレット・パッカード・ユニックス１１オペレーティング・システム上で使用可能な通信スタックを用いる。好適実施例では、通信スタックは、アプリケーション層よりも下位にあるサービスを実行する役割を有している。実際に必要とされるサービスの量は、ＭＱＦの選択と、ＤＳＴＣ１０２の補助的な必要性とに依存する。ＭＱＦ１１４は、キュー監視ロジック１１８と協動する。キュー監視ロジック１１８は、アドレス監視ロジック１１０と同じように、ＭＱＦ１１４とマッピング・ロジック１１２とによって処理されているすべてのキューに対応する内部テーブル１１８ａを有する。アドレス監視ロジック状態テーブル１１０ａがＭＣＨＲアドレスを指名されたキューにマップするのに対し、キュー監視ロジック状態テーブル１１８ａは、指名されたキューをＭＣＨＲアドレスにマップする。好適実施例では、キュー監視ロジック１１８は、メッセージが指名されたキューに到着したときに、ＭＱＦ１１４によってトリガされる。このトリガは、キュー監視ロジック状熊テーブル１１８ａに保存されているコンフィギュレーション及び状態に基づく既知のＭＱＦ技術を用いる。キュー監視ロジック１１８は、マッピング・ロジック１１２をトリガし、メッセージを対応するＭＣＨＲに転送する（例えば、メインフレームからのペンディングのＦＩＷＨＣコマンドがその上でホールド待機状態にある場合）か、又は、告知質問（notification inquiry）メッセージをマスタ制御応答キュー（これは、後で述べるように、マイクロフレークとの通信に用いられる）の中にプットする。以上で概略が述べられたように、マッピング・ロジック１１２は、他のことに加えて、中間的な作用（intermediate actions）を実行する。これらの作用は、流れ図３−２０に説明されている。ある場合には、メインフレームは、一連の動作を実行する、すなわち、一連のチャネル・プログラムを送り及び応答し手、与えられたＭＱＦ作用を実現することを必要とする。この意味では、メインフレームは、Ｉ／Ｏデバイスとの複数の相互作用を必要とし、他方で、従来型の構成では、Ｉ／Ｏデバイス１００との間では最も少ない場合には１つの動作、すなわち、メッセージを持続型ストレージに記憶することを必要とするだけであった。しかし、メインフレームからＩ／Ｏデバイスへの相互作用の数が増加しても、ＭＱＦと通信スタックとの処理をオフロードすることによる利益は、そのコストを上まわる。アドレス監視ロジック１００は、関心対象のＭＣＨＲアドレスを求めてＤＳＴＣ１０８の活動を検出するときには、ＭＣＨＲアドレスをそのアドレス監視ロジック状態テーブル１１０ａの中において見つける。アドレス監視ロジック状態テーブル１１０ａは、監視されたすべてのＭＣＨＲアドレスに対するエントリを含む。それぞれのエントリは、アドレス・マップ・ベクトル・フィールドを含み、このアドレス・マップ・ベクトル・フィールドは、ＭＣＨＲアドレスに対する活動を処理するマッピング・ロジック１１２におけるルーチンへのインデクス・ポインタを含む。表Ａには、商用のＭＱＦに関係する最も典型的なシナリオがまとめられている。ただし、これらのシナリオは完全なものであると考えるべきではなく、最も広く用いられているシナリオの作業モデルと考えるべきものである。［表Ａ］図２は、ＤＳＴＣ１０８ａチャネル・プログラム収集ロジックによって付勢されるアドレス監視ロジック１１０を示している。アドレス監視ロジック１１０は、チャネル・プログラム収集ロジック１０８ａがチャネル・インターフェース１０４からのチャネル・プログラムを解析し、どのＩ／Ｏコマンドが付随するＭＣＨＲアドレス上で実行されているかを判断すると、ステップ２００において、付勢される。処理は、ステップ２０５に進み、そこで、ＭＣＨＲアドレスは、アドレス監視ロジック・テーブル１１０ａに記憶されている値に対して範囲がチェックされる。ＭＣＨＲがこの範囲チェックに合格しない場合には、ロジックは、次に、ステップ２１０に進み、制御の流れは、ＤＳＴＣエンジン１０８に戻される。アドレス範囲テストの試験に合格すると、処理は、ステップ２１０に進む。ステップ２１０は、実施に応じて、アドレス監視ロジック・テーブル１１０ａの中でサーチ、ハッシング、インデクスを行い、適切なＭＣＨＲアドレス・エントリを見つける。ステップ２２０では、ＭＣＨＲアドレスに対するエントリがない場合には、又は、エントリはあるがテーブルＡからのブランチ・ベクトルをその中にもっていない場合には、処理はステップ２２５に進む。ステップ２２５では、制御の流れは、ＤＳＴＣエンジン１０８に戻される。ステップ２２０で有効なエントリとブランチ・ベクトルが見つかった場合には、ステップ２４０及び２５０において、ＭＣＨＲのアドレス監視状態テーブル１１０ａのエントリのブランチ・ベクトル・フィールドにおいて見いだされたアドレスは、それに対してブランチ（分岐）がなされる。このブランチ・アドレスは、マッピング・ロジック１１２における一意的なロジック・ルーチンを表す。このロジックすなわちアドレス監視ロジック１１０へのマッピング・ロジック１１２へのブランチからの予期されるリターンは存在しない。図３は、メッセージが４Ｋバイト未満の場合のシングル・プット・コマンドを処理するロジックを示している。（ＴＰＦメインフレームによってサポートされる最も大きなレコード・サイズは、４ＫＢである。）このロジックは、次の表１のバッファされたチャネル・プログラム・コマンドの中の１つが、テーブル１１０ａにおいて識別されるように、シングル・プットと関連付けされたＭＣＨＲアドレスとの関連でマッピング・ロジック１１２によって検出されたときに呼び出される。［表１］ロジックは、ステップ３００において開始し、ステップ３０５に進む。ステップ３０５では、ロジックは、指名されたキューが開いているかどうかを判断する。キューに対する名称は、バッファされたチャネル・プログラムにおいてＭＣＨＲアドレスを有するアドレス・テーブル１１０ａにおけるエントリから検索される。これは、ＭＱＦ１１４への既知のＡＰＩコールを用いて判断されるが、好適実施例では、状態インジケータがテーブル１１０ａに維持される。テーブル・ロジック１１０ａは、アソシエーション・ロジック（図示せず）を含み、それにより、与えられた指名されたキューに対するすべてのＭＣＨＲエントリにアクセスがなされ、相互に矛盾なく修正される。従って、対応するＭＣＨＲアドレスＡを用いてexample_q へのシングル・プットが実行されるときにキューが開いている場合には、exampl e_qに対する他方のＭＣＨＲエントリは、同じように、開くように修正され、従って、大きなプット（すなわち、４ＫＢよりも大きい）に対応するＭＣＨＲアドレスＢも、同じように、開くように修正される。このアドレスもまたexample_q にマップされるからである。指名されたキューが開いていない（オープンでない）場合には、ロジックは、ステップ３１０に進み、ここで、指名されたキューは、ＭＱＦ１１４への既知のＡＰＩコールを用いて開かれる。マッピング・ロジック１１２は、アドレス監視ロジック１１０とキュー監視ロジック１１８とをそれぞれ用いて、アドレス監視ロジック状態テーブル１１０ａとキュー監視ロジック状態テーブル１１８ａとの両方を協動的に維持する。従って、この時点で、マッピング・ロジック１１２は、テーブル１１０ａ及び１１８ａを、すべての関連するエントリに関して修正させる。次に、ロジックは、ステップ３２５に進む。指名されたキューが開いている（オープンな）場合には、ロジックは、ステップ３２５に進む。ステップ３２５では、ロジックは、チャネル・プログラム・コマンドがＦＩＬＥＣであるかどうか、すなわち、ロッキング・コマンドのないライトであるかどうかを判断する。ステップ３２５において解析されたコマンドがＦＩＬＥＣである場合には、ロジックは、ステップ３３０に進み、そこでは、バッファされたチャネル・コマンドのデータ・ペイロードが、ＭＱＦの既知のＡＰＩを用いて、対応する指名されたキューにプットされる。キューの名称は、テーブル１１０ａから提供される。次に、ロジックは、ステップ３３５に進み、そこで、制御の流れは、ＤＡＳＤエンジン１０８に戻される。ステップ３２５におけるコマンドがＦＩＬＥＣではない場合には、ロジックは、ステップ３４０に進む。ステップ３４０では、ロジックは、制御の流れをＤＡＳＤエンジン１０８に戻し、エラー条件が発せられる。このシナリオでは、認識されていないチャネル・プログラム・コマンドが受け取られる。図４は、メッセージが４Ｋバイトよりも小さい共有されたキューへのシングル・プット・コマンドを処理するロジックを示している。このロジックは、図２のバッファされたチャネル・プログラム・コマンドの１つがテーブル１１０ａにおいて識別されるように、シングル・プットと関連付けされたＭＣＨＲアドレスと関連してマッピング・ロジック１１２によって検出されるときに呼び出される。このロジックは、以下で説明されるように、シングル・プットをサポートするのと同時に、共有されたＭＱＦキューへのプットもサポートする。キューの共有可能性は、図４に示されたマッピング・ロジック１１２によって拡張された機能の結果であり、ＭＱＦ１１４に内在的なものではない。［表２］ロジックは、ステップ４００において開始し、ステップ４０５に進む。ステップ４０５では、ロジックは、指名されたキューが開いているかどうかを判断する。キューに対する名称は、バッファされたチャネル・プログラムにおいてＭＣＨＲアドレスを有するアドレス・テーブル１１０ａにおけるエントリから検索される。これは、ＭＱＦ１１４への既知のＡＰＩコールを用いて判断されるが、好適実施例では、状態インジケータがテーブル１１０ａに維持される。指名されたキューが開いていない場合には、ロジックは、ステップ４１０に進み、ここで、指名されたキューは、ＭＱＦ１１４への既知のＡＰＩコールを用いて開かれる。マッピング・ロジック１１２は、アドレス監視ロジック１１０とキュー監視ロジック１１８とをそれぞれ用いて、アドレス監視ロジック状態テーブル１１０ａとキュー監視ロジック状態テーブル１１８ａとの両方を協動的に維持し、キュー状態を修正する。指名されたキューが開いている場合には、ロジックは、ステップ４１５に進む。ステップ４１５では、ロジックは、バッファされたチャネル・プログラム・コマンドを解析し、それがＦＩＷＨＣであるかどうか、すなわち、ブロックされたリード及びロックであるかどうかを判断する。（ブロックされたという側面は、メインフレーム側の状態を指しており、Ｉ／Ｏ側のブロッキングの側面には関係ない。）このコマンドは、Ｉ／Ｏデバイス１００に接続された複数のメインフレームの間でキューが共有可能である場合に用いられる。好適実施例でＦＩＷＨＣを用いる理由は、以下で説明されるように、それが、ロック・ファシリティ１０８ｃの通常の処理を通じてＭＣＨＲアドレス・レコード上のロックを自然にトリガするからである。ロックにより、このロックが解除（アンホールド）されるまでは、他のメインフレームが、対応するＭＣＨＲレコードにアクセスすることができなくなる。ステップ４１５において解析されたコマンドがＦＩＷＨＣである場合には、ロジックは、ステップ４２０に進み、そこでは、制御の流れが、ＤＡＳＤエンジン１０８に、そして、結果的には、レコードをロックすることにより他のエンティティがそのキューに対応するＭＣＨＲアドレスにアクセスできなくするロック・ファシリティ１０８ｃに戻される。ステップ４１５におけるコマンドがＦＩＷＨＣではない場合には、ロジックは、ステップ４２５に進み、そこで、ロジックは、チャネル・プログラム・コマンドがＦＩＬＵＣであるかどうか、すなわち、アンロック・コマンドを備えたライトであるかどうかを判断する。ステップ４２５において解析されたコマンドがＦＩＬＵＣである場合には、ロジックは、ステップ４３０に進み、そこで、バッファされたチャネル・コマンドのデータ・ペイロードが、ＭＱＦの既知のＡＰＩを用いて、対応する指名されたキューにプットされる。キューの名称は、テーブル１１０ａから提供される。ロジックは，次に、ステップ４３５に進み、そこで、制御の流れは、ＤＡＳＤエンジン１０８に，そして結果的には、レコードをアンロックすることにより他のエンティティがそのキューに対応するＭＣＨＲアドレスにアクセスすることを許容するロック・ファシリティ１０８ｃに戻される。ステップ４２５のコマンドがＦＩＬＵＣでない場合には、ロジックは、ステップ４４０に進み、そこで、ロジックは、チャネル・プログラム・コマンドがＵＮＦＲＣであるかどうか、すなわち、アンロック・コマンドであるかどうかを判断する。このコマンドは、キューを既にロックした後に、共有されたキューへのプットをアボートする必要がある場合に、メインフレームによって用いられる。ステップ４４０において解析されたコマンドがＵＮＦＲＣである場合には、ロジックは、ステップ４４５に進み、そこで、制御の流れは、ＤＡＳＤエンジン１０８に、そして結果的には、レコードをアンロックすることにより他のエンティティがそのキューに対応するＭＣＨＲアドレスにアクセスすることを許容するロック・ファシリティ１０８ｃに戻される。ステップ４４０で解析されたコマンドがＵＮＦＲＣでない場合には、ロジックは、ステップ４５０に進み、そこで、制御の流れは、ＤＡＳＤエンジン１０８に戻され、そこで、エラー条件が発せられる。このシナリオでは、認識されていないチャネル・プログラム・コマンドが受け取られる。図５は、メッセージが４Ｋバイトよりも大きいシングル・プット・コマンドを処理するロジックを示している。このロジックは、表３のバッファされたチャネル・プログラム・コマンドが、テーブル１１０ａにおいて識別されるように、シングル・プットと関連付けされたＭＣＨＲアドレスと関連してマッピング・ロジック１１２によって検出されるときに、呼び出される。このロジックは、以下で説明されるように、共有されたＭＱＦキューへのプットをサポートする。キューの共有可能性は、マッピング・ロジック１１２によって拡張された機能の結果である。メインフレームのソフトウェアは、４Ｋバイトよりも大きなメッセージを、４Ｋのレコード・セグメントのチェーン（列）にセグメント化する。好適実施例では、従来型のＴＰＦレコード処理を用いて、長いメッセージのセグメント化及び再組み立て（リアセンブリ）を実現している。ＴＰＦのチェーンにおける個別的なレコードは、修正されたＤＳＴＣ１００のＤＡＳＤ上の既知のファイル・プール・アドレスにおいてファイルされる。このＴＰＦレコードのチェーン化は既知である。これには、チェーンにおける次の及び直前のＭＣＨＲアドレスをそれぞれ含むフォワード及びバック・チェーン化フィールドを有する標準的なレコード・ヘッダが用いられる。チェーンがＤＳＴＣの従来型のプール・ストレージの中にいったんファイルされると、そのチェーンにおける最初のレコード（チェーンのプライム又はヘッドとして知られている）は、以下で説明されるように、キューにプットされる。（セグメント化された長いメッセージの処理の実現には、長いメッセージのステージングのために指定されたＭＱＦキューを用いることを含めて、複数のアプローチが存在する。）［表３］ロジックは、ステップ５００において開始し、ステップ５０５に進む。ステップ５０５では、ロジックは、指名されたキューが開いているかどうかを判断する。指名されたキューが開いていない場合には、ロジックは、ステップ５１０に進み、ここで、指名されたキューは、ＭＱＦ１１４への既知のＡＰＩコールを用いて開かれる。マッピング・ロジック１１２は、アドレス監視ロジック１１０とキュー監視ロジック１１８とをそれぞれ用いて、アドレス監視ロジック状態テーブル１１０ａとキュー監視ロジック状態テーブル１１８ａとの両方を協動的に維持し、キュー状態を修正する。指名されたキューが開いている場合には、ロジックは、ステップ５１５に進む。ステップ５１５では、ロジックは、バッファされたチャネル・プログラム・コマンドを解析し、それがＦＩＷＨＣであるかどうか、すなわち、ブロックされたリード及びロックであるかどうかを判断する。ステップ５１５において解析されたコマンドがＦＩＷＨＣである場合には、ロジックは、ステップ５２０に進み、そこでは、制御の流れが、ＤＡＳＤエンジン１０８に、そして、結果的には、レコードをロックすることにより他のエンティティがそのキューに対応するＭＣＨＲアドレスにアクセスできなくするロック・ファシリティ１０８ｃに戻される。ステップ５１５において解析されたコマンドがＦＩＷＨＣではない場合には、ロジックは、ステップ５２５に進み、そこで、ロジックは、チャネル・プログラム・コマンドがＦＩＬＵＣであるかどうか、すなわち、アンロック・コマンドを備えたライトであるかどうかを判断する。ＦＩＬＵＣコマンドは、共有されたキューへのプットに対して発行される一連のコマンドの中の第２のコマンドとして用いられる。ステップ５２５において解析されたコマンドがＦＩＬＵＣである場合には、ロジックは、ステップ５２７に進み、そこで、バッファされたチャネル・コマンドのデータ・ペイロードが更に解析される。ステップ５２７では、ロジックは、データ・ペイロードにおけるレコードの既知のフォワード及びバック・チェーン化フィールド（chaining field）を解析する。ステップ５２７の一部として、現在のレコードが、マッピング・ロジック１１２の内部の長いメッセージ・ステージング・キャッシュ１１２ａの中にシーケンシャルにコピーされる。マッピング・ロジック１１２がＴＰＦ標準レコード・ヘッダにおける既知のフォワート・チェーン・フィールドがバイナリ・ゼロに設定されていると判断する場合には、現在のレコードは、チェーンの最後にある。現在のレコードにおける非ゼロのフォワード・チェーン・フィールドは、チェーンにおける次のレコードを指している既知のＭＣＨＲプール・アドレスである。マッピング・ロジック１１２は、フォワード・チェーンＭＣＨＲアドレスを用いて、ＤＳＴＣエンジン１０８をセットアップし、フォワード・チェーン化されたレコードの内部ＦＩＮＷＣコマンドをステージングする。そして、ＤＡＳＤエンジン１０８をトリガしてフェッチする。ＤＡＳＤエンジン１０８によってフェッチされたフォワード・チェーン化されたレコードは、マッピング・ロジック１１２によって、内部の長いメッセージ・ステージング・キャッシュ１１２ａの中への次のシーケンシャルなレコードとして、コピーされる。フォワード・チェーンがあるかどうかを判断し、次に、それを内部の長いメッセージ・ステージング・キャッシュ１１２ａにフェッチするというこの走査プロセスは、チェーンの終わりを示すバイナリ・ゼロのフォワード・チェーン・フィールドが見つかるまで継続する。処理は、ステップ５３０に進む。ステップ５３０では、ロジックは、内部の長いメッセージ・ステージング・キャッシュ１１２ａに保存されたそれぞれのレコードを通じてシーケンシャルにステッピングすることにより、レコート・チェーンを解析する。それぞれのレコードのフォワード及びバックワード両方のチェーン化フィールドにおけるＭＣＨＲアドレスを用いることにより、レコードのチェーンは、フォワード（順方向）及びバックワード（逆方向）の両方に論理的に横断され得る。この作用により、内部的な長いメッセージ・ステージング・キャッシュ１１２ａとして存在しているチェーンの物理的シーケンスが、その論理シーケンスと適切に一致することが保証される。ステップ５３０では、ロジックは、レコードのチェーンに存在するメッセージのセグメントを、１つの大きなメッセージに再組み立てする。（ＤＡＳＤエンジン１０８と好適実施例のロジックとは、ＴＰＦとは異なり、４Ｋレコードに限定されない。）再び、内部のメッセージ・ステージング・キャッシュ１１２ａに保存されているそれぞれのレコードを通じてシーケンシャルにステッピングすることにより、それぞれの標準的なＴＰＦレコード・ヘッダは、取り除かれ、残りのメッセージ・セグメントが、長いメッセージに連結される。処理は、ステップ５３５に進み、そこでは、ロジックは、この再組み立てが成功したかどうかを判断する。成功であれば、ロジックは、ステップ５４０に進む。そうでなければ、それは正しくない（bad）チェーンであり、処理は、ステップ５９０を継続するが、そこでは、制御の流れは、ＤＡＳＤエンジン１０８に戻され、エラー条件が発せられる。ステップ５４０では、ロジックは、内部の長いメッセージ・ステージング・キャッシュ１１２ａからの長いメッセージを、ＭＱＦ１１４における開いたキューにプットする。そして、ロジックは、次に、ステップ５７０に進み、そこでは、制御の流れは、ＤＡＳＤエンジンに、そして結果的には、ＦｌＬＵＣのＭＣＨＲと関連付けされたレコードをアンロックすることにより他のエンティティがそのキューに対応するＭＣＨＲアドレスにアクセスすることを許容するロック・ファシリティ１０８ｃに戻される。（この実施例では詳細を述べないが、マッピング・ロジック１１２において長いメッセージを再組み立てする代わりに、チェーンの中のそれぞれのレコードを、作業の１単位としてＭＱＦ１１４にシーケンシャルにプットし、オフボードのプロセッサにそれらを１つの長いメッセージとして再組み立てすることが可能である。）ステップ５２５のコマンドがＦＩＬＵＣでない場合には、ロジックは、ステップ５６０に進む。ステップ５６０では、ロジックは、バッファされたチャネル・コマンドを解析する。ステップ５６０において解析されたコマンドがＵＮＦＲＣである場合には、ロジックは、ステップ５６５に進み、そこで、制御の流れは、ＤＡＳＤエンジン１０８に、そして結果的には、レコードをアンロックすることにより他のエンティティがそのキューに対応するＭＣＨＲアドレスにアクセスすることを許容するロック・ファシリティ１０８ｃに戻される。ステップ５６０で解析されたコマンドがＵＮＦＲＣでない場合には、ロジックは、ステップ５９０に進み、そこで、制御の流れは、ＤＡＳＤエンジン１０８に戻され、そこで、エラー条件が発せられる。このシナリオでは、認識されていないチャネル・プログラム・コマンドが受け取られる。図６は、マルチプル・プット・コマンドを、作業のトランザクション・ユニットとして処理するロジックを示している。ただし、作業ユニットを構成する個々のメッセージは、それぞれが、４Ｋバイトよりも小さい。このロジックは、表４のバッファされたチャネル・プログラム・コマンドが、マルチプル・プットと関連付けされたＭＣＨＲアドレスと関連してマッピング・ロジック１１２によって検出されるときに、呼び出される。このロジックは、以下で説明されるように、プットをサポートし、更に、共有されたＭＱＦキューへのプットもサポートする。キューの共有可能性は、マッピング・ロジック１１２によって拡張された機能の結果である。［表４］ロジックは、ステップ６００において開始し、ステップ６０５に進む。ステップ６０５では、ロジックは、指名されたキューが開いているかどうかを判断する。指名されたキューが開いていない場合には、ロジックは、ステップ６１０に進み、ここで、指名されたキューは、ＭＱＦ１１４への既知のＡＰＩコールを用いて開かれる。マッピング・ロジック１１２は、アドレス監視ロジック１１０とキュー監視ロジック１１８とをそれぞれ用いて、アドレス監視ロジック状態テーブル１１０ａとキュー監視ロジック状態テーブル１１８ａとの両方を協動的に維持し、キュー状態を修正する。ロジックは、次に、ステップ６１５に進む。指名されたキューが開いている場合には、ロジックは、ステップ６１５に進む。ステップ６１５では、ロジックは、バッファされたチャネル・プログラム・コマンドを解析し、それがＨＯＬＤＣであるかどうか、すなわち、ＭＣＨＲアドレスをホールドしロックするかどうかを判断する。このコマンドは、特定のメインフレームからの作業のシンクポインテド（SyncPointed）ユニットが初期化されていることを示すのに用いられる。キューへの動作は、作業の１ユニットとして見られる一連のメッセージ・プットであるから、動作は、シンクポイントを用いてフレームされ、フレームとコミット又はロールバックのどちらかとを開始させて、フレームを終了させなければならない。好適実施例では、ＨＯＬＤＣを用いてシンクポイントをマップしているが、この理由は、それによって、ロック・ファシリティ１０８ｃの通常の処理を通じてＭＣＨＲアドレス・レコード上のロックが自然にトリガされるからである。ステップ６１５において解析されたコマンドがＨＯＬＤＣである場合には、ロジックは、状態テーブル１１０ａ及び１１２を修正して、シンクポイントが要求されたことを指示し、ロジックは、ステップ６２０に進み、ここで、制御の流れは、ＤＡＳＤエンジン１０８に、そして、結果的には、レコードをロックすることにより他のエンティティがそのキューに対応するＭＣＨＲアドレスにアクセスできなくするロック・ファシリティ１０８ｃに戻される。ステップ６１５において解析されたコマンドがＨＯＬＤＣではない場合には、ロジックは、ステップ６２５に進み、そこで、ロジックは、チャネル・プログラム・コマンドがＦＩＬＥＣであるかどうか、すなわち、ライト・コマンドであるかどうかを判断する。ステップ６２５において解折されたコマンドがＦＩＬＥＣである場合には、ロジックは、ステップ６３０に進み、そこで、バッファされたチャネル・コマンドのデータ・ペイロードが対応する指名されたキューにプットされる。これが作業ユニットにおける最初のＦＩＬＥＣである場合には、シンクポイント指示セットを有するテーブル１１０ａによって示されるように、ＦＩＬＥＣは、シンクポイント・パラメータ・セットを用いてプットにマップされる。その作用の後で、テーブル１１０ａのシンクポイント指示がクリアされる。ＦＩＬＥＣがトランザクションの最初ではない場合には、シンクポイント指示がクリアされたテーブルによって指示されるように、ＦＩＬＥＣは、シンクポイント・パラメータを設定することなくプットにマップされる。次にロジックは、ステップ６３５に進み、そこで、制御の流れは、ＤＡＳＤエンジン１０８に戻される。このように、制御は、結果的にはメインフレームに戻され、メインフレームはこの作業ユニットにおいてより多くのプットを送ることができ、又は、その作業ユニットの最後のプットを送ることができる。ステップ６２５におけるコマンドがＦＩＬＥＣではない場合には、ロジックは、ステップ６４０に進み、バッファされたチャネル・プログラム・コマンドを解析する。ステップ６４０において解折されたコマンドがＦＩＬＵＣである場合には、ロジックは、ステップ６４５に進み、そこで、バッファされたチャネル・コマンドのデータ・ペイロードが、対応する指名されたキューにプットされ、ＭＱＦの既知のＡＰＩを用いて、作業ユニットが省略される。ロジックは、次に、ステップ６６０に進み、そこで、制御の流れが、ＤＡＳＤエンジン１０８に、そして、結果的には、レコードをアンロックすることにより他のエンティティがそのキューに対応するＭＣＨＲアドレスにアクセスすることを許容するロック・ファシリティ１０８ｃに戻される。ＦＩＬＵＣは、作業ユニットを終了させるのに用いられる。メインフレームは、作業ユニットの性質に依存して、ＦＩＬＵＣに先行して多くのＦＩＬＥＣを送る。ステップ６４０におけるコマンドがＦＩＬＵＣではない場合には、ロジックは、ステップ６５０に進み、そこでは、ロジックは、チャネル・プログラム・コマンドがＵＮＦＲＣであるかどうか、すなわち、アンロック・コマンドであるかどうかを判断する。コマンドがＵＮＦＲＣである場合には、ロジックは、ステップ６５５に進み、そこでは、ロールバック・コマンドがＭＱＦに発せられ、作業の全体のフレームされたユニットをアボートする。メインフレームのアプリケーションが作業のシンクポイント・ユニットとしてメッセージのプットを実行することを開始した場合には、しかし、何らかの理由により、終了すべきではないと判断した場合には、メインフレームは、ＵＮＦＲＣを送って、ＭＱＦの既知のＡＰＩを用いてロールバックをトリガする。ロジックは、次に、ステップ６６０に進み、そこでは、制御の流れは、ＤＡＳＤエンジン１０８に、そして、結果的には、レコードをアンロックすることにより他のエンティティがそのキューに対応するＭＣＨＲアドレスにアクセスできるようにするロック・ファシリティ１０８ｃに戻される。ステップ６５０において解析されたコマンドがＵＮＦＲＣではない場合には、ロジックは、ステップ６６５に進み、そこでは、制御の流れは、ＤＡＳＤエンジン１０８に戻され、エラー条件が発せられる。このシナリオでは、認識されないチャネル・プログラム・コマンドが受けとらえる。図７は、作業のトランザクション・ユニットとしてのマルチプル・プット・コマンドに対するロジックを示している。ただし、作業ユニットの中の個々のメッセージは、それぞれが、４Ｋバイトよりも大きい。このロジックは、表３のバッファされたチャネル・プログラム・コマンドが、作業の大きなプット・ユニットと関連付けされたＭＣＨＲアドレスと関連してマッピング・ロジック１１２によって検出されるときに、呼び出される。このロジックは、以下で説明されるように、共有されたＭＱＦキューへのプットをサポートする。キューの共有可能性は、マッピング・ロジック１１２によって拡張された機能の結果である。メインフレーム・ソフトウェアは、４Ｋバイトよりも大きいメッセージを４Ｋのレコード・セグメントのチェーンにセグメント化する。ＴＰＦチェーンにおけるここのレコードは、既に説明されたように、修正されたＤＳＴＣ１００のＤＡＳＤ１０９上にある既知のファイル・プール・アドレスにおいてファイルされる。［表５］ロジックは、ステップ７００において開始し、ステップ７０５に進む。ステップ７０５では、ロジックは、指名されたキューが開いているかどうかを判断する。指名されたキューが開いていない場合には、ロジックは、ステップ７１０に進み、ここで、指名されたキューは、ＭＱＦ１１４への既知のＡＰＩコールを用いて開かれる。マッピング・ロジック１１２は、アドレス監視ロジック１１０とキュー監視ロジック１１８とをそれぞれ用いて、アドレス監視ロジック状態テーブル１１０ａとキュー監視ロジック状態テーブル１１８ａとの両方を協動的に維持し、キュー状態を修正する。指名されたキューが開いている場合には、ロジックは、ステップ７１５に進む。ステップ７１５では、ロジックは、バッファされたチャネル・プログラム・コマンドを解析し、それがＨＯＬＤＣであるかどうか、すなわち、ＭＣＨＲアドレスをホールドしロックするかどうかを判断する。このコマンドは、特定のメインフレームからの作業のシンクポインテド（SyncPointed）ユニットが初期化されていることを示すのに用いられる。キューへの動作は、作業の１ユニットとして見られる一連のメッセージ・プットであるから、動作は、既知のＭＱＦ１１４のシンクポイントを用いてフレームされ、コミット又はロールバックのどちらかを用いて終了させなければならない。好適実施例では、ＨＯＬＤＣコマンドを用いてシンクポイントをマップしているが、この理由は、それによって、ロック・ファシリティ１０８ｃの通常の処理を通じてＭＣＨＲアドレス・レコード上のロックが自然にトリガされるからである。通常のロッキングにより、この作業ユニットを、このキューを共有している他のプロセッサがそれらのメッセージをこの作業ユニットの中に挿入することから保護することができる。ステップ７１５において解析されたコマンドがＨＯＬＤＣである場合には、ロジックは、ステップ７２０に進み、そこで、既に述べたように、テーブル１１０ａが更新されてシンクポイント指示を設定し、また、制御の流れは、ＤＡＳＤエンジン１０８に戻され、そして、ロック・ファシリティ１０８ａが、ＨＯＬＤＣコマンドを処理する通常の過程において、ＭＣＨＲアドレスをロックする。ステップ７１５において解析されたコマンドがＨＯＬＤＣではない場合には、ロジックは、ステップ７２５に進み、そこで、ロジックは、チャネル・プログラム・コマンドがＦＩＬＥＣ又はＦＩＬＵＣタイプのコマンドであるかどうか、すなわち、ライト・コマンド又はライト及びアンホールド／アンロックであるかどうかを判断する。ＦＩＬＥＣコマンドは、作業ユニットに対して用いられているキューへのプットに用いられ、また、キューへのプットに対して発せられたー連のコマンドにおける第２のコマンドとして用いられる。ＦＩＬＵＣは、作業ユニットにおける最後のメッセージのキューへのプットに用いられ、作業ユニット全体をコミットする。キューへのシングル・プットに対して、又は、作業のマルチ・メッセージ・ユニットに対する一連のプット（ＦＩＬＥＣ）の後に発行される一連のコマンドにおける第２のコマンドでありうる。ステップ７２５において解析されたコマンドがＦＩＬＥＣ又はＦＩＬＵＣのどちらかである場合には、処理は、ステップ７２７に進む。コマンドがＦＩＬＥＣでもＦＩＬＵＣでもない場合には、ロジックは、ステップ７６０に進む。ステップ７２７では、ロジックは、バッファされたチャネル・コマンドのデータ・ペイロードを解析する。特に、ロジックは、データ・ペイロードにおけるレコードの既知のフォワード及びバック・チェーン化フィールド（chaining field ）を解析し、現在のレコードが、マッピング・ロジック１１２の内部の長いメッセージ・ステージング・キャッシュ１１２ａの中にシーケンシャルにコピーされる。マッピング・ロジック１１２がＴＰＦ標準レコード・ヘッダにおける既知のフォワード・チェーン・フィールドがバイナリ・ゼロに設定されていると判断する場合には、現在のレコードは、チェーンの最後にある。現在のレコードにおける非ゼロのフォワード・チェーン・フィールドは、チェーンにおける次のレコードを指している既知のＭＣＨＲプール・アドレスである。マッピング・ロジック１１２は、フォワード・チェーンＭＣＨＲアドレスを用いて、ＤＡＳＤエンジン１０８をセットアップし、フォワード・チェーン化されたレコードの内部ＦＩＮＷＣコマンドをステージングする。そして、ＤＡＳＤエンジン１０８をトリガしてフェッチする。ＤＡＳＤエンジン１０８によってフェッチされたフォワード・チェーン化されたレコードは、マッピング・ロジック１１２によって、内部の長いメッセージ・ステージング・キャッシュ１１２ａの中への次のシーケンシャルなレコードとして、コピーされる。フォワード・チェーンがあるかどうかを判断し、次に、それを内部の長いメッセージ・ステージング・キャッシュ１１２ａにフェッチするというこの走査プロセスは、チェーンの終わりを示すバイナリ・ゼロのフォワード・チェーン・フィールドが見つかるまで継続する。処理は、ステップ７３０に進む。ステップ７３０では、ロジックは、内部の長いメッセージ・ステージング・キャッシュ１１２ａに保存されたそれぞれのレコードを通じてシーケンシャルにステッピングすることにより、レコード・チェーンを解析する。それぞれのレコードのフォワード及びバックワード両方のチェーン化フィールドにおけるＭＣＨＲアドレスを用いることにより、レコードのチェーンは、フォワード（順方向）及びバックワード（逆方向）の両方に論理的に横断され得る。この作用により、内部的な長いメッセージ・ステージング・キャッシュ１１２ａとして存在しているチェーンの物理的シーケンスが、その論理シーケンスと適切に一致することが保証される。ステップ７３０では、ロジックは、レコードのチェーンに存在するメッセージのセグメントを、１つの大きなメッセージに再組み立てする。再び、内部のメッセージ・ステージング・キャッシュ１１２ａに保存されているそれぞれのレコードを通じてシーケンシャルにステッピングすることにより、それぞれの標準的なＴＰＦレコード・ヘッダは、それぞれのレコードから取り除かれ、残りのメッセージ・セグメントが、長いメッセージに連結される。処理は、ステップ７３５に進み、そこでは、ロジックは、この再組み立てが成功したかどうかを判断する。成功であれば、ロジックは、ステップ７４０に進む。そうでなければ、それは正しくない（bad）チェーンであり、処理は、ステップ５９０を継続する。ステップ７９０では、チェーンが正しくない場合には、制御の流れは、ＤＡＳＤエンジン１０８に戻され、エラー条件が発せられる。ステップ７４０では、ロジックは、内部の長いメッセージ・ステージング・キャッシュ１１２ａにおける完全に再組み立てされた長いメッセージを、ＭＱＦ１１４における開いたキューにプットする。シンクポイント指示が設定されている場合には、この長いメッセージは、作業ユニットの一部としてそれを含むシンクポイントを用いてプットされる。ロジックは、次に、ステップ７４５に進み、そこでは、ステップ７２５において解析されたＩ／Ｏファイル・コマンドがＦＩＬＵＣであった場合には、処理は、ステップ７５０を継続する。コマンドがＦＩＬＵＣではなかった場合には、処理はステップ７５５に進み、そこで、制御の流れは、ＤＡＳＤエンジン１０８に戻され、メインフレームへの正常なリターンを告知する。ステップ７５０では、ロジックは、コミットを発し、作業のＭＱＦ１１４ユニットを完了する。処理は、ステップ７７０を継続し、そこでは、制御の流れは、ＤＡＳＤエンジン１００に戻され、そして結果的には、ＦＩＬＵＣのＭＣＨＲと関連付けされたレコードをアンロックすることにより他のエンティティがそのキューに対応するＭＣＨＲアドレスにアクセスすることを許容するロック・ファシリティ１０８ｃに戻される。ステップ５２５で解析されたコマンドがＦＩＬＥＣでもＦＩＬＵＣでもない場合には、ロジックは、ステップ７６０に進み、そこで、バッファされたチャネル・プログラム・コマンドが解析される。ステップ７６０において解析されたコマンドがＵＮＦＲＣである場合には、ロジックは、ステップ７６５に進む。ステップ７６５では、ロジックは、ＭＱＦ１１４にロールバックを発行し、作業ユニットをアボートする。処理は、ステップ７７０を継続し、そこで、制御の流れは、ＤＡＳＤエンジン１０８に、そして結果的には、レコードをアンロックすることにより他のエンティティがそのキューに対応するＭＣＨＲアドレスにアクセスすることを許容するロック・ファシリティ１０８ｃに戻される。ステップ７６０で解析されたコマンドがＵＮＦＲＣでない場合には、ロジックは、ステップ７９０に進み、そこで、制御の流れは、ＤＡＳＤエンジン１０８に戻され、そこで、エラー条件が発せられる。このシナリオでは、認識されていないチャネル・プログラム・コマンドが受け取られる。図８は、個々のメッセージがそれぞれ４Ｋバイト未満であるシングル・ゲット・コマンドに対するロジックを示している。このシナリオによれば、メッセージに対する非共有キューのポーリングが可能になる。キュー上にメッセージがある場合にはそれは戻され、ない場合には、ゼロ・レコード（null record）が戻される。このロジックは、表６のバッファされたチャネル・プログラム・コマンドの１つが、シングル・ゲットと関連付けされたＭＣＨＲアドレスと共にマッピング・ロジック１１２によって検出されるときに呼び出される。［表６］このロジックは、ステップ８００において開始し、ステップ８０５に進む。ステップ８０５では、ロジックは、指名されたキューが開いているかどうかを判断する。指名されたキューが開いていない場合には、ロジックは、ステップ８１０に進み、そこで、指名されたキューは、ＭＱＦ１１４への既知のＡＰＩコールを用いて、開かれる。マッピング・ロジック１１２は、アドレス監視ロジック１１０とキュー監視ロジック１１８とをそれぞれ用いて、アドレス監視ロジック状態テーブル１１０ａとキュー監視ロジック状態テーブル１１８ａとの両方を協動的に維持し、キュー状態を修正する。指名されたキューが開いている場合には、ロジックは、ステップ８３０に進む。ステップ８３０では、ロジックは、バッファされたチャネル・プログラム・コマンドを解析し、それが、ＦＩＮＷＣであるかどうか、すなわち、ブロックされたリードであるかどうかを判断する。ステップ８３０において解析されたコマンドがＦＩＮＷＣでない場合には、ロジックは、ステップ８３５に進み、そこで、制御の流れは、ＤＡＳＤエンジン１０８に戻され、エラー条件が告知される。このシナリオでは、認識されていないチャネル・プログラム・コマンドが受け取られている。ステップ８３０におけるコマンドがＦＩＮＷＣである場合には、ロジックは、ステップ８４０に進む。ステップ８４０では、ロジックは、ＭＣＨＲアドレスに対応する指名されたキューにゲット・コマンドを発行する。ＭＱＦ１１４がゲットの処理から戻ると、ロジックは、ステップ８８０を継続する。ステップ８８０においては、ロジックは、ＭＱＦからのリターン・コードを用いることによって、ＭＱＦからの結果を受け取ったかどうかを判断する。メッセージが受け取られている場合には、ロジックは、ステップ８８５に進み、そこで、制御の流れが、エンジン１０８に戻され、処理ロジック１０８ｂが、関連するＭＣＨＲにおけるレコードをメインフレームに戻す。メッセージが受け取られていない場合には、ロジックは、ステップ８９０に進む。更に詳しくは、ステップ８８５では、マッピング・ロジック１１２は、戻されたメッセージ・ペイロードをＦＩＮＷＣのＭＣＨＲアドレスに対応するＤＳＴＣのＲＡＭキャッシュ・バッファ１２０のエントリに配置する。そして、制御の流れが、ＤＡＳＤエンジンに、そして、結果的に、レコードを、ＲＡＭキャッシュ・バッファ１２０からチャネル・インターフェース１０４を介してメインフレームに転送させる処理ロジック１０８ｂに、戻される。ＭＱＦへのゲットが指名されたキューにおいて何も見つけなかった（例えば、キューが空であった）場合には、ロジックは、ステップ８９０に進み、そこで、マッピング・ロジック１１２は、メッセージなしを示すゼロ・レコード（null r ecord）を、ＦＩＮＷＣのＭＣＨＲアドレスに対応するＤＳＴＣのＲＡＭキャッシュ・バッファ１２０のエントリに配置する。ロジックは、ステップ８９５に進み、そこで、ＤＡＳＤエンジン１０８に、そして結果的には、ゼロ・レコードを、ＲＡＭキャッシュ・バッファ１２０からチャネル・インターフェース１０４を介してメインフレームに転送させる処理ロジック１０８ｂに、戻される。ステップ８９５は、制御の流れをＤＡＳＤエンジンに戻させ、ゼロ・エンジンは、メインフレームに戻される。図９は、個々のメッセージがそれぞれ４Ｋバイト未満であるシングル・ゲット・コマンドに対するロジックを示している。このロジックは、表７のバッファされたチャネル・プログラム・コマンドの１つが、シングル・ゲットと関連付けされたＭＣＨＲアドレスと共にマッピング・ロジック１１２によって検出されるときに呼び出される。このロジックは、以下で説明されるように、共有されたＭＱＦキューへのゲットをサポートする。キューの共有可能性は、マッピング・ロジック１１２によって拡張された機能の結果である。［表７］このロジックは、ステップ９００において開始し、ステップ９０５に進む。ステップ９０５では、ロジックは、指名されたキューが開いているかどうかを判断する。指名されたキューが開いていない場合には、ロジックは、ステップ９１０に進み、そこで、指名されたキューは、ＭＱＦ１１４への既知のＡＰＩコールを用いて、開かれる。マッピング・ロジック１１２は、アドレス監視ロジック１１０とキュー監視ロジック１１８とをそれぞれ用いて、アドレス監視ロジック状態テーブル１１０ａとキュー監視ロジック状態テーブル１１８ａとの両方を協動的（co operatively）に維持し、キュー状態を修正する。ロジックは、ステップ９３０に進む。ステップ９３０では、ロジックは、バッファされたチャネル・プログラム・コマンドを解析し、それが、ＦＩＷＨＣであるかどうか、すなわち、ブロックされたリードであるかどうかを判断する。このコマンドは、指名されたキューがＩ／Ｏデバイス１００に接続された複数のメインフレームの間で共有可能である場合に、用いられる。指名されたキューに対して意図されている動作はゲットであり、メッセージがキュー上に現れたすぐにメッセージをキューからメインフレームに転送することが意図されているから、アクセスのシーケンシャル性（sequenti ality）を保護するためにロック・ファシリティ１０８ｃが用いられる。このようにブロックされたリードが用いられることにより、メインフレームが、新たなメッセージのためにキューを連続的にブラウズしなければならないことが回避される。好適実施例でＦＩＷＨＣが用いられる理由は、それにより、ロック・ファシリティ１０８ｃの通常の処理を通じて、ＭＣＨＲアドレス・レコード上のロックが自然にトリガされるからである。ステップ９３０において解析されたコマンドがＦＩＷＨＣでない場合には、ロジックは、ステップ９３５に進み、そこで、制御の流れは、ＤＡＳＤエンジン１０８に戻され、エラー条件が告知される。このシナリオでは、認識されていないチャネル・プログラム・コマンドが受け取られている。ステップ９３０におけるコマンドがＦＩＷＨＣである場合には、ロジックは、ステップ９４０に進む。ステップ９４０では、ロジックは、ＭＣＨＲアドレスに対応する指名されたキューにゲット・コマンドを発行する。ＭＱＦ１１４がゲットの処理から戻ると、ロジックは、ステップ９８０を継続する。ステップ９８０においては、ロジックは、ＭＱＦからのリターン・コードを用いることによって、ＭＱＦからの結果を受け取ったかどうかを判断する。メッセージが受け取られている場合には、ロジックは、ステップ９８５に進み、そこで、制御の流れが、エンジン１０８に戻され、処理ロジック１０８ｂが、関連するＭＣＨＲにおけるレコードをメインフレームに戻す。メッセージが受け取られていない場合には、ロジックは、ステップ９９０に進む。更に詳しくは、ステップ９８５では、マッピング・ロジック１１２は、戻されたメッセージ・ペイロードをＦＩＷＨＣのＭＣＨＲアドレスに対応するＤＳＴＣのＲＡＭキャッシュ・バッファ１２０のエントリに配置する。そして、制御の流れが、ＤＡＳＤエンジン１０８に、そして結果的に、レコードを、ＲＡＭキャッシュ・バッファ１２０からチャネル・インターフェース１０４を介してメインフレームに転送させる処理ロジック１０８ｂに、戻される。この時点では、ＵＮＦＲＣコマンドを実行してＭＣＨＲ上のロックを解除するのは、メインフレームの役割である。ＭＱＦへのゲットが指名されたキューにおいて何も見つけなかった（例えば、キューが空であった）場合には、ロジックは、ステップ９９０において、キュー監視ロジック１１８を用いて、トリガ付勢プロセスをセットアップする。ステップ９９０のロジックは、ＦＩＷＨＣのロック及びリード要求を利用する。特に、ステップ９９５のロジックは、ＤＡＳＤエンジンのロック・ファシリティ１０８ｃを直接にコールし、条件を設定して、ＭＣＨＲを共有しているクラスタにおける別の（ファントム）メインフレームが既にロックを備えたレコードを有していることを示す。このようにして、メインフレームに戻された結果により、関連するメインフレームのソフトウェアは、そのレコードに対する待機状態に入る。従って、ＦＩＷＨＣを実行しているメインフレームは、それをアンロックするには、他のものを待機しなければならない。このほかのファントム・メインフレームは、実際には、以下で説明するように、キュー待機ロジック１１８である。ロジックは、次に、ステップ９９５に進み、そこで、制御の流れは、ＤＡＳＤエンジン１０８に戻される。（後に、この他のもの、すなわち、キュー監視ロジック１１８が新たに受け取られたメッセージをメッセージ・キューにおいて検出すると、キュー監視ロジック１１８は、ＤＡＳＤエンジン１０８に、ルーチン的に、レコードをアンロックさせ、待機しているメインフレームに割り込みを生じさせ、それによって、待機しているメインフレームがレコード上の発見を再要求し、今回は、その発見に成功する。このプロセスは、後で、図１９において、説明される。）ステップ９９５では、ロジックは、制御の流れをＤＡＳＤエンジン１０８に、そして結果的には、ロック・ファシリティ１０８ｃに戻させる。ロック・ファシリティ１０８ｃは、要求しているメインフレームに、別のメインフレームが、レコード上にロックを有していることを告知し、また、ロック・ファシリティ１０８ｃは、待機しているすべてのメインフレームに、キューに対応する所望のＭＣＨＲ上のロックがいつ解除されるかを告知する。（このロック・ファシリティ・ロジックは、従来型のものである。）図１０Ａ−Ｂは、個々のメッセージがそれぞれ４Ｋバイトよりも大きいシングル・ゲット・コマンドに対するロジックを示している。このロジックは、表８のバッファされたチャネル・プログラム・コマンドの１つが、シングル・ラージ・ゲットと関連付けされたＭＣＨＲアドレスと共にマッピング・ロジック１１２によって検出されるときに呼び出される。このロジックは、以下で説明されるように、共有されたＭＱＦキューへのゲットをサポートする。キューの共有可能性は、マッピング・ロジック１１２によって拡張された機能の結果である。［表８］このロジックは、ステップ１０００において開始し、ステップ１００５に進む。ステップ１００５では、ロジックは、指名されたキューが開いているかどうかを判断する。指名されたキューが開いていない場合には、ロジックは、ステップ１０１０に進み、そこで、指名されたキューは、ＭＱＦ１１４への既知のＡＰＩコールを用いて、開かれる。マッピング・ロジック１１２は、アドレス監視ロジック１１０とキュー監視ロジック１１８とをそれぞれ用いて、アドレス監視ロジック状態テーブル１１０ａとキュー監視ロジック状態テーブル１１８ａとの両方を協動的（ cooperatiｖely）に維持し、キュー状態を修正する。ロジックは、ステップ１０１５に進む。ステップ１０１５では、ロジックは、バッファされたチャネル・プログラム・コマンドを解析し、それが、ＦＩＷＨＣであるかどうか、すなわち、ブロックされたリードであるかどうかを判断する。ステップ１０１５において解析されたコマンドがＦＩＷＨＣでない場合には、ロジックは、ステップ１０７２に進む。ステップ１０１５におけるコマンドがＦＩＷＨＣである場合には、ロジックは、ステップ１０３０に進む。ステップ１０３０では、ロジックは、ＭＣＨＲアドレスに対応する指名されたキューにゲット・コマンドを発行する。既知のＡＰＩを用いて、ＭＱＦ１１４へのゲット・コールがなされ、長いメッセージをキューからマッピング・ロジック１１２の内部の長いメッセージ・ステージング・キャッシュ１１２ａにコピーさせる。ＭＱＦ１１４がゲットの処理から戻ると、ロジックは、ステップ１０３５を継続する。ステップ１０３５においては、ロジックは、ＭＱＦ１１４からのリターン・コードを用いることによって、ＭＱＦ１１４からの結果を受け取ったかどうかを判断する。長いメッセージが受けとらえている場合には、ロジックは、ステップ１０４０に進む。メッセージが受け取られていない場合には、ロジックは、ステップ１０５５に進む。ステップ１０４０では、ロジックは、長いメッセージを、内部の長いメッセージ・ステージング・キャッシュ１１２ａにおける４ＫのＴＰＦレコードにセグメント化することによって、ＴＰＦレコード・チェーンを構築する。レコード・チェーンにおけるそれぞれのメッセージ・セグメントには、標準的なＴＰＦレコード・ヘッダが与えられる。それぞれのレコードのフォワード及びバックワード両方のチェーン化フィールド（Chaining fields）にシーケンス番号を配置することによって、レコードのチェーンは、論理的にはフォワード及びバックワードの両方向に横断することが可能になる。この作用によって、内部の長いメッセージ・ステージング・キャッシュ１１２ａに物理的に存在しているセグメント化されたチェーンの物理的なシーケンスがその論理シーケンスに適切に一致することが保証される。チェーンのフォワード・チェーン化フィールドにおける最後のレコードは、チェーンの最後を示すゼロ（null）に設定される。ステップ１０４５では、マッピング・ロジック１１２は、セグメント化された長いメッセージに対応するチェーンにおける最初のＴＰＦレコードを、ＦＩＷＨＣのＭＣＨＲアドレスに対応するＤＡＳＤエンジンのＲＡＭキャッシュ・バッファ１２０のエントリに配置する。アドレス監視ロジック状態テーブル１１０ａは、チェーンの最初のレコードがＤＡＳＤエンジンのＲＡＭキャッシュ・バッファ１２０の中へのステージングの準備ができていることを示す長いメッセージ・カーソルを用いて更新される。処理は、ステップ１０７８を継続する。ステップ１０３５では、ＭＱＦへのゲットが指名されたキューにおいて何も見つけなかった（例えば、キューが空であった）場合には、ロジックは、ステップ１０５５に進み、そこで、上述のものと類似の、キュー監視ロジック１１８を用いて、トリガ付勢プロセスをセットアップする。（先に述べたように、この他のもの、すなわち、キュー監視ロジック１１８が、メッセージ・キューにおいて新たに受け取られたメッセージによって、アクティブにトリガされると、キュー監視ロジック１１８は、ＤＡＳＤエンジン１０８に、ルーチン的に、レコードをアンロックさせ、待機しているメインフレームに割り込みを生じさせ、それによって、待機しているメインフレームがレコード上の発見を再要求し、今回は、その発見に成功する。このプロセスは、後で、図１９において、説明される。）ロジックは、ステップ１０５９に進み、そこで、ロジックは、制御の流れをＤＡＳＤエンジン１０８に、そして結果的には、ロック・ファシリティ１０８ｃに戻させる。ロック・ファシリティ１０８ｃは、要求しているメインフレームに、別のメインフレームが、レコード上にロックを有していることを告知し、また、ロック・ファシリティ１０８ｃは、待機しているすべてのメインフレームに、キューに対応する所望のＭＣＨＲ上のロックがいつ解除されるかを告知する。（このロック・ファシリティ・ロジックは、従来型のものである。）ステップ１０１５において、ロジックは、コマンドがＦＩＷＨＣでないことと判断した場合には、ステップ１０７２に進む。ステップ１０７２では、ロジックは、バッファされたチャネル・プログラム・コマンドを解析し、それがＦＩＮＷＣであるかどうか、すなわち、ブロックされたリードであるかどうかを判断する。そうである場合には、処理は、ステップ１０７４を継続する。ＦＩＮＷＣは、長いゲットのすべての後続の４Ｋセグメントをリードするのに用いられる。ステップ１０７２において解析されたコマンドがＦＩＮＷＣではない場合には、ロジックは、ステップ１０９２に進み、そこで、制御の流れは、ＤＡＳＤエンジンに戻され、エラー条件が告知される。このシナリオでは、認識されていないチャネル・プログラム・コマンドが受け取られている。ステップ１０７４では、ロジックは、アドレスを監視する長い状態テーブル１１０ａの長いメッセージ・カーソルをチェックして、長いメッセージのチェーン化されたレコード・セグメントのすべてがメインフレームに転送されているかどうかを判断する。そうではない場合には、処理は、ステップ１０７８を継続する。長いメッセージの全体がメインフレームに転送されている場合には、処理は、ステップ１０７６を継続する。ステップ１０７６において、ロジックは、ゼロ・レコード（長いメッセージのセグメントのすべてがメインフレームに転送されていることを示す）を、ＦＩＮＷＣのＭＣＨＲアドレスに対応するＤＡＳＤエンジンのＲＡＭキャッシュ・バッファ１２０のエントリに配置する。ステップ１０７８では、マッピング・ロジック１１２は、長いメッセージ・カーソルによって示されたチェーンにおける次のＴＰＦレコードを、ＦＩＷＨＣのＭＣＨＲアドレスに対応するＤＡＳＤエンジンのＲＡＭキャッシュ・バッファ１２０のエントリに配置する。ステップ１０８０では、ロジックは、ＤＡＳＤエンジンのＲＡＭキャッシュ・バッファ１２０に転送されたばかりのレコードの標準的なＴＰＦフォワード・チェーン・フィールドをチェックし、これが、チェーンにおける最後のレコードであるかどうかを判断する。最後のレコードではない場合には、処理は、ステップ１０８５に進む。チェーンにおける最後のレコードである場合には、処理は、ステップ１０９０に進む。ステップ１０９０では、ロジックは、このエントリに対する長いメッセージ・ステージング・キャッシュ１１２ａをフラッシュし、アドレス監視ロジック状態テーブル１１０ａの長いメッセージ・カーソルをクリアする。処理は、ステップ１０９５に進む。ステップ１０８５では、ロジックは、アドレス監視ロジック状態テーブル１１０ａの長いメッセージ・カーソルを更新して、チェーンにおける次のレコードを指す。処理は、ステップ１０９５を継続する。ステップ１０９５では、ロジックは、制御の流れを、ＤＡＳＤエンジンに、そして結果的には、レコードをＲＡＭキャッシュ・バッファ１２０からチャネル・インターフェース１０４を介してメインフレームに転送させる処理ロジック１０８ｂに戻させる。チェーンの最後のレコードがメインフレームに転送されるときには、ＵＮＦＲＣを実行して、ＭＣＨＲ上のロックを解除するのは、メインフレーム・アプリケーションの責任である。図１１Ａ−Ｂは、個々のメッセージが作業のトランザクション・ユニットを構成するマルチプル・ゲット・コマンドに対するロジックを示している。ただし、作業ユニットを構成する個々のメッセージは、それぞれが、４Ｋバイトよりも小さい。このロジックは、表９のバッファされたチャネル・プログラム・コマンドの１つが、マルチプル・ゲットと関連付けされたＭＣＨＲアドレスと共にマッピング・ロジック１１２によって検出されるときに、呼び出される。このロジックは、以下で説明されるように、共有されたＭＱＦキューへのゲットをサポートする。キューの共有可能性は、マッピング・ロジック１１２によって拡張された機能の結果である。［表９］ロジックは、ステップ１１００において開始し、ステップ１１０５に進む。ステップ１１０５では、ロジックは、指名されたキューが開いているかどうかを判断する。指名されたキューが開いていない場合には、ロジックは、ステップ１１１０に進み、ここで、指名されたキューは、ＭＱＦ１１４への既知のＡＰＩコールを用いて開かれる。マッピング・ロジック１１２は、アドレス監視ロジック１１０とキュー監視ロジック１１８とをそれぞれ用いて、アドレス監視ロジック状態テーブル１１０ａとキュー監視ロジック状態テーブル１１８ａとの両方を協動的に維持し、キュー状態を修正する。ロジックは、次に、ステップ１１２５に進む。ステップ１１２５では、ロジックは、バッファされたチャネル・プログラム・コマンドを解析し、それがＨＯＬＤＣであるかどうか、すなわち、ロックであるかどうかを判断する。コマンドがＨＯＬＤＣである場合には、処理は、ステップ１１３０を継続し、そこで、制御の流れは、エンジン１０８とロック・ファシリティ１０８ｃに戻り、これにより、ＭＣＨＲがロックされる。テーブル１１０ａが更新され、シンクポイント指示が設定される。ステップ１１２５において解析されたコマンドがＨＯＬＤＣでない場合には、ロジックは、ステップ１１３５に進む。ステップ１１３５では、ロジックは、バッファされたチャネル・プログラム・コマンドを解析し、それがＦＩＮＷＣであるかどうか、すなわち、ブロックされたリードであるかどうかを判断する。そうである場合には、ロジックは、ステップ１１３７を継続し、そうでない場合には、処理は、ステップ１１８０を継続する。ステップ１１３７では、ロジックは、作業ユニットを指示するシンクポイントを備えたゲット・コマンドを、シンクポイント指示がテーブル１１０ａにおいて設定されている場合にはＭＣＨＲに対応する指名されたキューに対して、発行する。ＭＱＦ１１４が結果を戻すと、処理は、ステップ１１５５を継続する。ステップ１１５５では、ロジックは、ＭＱＦ１１４からのリターン・コードを用いて、ＭＱＦ１１４がメッセージを戻すかどうかを判断する。メッセージを見つけなかった場合には、ロジックは、ステップ１１６０に進む。ロジックがメッセージを受け取った場合には、ロジックは、ステップ１１５９を継続する。ステップ１１５９では、ロジックは、戻されたメッセージ・ペイロードを、ＦＩＮＷＣのＭＣＨＲアドレスに対応するＤＳＴＣのＲＡＭキャッシュ・バッファ１２０のエントリに配置する。ロジックは、また、このＭＣＨＲに対するアドレス監視ロジック・テーブル１１０ａのエントリを更新し、作業のこのゲット・ユニットに対するデータ転送が開始していることを示し、シンクポイントをクリアする。ロジックは、ステップ１１６９に進み、そこで、制御の流れは、ＤＡＳＤエンジン１０８に、そして結果的に、レコードをＲＡＭキャッシュ・バッファ１２０からチャネル・インターフェース１０４を介してメインフレームに転送させる処理ロジック１０８ｃに戻される。ステップ１１６０では、ロジックは、このＭＣＨＲに対するアドレス監視ロジック・テーブル１１０ａをチェックして、作業のこのゲット・ユニットに対するキューからメインフレームへのデータ転送が、実際に開始されているかどうかを調べている。まだ開始していない場合には、処理は、キューにおいて受け取られる作業の入ってくるユニットに対する待機をセットアップしなければならない。このトリガ待機処理のセットアップは、ステップ１１７０において生じる。ステップ１１６０では、作業ユニットのデータ転送は、キューからメインフレームに開始されており、ＭＱＦ１１４上にメッセージが全く存在しないということが、作業の全ユニットがメインフレームに転送されたということを示している。処理は、ステップ１１６５を継続する。ステップ１１７０では、マッピング・ロジック１１２は、図９及び図１０において既に説明したものと類似のキュー監視ロジック１１８を用いて、トリガ付勢プロセスをセットアップする。次に、ロジックは、ステップ１１７５に進む。ステップ１１７５では、ロジックは、制御ロック・ファシリティの流れを、ＤＡＳＤエンジン１０８に、そして結果的には、ロック・ファシリティ１０８ｃに戻す。ロック・ファシリティは、要求しているメインフレームに、別のメインフレームがレコード上にロックを有していることを告知し、また、ロック・ファシリティ１０８ｃは、待機しているすべてのメインフレームに、キューに対応する所望のＭＣＨＲ上のロックがいつ解除されるかを告知する。ステップ１１６５では、ロジックは、ゼロ・レコード（作業ユニットの最後に到達したことを示している）を、ＦＩＮＷＣのＭＣＨＲアドレスに対応するＤＳＴＣのＲＡＭキャッシュ・バッファ１２０に配置する。ロジックは、ステップ１１６９に進み、そこで、制御の流れは、ＤＡＳＤエンジン１０８に、そして結果的には、ゼロ・レコードをＲＡＭキャッシュ・バッファ１２０からチャネル・インターフェース１０４を介してメインフレームに転送させる処理ロジック１０８ｂに戻される。ステップ１１８０では、ロジックは、バッファされたコマンドがＵＮＦＲＣであるかどうかを判断する。ＵＮＦＲＣである場合には、処理は、ステップ１１８５を継続する。コマンドがＵＮＦＲＣではない場合には、処理は、ステップ１１９０に進み、コマンドがＦＩＬＵＣであるかどうかを判断する。ＦＩＬＵＣである場合には、処理は、ステップ１１９２を継続する。そうでない場合には、コマンドは認識されず、ロジックは、ステップ１１９９に進み、制御の流れはＤＡＳＤエンジン１０８に戻され、エラー条件が告知される。このシナリオでは、認識されていないチャネル・プログラム・コマンドが受け取られる。ステップ１１８５では、ロジックは、ＭＱＦ１１４へのコミットに作業ユニットを発行するが、その理由は、それが、キューからメインフレームに成功裏に完全に転送されたからである。処理は、ステップ１１９５を継続し、そこで、制御の流れは、ＤＡＳＤエンジン１０８に、そして結果的には、ＵＮＦＲＣのＭＣＨＲと関係付けられたレコードをアンロックすることにより他のエンティティがそのキューに対応するＭＣＨＲアドレスにアクセスすることを可能にするロック・ファシリティ１０８ｃに、戻される。ステップ１１９０において解析されたコマンドがＦＩＬＵＣである場合には、ロジックは、ステップ１１９２に進む。ステップ１１９２では、ロジックは、ロールバックをＭＱＦ１１４に発行して、作業ユニットをアボートする。処理は、ステップ１１９５を継続し、そこでは、制御の流れは、ＤＡＳＤエンジン１０８に、そして結果的には、レコードをアンロックすることにより他のエンティティがそのキューに対応するＭＣＨＲアドレスにアクセスすることを可能にするロック・ファシリティ１０８ｃに、戻される。図１２Ａ−Ｂは、個々のメッセージが作業のトランザクション・ユニットを構成するマルチプル・ゲット・コマンドに対するロジックを示している。ただし、作業ユニットにおいて与えられる任意のメッセージは、それぞれが、４Ｋバイトよりも大きい。このロジックは、表１０のバッファされたチャネル・プログラム・コマンドの１つが、マルチプル・ゲットと関連付けされたＭＣＨＲアドレスと共にマッピング・ロジック１１２によって検出されるときに、呼び出される。このロジックは、以下で説明されるように、共有されたＭＱＦキューへのゲットをサポートする。キューの共有可能性は、マッピング・ロジック１１２によって拡張された機能の結果である。［表１０］ロジックは、ステップ１２００において開始し、ステップ１２０５に進む。ステップ１２０５では、ロジックは、指名されたキューが開いているかどうかを判断する。指名されたキューが開いていない場合には、ロジックは、ステップ１２１０に進み、ここで、指名されたキューは、ＭＱＦ１１４への既知のＡＰＩコールを用いて開かれる。マッピング・ロジック１１２は、アドレス監視ロジック１１０とキュー監視ロジック１１８とをそれぞれ用いて、アドレス監視ロジック状態テーブル１１０ａとキュー監視ロジック状態テーブル１１８ａとの両方を協動的に維持し、キュー状態を修正する。ロジックは、次に、ステップ１２２５に進む。ステップ１２２５では、ロジックは、バッファされたチヤネル・プログラム・コマンドを解析し、それがＨＯＬＤＣであるかどうか、すなわち、ロックであるかどうかを判断する。コマンドがＨＯＬＤＣである場合には、処理は、ステップ１２３０を継続し、そこで、制御の流れは、エンジン１０８とロック・ファシリティ１０８ｃに戻り、これにより、ＭＣＨＲがロックされる。テーブル１１０ａが更新され、シンクポイント指示（syncpoint indication）が設定される。ステップ１２２５において解析されたコマンドがＨＯＬＤＣでない場合には、ロジックは、ステップ１２３５に進む。ステップ１２３５では、ロジックは、バッファされたチャネル・プログラム・コマンドを解析し、それがＦＩＮＷＣであるかどうか、すなわち、ブロックされたリードであるかどうかを判断する。そうである場合には、ロジックは、ステップ１２３７を継続し、そうでない場合には、処理は、ステップ１２８０を継続する。ステップ１２３７及び１２４０は、ステップ１２４２への処理通過コネクタである。ステップ１２４２は、アドレス監視ロジック・テーブル１１０ａをチェックして、この作業ユニットに対するすべてのメッセージが転送されているかどうかを判断する。作業ユニットが転送されている場合には、処理は、ステップ１２５０に進む。ステップ１２４４において、そうでない場合には、ロジックは、シンクポイントを備えたゲット・コマンドを発行し、作業ユニットにおける最初の長いメッセージを、ＭＣＨＲアドレスに対応する指名されたキューからゲットする。ゲット・コールは、既知のＡＰＩを用いてＭＱＦ１１４に対してなされ、それによって、長いメッセージがキューからマッピング・ロジック１１２の内部の長いメッセージ・ステージング・キャッシュ１１２ａの中にコピーされる。ＭＱＦ１１４がゲットの処理から戻ると、ロジックは、ステップ１２６０を継続する。ステップ１２６０では、ロジックは、ＭＱＦ１１４からのリターン・コードを用いることによって、ＭＱＦ１１４からの結果を受け取ったかどうかを判断する。長いメッセージが受け取られた場合には、ロジックは、ステップ１２６５に進む。メッセージが受け取られていない場合には、ロジックは、ステップ１２６１に進む。ステップ１２６５では、ロジックは、最初の長いメッセージを、内部の長いメッセージ・ステージング・キャッシュ１１２ａにおける４ＫのＴＰＦレコードにセグメント化することによって、ＴＰＦレコード・チェーンを構築する。レコード・チェーンにおけるそれぞれのメッセージ・セグメントには、標準的なＴＰＦレコード・ヘッダが与えられる。それぞれのレコードのフォワード及びバックワード両方のチェーン化フィールド（Chaining fields）にシーケンス番号を配置することによって、レコードのチェーンは、論理的にはフォワード及びバックワードの両方向に横断することが可能になる。この作用によって、内部の長いメッセージ・ステージング・キャッシュ１１２ａに物理的に存在しているセグメント化されたチェーンの物理的なシーケンスがその論理シーケンスに適切に一致することが保証される。チェーンのフォワード・チェーン化フィールドにおける最後のレコードは、チェーンの最後を示すゼロ（null）に設定される。ステップ１２６７では、マッピング・ロジック１１２は、セグメント化された長いメッセージに対応するチェーンにおける最初のＴＰＦレコードを、ＦＩＷＨＣのＭＣＨＲアドレスに対応するＤＳＴＣエンジン１０８のＲＡＭキャッシュ・バッファ１２０のエントリに配置する。アドレス監視ロジック状態テーブル１１０ａは、チェーンの最初のレコードがＤＳＴＣエンジンのＲＡＭキャッシュ・バッファ１２０からメインフレームの中への転送の準備ができていることを示す長いメッセージ・カーソルを用いて更新される。処理は、ステップ１２７９を継続する。ステップ１２６１では、マッピング・ロジック１１２は、図９及び図１０において先に説明したものと類似するキュー監視ロジック１１８を用いて、トリガ付勢プロセスをセットアップする。ロジックは、次に、ステップ１２６２に進む。ステップ１２６２では、ロジックは、制御ロック・ファシリティの流れをＤＡＳＤエンジン１０８に、そして結果的には、ロック・ファシリティ１０８ｃに戻させる。ロック・ファシリティは、要求しているメインフレームに、別のメインフレームが、レコード上にロックを有していることを告知し、また、ロック・ファシリティ１０８ｃは、待機しているすべてのメインフレームに、キューに対応する所望のＭＣＨＲ上のロックがいつ解除されるかを告知する。ステップ１２５０（ステップ１２４２から）では、ロジックは、アドレス監視ロジック状態テーブル１１０ａの長いメッセージ・カーソルをチェックして、長いメッセージのチェーン化されたレコード・セグメントのすべてがメインフレームに転送されているかどうかを判断する。そうではない場合には、処理は、ステップ１２５１を継続する。長いメッセージの全体がメインフレームに転送されている場合には、処理は、ステップ１２５２を継続する。ステップ１２５１では、マッピング・ロジック１１２は、長いメッセージ・カーソルによって示されたチェーンにおける次のＴＰＦレコードを、ＦＩＷＨＣのＭＣＨＲアドレスに対応するＤＳＴＣエンジンのＲＡＭキャッシュ・バッファ１２０のエントリに配置する。処理は、長いメッセージ・カーソルをインクリメントした後で、ステップ１２７９を継続する。ステップ１２７９では、制御の流れが、ＤＳＴＣエンジン１０８に、そして結果的には、レコードをＲＡＭキャッシュ・バッファ１２０からチャネル・インターフェース１０４を介してメインフレームに転送させる処理ロジック１０８ｃに戻される。ステップ１２５２では、ロジックは、別のゲット・コマンドを発行し、ＭＣＨＲアドレスに対応する指名されたキューから、作業のシンクポインテド・ユニットにおける次のメッセージをゲットする。ゲット・コールが、既知のＡＰＩを用いてＭＱＦ１１４に対してなされ、それによって、長いメッセージが、キューからマッピング・ロジック１１２の内部の長いメッセージ・ステージング・キャッシュ１１２ａの中にコピーされる。ＭＱＦ１１４がゲットの処理から戻ると、ロジックは、ステップ１２５４を継続する。ステップ１２５４では、ロジックは、ＭＱＦ１１４からのリターン・コードを用いることにより、ＭＱＦ１１４からの結果を受け取ったかどうかを判断する。長いメッセージが受け取られた場合には、ロジックは、１２５６に進む。メッセージが受け取られなかった場合には、ロジックは、ステップ１２５８に進む。ステップ１２５６では、ロジックは、長いメッセージを、内部の長いメッセージ・ステージング・キャッシュ１１２ａにおける４ＫのＴＰＦレコードにセグメント化することによって、ＴＰＦレコード・チェーンを構築する。レコード・チェーンにおけるそれぞれのメッセージ・セグメントには、標準的なＴＰＦレコード・ヘッダが与えられる。それぞれのレコードのフォワード及びバックワード両方のチェーン化フィールド（chaining fields）にシーケンス番号を配置することによって、レコードのチェーンは、論理的にはフォワード及びバックワードの両方向に横断することが可能になる。この作用によって、内部の長いメッセージ・ステージング・キャッシュ１１２ａに物理的に存在しているセグメント化されたチェーンの物理的なシーケンスがその論理シーケンスに適切に一致することが保証される。チェーンのフォワード・チェーン化フィールドにおける最後のレコードは、チェーンの最後を示すゼロ（null）に設定される。ステップ１２５７では、ロジックは、長いメッセージの最後に到達したが、作業ユニットの最後には到達していないことを示すＸ’ＦＦされたレコードを準備する。アドレス監視ロジック状態テーブル１１０ａの長いメッセージ・カーソルは、次の長いメッセージに対してクリアされる。Ｘ’ＦＦされたレコードは、ＦＩＮＷＣのＭＣＨＲアドレスに対応するＤＳＴＣのＲＡＭキャッシュ・バッファ１２０のエントリに配置される。ロジックは、ステップ１２７９に進み、そこで、制御の流れは、ＤＳＴＣエンジン１０８と、そして結果的には、Ｘ’ＦＦされたレコードをＲＡＭキャッシュ・バッファ１２０からチャネル・インターフェースを介してメインフレームに転送させる処理ロジック１０８ｂに戻される。ステップ１２５８では、ロジックは、長いメッセージの最後と、作業ユニットの最後との両方に到達したことを示すゼロ・レコードを準備する。このゼロ・レコードは、ＦＩＮＷＣのＭＣＨＲアドレスに対応するＤＳＴＣのＲＡＭキャッシュ・バッファ１２０のエントリに配置される。ステップ１２５９では、この長いメッセージに対する内部の長いメッセージ・ステージング・キャッシュ１１２ａの長いメッセージ・カーソルがクリアされる。ロジックは、ステップ１２７９に進み、そこで、制御の流れは、ＤＳＴＣエンジン１０８と、そして結果的には、ゼロ・レコードをＲＡＭキャッシュ・バッファ１２０からチャネル・インターフェースを介してメインフレームに転送させる処理ロジック１０８ｂに戻される。ステップ１２８０においては、ロジックは、バッファされたコマンドがＵＮＦＲＣであるかどうかを判断する。ＵＮＦＲＣである場合には、処理は、ステップ１２８５を継続する。コマンドがＵＮＦＲＣではない場合には、処理は、ステップ１２９０に進み、コマンドがＦＩＬＵＣであるかどうかを判断する。ＦＩＬＵＣである場合には、処理は、ステップ１２９２を継続する。そうでない場合には、コマンドは認識されず、ロジックは、ステップ１２９９に進み、制御の流れはＤＳＴＣエンジン１０８に戻され、エラー条件が告知される。このシナリオでは、認識されていないチャネル・プログラム・コマンドが受け取られる。ステップ１２８５では、ロジックは、ＭＱＦ１１４へのコミットに作業ユニットを発行するが、その理由は、それが、キューからメインフレームに成功裏に完全に転送されたからである。処理は、ステップ１２９５を継続し、そこで、制御の流れは、ＤＳＴＣエンジン１０８に、そして結果的には、ＵＮＦＲＣのＭＣＨＲと関係付けられたレコードをアンロックすることにより他のエンティティがそのキューに対応するＭＣＨＲアドレスにアクセスすることを可能にするロック・ファシリティ１０８ｃに、戻される。ステップ１２９０において解析されたコマンドがＦＩＬＵＣである場合には、ロジックは、ステップ１２９２に進む。ステップ１２９２では、ロジックは、ロールバックをＭＱＦ１１４に発行して、作業ユニットをアボートする。処理は、ステップ１２９５を継続し、そこでは、制御の流れは、ＤＳＴＣエンジン１０８に、そして結果的には、レコードをアンロックすることにより他のエンティティがそのキューに対応するＭＣＨＲアドレスにアクセスすることを可能にするロック・ファシリティ１０８ｃに、戻される。図１３は、個々のメッセージがそれぞれ４Ｋバイト未満であるブラウズ・ファースト（Browse First）コマンドに対するロジックを示している。このロジックは、次の表１１のバッファされたチャネル・プログラム・コマンドの中の１つが、ブラウズ・ファーストと関連付けされたＭＣＨＲアドレスと共にマッピング・ロジック１１２によって検出されるときに呼び出される。［表１１］ロジックは、ステップ１３００において開始し、ステップ１３０５に進む。ステップ１３０５では、ロジックは、指名されたキューが開いているかどうかを判断する。指名されたキューが開いていない場合には、ロジックは、ステップ１３１０に進み、ここで、指名されたキューは、ＭＱＦ１１４への既知のＡＰＩコールを用いて開かれる。マッピング・ロジック１１２は、アドレス監視ロジック１１０とキュー監視ロジック１１８とをそれぞれ用いて、アドレス監視ロジック状態テーブル１１０ａとキュー監視ロジック状態テーブル１１８ａとの両方を協動的に維持し、キュー状態を修正する。指名されたキューが開いている場合には、ロジックは、ステップ１３３０に進む。ステップ１３３０では、ロジックは、バッファされたチャネル・プログラム・コマンドを解析して、それがＦＩＮＷＣであるかどうか、すなわち、与えられたＭＣＨＲのリードであるかどうかを判断する。このコマンドは、ブラウズ・ファースト・バーブにマップするのに用いられる。ＭＱＦ１１４に指名されたキューへのブラウズは、非破壊的（nondestructive）なアクセス、すなわち、メッセージがリードされるがメッセージはキューに留まるリートである。ＦＩＮＷＣが検出されると、ロジックは、ステップ１３４０に進む。ステップ１３３０において解析されたコマンドがＦＩＮＷＣではない場合には、ロジックは、ステップ１３３５に進み、そこでは、制御の流れはＤＡＳＤエンジン１０８に戻され、エラー条件が告知される。このシナリオでは、認識されていないチャネル・プログラム・コマンドが受け取られる。ステップ３４０では、ロジックは、Browse_Firsセオプションを備えたゲットをＭＱＦ１１４に発行する。マッピング・ロジック１１２は、戻されたメッセージ・ペイロードを、ＦＩＮＷＣのＭＣＨＲアドレスに対応するＤＳＴＣのＲＡＭキャッシュ・バッファ１２０のエントリに配置する。ステップ１３８０では、マッピング・ロジック１１２がメッセージが戻されたというＭＱＦからリターン・コードを検出すると、処理は、ステップ１３８５に進む。ステップ１３８５では、ロジックは、制御の流れを、ＤＡＳＤエンジン１０８に、そして結果的には、ブラウズ・レコードをＲＡＭキャッシュ・バッファ１２０からチャネル・インターフェース１０４を介してメインフレームに転送させるチャネル・プログラム処理ロジック１０８ａに戻させる。ステップ１３８０においてメッセージが存在しない場合には、ロジックは、ステップ１３９０に進み、そこでは、ゼロ・レコードがキャッシュ・バッファ１２０に記憶される。ロジックは、ステップ１３９５に進み、そこで、ゼロ・レコードは、メインフレームに戻される。図１４には、個々のメッセージがそれぞれ４Ｋバイトよりも小さいブラウズ・ネクスト・コマンドに対するロジックが示されている。このロジックは、表１２のバッファされたチャネル・プログラム・コマンドの１つがブラウズ・ネクストと関連付けされたＭＣＨＲアドレスと共にマッピング・ロジック１１０によって検出されるときに、呼び出される。［表１２］ロジックは、ステップ１４００において開始し、ステップ１４０５に進む。ステップ１４０５では、ロジックは、指名されたキューが開いているかどうかを判断する。指名されたキューが開いていない場合には、ロジックは、ステップ１４１０に進み、ここで、指名されたキューは、ＭＱＦ１１４への既知のＡＰＩコールを用いて開かれる。マッピング・ロジック１１２は、アドレス監視ロジック１１０とキュー監視ロジック１１８とをそれぞれ用いて、アドレス監視ロジック状態テーブル１１０ａとキュー監視ロジック状態テーブル１１８ａとの両方を協動的に維持し、キュー状態を修正する。指名されたキューが開いている場合には、ロジックは、ステップ１４３０に進む。ステップ１４３０では、ロジックは、バッファされたチャネル・プログラム・コマンドを解析し、それがＦＩＮＷＣであるかどうか、すなわち、与えられたＭＣＨＲ又はＦＩＬＥＣのブロックされたリード及びロックであるかどうか、すなわち、ロックのない単純なファイル・ライトであるかどうかを判断する。これらのコマンドは、それぞれ、ブラウズ・ネクスト・バーブにマップし、ブラウズ・ネクストをキューの最初に強制するのに用いられる。ＭＱＦ１１４に指名されたキューへのブラウズは、非破壊的（nondestructive）なアクセス、すなわち、メッセージがリードされるがメッセージはキューに留まるリードである。ＦＩＮＷＣ又はＦＩＬＥＣが検出されると、ロジックは、ステップ１４４０に進む。ステップ１４３０において解析されたコマンドがＦＩＮＷＣ又はＦＩＬＥＣではない場合には、ロジックは、ステップ１４３５に進み、そこでは、制御の流れはＤＡＳＤエンジン１０８に戻され、エラー条件が告知される。このシナリオでは、認識されていないチャネル・プログラム・コマンドが受け取られる。ステップ１４３０では、コマンドがＦＩＬＥＣではない場合には、ロジックは、ステップ１４４５に進み、そこで、ロジックは、アドレス監視ロジック状態テーブル１１０においてBrowse_Nexセインジケータを設定し、このＭＣＨＲエントリが、Browse_Nextをキューの最初に強制するようにする。ロジックは、ステップ１４４９に進み、そこで、制御の流れはＤＡＳＤエンジン１０８に戻され、エラー条件が告知される。コマンドがＦＩＬＥＣではない場合には、ＦＩＮＷＣであり、これは、ステップ１４５０で処理される。ステップ１４５０では、ロジックは、Browse_Nextオプションを備えたゲットをＭＱＦ１１４に発行する。キュー・インジケータの開始への強制（force）がこのＭＣＨＲに対するアドレス監視ロジック状態テーブル１１０ａエントリにおいて設定される場合には、Browse_Nextを伴うゲットは、キューの最初に強制される。マッピング・ロジック１１２は、戻されたメッセージ前記ペイロードを、ＦＩＮＷＣのＭＣＨＲアドレスに対応するＤＳＴＣ１０２のＲＡＭキャッシュ・バッファ１２０のエントリに配置する。次に、ロジックは、ステップ１４６０に進む。ステップ１４６０では、ロジックがメッセージが戻されたＭＱＦからのリターン・コードを検出すると、処理は、ステップ１４６５に進む。ステップ１４６５では、ロジックは、制御の流れを、ＤＡＳＤエンジン１０８に、そして結果的には、ブラウズ・レコードをＲＡＭキャッシュ・バッファ１２０からチャネル・インターフェース１０４を介してメインフレームに転送させるチャネル・プログラム処理ロジック１０８ａに戻させる。戻されたメッセージが存在しない場合には、ロジックは、ステップ１４７０に進む。ステップ１４７０では、リターン・コードが、キューが空であることを示す場合には、ステップ１４７５が、ロジックに、ゼロ・レコード（キューが空であることを示す）を、ＦＩＮＷＣのＭＣＨＲアドレスに対応するＤＳＴＣのＲＡＭキャッシュ・バッファ１２０のエントリに配置させる。ステップ１４８５では、ロジックが、制御の流れを、ＤＡＳＤエンジン１０８に、そして結果的には、ゼロ・レコードをＲＡＭキャッシュ・バッファ１２０からチャネル・インターフェース１０４を介してメインフレームに転送させる処理ロジック１０８ｂに戻させる。ステップ１４７０では、リターン・コードがキューに現在あるすべてのレコードがブラウズされたことを示す場合には、ステップ１４８０は、ロジックに、Ｘ ’ＦＦ（キューの終わりを示す）で満たされたレコードを、ＦＩＮＷＣのＭＣＨＲアドレスに対応するＤＳＴＣのＲＡＭキャッシュ・バッファ１２０のエントリに配置させる。ステップ１４８５では、制御の流れが、ＤＡＳＤエンジン１０８と、そして結果的には、Ｘ’ＦＦ’のゼロ・レコードをＲＡＭキャッシュ・バッファ１２０からチャネル・インターフェースを介してメインフレームに転送させる処理ロジック１０８ｂに戻される。図１５には、個々のメッセージがそれぞれ４Ｋバイトよりも小さいBrowse_wit h_Cursorコマンドに対するロジツクが示されている。このロジックは、表１３のバッファされたチャネル・プログラム・コマンドの１つがBrowse_w ith_Cursorと関連付けされたＭＣＨＲアドレスと共にマッピング・ロジック１１０によって検出されるときに、呼び出される。［表１３］ロジックは、ステップ１５００において開始し、ステップ１５１０に進む。ステップ１５１０では、ロジックは、指名されたキューが開いているかどうかを判断する。指名されたキューが開いていない場合には、ロジックは、ステップ１５１５に進み、ここで、指名されたキューは、ＭＱＦ１１４への既知のＡＰＩコールを用いて開かれる。マッピング・ロジック１１２は、アドレス監視ロジック１１０とキュー監視ロジック１１８とをそれぞれ用いて、アドレス監視ロジック状態テーブル１１０ａとキュー監視ロジック状態テーブル１１８ａとの両方を協動的に維持し、キュー状態を修正する。指名されたキューが開いている場合には、ロジックは、ステップ１５２０に進む。ステップ１５２０では、ロジックは、バッファされたチャネル・プログラム・コマンドを解析し、それがＦＩＷＨＣであるかどうか、すなわち、ブロックされたリード及びロックであるかどうかを判断する。ステップ１５４０において解析されたコマンドがＦＩＷＨＣコマンドである場合には、ロジックは、ステップ１５２５に進み、そこで、制御の流れは、ＤＡＳＤエンジン１０８に、そして結果的には、レコードをロックすることにより他のエンティティがそのキューに対応するＭＣＨＲアドレスにアクセスすることを防止するロック・ファシリティ１０８ｃに戻させる。コマンドがＦＩＷＨＣではない場合には、ロジックは、ステップ１５３０に進む。ステップ１５３０では、ステップ１５３０で解折されたコマンドがＦＩＬＥＣである場合には、ロジックは、ステップ１５３５に進むが、そこでは、データペイロードはＭＱＦ１１４へのBrowse_with_Cursorコールに対する数値カーソル（numeric cursor）である。数値カーソルは、このＭＣＨＲに対するアドレス監視ロジック状態テーブル１１０ａのエントリのカーソル・フィールドに転送される。ロジックは、ステップ１５３９に進み、制御の流れはＤＡＳＤエンジン１０８に戻され、正常なリターン条件（good return condition）が告知される。コマンドがＦＩＬＥＣでない場合には、処理は、ステップ１５４０に進む。ステップ１５４０では、解析されたコマンドがＦＩＮＷＣである、すなわち、ブロックされたリードである場合には、コマンドは、ステップ１５５０において、このＭＣＨＲに対応するキューへのBrowse_with_Cursorにマップされる。Brow se_with_Cursorコールが、ＭＱＦ１１４に指名されたキューに、このＭＣＨＲに対するアドレス監視ロジック状態テーブル１１０ａに保存されている数値カーソルを用いてなされる。カーソルを用いてのブラウズは、非破壊的なアクセス、すなわち、特定のメッセージがリードされるがメッセージはキューに留まるようなリードである。ロジックは、戻されたメッセージ・ペイロードを、ＦＩＮＷＣのＭＣＨＲアドレスに対応するＤＳＴＣのＲＡＭキャッシュ・バッファ１２０のエントリに配置する。ロジックは、次に、ステップ１５６０に進む。ステップ１５４０において解析されたコマンドがＦＩＮＷＣでない場合には、ロジックは、ステップ１５４５に進む。ステップ１５４５では、解析されたコマンドがＵＮＦＲＣでない場合には、ロジックは、ステップ１５４９に進み、そこで、制御の流れはＤＡＳＤエンジン１０８に戻され、エラー条件が告知される。このシナリオでは、認識されていないチャネル・プログラム・コマンドが受け取られる。ステップ１５４５で解析されるコマンドがＵＮＦＲＣである場合には、ロジックは、ステップ１５５５に進み、そこで、制御の流れは、ＤＡＳＤエンジン１０８に、そして結果的には、レコードをアンロックすることにより他のエンティティがそのキューに対応するＭＣＨＲアドレスにアクセスすることを許容するロック・ファシリティ１０８ｃに戻させる。ステップ１５６０では、マッピング・ロジック１１２がメッセージが戻されたというＭＱＦ１１４からのリターン・コードを検出すると、処理は、ステップ１５６５に進む。ステップ１５６５では、制御の流れを、ＤＡＳＤエンジン１０８に、そして結果的には、ブラウズ・レコードをＲＡＭキャッシュ・バッファ１２０からチャネル・インターフェース１０４を介してメインフレームに転送させるチャネル・プログラム処理ロジック１０８ａに戻させる。ステップ１５６０では、リターン・コードがキューが空であるであることを示す場合には、ロジックは、ステップ１５７０に進み、そこで、ロジックは、ゼロ・レコード（キューが空であることを示す）を、ＦＩＮＷＣのＭＣＨＲアドレスに対応するＤＳＴＣのＲＡＭキャッシュ・バッファ１２０のエントリの中に配置させる。ステップ１５７５では、制御の流れは、ＤＡＳＤエンジンに、そして結果的には、ゼロ・レコードをＲＡＭキャッシュ・バッファ１２０からチャネル・インターフェース１０４を介してメインフレームに転送させる処理ロジック１０８ｂに、戻される。図１６には、個々のメッセージがそれぞれ４Ｋバイトよりも小さいGet_with_C ursorコマンドに対するロジックが示されている。このロジックは、表１４のバッファされたチャネル・プログラム・コマンドの１つがGet_with_Cursorと関連付けされたＭＣＨＲアドレスと共にマッピング・ロジック１１０によって検出されるときに、呼び出される。このロジックは、以下で説明されるように、共有されたＭＱＦキューへのゲットをサポートする。キューの共有可能性は、マッピング・ロジック１１２によって拡張された機能の結果である。［表１４］ロジックは、ステップ１６００において開始し、ステップ１６１０に進む。ステップ１６１０では、ロジックは、指名されたキューが開いているかどうかを判断する。指名されたキューが開いていない場合には、ロジックは、ステップ１６１５に進み、ここで、指名されたキューは、ＭＱＦ１１４への既知のＡＰＩコールを用いて開かれる。マッピング・ロジック１１２は、アドレス監視ロジック１１０とキュー監視ロジック１１８とをそれぞれ用いて、アドレス監視ロジック状態テーブル１１０ａとキュー監視ロジック状態テーブル１１８ａとの両方を協動的に維持し、キュー状態を修正する。指名されたキューが開いている場合には、ロジックは、ステップ１６２０に進む。ステップ１６２０では、ロジックは、バッファされたチャネル・プログラム・コマンドを解析し、それがＦＩＷＨＣであるかどうか、すなわち、ブロックされたリード及びロックであるかどうかを判断する。このコマンドは、Ｉ／Ｏデバイスに接続された複数のメインフレームの間でキューが共有可能である場合に用いられる。好適実施例でＦＩＷＨＣを用いる理由は、それによって、ＭＣＨＲアドレス上のロックが、ロック・ファシリティ１０８ｃの通常の処理を通じて自然にトリガされるからである。ロックによって、このロックが解除（アンホールド）されるまで、他のメインフレームが対応するＭＣＨＲレコードにアクセスすることができなくなる。ステップ１６２０において解析されたコマンドがＦＩＷＨＣコマンドである場合には、ロジックは、ステップ１６２５に進み、そこで、制御の流れは、ＤＡＳＤエンジン１０８に、そして結果的には、レコードをロックすることにより他のエンティティがそのキューに対応するＭＣＨＲアドレスにアクセスすることを防止するロック・ファシリティ１０８ｃに戻させる。ステップ１６２０におけるコマンドがＦＩＷＨＣではない場合には、ロジックは、ステップ１６３０に進む。ステップ１６３０では、ステップ１６３０で解析されたコマンドがＦＩＬＥＣである場合には、ロジックは、ステップ１６１５に進むが、そこでは、データペイロードはＭＱＦ１１４へのGet_with_Cursorコールに対する数値カーソル（numeric cursor）である。数値カーソルは、このＭＣＨＲに対するアドレス監視ロジック状態テーブル１１０ａのエントリのカーソル・フィールドに転送される。ロジックは、ステップ１６３９に進み、制御の流れはＤＡＳＤエンジン１０８に戻され、正常なリターン条件（good return condit ion）が告知される。コマンドがＦＩＬＥＣでない場合には、処理は、ステップ１６４０に進む。ステップ１６４０では、解析されたコマンドがＦＩＮＷＣである、すなわち、ブロックされたリードである場合には、コマンドは、ステップ１６５０において、このＭＣＨＲに対応するキューへのGet_with_Cursorにマップされる。Get_wit h_Cursorコールが、ＭＱＦ１１４に指名されたキューに、このＭＣＨＲに対するアドレス監視ロジック状態テーブル１１０ａに保存されている数値カーソルを用いて、なされる。カーソルを用いてのゲットは、キューから特定のメッセージをゲットする。ロジックは、戻されたメッセージ・ペイロードを、ＦＩＮＷＣのＭＣＨＲアドレスに対応するＤＳＴＣのＲＡＭキャッシュ・バッファ１２０のエントリに配置する。ロジックは、次に、ステップ１６６０に進む。コマンドがＦＩＮＷＣでない場合には、ロジックは、ステップ１６４５に進む。ステップ１６４５では、解析されたコマンドがＵＮＦＲＣでない場合には、ロジックは、ステップ１６４９に進み、そこで、制御の流れはＤＡＳＤエンジン１０８に戻され、エラー条件が告知される。このシナリオでは、認識されていないチャネル・プログラム・コマンドが受け取られる。ステップ１６４５で解析されるコマンドがＵＮＦＲＣである場合には、ロジックは、ステップ１６５５に進み、そこで、制御の流れは、ＤＡＳＤエンジン１０８に、そして結果的には、レコードをアンロックすることにより他のエンティティがそのキューに対応するＭＣＨＲアドレスにアクセスすることを許容するロック・ファシリティ１０８ｃに戻させる。ステップ１６６０では、マッピング・ロジック１１２がメッセージが戻されたというＭＱＦ１１４からのリターン・コードを検出すると、処理は、ステップ１６６５に進む。ステップ１６６５では、制御の流れを、ＤＡＳＤエンジン１０８に、そして結果的には、ゲット・レコードをＲＡＭキャッシュ・バッファ１２０からチャネル・インターフェース１０４を介してメインフレームに転送させるチャネル・プログラム処理ロジック１０８ａに戻させる。ステップ１６６０では、リターン・コードがキューが空であるであることを示す場合には、ロジックは、ステップ１６７０に進み、そこで、ロジックは、ゼロ・レコード（キューが空であることを示す）を、ステップ１６７０において、ＦＩＮＷＣのＭＣＨＲアドレスに対応するＤＳＴＣのＲＡＭキャッシュ・バッファ１２０のエントリの中に配置させる。ステップ１６７５では、制御の流れは、ＤＡＳＤエンジンに、そして結果的には、ゼロ・レコードをＲＡＭキャッシュ・バッファ１２０からチャネル・インターフェース１０４を介してメインフレームに転送させる処理ロジック１０８ｂに、戻される。図１７には、個々のメッセージがそれぞれ４Ｋバイトよりも小さいオプション及び説明付きのゲット・コマンドに対するロジックが示されている。このロジックは、表１５のバッファされたチャネル・プログラム・コマンドの１つがオプション及び説明付きのゲットと関連付けされたＭＣＨＲアドレスと共にマッピング・ロジック１１０によって検出されるときに、呼び出される。このロジックは、以下で説明されるように、共有されたＭＱＦキューへのゲットをサポートする。キューの共有可能性は、マッピング・ロジック１１２によって拡張された機能の結果である。［表１５］ロジックは、ステップ１７００において開始し、ステップ１７１０に進む。ステップ１７１０では、ロジックは、指名されたキューが開いているかどうかを判断する。指名されたキューが開いていない場合には、ロジックは、ステップ１７１５に進み、ここで、指名されたキューは、ＭＱＦ１１４への既知のＡＰＩコールを用いて開かれる。マッピング・ロジック１１２は、アドレス監視ロジック１１０とキュー監視ロジック１１８とをそれぞれ用いて、アドレス監視ロジック状態テーブル１１０ａとキュー監視ロジック状態テーブル１１８ａとの両方を協動的に維持し、キュー状態を修正する。指名されたキューが開いている場合には、ロジックは、ステップ１７２０に進む。ステップ１７２０では、ロジックは、バッファされたチャネル・プログラム・コマンドを解析し、それがＦＩＷＨＣであるかどうか、すなわち、ブロックされたリード及びロックであるかどうかを判断する。このコマンドは、Ｉ／Ｏデバイスに接続された複数のメインフレームの間でキューが共有可能である場合に用いられる。好適実施例でＦＩＷＨＣを用いる理由は、それによって、ＭＣＨＲアドレス上のロックが、ロック・ファシリティ１０８ｃの通常の処理を通じて自然にトリガされるからである。ロックによって、このロックが解除（アンホールド）されるまで、他のメインフレームが対応するＭＣＨＲレコードにアクセスすることができなくなる。ステップ１７２０において解析されたコマンドがＦＩＷＨＣコマンドである場合には、ロジックは、ステップ１７２５に進み、そこで、制御の流れは、ＤＡＳＤエンジン１０８に、そして結果的には、レコードをロックすることにより他のエンティティがそのキューに対応するＭＣＨＲアドレスにアクセスすることを防止するロック・ファシリティ１０８ｃに戻される。ステップ１７３０では、ステップ１７３０において解析されたコマンドがＦＩＬＥＣである場合には、ロジックは、ステップ１７３５に進み、そこでは、データペイロードは、ＭＱＦ１１４の既知のＡＰＩへのオプション付きのゲット・コールに対するオプションである。このオプションは、このＭＣＨＲに対するアドレス監視ロジック状態テーブル１１０ａのエントリのオプション・フィールドに転送される。ロジックは、ステップ１７３９に進み、制御の流れはＤＡＳＤエンジン１０８に戻され、正常なリターン条件（good return condition）が告知される。コマンドがＦＩＬＥＣでない場合には、処理は、ステップ１７４０に進む。ステップ１７４０では、解析されたコマンドがＦＩＮＷＣである、すなわち、ブロックされたリードである場合には、コマンドは、このＭＣＨＲに対応するキューへのオプション及び説明付きのゲットにマップされる。オプション及び説明付きのゲット・コールが、ＭＱＦ１１４に指名されたキューに、このＭＣＨＲに対するアドレス監視ロジック状態テーブル１１０ａに保存されている数値カーソルを用いて、なされる。ゲット・オプションは、キューから特定のメッセージとその説明とをゲットする。マッピング・ロジック１１２、戻されたメッセージ・ペイロードとメッセージ説明ペイロードとを、ＦＩＮＷＣのＭＣＨＲアドレスに対応するＤＳＴＣのＲＡＭキャッシュ・バッファ１２０のエントリに配置する。ロジックは、次に、ステップ１７６０に進む。コマンドがＦＩＮＷＣでない場合には、ロジックは、ステップ１６４５に進む。ステップ１７４５では、解析されたコマンドがＵＮＦＲＣでない場合には、ロジックは、ステップ１７４９に進み、そこで、制御の流れはＤＡＳＤエンジン１０８に戻され、エラー条件が告知される。このシナリオでは、認識されていないチャネル・プログラム・コマンドが受け取られる。ステップ１７４５で解析されるコマンドがＵＮＦＲＣである場合には、ロジックは、ステップ１７５５に進み、そこで、制御の流れは、ＤＡＳＤエンジン１０８に、そして結果的には、レコードをアンロックすることにより他のエンティティがそのキューに対応するＭＣＨＲアドレスにアクセスすることを許容するロック・ファシリティ１０８ｃに戻させる。ステップ１７６０では、マッピング・ロジック１１２がメッセージが戻されたというＭＱＦ１１４からのリターン・コードを検出すると、処理は、ステップ１７６５に進む。ステップ１７６５では、ロジックが、制御の流れを、ＤＡＳＤエンジン１０８に、そして結果的には、ゲット・レコードをＲＡＭキャッシュ・バッファ１２０からチャネル・インターフェース１０４を介してメインフレームに転送させるチャネル・プログラム処理ロジック１０８ａに戻させる。ステップ１７６０では、リターン・コードがキューが空であるであることを示す場合には、ロジックは、ステップ１６７０に進み、そこで、ゼロ・レコード（キューが空であることを示す）が、ステップ１７７０において、ＦＩＮＷＣのＭＣＨＲアドレスに対応するＤＳＴＣ１０８のＲＡＭキャッシュ・バッファ１２０のエントリの中に配置させる。ステップ１７７５では、制御の流れは、ＤＡＳＤエンジンに、そして結果的には、ゼロ・レコードをＲＡＭキャッシュ・バッファ１２０からチャネル・インターフェース１０４を介してメインフレームに転送させる処理ロジック１０８ｂに、戻される。図１８には、メッセージと組み合わされたプット・オプションとが４Ｋバイトよりも小さいシングル・プット・コマンドに対するロジックが示されている。このロジックは、表１６のバッファされたチャネル・プログラム・コマンドの１つが、テーブル１１０ａにおいて識別されるように、シングル・プットと関連付けされたＭＣＨＲアドレスと共にマッピング・ロジック１１２によって検出されるときに、呼び出される。このロジックは、以下で説明されるように、シングル・プットをサポートし、更に、共有されたＭＱＦキューへのプットをサポートする。キューの共有可能性は、マッピング・ロジック１１２によって拡張された機能の結果であって、ＭＱＦ１１４に内在するものではない。［表１６］ロジックは、ステップ１８００において開始し、ステップ１８０５に進む。ステップ１８０５では、ロジックは、指名されたキューが開いているかどうかを判断する。指名されたキューが開いていない場合には、ロジックは、ステップ１８１０に進み、ここで、指名されたキューは、ＭＱＦ１１４への既知のＡＰＩコールを用いて開かれる。マッピング・ロジック１１２は、アドレス監視ロジック１１０とキュー監視ロジック１１８とをそれぞれ用いて、アドレス監視ロジック状態テーブル１１０ａとキュー監視ロジック状態テーブル１１８ａとの両方を協動的に維持する。従って、この時点で、マッピング・ロジック１１２は、テーブル１１０ａ及び１１２ａを、すべての関係するエントリに対して修正させる。次に、ロジックは、ステップ１８１５に進む。指名されたキューが開いている場合には、ロジックは、ステップ１８１５に進む。ステップ１８１５では、ロジックは、バッファされたチャネル・プログラム・コマンドを解析し、それがＦＩＷＨＣであるかどうか、すなわち、ブロックされたリード及びロックであるかどうかを判断する。このコマンドは、Ｉ／Ｏデバイスに接続された複数のメインフレームの間でキューが共有可能である場合に用いられる。好適実施例でＦＩＷＨＣを用いる理由は、それによって、ＭＣＨＲアドレス上のロックが、ロック・ファシリティ１０８ｃの通常の処理を通じて自然にトリガされるからである。ロックによって、このロックが解除（アンホールド）されるまで、他のメインフレームが対応するＭＣＨＲレコードにアクセスすることができなくなる。ステップ１８１５において解析されたコマンドがＦＩＷＨＣコマンドである場合には、ロジックは、ステップ１８２０に進み、そこで、制御の流れは、ＤＡＳＤエンジン１０８に、そして結果的には、レコードをロックすることにより他のエンティティがそのキューに対応するＭＣＨＲアドレスにアクセスすることを防止するロック・ファシリティ１０８ｃに戻される。ステップ１８１５で解析されたコマンドがＦＩＷＨＣではない場合には、ロジックは、ステップ１８２５に進み、そこで、ロジックは、チャネル・プログラム・コマンドがＦＩＬＵＣであるかどうか、すなわち、アンロック・コマンドを備えたライトであるかどうかを判断する。ＦＩＬＵＣコマンドは、共有されたキューへのプットに用いられ、また、共有されたキューへのプットに対して発行された一連のコマンドにおける第２のコマンドとして用いられる。従って、非共有キューへのプットを望む場合には、メインフレームは、ステップ１８１５のＦＩＷＨＣを最初に送ることは必要ない。ステップ１８２５において解析されたコマンドがＦＩＬＵＣである場合には、ロジックは、ステップ１８３０に進み、そこでは、データ・ペイロードは、メッセージであり、リンクされたリストの形式でのそのプット・オプションである。メッセージは、ＭＱＦの既知のＡＰＩを用いて、対応する指名されたキューへのオプションを用いてプットされる。キューの名称は、メッセージのデータ・ペイロードが明白にキューの名称を提供しない限り、テーブル１１０ａから提供される。ロジックは、次に、ステップ１８３５に進み、そこでは、制御の流れは、ＤＡＳＤエンジン１０８に戻され、そして結果的には、レコードをアンロックすることにより、他のエンティティがこのキューに対応するＭＣＨＲアドレスにアクセスすることを可能にするロック・ファシリティ１０８ｃに戻される。ステップ１８２５におけるコマンドがＦＩＬＵＣではない場合には、ロジックは、ステップ１８４０に進み、そこでは、ロジックは、チャネル・プログラム・コマンドがＵＮＦＲＣであるかどうか、すなわち、アンロック・コマンドであるかどうかを判断する。このコマンドは、メインフレームによって、共有されたキューへのプットをアボートする必要がある場合に用いられる。そのような場合には、ステップ１８２５のＦＩＬＵＣの代わりに送られる。ステップ１８４０で解析されるコマンドがＵＮＦＲＣである場合には、ロジックは、ステップ１８４５に進み、そこで、制御の流れは、ＤＡＳＤエンジン１０８に、そして結果的には、レコードをアンロックすることにより他のエンティティがそのキューに対応するＭＣＨＲアドレスにアクセスすることを許容するロック・ファシリティ１０８ｃに戻される。ステップ１８４０で解析されるコマンドがＵＮＦＲＣではない場合には、ロジックは、ステップ１８５０に進み、そこで、制御の流れはＤＡＳＤエンジン１０８に戻され、エラー条件が告知される。このシナリオでは、認識されていないチャネル・プログラム・コマンドが受け取られる。図１９には、キュー監視ロジック１１８に対するロジックが示されている。キュー監視ロジック１１８は、マッピング・ロジック１１２によって実際に開かれたかどうかを問わずに、ＭＱＦ１１４におけるすべてのキューを監視する。メッセージがＭＱＦ１１４における指名されたキューに到着すると、キュー監視ロジック１１８が、既知のＭＱＦ１１４トリガ付勢メッセージによって付勢される。ステップ１９１０では、それは、キュー監視ロジック状態テーブル１１８ａをチェックし、ステップ１９２０において、指名されたキューがエントリを有するかどうかを判断する。エントリが存在する場合には、処理は、ステップ１９３０に進む。エントリがない場合には、ロジックは、ステップ１９２５において、トリガ付勢メッセージと、メッセージのキューに対するキュー監視ロジック状態テーブル１１８ａが初期化されていないことの指示との両方を合成するメッセージを、マスタ・トリガ応答キューに、プットする。マスタ・トリガ応答キューは、以下で説明される実施例に対する複数の制御キューの中の１つである。その目的は、ＭＱＦ１１４がメインフレームが処理する必要のあるメッセージを有していることをメインフレームが告知される合併されたキューを提供することである。これが用いられる理由は、先に述べたように、すべてのゲット・キューがトリガ・ロックされた待機状態を用いて構成されているとは限らないが、メインフレームは、依然として、いつメッセージが到着するのかを直ちに知る必要がある。処理は、ステップ１９６０に進む。ステップ１９３０では、アドレス監視ロジック状態テーブル１１０ａの対応するエントリがチェックされて、ＭＣＨＲアドレスがトリガされたロック待機状態にあるかどうかを判断する。その対応するキューにおいてメッセージが到着するのを待機している未決のＦＩＷＨＣが存在すると判断される場合には、キュー監視ロジック１１８は、ステップ１９３５に進む。それ以外の場合には、処理は、ステップ１９４０に進む。ステップ１９３５では、ロジックは、ロックされた待機状態キューをトリガする条件を設定する。これは、マッピング及びキュー監視ロジックに、ロックを備えたＭＣＨＲを保持する他のファントム・プロセッサであるような外見を与えるロック・ファシリティ１０８ｃに対する条件を設定することによって行われる。ロック・ファシリティ１０８ｃにおいて、他のプロセッサがＦＩＬＵＣコマンドを完了しているようにＤＡＳＤエンジン１０８を監視させる条件も更に設定される。これらの条件は、ＤＡＳＤエンジン１０８によって、通常のＤＳＴＣ１０８の処理が継続しているステップ１９８０に処理が移動する際に、作用される。ハイレベルにおいて、ステップ１９３５のシミュレートされたＦＩＬＵＣは、ＤＡＳＤエンジン１０８とロック・ファシリティ１０８ｃとを監視する。同様に、他のメインフレームが、最終的に、レコードの更新を終了しつつあり、また、ＭＣＨＲのホールドを放棄しつつある。従って、ＤＡＳＤエンジン１０８とロック・ファシリティ１０８ｃロジックとは、ホールド待機メインフレームへのアテンション割り込みをルーチン的に告知し、更新されたレコードを再度リードすることができる。この再リード（リリード、re-read）は、ＴＰＦメインフレームのアンロック処理の自然な結果である。このリリードが生じるときは、メインフレームからの新たなゲットのように見える。ただし、この場合には、キューの中に転送することができるメッセージが存在する。そのキューに対応するＭＣＨＲ上でＦＩＷＨＣコマンドを元々実行したメインフレームにおけるブロックされたアプリケーションは、ＭＣＨＲ上のロックを解除するリード・ロック・コマンドを有するメッセージによって、直ちに告知される。ステップ１９４０では、メインフレームは、ＭＣＨＲ上のトリガされたロック待機状態にはないので、メインフレームがキュー上にメッセージが存在することの告知を受ける必要があるかどうかが判断される。キュー監視状態テーブル１１８ａのエントリが告知を受ける必要ないことを示す場合には、ステップ１９４５は、キュー監視状態テーブル１１８ａを更新して、キュー上に少なくとも１つのメッセージがあることを指示し、ステップ１８７０に進む。（それぞれのエントリは、アテンション割り込みがクライアントに送られるべきかどうかの指示を含み、ＭＣＨＲアドレス上にトリガがロックされた待機状態が存在する場合には、ウェークアップ・メッセージがマスタ・トリガ応答キュー（後で更に説明する）に配置されるべキかどうか、又は、クライアントがトリガされるべきでないかどうか、を含む。）ステップ１９４０において、メインフレームが告知を受ける必要があると判断された場合には、ステップ１９５０は、対応するＭＣＨＲアドレスを有するトリガ付勢メッセージと、メインフレームにおいて１つのメッセージに付勢されるプログラムの名称とを合成し、それを、既知のＭＱＦ１４４のＡＰＩを用いて、マスタ・トリガ応答キューにプットする。処理は、ステップ１９６０を継続する。ステップ１９６０では、ロジックは、例えば、ロック・ファシリティ１０８ｃ又はああ状態テーブル１１０ａに問い合わせを行うことによって、マスタ・トリガ応答キューがトリガされたロック待機状態にあるかどうかを判断する。典型的には、マスタ・トリガ応答キューは、連続的にトリガされた待機状態にあるキューである。というのは、メインフレームにメッセージ活動を告知される主要な方法であるからである。トリガされたロック待機状態にある場合には、処理は、ステップ１９３５に進むが、ここでは、ステップ１９３５は、マスタ・トリガ応答キューに対して付勢されるのであって、実際のアプリケーション・メッセージが中にあるキューに対してではない。そうでない場合には、処理は、ステップ９７０に進む。ステップ１９７０は、キュー監視ロジック１１８を、イベント待機状態に戻し、そこでは、更なるメッセージを受け取ると、ＭＱＦ１１４によって再び付勢される。注意すべきは、トリガされたロック待機状態にあるＭＣＨＲアドレスは、メインフレーム・アプリケーションによっては解放（リリース）することができないということである。その理由は、ブロックされたリード・モードにあるからである。所定のタイムアウト値に到達したときには、メインフレームの既知の失われた割り込みハンドラによって解放される。好適実施例では、タイムアウト値は、従来型のＤＳＴＣよりも大きな値に設定される。しかし、異なるメインフレーム・アプリケーションは、ゼロ・メッセージをＭＣＨＲがマップされるキューにプットすることによって、トリガされたロック待機状態のＭＣＨＲアドレスをマニュアルで解放することができる。キュー・ベースの制御インターフェース図２０、表１７及び表１８は、それぞれが、ロジック、マスタ制御キュー及びキュー・ベースの制御インターフェースを示している。好適実施例では、改良型のＩ／Ｏデバイス１００上の新規なロジックと、デバイス１００に常駐するＭＱＦとへのキュー・ベースの制御インターフェースを定義している。キュー・ベースの制御インターフェースは、メインフレーム、好適実施例及びＭＱＦ並びにネットワークの間の制御、アドミニストレーション、マネージメントを容易にする。特に、インターフェースには、マスタ制御キュー、マスタ制御応答キュー、マスタ制御質問（inguiry）キュー、マスタ制御ロギング・キュー、マスタ・トリガ応答キュー、マスタ・アドレス監視ロジック・テーブル・キュー、マスタ・キュー監視状態テーブル及びマスタＭＣＨＲキューが含まれる。これらのキューにより、メインフレームのアプリケーションが、以下で説明されるように、キュー状態をモニタ及び／又は修正することが可能になる。キュー・ベースの制御インターフェースは、メインフレーム・システムには既知であるＭＣＨＲの静的な組（static set）にマップされ得るマスタ制御キューの固定された組（fixed set）を用いる。この静的なマッピングは、メインフレームのオペレーティング・システムのコンフィギュレーションの一部である。このようにして、メインフレーム・キーイング・アプリケーションが開始するときには、静的にマップされた制御キューを介して好適実施例と通信し、全体の好適実施例及びＭＱＦのコンフィギュレーション及び状態にアクセスすることができる。表１７には、好適実施例のマスタ制御キューがまとめられている。［表１７］マスタ制御キューは、すべての明白な状態変化要求をＭＱＦに配置するのに用いられる。特に、キューは、開く（オープン）、閉じる（クローズ）、接続（コネクト）、切断（ディスコネクト）又は特定キューの設定などの要求を受け取る。ＭＱＦへの明白なコマンドと明白に選択されたキューとは、マスタ制御キューへのプット・シングルＭＱＦ制御メッセージのデータ・ペイロード・セクションにおけるメインフレームから、マッピング・ロジック１１２に送られる。処理ロジックについては、後で、図２０において説明される。マスタ制御応答キューは、与えられたマスタ制御キュー要求への応答であるＭＱＦ空のすべての応答を配置するのに用いられる。マスタ制御質問キューは、既知のＭＱＦ質問メッセージへの応答を含む。ＭＱＦ質問応答メッセージは、特定されたＭＱＦキューの現在の状態を説明する。既知のＭＱＦフォーマットでその特性及び状態を説明しているＭＱＦにおいては、すべてのキューに対して、マスタ制御質問キューにおいて、１つの質問メッセージ応答が存在する。MQCLOSE、MQCONN、MQDISC、MQOPEN、MQSETなどのＭＱＦＡＰＩバーブのいずれかによって、いずれかのＭＱＦキューの特性又は状態に変更がなされた場合には、又は、キュー・マネジャに対する適切なＭＱＦ制御コマンドがキューに衝撃を与えている場合には、新たな質問応答メッセージが古いものに代わる。（キュー・マネジャは、ＭＱＦ１１４の成分であり、制御コマンドに応答する。）マスタ制御ロギング・キューは、マスタ制御キューに対してなされたすべての制御タイプ・メッセージ要求及び応答（マスタ制御質問キューとの関係で既に述べた）のコピーを配置するのに用いられる。マスタ制御制御ロギング・キューは、履歴をトラッキングする。いったん初期化されると、決してリセットされることはない。その中の項目（アイテム）は、履歴データベースに転送される。マスタ・トリガ応答キューは、合併されたキューを提供する。ただし、メインフレームは、ＭＱＦキューが処理を必要とするメッセージを有することを告知される。これは、状態テーブル１１０ａ及び１１８ａにおいて構成されたキューに対して用いられる。キュー監視ロジック１１８は、ウェークアップ・メッセージをこのキューの中に配置するかどうかをいつ決定するかを質問する。マスタ・トリガ応答キューは、通常は、トリガされたロック待機状態アドレスによって構成される。これは、メインフレームのＦＩＷＨＣがそのアドレス上でホールド待機状態にあるという意味であり、すなわち、ブロックされたゲットがあるということである。マスタ・アドレス監視ロジック・テーブル・キューとマスタ・キュー監視状態テーブル・キューとは、それぞれが、アドレス監視ロジック・テーブル１１０ａとキュー監視状態テーブル１１８ａとのＤＳＴＣ１０２のメモリ作業用コピーにおいて、持続型ストレージをチェックポイント（又は、キーポイント）するのに用いられる。ＤＳＴＣ１０２の再スタート処理の間に、テーブルの持続型のコピーがメモリの中に再びリードされ、好適実施例を、その最後の既知のチェックポイント状態に回復させる。新たなＭＣＨＲ又はキュー・エントリは、外部ソースによって、これらのテーブルのそれぞれの持続型コピーに追加することができる。新たなエントリは、選択的な再スタート・ロジック（図示せず）によってメモリの中に選択的にリードすることができる。マスタＭＣＨＲキューは、メインフレームによって、キューへのＭＣＨＲアドレスを取得して動的に配分する、すなわち、ＭＣＨＲアドレスをキューの名称・バーブの組合せに拘束するのに用いられる。好適実施例においては、このテーブルによって、上述したキューのマスタ制御ファミリに用いられる静的な拘束ではなく、ＭＣＨＲをキューにより動的に拘束することが可能になる。また、キューが動的に追加されるので、キューへのＭＣＨＲアドレスのマッピングをリアルタイムで追加することが可能になる。図２０には、制御コマンドのマスタ制御キューへのシングル・プットを処理するロジックが示されている。ただし、メッセージ、ＭＱＦバーブ、オプション及びデスクリプタ情報が４Ｋバイトよりも小さい。特に、この特別のプット・コマンドは、メインフレーム・アプリケーションからのＭＱＦに対する制御、マネージメント及びアドミニストレーションを実行する目的で、特定の指名されたキューに対して、選択されたＭＱＦ制御バーブを実行するものである。ＭＱＦ又はマッピング・ロジック１１２からのすべての応答は、マスタ制御応答キューに配置される。このロジックは、表１８のバッファされたチャネル・プログラム・コマンドの１つが、テーブル１１０ａにおいて識別されるように、制御メッセージを有するシングル・プットと関連付けされた静的なＭＣＨＲアドレスと共にマッピング・ロジック１１２によって検出されるときに、呼び出される。このロジックは、以下で説明されるように、シングル・プットをサポートし、更に、共有されたＭＱＦキューへのプットもサポートする。キューの共有可能性は、図２０に示されているマッピング・ロジック１１２によって拡張された機能の結果であって、ＭＱＦ１１４に内在するものではない。［表１８］ロジックは、ステップ２０００において開始し、ステップ２００５に進む。ステップ２００５では、ロジックは、マスタ制御キューが開いているかどうかを判断する。マスタ制御キューの名称は、バッファされたチャネル・プログラムにＭＣＨＲアドレスを有するアドレス・テーブル１１０ａの中のエントリから検索される。マスタ制御キューが開いていない場合には、ロジックは、ステップ２０１０に進み、ここで、マスタ制御キューは、キューのマスタ制御ファミリにおけるすべてのキューと同様に、ＭＱＦ１１４への既知のＡＰＩコールを用いて開かれる。マッピング・ロジック１１２は、アドレス監視ロジック１１０とキュー監視ロジック１１８とをそれぞれ用いて、アドレス監視ロジック状態テーブル１１０ａとキュー監視ロジック状態テーブル１１８ａとの両方を協動的に維持する。従って、この時点で、マッピング・ロジック１１２は、テーブル１１０ａ及び１１８ａを、すべての関係するエントリに対して修正させる。次に、ロジックは、ステップ２０１５に進む。キューのマスタ制御ファミリが開いている場合には、ロジックは、ステップ２０１５に進む。ステップ２０１５では、ロジックは、バッファされたチャネル・プログラム・コマンドを解析し、それがＦＩＷＨＣであるかどうか、すなわち、ブロックされたリード及びロックであるかどうかを判断する。ステップ２０１５において解析されたコマンドがＦＩＷＨＣコマンドである場合には、ロジックは、ステップ２０２０に進み、そこで、制御の流れは、ＤＡＳＤエンジン１０８に、そして結果的には、レコードをロックすることにより他のエンティティがそのキューに対応するＭＣＨＲアドレスにアクセスすることを防止するロック・ファシリティ１０８ｃに戻される。ステップ２０１５で解析されたコマンドがＦＩＷＨＣではない場合には、ロジックは、ステップ２０２５に進み、そこで、ロジックは、チャネル・プログラム・コマンドがＦＩＬＵＣであるかどうか、すなわち、アンロック・コマンドを備えたライトであるかどうかを判断する。ステップ２０２５において解析されたコマンドがＦＩＬＵＣである場合には、ロジックは、ステップ２０３０に進み、そこでは、データ・ペイロードは、メッセージ、MQPUT、MQCLOSE、MQCONN、MQDISC、MQGET、MQINQ、MQOPEN、MQSETなどのＭＱＦＡＰＩバーブである。特定のキューの名称、ＭＱＦバーブのオプションなどは、リンクされたリストの形式であり、既知のＭＱＦＡＰＩコールとして再フォーマットされており、特定のキューの名称に対して実行される。キューの名称は、メッセージのデータ・ペイロートにおいて、明白に提供される。ロジックは、ステップ２０３５に進み、ＭＱＦＡＰＩによって実行された直後の要求メッセージとＭＱＦＡＰＩコールからのその応答及びリターン・コードは、合成され、マスタ制御ロギング・キューだけでなく、マスタ制御応答キューにプットされる。メインフレームは、マスタ制御応答キューにおいて、その要求への応答を得ることができる。処理は、ステップ２０４０に進む。ステップ２０４０では、ロジックは、ＭＱＦＡＰＩへの既知の質問コールを実行し、キューの状態及び特性を取得する。ＭＱＦＡＰＩコールから戻る既知の応答は、マスタ制御キューに対してなされた最初の要求において指名された特定のキューに対して、マスタ制御質問キューニスでに存在していた任意の質問メッセージ・エントリへの交換として、マスタ制御質問キューにプットされる。ロジックは、ステップ２０４５に進み、そこでは、質問応答は、やはり、マスタ制御ロギング・キューにプットされる。ロジックは、ステップ２０５０に進み、そこでは、制御メッセージからの任意の更新が、それぞれ、適切なアドレス監視ロジック・テーブル１１０ａと、キュー監視状態テーブル１１８ａのエントリに与えられる。ステップ２０５５では、２つのメモリ・ベースの状態テーブルのいずれかへの任意のエントリが、チェックポイントされる、すなわち、持続型のキュー・コピーにプットされる。持続型ストレージ・ベースのキューにおける対応するエントリの古い方が、削除され、それによって、エントリの最も現時点でのコピーだけが存在することになる。ロジックは、次にステップ２０６０に進み、ここで、制御の流れは、ＤＡＳＤエンジン１０８に戻され、そして結果的には、レコードをアンロックすることにより、他のエンティティがこのキューに対応するＭＣＨＲアドレスにアクセスすることを可能にするロック・ファシリティ１０８ｃに戻される。ステップ２０２５におけるコマンドがＦＩＬＵＣではない場合には、ロジックは、ステップ２０７０に進み、そこでは、ロジックは、チャネル・プログラム・コマンドがＵＮＦＲＣであるかどうか、すなわち、アンロック・コマンドであるかどうかを判断する。このコマンドは、メインフレームによって、マスタ制御キューへのプットをアボートする必要がある場合に用いられる。そのような場合には、ステップ２０２５のＦＩＬＵＣの代わりに送られる。ステップ２０７０で解析されるコマンドがＵＮＦＲＣである場合には、ロジックは、ステップ２０７５に進み、そこで、制御の流れは、ＤＡＳＤエンジン１０８に、そして結果的には、レコードをアンロックすることにより他のエンティティがそのキューに対応するＭＣＨＲアドレスにアクセスすることを許容するロック・ファシリティ１０８ｃに戻される。ステップ２０７０で解析されるコマンドがＵＮＦＲＣではない場合には、ロジックは、ステップ２０８０に進み、そこで、制御の流れはＤＡＳＤエンジン１０８に戻され、エラー条件が告知される。このシナリオでは、認識されていないチャネル・プログラム・コマンドが受け取られる。その他の側面ＩＢＭのMQseriesなどのＭＱＦは、典型的には、マルチスレッド型のオペレーティング・システムを用いてパフォーマンスを獲得する。マルチスレッド型の環境では、複数のアプリケーションや、１つのアプリケーションの複数のスレッドが、相互に独立に、同じキューにライトすることができる。すなわち、それぞれが、同じキューに対する作業ユニットを用いて作業をすることができ、ＭＱＦは、それらを相互に分離しておくことができる。好適実施例におけるマルチスレッドの長所は、ＤＡＳＤロジック１０８、アドレス監視ロジック１１０、キュー監視ロジック１１８及びマッピング・ロジック１１２が、すべて、適切な位置で、異なるスレッドにおいて動作することができる点である。しかし、マルチスレッド環境の中には、適切な場合にはそれらが互いに相互作用することを可能にするメカニズムが存在している。これによって、アドレス監視ロジック１１０は、キュー監視ロジック１１８から分離して動作することが可能になる。既に概要を述べた別の長所としては、与えられた指名されたキューは、それぞれのＭＣＨＲアドレスが与えられた１つの作用に対応する複数の対応するＭＣＨＲアドレスを有することができるという点がある。従って、ＭＣＨＲアドレスＡは小さなプットに対応し、ＭＣＨＲアドレスＢは大きなプットに対応することも可能である。改良型のＤＳＴＣ１０８の好適実施例では、マルチスレッドのオペレーティング・システムが用いられている。マルチスレッドであることにより、複数のＭＣＨＲアドレスからの作業の複数ユニットが異なる複数のＭＣＨＲを介して同じキューにプットされている場合に、キューの統一性（coherency）が保証される。好適実施例は、小さな及び大きなメッセージのゲットを含めて、複数の形式のゲットをサポートしている。このようにして、小さなメッセージを有していることを知っているアプリケーションは、この知識を利用して、複雑性のより低いロジックによって動作効率を向上させる小さなゲット要求を用いることができる。ＭＱＦの主要な使用は、共通点を有していないヘテロジーニアスなコンピューティング環境を、メッセージが一度だけ送られるという堅固な機能性と絶対的な統一性をもって、相互にリンクさせることである。ＭＱＦの著しい利点は、オープン・システムをオープン・システムとリンクさせることにあるが、最大の長所は、オープン・システムのアプリケーションをメインフレームのアプリケーションに密結合（tightly couple）させることを必要とせずに、オープン・システムをメインフレーム・システムとリンクさせることである。本発明は、特に、オープン・システムのアプリケーションとレガシー・メインフレーム・アプリケーションとの間で、メインフレームのアプリケーションが、それ自体が最も精通している処理パラダイム、すなわち、データベース、クラスタ処理環境におけるファイル及びレコード処理などを継続的に使用し続けながら、意味のあるアプリケーション情報の交換を容易にする。メインフレーム・アプリケーションによるファイル及びレコード処理からオープン・システムでのメッセージングへのパラダイム・シフトを、メインフレームに代わって、改良されたＩ／Ｏデバイスにおいて、抽象化し、行うことができる。これによって、既存のファイル処理を行うことができるオープン・システムと、ＭＱＦＡＰＩを用いて通信する際であっても、メインフレーム・アプリケーションを著しく再構成（rework）する必要が限定される。これは、後で、その他の実施例のセクションで説明される。ＴＰＦでは、この実施例と容易にインターフェースすることが可能な多数のファイル・ベースのインターフェース・ユーティリティが存在し、オープン・システムなどの外部システムにより多数の応用例を与える。キュー・ベースの制御インターフェースを用いたシステムの初期化どのようなＭＱＦ環境のセットアップにも計画が必要である。どのようなＭＱＦ環境でも、キュー・マネジャ、キュー及び通信が、計画され、設定され、構成（コンフィギュレート）されなければならない。改良型のＩ／Ｏデバイス上でのＭＱＦのコンフィギュレーション及びセットアップは、ＭＱＦ環境全体のコンテキストの中でなされなければならない。好適実施例では、キュー監視状態テーブルが、改良型のＩ／Ｏデバイス上に常駐するキュー・マネジャに対して明白（ex plicitly）にコンフィギュレーションのなされたキューに基づいてセットアップされる。ＭＱＦのためにコンフィギュレーションのなされたすべてのキューに対して、キュー監視状態テーブル１１８ａ内に、１つのエントリが存在する。既に述べたように、これらのエントリは、マスタ・キュー監視状態テーブルのキューの中にチェックポイント（プット）される。キューは、マスタ制御キューへの明白なオープンを用いて、メインフレーム・アプリケーションによって、最初は選択的に開かれるので、ＭＣＨＲアドレスは、マスタＭＣＨＲキューから除去され、アドレス監視ロジック・テーブル１１０ａ（awst）のエントリを増加させる（populate）のに用いられる。アドレス監視テーブル１１０ａにおけるそれぞれのＭＣＨＲアドレス・エントリは、キュー監視状態テーブル１１８ａにおける対応する指名されたキューと相互参照（クロスリファレンス）される。指名されたキューが処理のために構成されるすべてのタイプの処理に対してマップされた、一意的なＭＣＨＲアドレス（ awst）エントリが存在する。少なくとも１つのＭＣＨＲアドレス（awstエントリ）が１つのキューに対して構成されたそれぞれの一意的な動作に対して用いられる。それぞれのＭＣＨＲのawstエントリは、それに割り当てられた表Ａからのブランチ・ベクトル・コードを有している。これは、その一意的な動作に対応するマッピング・ロジック１１２を付勢するのに用いられる。（すなわち、共有されたキューへのシングル・ロングを５とプットし、シングル非共有を３とプットするなど。）通常は、それぞれ（一対一マッピング（写像））の指名されたキューに対して、アドレス監視ロジック・テーブル１１０ａの複数のエントリが存在し、それぞれが、異なるプロセスにマップされる。アドレス監視ロジック・テーブル１１０ａのエントリが作られ、変更され又は削除されると、それらは、高速での一般的な再スタートのために、チェックポイントされ、マスタ・アドレス監視状態テーブル・キューとなる。メインフレーム・アプリケーションが対応する指名されたキューを明白に閉じるときにだけ、アドレス監視ロジック・テーブルのエントリは削除され、閉じるというメッセージは、マスタ制御キューに送られる。その他の実施例上述の実施例は、特に、ＴＰＦ環境に関係する。同じ技術は、既知であるＭＶＳ／ＯＳ３９０環境を含む他のシステムにも応用できる。いくつかの点で、ＭＶＳ／ＯＳ３９０環境の方が単純である。例えば、ＭＶＳ／ＯＳ３９０環境は、４Ｋのレコードに制限されず、既に説明したセグメント化やリアセンブリ・ロジックを必要としない。他方で、ＭＶＳ／ＯＳ３９０環境は、それ自身の問題点を有している。例えば、ネイティブのＤＡＳＤロッキング・システムは、メインフレーム自体を中心としており、ＤＳＴＣ１０２にはほとんどの機能が常駐していない。ＭＶＳ／ＯＳ３９０環境のネイティブのＤＳＴＣは、機能が非常に限定されているので、クラスタ・アウェア（cluster aware）で非同期信号待機型プロセッサとはならず、リソースがアンロックされている。この点で、市販のリソース・ロッキング又はシリアル化ソフトウェアの助けを借りないネイティブなＭＶＳ／ＯＳ３９０は、オープン・システムズ（open Systems）やマイクロソフトのＮＴアーキテクチャに非常に類似している。しかし、後で述べるように、ＭＶＳ／ＯＳ３９０とオープン・システムズとのロッキング、シグナリング、クラスタ・アウェアネスの制限などは、本発明の実施例においては、容易に克服が可能である。以上の及びこれ以下の説明を与えられれば、この技術分野における当業者であれば、上述の実施例を、ＭＶＳ／ＯＳ３９０、オープン・システムズ、マイクロソフトＮＴ又はそれ以外の同様の環境に適合するように修正することは容易である。上述の環境のそれぞれに対する実施例は、相互に影響を有しあう。上述の実施例は、ＭＱＦの機能を多くの方法で拡張しており、それには、共有されたキューの使用が含まれる。これらの機能の拡張は、望むのであれば、複雑性を低下させた実施例を得るために削除することが容易にできる。これは、特に、ＭＶＳ／ＯＳ３９０環境において意味を有するのであるが、それは、多くのレガシー・アプリケーションは、ネイティブに、シーケンシャルなデータ・セットのリード・ライトを行うからである。データ・セットが実施例の改良型のＤＳＴＣ上に常駐している場合には、レガシーのシーケンシャルなデータ・セットのライトは、ＭＱＦメッセージ・キューに再方向付けすることができる。シーケンシャルなデータ・セットのライト又は個々のライトは、データ・セットとＭＱＦキューとの両方へのミラー・ライトでありうる（mirror written）。同じことが、改良型のＩ／Ｏデバイス上に常駐するシーケンシャルなデータ・セットからリードしているレガシー・アプリケーションについてもいえる。というのは、実際には、ＭＱＦキューからのリードであるからである。この実施例では、レガシー・アプリケーションは、ＭＱＦＡＰＩを用いれば、新たなシステムとのインターフェースのために再度のライトは必要ない。アプリケーションのレベルでは、変更されずに処理を継続するが、システムのレベルでは、オープン・システムズの世界に開かれているのである。上述の実施例は、特に、ＤＡＳＤである改良型のＩ／Ｏデバイスに向けられていた。以上の説明を与えられれば、この分野の当業者であれば、テープ・デバイスなど、他のＩ／Ｏデバイス上で動作するように、この実施例を容易に修正することができる。この点で、拡張された機能の幾つかは犠牲になるが、これ以上説明する必要はないだろう。特に、カーソルによるゲットは、犠牲になる可能性があり、幾つかのテープ指向の実施例も同様である。上述の実施例は、メインフレームが応答への待機を保持することができるゲットを実現している。この実施例は、メインフレームが結果を求めてポーリングを行うような状況をカバーするように変更することは容易である。しかし、改良型のＩ／Ｏデバイス１００とＭＶＳ／ＯＳ３９０、オープン・システムズ、マイクロソフトＮＴ及びそれ以外の類似の環境における現在のコンピューティング技術の性質のために、ロッキング、非同期、シグナリング及びクラスタ・アウェアなどの特徴を、それぞれの環境の中で実現することが可能である。上述の環境のすべての中で、幾つかは、ボリューム、データ・セットファイル又はレコード・ロック・シリアル化は、ＤＡＳＤレベルで生じていることを示しているが、原始的であり、ボリュームなどの階層において最も高いレベルをカバーするだけでありうる。ＭＶＳ／ＯＳ３９０のボリューム・ロックであったり、又はオープン・システムズのファイル・モード・インジケータであっても、ロック・シリアル化の幾つかの形式は、ＤＳＴＣ又はＤＳＴＣに同等なものによって検出することができる。ＴＰＦ環境の実施例は、ＭＣＨＲアドレスの与えられた組に向けられた与えられた一連のＤＡＳＤＩ／Ｏコマンドは、マッピングされて、マッピングされたＭＱＦキューにおけるメッセージ上の一連のＭＱＦバーブを呼び出すことができることを示している。更に、この実施例は、指名されたキューを、他のキューすなわちマスタ制御キュー・ファミリを介して、メインフレーム・アプリケーションから制御し管理することができることを示している。この実施例は、ＤＳＴＣ、インターフェース・ロジック、ＭＱＦ及び通信スタックの間の堅固な統一性を示している。他の実施例では、与えられたＩ／Ｏデバイス・タイプの要素だけでは不十分であるときに、他のＩ／Ｏデバイス・タイプの処理を本発明による改良型のＩ／Ｏデバイス上に配置する、又は、これらを組み合わせて、同じ目的を達成することに制限はない。例として、ＭＶＳ／ＯＳ３９０環境のＤＳＴＣは、ロッキングの分野では不十分である。別のＩ／Ｏデバイス・タイプであるチャネル・ツー・チャネル・アダプタを、ＤＡＳＤが用いるのと同じチャネル・インターフェースを介して、本発明による改良型のＩ／Ｏデバイスにインターフェースするという例を後で述べる。本発明による改良型のＩ／Ｏデバイス・タイプは、複数のハードウェア・デバイス・タイプを同時にサポートし調整を行って、オフロードされたＭＱＦキューを制御するという目的を達成する。これは、既存のメインフレーム又はオープン・システムズのＩ／Ｏインターフェース（又は、プロトコル）を用いてなされている。ＴＰＦＤＳＴＣが提供するクラスタ・アウェアネス及び非同期シグナリングを有する環境はほとんどないが、現在のコンピューティング技術によれば、本発明による改良型のＩ／Ｏデバイスを用いて、その拡張を行うことが可能である。ＭＶＳ／ＯＳ３９０環境のための改良型のＤＳＴＣの実施例は、既知のＥＸＣＰ（ＭＶＳ／ＯＳ３９０実行チャネル・プログラム）インターフェースを介して、ＭＶＳ／ＯＳ３９０待機アプリケーションに非同期的にシグナリングをすることができる。そのような実施例では、改良型のＤＳＴＣデバイスに接続されたＭＶＳ／ＯＳ３９０のチャネル／サブチャネルの幾つかは、ＤＡＳＤデバイスではなく、チャネル・ツー・チャネル（channel to channel）デバイスとして設計することができる。トリガされた待機状態処理のためのすべての非同期シグナリングは、改良型のＩ／Ｏデバイス上のインターフェース・ロジック１０５と協動する追加的なロジックと、既知のチャネル・ツー・チャネル／ＥＸＣＰインターフェースを介してシグナリング処理を扱うＭＶＳ／ＯＳ３９０アプリケーションにおける追加的なロジックとを用いることにより、チャネル・ツー・チャネル・インターフェースを介して行うことができる。改良型のＭＶＳ／ＯＳ３９０ロッキングもまた、同じチャネル・ツー・チャネル／ＥＸＣＰインターフェースを用いて実現することができる。例えば、ＨＯＬＤＣマクロ（作業のシンクポイント・ユニットを表す）は、メインフレーム・アプリケーションからマッピング・ロジック１１２へのチャネル・ツー・チャネル・メッセージであって、ＭＣＨＲのアドレスａを介して転送されるＦＩＬＥＣライトが作業ユニットであることを示すものによって代替することができる。この場合には、ハードウェア経路が、ＤＡＳＤＭＣＨＲ経路と共に、ＤＡＳＤファイル・ライトが作業ユニットの一部であるマッピング・ロジック１１２に告知するのに用いられる。また、作業メッセージのＨＯＬＤＣユニットは、ＤＡＳＤＭＣＨＲ経路を介してであるが、ＭＣＨＲアドレスＡ上のリード／ライト活動を関連付けるようにマッピング・ロジック１１２が構成されているＭＣＨＲアドレスＢに送られる。この技術により、ある１つのハードウェア・デバイス・タイプの弱点を別のものによって補完することが可能になる。別の実施例は、オープン・システムズのアプリケーションがメッセージ上で待機している場合の、改良型の非同期シグナリングのオープン・システムズ実施例である。この実施例では、既知のＳＣＳＩ（スモール・コンピュータ・システムズ・インターフェース）インターフェースと、オープン・システムズのアプリケーションとの直接のインターフェースが可能な対応する改良型のオープン・システムズのデバイス・ドライバとを用いる。ＭＶＳ／ＯＳ３９０環境の場合のように、アプリケーションは、ユーザ・アプリケーションであったり、中間的なアプリケーション・プログラミング・インターフェースを介してトラフィックを結合させるシステム・アプリケーションであったりする。以上で述べた実施例のいずれかを用いる非ＴＰＦコンピューティング環境の直接非同期シグナリングであれば、ファントム・プロセッサ（キュー監視ロジック１１８）がメッセージがＭＣＨＲの対応するキューにおいて受け取られるまでＭＣＨＲアドレスをホールド／ロックしている間、待機しているプロセッサをトリックにかけることが不要になる。メインフレーム又はオープン・システムズのアプリケーションは、メッセージがそのキューに到着したことを明白に告知されることができる。改良型のＩ／Ｏデバイスの新規性は、これまでは別個であったＩ／Ｏデバイスを、ＭＱＦなどの新たな処理ファシリティがレガシー・アプリケーションの処理パラダイムと、ＭＱＦＡＰＩなどの新たなインターフェースを用いて処理を行う新たなアプリケーション処理パラダイムとの両方と共に、透過性を備えながら動作することを可能にするものに統合させたことである。以上で実施例を説明したが、本発明の精神及び範囲から逸脱せずにここで説明した実施例に変更を加えることが可能であることは、この分野の当業者には明らかなはずである。

───────────────────────────────────────────────────── 【要約の続き】ロードする。

Claims

【特許請求の範囲】１．プロセッサとメモリとを有し、対応するアドレスを有するＩ／Ｏコマンドを受け取るストレージ・コントローラにおいて、前記メモリに常駐する、プロセッサが実行可能な命令の組（a set of processor-executable instructions）であって、ネットワーク上で情報を受信及び送信する通信スタックと、メッセージ・キュー・ファシリティ（ＭＱＦ）であって、前記通信スタックと協動し、メッセージ・キュー・バーブに応答して、前記通信スタックに、情報をこのＭＱＦにおけるキューに提供させる、又は、このＭＱＦにおけるキューに情報を前記通信スタックに提供させるメッセージ・キュー・ファシリティ（ＭＱＦ）と、前記Ｉ／Ｏコマンドに応答して、Ｉ／Ｏコマンドが所定のＩ／Ｏコマンドの第１の組の中にあるかどうかを判断し、ある場合には、前記Ｉ／Ｏコマンドを対応するメッセージ・キュー・バーブにマップし、前記ＭＱＦを呼び出すようにキューイングして、それにより、前記ＭＱＦが前記通信スタックと協動して前記バーブと対応する情報を送受信する、インターフェース・ロジックと、を備えていることを特徴とするプロセッサが実行可能な命令の組。２．請求項１記載のプロセッサが実行可能な命令の組において、前記ＭＱＦは、非共有キューを有し、前記インターフェース・ロジックは、第１のＩ／Ｏコマンドに応答して、前記メモリの中にありキューに対応するデータ構造をロックし、第２のＩ／Ｏコマンドに応答して、前記キューに対応する前記データ構造をアンロックし、それによって、前記キューが前記ストレージ・コントローラと相互作用する複数のクライアント・コンピュータの間で共有されるようにすることを特徴とするプロセッサが実行可能な命令の組。３．請求項２記載のプロセッサが実行可能な命令の組において、前記ストレージ・コントローラは、ロック・ファシリティを含み、前記インターフェース・ロジックは、前記ロック・ファシリティと協動して前記データ構造をロック及びアンロックすることを特徴とするプロセッサが実行可能な命令の組。４．請求項２記載のプロセッサが実行可能な命令の組において、前記第１及び第２のＩ／Ｏコマンドは、前記ロック・ファシリティによって処理され、前記データ構造のロック及びアンロックを生じさせることを特徴とするプロセッサが実行可能な命令の組。５．請求項１記載のプロセッサが実行可能な命令の組において、前記Ｉ／Ｏコマンドの部分集合は限定されたサイズのペイロードを有しており、前記限定されたサイズのペイロードは、前記ＭＱＦによってサポートされるメッセージ・サイズよりも小さく、前記インターフェース・ロジックは、リアセンブリ・ロジックを含み、複数のコマンド・ペイロードから前記限定されたサイズよりも大きなペイロードを有するメッセージ・キュー・バーブを形成することを特徴とするプロセッサが実行可能な命令の組。６．請求項５記載のプロセッサが実行可能な命令の組において、前記ストレージ・コントローラは、複数のＩ／Ｏコマンド・ペイロードを受け取り関係付けするレコード・プーリング・ファシリティを含み、前記リアセンブリ・ロジックは、前記レコード・プーリング・ファシリティと協動し、複数のＩ／Ｏコマンド・ペイロードを収集して、前記メモリ内に、メッセージ・キュー・バーブのペイロードとして用いられる物理的にシーケンシャルなペイロードを形成することを特徴とするプロセッサが実行可能な命令の組。７．請求項１記載のプロセッサが実行可能な命令の組において、前記インターフェース・ロジックは、前記ＭＱＦにおけるキューへのプット・メッセージ・キュー・バーブをサポートするロジックと、前記ＭＱＦにおけるキューへのゲット・メッセージ・キュー・バーブをサポートするロジックと、を備えていることを特徴とするプロセッサが実行可能な命令の組。８．請求項７記載のプロセッサが実行可能な命令の組において、プット・メッセージ・キュー・バーブをサポートする前記ロジックは、限定されたサイズよりも小さなペイロードを有するプット・バーブをサポートするロジックと、前記限定されたサイズよりも大きなペイロードを有するプット・バーブをサポートするロジックと、複数のプット・バーブを、作業の取引ユニットとしてサポートするロジックと、を含むことを特徴とするプロセッサが実行可能な命令の組。９．請求項７記載のプロセッサが実行可能な命令の組において、ゲット・メッセージ・キュー・バーブをサポートする前記ロジックは、限定されたサイズよりも小さなペイロードを有するゲット・バーブをサポートするロジックと、前記限定されたサイズよりも大きなペイロードを有するゲット・バーブをサポートするロジックと、複数のゲット・バーブを、作業の取引ユニットとしてサポートするロジックと、を含むことを特徴とするプロセッサが実行可能な命令の組。１０．請求項５記載のプロセッサが実行可能な命令の組において、前記インターフェース・ロジックは、前記ＭＱＦにおけるキューへのブラウズ・メッセージ・キュー・バーブをサポートするロジックを含むことを特徴とするプロセッサが実行可能な命令の組。１１．請求項７記載のプロセッサが実行可能な命令の組において、ゲット・メッセージ・キュー・バーブをサポートする前記ロジックは、いつ前記ＭＱＦがセロ・メッセージを用いて応答するかを検出するロジックと、いつ前記キューがメッセージを受け取ったかを前記ゲット・メッセージ・キュー・バーブを生じさせたクライアント・コンピュータに知らせ、それによって、前記コンピュータ上で動作しているソフトウェアが応答への待機をブロックする、ロジックと、を含むことを特徴とするプロセッサが実行可能な命令の組。１２．請求項７記載のプロセッサが実行可能な命令の組において、前記ＭＱＦにおけるキューへのプット・メッセージ・キュー・バーブをサポートする前記ロジックは、Ｉ／Ｏコマンドの前記第１の組の第１の部分集合に応答して、前記Ｉ／Ｏコマンドのペイロードを検索し、前記Ｉ／Ｏコマンドと関連付けされたアドレスを指名されたキューにマップし、前記検索されたペイロードを備えたプット・バーブを形成し、それを前記指名されたキューに発行するロジックを含むことを特徴とするプロセッサが実行可能な命令の組。１３．請求項７記載のプロセッサが実行可能な命令の組において、前記ＭＱＦにおけるキューへのプット・メッセージ・キュー・バーブをサポートする前記ロジックは、Ｉ／Ｏコマンドの前記第１の組の第２の部分集合に応答して、前記Ｉ／Ｏコマンドと関連付けされたアドレスに対応するデータ構造をロックし、それによって、前記データ構造がアンロックされるまでは、前記Ｉ／Ｏコントローラの他のクライアントがこのアドレスに作用することを回避するロジックと、Ｉ／Ｏコマンドの前記第１の組の第３の部分集合に応答して、前記Ｉ／Ｏコマンドの前記ペイロードを検索し、前記Ｉ／Ｏコマンドと関連付けされたアドレスを指名されたキューにマップし、前記検索されたペイロードを備えたプット・バーブを形成し、それを前記指名されたキューに発行するロジックと、Ｉ／Ｏコマンドの前記第１の組の第４の部分集合に応答して、前記Ｉ／Ｏコマンドと関連付けされたアドレスに対応するデータ構造をアンロックし、それによって、このアドレスに対する他の作用を許容するロジックと、を含んでおり、それによって、クライアント・コンピュータに、前記第２の部分集合から指名されたキューに対応するアドレスにＩ／Ｏコマンドを発行させ、次に、前記第３の部分集合から前記アドレスにＩ／Ｏコマンドを発行させ、次に、前記第４の部分集合から前記アドレスにＩ／Ｏコマンドを発行させることによって、共有されたキューへのプットが達成されることを特徴とするプロセッサが実行可能な命令の組。１４．請求項７記載のプロセッサが実行可能な命令の組であって、前記ＭＱＦへのキューへのプット・メッセージ・キュー・バーブをサポートするロジックは、Ｉ／Ｏコマンドの前記第１の組の第５の部分集合に応答して、前記Ｉ／Ｏコマンドのペイロードを検索し、前記Ｉ／Ｏコマンドと関連付けされたアドレスを指名されたキューにマップし、前記検索されたペイロードを備えたシンクポイントを用いて、プット・バーブを形成し、それを前記指名されたキューに発行して、作業ユニットのフレーミングを開始するロジックと、Ｉ／Ｏコマンドの前記第１の組の第６の部分集合に応答して、前記Ｉ／Ｏコマンドのペイロードを検索し、前記Ｉ／Ｏコマンドと関連付けされたアドレスを指名されたキューにマップし、前記検索されたペイロードを備えた中間的なプット・バーブを形成し、それを前記指名されたキューに発行するロジックと、Ｉ／Ｏコマンドの前記第１の組の第７の部分集合に応答して、前記Ｉ／Ｏコマンドのペイロードを検索し、前記Ｉ／Ｏコマンドと関連付けされたアドレスを指名されたキューにマップし、前記検索されたペイロードを備えた最後のプット・バーブを前記指名されたキューに発行し、コミット・バーブを前記指名されたキューに発行して、前記作業ユニットのフレーミングを終了するロジックと、Ｉ／Ｏコマンドの前記第１の組の第８の部分集合に応答して、前記Ｉ／Ｏコマンドと関連付けされたアドレスを指名されたキューにマップし、ロールバック・バーブを前記指名されたキューに発行して、前記作業ユニットのフレーミングを終了し前記作業ユニットをアボートするロジックと、を含むことを特徴とするプロセッサが実行可能な命令の組。１５．請求項７記載のプロセッサが実行可能な命令の組において、前記ＭＱＦにおけるキューへのゲット・メッセージ・キュー・バーブをサポートする前記ロジックは、Ｉ／Ｏコマンドの前記第１の組の第９の部分集合に応答して、前記Ｉ／Ｏコマンドと関連付けされたアドレスを指名されたキューにマップし、ゲット・バーブを形成し、それを前記指名されたキューに発行し、前記検索されたペイロードを前記指名されたキューから前記ゲット・メッセージを生じさせるクライアント・コンピュータに戻すロジックを含むことを特徴とするプロセッサが実行可能な命令の組。１６．請求項７記載のプロセッサが実行可能な命令の組において、前記ＭＱＦにおけるキューへのゲット・メッセージ・キュー・バーブをサポートする前記ロジックは、Ｉ／Ｏコマンドの前記第１の組の第１０の部分集合に応答して、前記Ｉ／Ｏコマンドと関連付けされたアドレスに対応するデータ構造をロックし、それによって、前記データ構造がアンロックされるまでは、他のクライアントがこのアドレスに作用することを回避するロジックと、Ｉ／Ｏコマンドの前記第１の組の第１１の部分集合に応答して、前記Ｉ／Ｏコマンドと関連付けされたアドレスを指名されたキューにマップし、ゲット・バーブを形成し、それを前記指名されたキューに発行し、前記検索されたペイロードを前記指名されたキューから前記ゲット・メッセージを生じさせるクライアント・コンピュータに戻すロジックと、Ｉ／Ｏコマンドの前記第１の組の第１２の部分集合に応答して、前記Ｉ／Ｏコマンドと関連付けされたアドレスに対応するデータ構造をアンロックし、それによって、このアドレスに対する他の作用を許容するロジックと、を含んでおり、それによって、クライアント・コンピュータに、前記第１０の部分集合から指名されたキューに対応するアドレスにＩ／Ｏコマンドを発行させ、次に、前記第１１の部分集合から前記アドレスにＩ／Ｏコマンドを発行させ、次に、前記第１２の部分集合から前記アドレスにＩ／Ｏコマンドを発行させることによって、共有されたキューへのゲットが達成されることを特徴とするプロセッサが実行可能な命令の組。１７．請求項７記載のプロセッサが実行可能な命令の組であって、前記ＭＱＦへのキューへのゲット・メッセージ・キュー・バーブをサポートするロジックは、Ｉ／Ｏコマンドの前記第１の組の第１３の部分集合に応答して、前記Ｉ／Ｏコマンドと関連付けされたアドレスを指名されたキューにマップし、ゲット・バーブを形成し、それを前記指名されたキューに発行して、作業ユニットのフレーミングを開始するロジックと、Ｉ／Ｏコマンドの前記第１の組の第１４の部分集合に応答して、前記Ｉ／Ｏコマンドと関連付けされたアドレスを指名されたキューにマップし、中間的なゲット・バーブを形成し、それを前記指名されたキューに発行するロジックと、Ｉ／Ｏコマンドの前記第１の組の第１５の部分集合に応答して、前記Ｉ／Ｏコマンドと関連付けされたアドレスを指名されたキューにマップし、最後のゲット・バーブを形成して、それを前記指名されたキューに発行し、コミット・バーブを前記指名されたキューに発行して、前記作業ユニットのフレーミングを終了するロジックと、Ｉ／Ｏコマンドの前記第１の組の第１６の部分集合に応答して、前記Ｉ／Ｏコマンドと関連付けされたアドレスを指名されたキューにマップし、ロールバック・バーブを前記指名されたキューに発行して、前記作業ユニットのフレーミングを終了し前記作業ユニットをアボートするロジックと、を含むことを特徴とするプロセッサが実行可能な命令の組。１８．請求項１記載のプロセッサが実行可能な命令の組において、前記インターフェース・ロジックは、前記Ｉ／Ｏコマンドが関心対象であるかどうかを判断するアドレス監視ロジックと、前記アドレス監視ロジックと協動し、関心対象のＩ／Ｏコマンドを前記ＭＱＦへの中間的な作用の中にマップするマッピング・ロジックと、前記ＭＱＦ及び前記マッピング・ロジックと協動し、未決のゲット・バーブに対して、前記ＭＱＦにおけるキューにいつメッセージが到着したかを判断するキュー監視ロジックと、を含むプロセッサが実行可能な命令の組。１９．請求項１記載のプロセッサが実行可能な命令の組において、前記インターフェース・ロジックは、Ｉ／Ｏコマンドのアドレスを監視して、それが関心対象であるかどうかを判断する手段と、関心対象のＩ／Ｏコマンドを前記ＭＱＦへの中間的な作用にマップする手段と、前記ＭＱＦにおけるキューを監視して、未決のゲット・バーブに対して、前記ＭＱＦにおけるキューにいつメッセージが到着したかを判断する手段と、を含むことを特徴とするプロセッサが実行可能な命令の組。２０．ＭＱＦプロトコルに従ってメッセージの送受信をする方法であって、アドレスを有するＩ／Ｏコマンドを、その上に常駐する、通信スタックと、前記通信スタックと協動するＭＱＦと、前記ＭＱＦと協動するインターフェース・ロジックとを有するＩ／Ｏコントローラに送信するステップと、前記インターフェース・ロジックが、前記Ｉ／ＯコマンドをＭＱＦバーブにマップし、前記バーブを前記Ｉ／Ｏコントローラに常駐するＭＱＦに発行するステップと、前記Ｉ／Ｏコントローラに常駐するＭＱＦが、前記通信スタックに、メッセージを、前記ＭＱＦプロトコルに従って、前記ＭＱＦバーブに対応して送信させるステップと、を含むことを特徴とする方法。２１．請求項２０記載の方法において、Ｉ／Ｏコマンドを前記Ｉ／Ｏコントローラに送信し、前記アドレスに対応するデータ構造をロックさせ、それによって、前記Ｉ／Ｏコントローラの他のクライアントが、前記構造がアンロックされるまで、前記アドレスへの作用を実行することを回避させるステップと、Ｉ／Ｏコマンドを前記Ｉ／Ｏコントローラに送信し、前記アドレスに対応するデータ構造をアンロックさせるステップと、を更に含むことを特徴とする方法。２２．請求項２０記載の方法において、前記Ｉ／Ｏコントローラが、前記クライアントに、前記ＭＱＦはＭＱＦに応答するデータを含んでいないことを指示し、それによって、前記クライアントは待機をブロックするようにするステップと、前記インターフェース・ロジックが、前記ＭＱＦが応答するデータが以前は存在しなかったＭＱＦバーブに応答するデータをいつ有するかを検出するステップと、前記インターフェース・ロジックが、Ｉ／Ｏコントローラに、クライアントに対して、前記ＭＱＦが応答するデータが以前は存在しなかったＭＱＦバーブに応答するデータを現在では有していることを告知させるステップと、を更に含むことを特徴とする方法。