JPH05224931A - 実行時プログラム条件を表現し、信号で通知する方法及びシステム - Google Patents

Abstract

(57)【要約】 【目的】 言語構文の修正なくして、多言語環境で多言
語条件マネージャとともに機能できる条件を信号を通知
するための機構を提供する。 【構成】 上記のような多言語環境におけるアプリケー
ションをリンクする機能を有する外部入口点のためのオ
ブジェクト・コードを有する信号処理ルーチンを使用す
ることによる。このような信号処理ルーチンを使用する
ことによって、種々のアプリケーションにおいてそのサ
ブルーチンが自動的に条件マネージャに対して正常な条
件を返信するようにコーディングされれば、その結果サ
ブルーチンからのリターン・コードをチェックする必要
がなくなる。また、この発明においてはこの条件を返信
するための表示フォーマットとして条件識別子、そのフ
ォーマット・コード、条件の重大度コード等を含むもの
を定義する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、コンピュータ化データ
処理の分野における方法及びシステムに関する。より具
体的にはコンピュータ・プログラムの実行中に生じる条
件（異常事態）の処理に関する。

【０００２】

【従来の技術】一般に、コンピュータ・システムは、プ
ログラム実行中に生じる条件を検出し適切に応答するた
めに、組み合わせて使用される、ハードウェア及びソフ
トウェア機構を有する。条件及び例外という用語は、し
ばしば同義に使用される。こうした条件または例外とし
ては、例えば無効な機械語アドレスを使うとか、０で割
るなどのエラーがある。条件には、実際のエラーでない
かもしれないが、特別の注意を必要とする事象も含まれ
る。この種の条件の例としては、初期設定されていない
変数を参照しようとする試みがある。ハードウェアで検
出される条件は、一般に、ハードウェア割込み機構によ
って、ＣＰＵに、その条件を引き起こしたプログラムの
実行を停止させる。システムにおける低レベルのソフト
ウェアまたはファームウェアの割込み処理ルーチンに、
最初に制御が与えられる。次いで、ソフトウェア分岐及
び呼出し技法により、オペレーティング・システム、実
行時環境プログラム、適用業務プログラムなど現在実行
中のプログラムの様々な層中を制御がパスされる。一般
に、ソフトウェアで検出される条件は、条件処理ルーチ
ンと呼ばれるルーチンを呼び出す。プログラムが条件処
理ルーチンを実行させる場合、そのプログラムは、条件
を信号で通知すると言われる。

【０００３】従来のシステムは、これらの条件に関する
情報を、例えばリターン・コードや例外など様々なやり
方で通信する。従来技術では、ソフトウェア製品及びオ
ペレーティング・システムを横断してこれらの条件に用
いられる使用、表現、あるいは通信の方法には、ほとん
ど共通性がない。

【０００４】したがって、多言語適用業務、及び適用業
務のシステム間原始コード可搬性を促進するため、条件
を表現し、その存在の結果を処理するのに必要な情報を
通信するために、首尾一貫したデータ・タイプを定義す
ることが必要である。

【０００５】システムにおける条件処理機構の直接的機
能は、エラーを診断し、次いで、そのエラーを選択的
に、おそらくはあるデータ値を復元してから、報告また
は許容しあるいはその両方を行うことである。これらの
処置は、特定の問題をシステム内で解決し、システムが
その目的を達成できるようにするために取られる。歴史
的に見ると、高水準言語での条件処理は、それぞれのプ
ログラミング言語の目的に適したものとして実施されて
きた。これらの個々の実施態様が互いに異なり、実際に
は、同じ適用業務で一緒に使用する場合、しばしば相互
に破壊的であることは驚くに当らない。

【０００６】従来技術では、実行中のプログラムの原始
言語に基づいて、条件処理が実行される。つまり、ＣＯ
ＢＯＬコンパイラを用いて生成されたプログラムではあ
る１組の条件処理ルーチンを使用し、ＰＬ／Ｉで書かれ
たプログラムでは別の１組の条件処理ルーチンを使用す
る。ある適用業務における高水準言語の任意の混合物を
サポートすることが望ましくかつ必要であるとすると、
この混合環境を単一言語環境と並んで管理する条件処理
モデルを開発することが不可欠である。基本的要件は、
各個別言語用の標準を満足することである。完全に１言
語で実施されているどんな適用業務も、その言語の外部
標準で指定されたものとして動作しなければならない。
こうでなければ、条件処理モデルは全く実現不能であ
る。

【０００７】現在存在する高水準言語（ＨＬＬ）コンパ
イラは、条件処理機構に対するユーザ・アクセスの度合
が様々である。ＰＬ／Ｉ言語は、ユーザが「ＯＮ条件」
を用いて条件処理プロセスに分岐することのできる比較
的強力な１組の方法を提供する。他方、ＣＯＢＯＬ言語
は、条件が発生したとき、ユーザに制御を得させる機構
を実質上もっていない。今日、利用可能なコンピュータ
・プログラミング言語は多数存在する。条件処理に対す
る組込みユーザ・アクセスを実現するために、これらの
コンパイラの言語構文を大幅に修正する必要があるの
は、面倒な解決方法であろう。

【０００８】プログラムの実行は、一般に、以下の４つ
の可能な結果のうちの１つをもたらす。 １．すべての入力が境界内にあり、プログラム中でエラ
ーに出会わず、ハードウェア及びオペレーティング・シ
ステムが正しく動作し、正しい結果がもたらされる。 ２．入力、プログラム、ハードウェア、またはオペレー
ティング・システムにおけるエラーのため、不完全また
は不正確な結果がもたらされるが、エラーとは診断され
ない。 ３．入力、プログラム、ハードウェア、またはオペレー
ティング・システムにおけるエラーのため、不完全また
は不正確な結果がもたらされる。しかし、エラーが発生
したことがプログラムに通知され、プログラムが、その
趣旨の通知（メッセージ、条件またはリターン・コー
ド）を生成する。 ４．入力、プログラム、ハードウェア、またはオペレー
ティング・システムにおけるエラーのため、正しい結果
を得ることができない。しかし、エラーが発生したこと
がプログラムに通知され、プログラムは、そのエラー
が、エラーを伝播させる傾向のある副作用を引き起こす
のを阻止する。大抵の場合、これは、プログラムが、エ
ラーの通知以外の結果を生成することを拒絶することを
意味する。

【０００９】これらの結果のそれぞれの場合に、所与の
結果を人またはプログラムあるいはその両方に通信する
必要がある。この通信は、「条件の通信」と定義でき
る。所与のプログラム実行状態の「条件」を正確に通信
するには、この通信を行うための機構（すなわち条件表
現）を定義することが必要である。

【００１０】

【発明が解決しようとする課題】従来技術では、サブル
ーチンが呼び出される時、呼出しプログラムはしばしば
サブルーチンからのリターン・コードを検査して、サブ
ルーチンがうまく働かなかったかどうか、したがって、
訂正処置をとる必要があるかどうか、あるいは実行を停
止しなければならないかどうかを決定しなければならな
い。このプロセスでは、コードを書き込む際にもそれを
実行する際にも多くの時間と資源が消費される。矯正処
置を実行するコードにサブルーチンがアクセスできる場
合は、サブルーチンからのリターン・コードについて検
査するためのコードをなくすことができる。従来技術で
は、これを実行するための一般的な機構はない。ＰＬ／
Ｉ言語は、組込み言語構成体を用いて、条件を信号で通
知する能力を提供する。この言語構成体は、「ＯＮ条
件」実行用に定義されたルーチンを呼び出す。この手法
は、ＰＬ／Ｉ構文に結合されており、したがって、この
問題に対する一般的な解決方法ではない。この手法を、
例えば、ＦＯＲＴＲＡＮ、Ｃ言語、Ｐａｓｃａｌ、ＣＯ
ＢＯＬのユーザに適用するには、新しい言語構文を定義
することが必要となる。

【００１１】言語構文の修正を要せず、多言語環境で多
言語条件マネージャと一緒に機能できる、条件を信号で
通知するための一般的機構が必要であるが、従来技術で
は提供されない。具体的には、従来技術は、次のものを
提供しない。 ・使用中の広い範囲の原始言語を横断してユーザがアク
セスできる、条件を信号で通知するための連係可能なル
ーチン。 ・サブルーチン実行後にリターン・コードを検査する必
要からプログラマを解放する一般的機構。 ・必要な通信のための共通性を提供するだけでなく、次
の機能特性も提供する、条件を標準的な方式で条件トー
クン中で表す方法または手段。 −使用を据え置くことができ、確実な据置きが可能であ
る −インスタンス特有データを任意に参照できる −適当な条件のもとで、重大度が高水準言語プログラム
によって容易かつ有効にアクセスできる ・以上の各項目を組み合わせて、協働的システムにする
ための方法または手段。

【００１２】

【課題を解決するための手段】本明細書では次の用語を
使用する。 ＣＥＥＣＩＢ ある大域状況情報がそこに記憶される変数 条件重大度コード ０〜４の範囲で使用され、０が最も重大度が低い。 条件マネージャ 条件が発生した時にコンピュータ・システムの制御を獲
得し、様々なシステムまたはユーザ適用業務ルーチンあ
るいはその両方を実行することにより、その条件の処理
を管理する、何らかのプログラムまたは手段。これは、
オペレーティング・システム、実行時環境、または適用
業務プログラムの一部分であり得る。 カーソル 実行可能な命令を指す、アドレス・ポインタ。 デバッグ・プログラム 適用業務プログラムをテスト条件下で実行してエラーを
見つけるのに使用されるプログラム。 処理カーソル 処理ルーチン、ならびに処理ルーチンが呼び出される対
象のスタック・フレームを指示するカーソル。 イネーブル 条件を、他の条件処理ルーチンに提示する前に、インタ
ーセプトして、その条件を無視すべきか否かを決定する
能力。未認知の条件は、必ず、イネーブルされるものと
定義される。通常、イネーブルを用いて、ハードウェア
に、それがもっていない機能、ならびに言語の意味論の
言語実施を補足する。ハードウェアを補足する例として
は、言語指定に基づく浮動小数点オーバーフロー例外の
特殊処理がある（ある機械では、これは例外をマスクす
ることによって達成できる）。 エンクレーブ 主ルーチンと０個以上のサブルーチンの集合。主ルーチ
ンがまず実行される。スレッドは、エンクレーブに由来
する。 ＩＮＴ２及びＩＮＴ４ それぞれ２バイト及び４バイトの整数を意味し、Ｃ構文
インターフェース定義の一部として使用される。 プラットフォーム オペレーティング・システムと、プログラムがその上で
実行されるコンピュータ・ハードウェアの組合せ。 再開カーソル 適用業務中の実行が再開される点を指定するカーソル。 再開 条件処理を終了し、再開始カーソルによって指定される
命令及びスタック・フレームに制御を移転すること。 安全条件 処理されない場合には無視できる、何らかの条件。 スタック・フレーム 割込みが発生する時、あるいは呼出しまたは分岐に対す
るレジスタが保管される時に、コンピュータのスタック
に押し込まれる、セット・レジスタ及び条件フラグ。 スタック・フレーム０ 最初のルーチン用のスタック・フレームの直前の概念的
スタック・フレーム。これは、スレッドまたはタスクが
そこで初期設定され、第１プロシージャがそこから呼び
出され、終了がそこから開始される、理論的場所であ
る。条件処理の場合、スタック・フレーム０は、ある言
語に対する省略時処置が適用されるフレームである。 スレッド ルーチンにおける実行の基本行を表すのに使用される用
語。

【００１３】本発明は、関連特許出願に記載されている
ような、複数言語で書かれたプログラムを処理する条件
マネージャを有するコンピュータ・システムにおいて、
プログラム実行中に発生する条件を処理するための一般
的方法及びシステムの改良である。この方法は、Ｐａｓ
ｃａｌ、ＦＯＲＴＲＡＮ、Ｃ言語、ＣＯＢＯＬなど外部
呼出しをサポートする任意の言語で書かれた適用業務プ
ログラムに連係するのに適した、外部入口点用の目的コ
ードをもつ一般的信号ルーチンを生成し使用するもので
ある。信号ルーチンは、プログラムによって呼び出され
ると、条件マネージャに条件を信号で通知し、次いで、
呼出し側に戻る。信号ルーチン用の目的コードは、後で
適用業務プログラムに連係し反復使用するために、コン
ピュータ・システム内の持久メモリに記憶される。プロ
グラムがこの信号ルーチンを使って、条件に適切に応答
して予め登録されているユーザ定義条件処理ルーチンを
実行する条件マネージャに、適切な条件を自動的に信号
で通知するように、サブルーチンをコード化することに
より、サブルーチンからのリターン・コードを検査する
段階を省略することができる。フィードバック・トーク
ンとして働くことのできる一般的条件トークンが定義さ
れる。このトークンは、条件識別子、条件識別子用フォ
ーマット・コード、条件用重大度コード、ファシリティ
識別子用制御コード、ファシリティ識別子、及びインス
タンス特有情報を識別する任意選択のハンドルから構成
される。信号ルーチン及びフィードバック・トークン
は、フィードバック・トークンを記憶できるアドレスの
引渡しを任意選択で行うことのできるサブルーチンが使
用できる。実行中、このサブルーチンが条件の有無を監
視する。検出された条件の重大度が閾値よりも大きい場
合、サブルーチンは条件マネージャに条件を信号で通知
し、そうでない場合には、渡されたアドレスにフィード
バック・トークンを記憶する。

【００１４】

【実施例】本発明は、条件マネージャ及び１組の呼出し
可能なサービスを含む共通条件処理ルーチン（ＣＣＨ）
に関して実施される。ＣＣＨは、複数の高水準言語（Ｈ
ＬＬ）で書かれた適用業務プログラム用の、共通実行環
境（ＣＥＥ）と呼ばれる、より大きな共通実行時環境の
一部分である。

【００１５】本発明は、次の諸特性をもつ共通データ・
タイプを使用して条件を表す、共通の方法を提供する。 ・自己記述式 ・リターン・コードとして使用できる ・条件マネージャに信号で通知することができる ・使用が据置きできる ・パスできる ・各トークンが条件特有である ・条件を記述するメッセージと１対１で対応する ・任意選択で、インスタンス特有データを参照できる

【００１６】本発明は、１２バイト（９６ビット）の条
件トークン・データ・タイプを用いて条件を通信するこ
とができる。呼出し可能なサービスからの戻り情報（フ
ィードバック・コード）は、このデータ・タイプの１イ
ンスタンスである。条件トークン・データ・タイプの利
点には、次のことが含まれる。 ・呼び出されたサービスからの戻り情報を処理するた
め、条件処理ルーチンが確立できる。この方法では、プ
ログラマが「呼込み後検査」タイプの呼出しをコード化
することから解放される。その代りに、集中位置を使っ
て戻り情報を処理することになる。 ・すべての呼出し可能サービス間の共用データ・タイプ
として、これらの構成要素を一つに結合する。 ・表示できる、あるいはファイルにログできるメッセー
ジが、条件の各インスタンスに関連づけられる。 ・後で処理するため、フィードバック・コードとして記
憶またはログできる。 ・プラットフォーム間でのコード可搬性をサポートする
ため、（記号名をサポートする言語による）記号名を、
定義済みのフィードバック・コード及びハードウェア条
件と等しくすることができる。

【００１７】「呼込み後検査」型の従来の呼出し方法に
伴うオーバーヘッドの量及び完全性の欠如を軽減するた
め、条件トークン・データを入力として条件マネージャ
に送る方法が提供される。この方法は、次の通りであ
る。 ・サービス・ルーチンに対するＣＡＬＬ（呼出し）ステ
ートメントに応じて、呼出し側が、フィードバック・コ
ード用アドレス・パラメータをパスすることを選ぶこと
ができる。 ・重大条件（重大度＝４）が、必ず、条件マネージャに
信号で通知される。 ・このパラメータが供給され、サービスの結果が重大で
ない場合には、フィードバック・コードが呼出し側に戻
される。 ・パラメータが供給されず、呼び出されたサービスの結
果が完全な成功ではない（条件＝０）場合は、呼出し側
が、条件マネージャにその旨を信号で通知し、条件トー
クンを渡す。 ・パラメータが供給されず、呼び出されたサービスの結
果が完全な成功である場合は、サービスが戻されるだけ
である。

【００１８】任意選択パラメータ法を使用するには、言
語は、ＣＡＬＬステートメント上の任意選択パラメータ
を許容しなければならない。言語が任意選択パラメータ
を許容しない場合、フィードバック・コード・パラメー
タは必ず呼出し側によってコード化される。この場合、
任意選択パラメータと同じ効果を達成するために、特別
な値を定義してもよい。例えば、アドレス・パラメータ
にゼロの値を入れることにより、すべての条件を信号で
通知する方法をトリガすることができる。この任意選択
パラメータを用いて、プログラマは、それが有利な場
合、信号方法の全能力を利用することが可能となり、ま
た従来の呼出し・検査シーケンスを使用し、条件トーク
ン使用の利益を得ることも可能となる。

【００１９】次に、この条件を表すのに用いられるデー
タ・オブジェクトを定義する。

【００２０】条件トークン・データ・タイプ（ＣＥＥＴ
ＯＫ）は、メッセージ・サービス、条件マネージャ、呼
出し可能サービス、及びユーザ適用業務と通信するのに
使用される。インスタンスが動的に構築でき、より典型
的には、静的に構成できる。

【００２１】条件トークンの１インスタンスは、長さが
１２バイト（９６ビット）であり、（Ｃ構文で表した）
次の情報を含んでいる。 ただし、 Ｃｏｎｄｉｔｉｏｎ＿ＩＤ Facility_IDと共に条件を記述する、識別子の４バイト
・コード化であり、Caseフィールドが識別子のタイプを
決定する。２つの識別子が定義される。 ・ケース１−サービス条件 ケース１は、呼出し可能サービス及び大部分の適用業務
プログラムによって使用される。 ただし、 ＭｓｇＳｅｖ ２バイトの２進整数で、次の値が可能である。 ０（Ｉ）情報のみ（あるいは、トークン全体が０の場合
は、情報なし）。 １（Ｗ）警告−サービスがおそらくは正しく完了。 ２（Ｅ）エラー検出−訂正が試みられ、サービスがおそ
らくは不正確に完了。 ３（Ｓ）サービス・エラー−サービスが未完了。 ４（Ｃ）重大エラー−サービスが完了せず、条件が信号
で通知される。このフィールドは明らかに他の値を含む
こともできるが、それらはアーキテクチャ構成されてい
ない。呼出し可能サービス中に重大なエラー（重大度＝
４）が発生した場合には、それは同期的に呼出し側に戻
されるのでなく、必ず条件マネージャに信号で通知され
る。 注：メッセージを表示する際、ＣＥＥＣＴＯＫからの重
大度指示が必ず使用される。 Ｍｓｇｎｏ 条件に関連するメッセージを識別する、２バイトの２進
数。Facility_IDとMsgnoの組合せが、条件を一義的に識
別する。 ・ケース２−クラス／原因コード条件 ある種のオペレーティング・システム及びコンパイラ実
行時ライブラリによって使用できる。 ただし、 Ｃｌａｓｓ＿Ｃｏｄｅ 条件のクラスに関連するメッセージを識別する２バイト
の２進数（上記のMsgnoと同じタイプ） Ｃａｕｓｅ＿Ｃｏｄｅ 条件の原因に関するメッセージを識別する２バイトの２
進数（上記のMsgnoと 同じタイプ） Ｆａｃｉｌｉｔｙ＿ＩＤ 製品または製品構成要素を識別する３文字の英数字スト
リング。Facility_IDは、実行時メッセージの格納場所
（例えば、ファイル）に関連し、メッセージ番号に関連
する時は、格納場所内のメッセージを一義的に識別す
る。ただし、メッセージ格納場所の命名規約はプラット
フォーム特有である。Facility_IDは システム内で一
義的である必要はなく、適用業務作成者が決定できる。
製品は、初期設定されると、そのメッセージ格納場所が
メッセージ・サービスによって位置決めできることを決
定する責任を負う。各プラットフォームは、メッセージ
格納場所を位置決めするそれ自体の方法を有する。例え
ば、ＯＳ／２では環境変数、ＶＭ／ＣＭＳではファイル
定義（ＦＩＬＥＤＥＦ）、ＭＶＳではddnanmeが使用で
きる。 注：Msgno/Facility_IDは、イネーブルされた製品の条
件を識別する。この識別 は、単一セッションの範囲を
越えて持続する必要がある。こうすると、条件を もた
らしたセッションが終了した後で条件及びその関連メッ
セージの意味が決 定できるようになる。 Ｃａｓｅ（ケース） トークンのCondition_ID部分のフォーマットを定義する
２ビットのフィールド。 値１はCase1の条件を識別
し、値２はCase2の条件を識別する。値０はプラット
フォーム特有の使用に留保され、値３は将来の使用に留
保される。 Ｓｅｖｅｒｉｔｙ（重大度） 条件の重大度を示す３ビットのフィールド。Sevirityの
値は、ケース１のCondition_IDの下で定義されるものと
同じである。重大度を評価する際、ケース２の条件を信
号で通知せるのにケース１の条件に対するものと同じ規
則が適用される。 注：このフィールドは、ケース１とケース２の両方の条
件にとって有効であり、 どちらかの条件トークンと共
に条件の重大度を評価するのに使用できる。ケース１条
件の場合、このフィールドはCondition_IDにおけるSeve
rityフィールドと同じ値を含む。 Ｃｏｎｔｒｏｌ（制御） 条件処理の様々な態様を記述または制御するフラグを含
む、次のような３ビットのフィールド。 ..１ Facility_IDがシステム・ソフトウェア供給者によって
割り当てられたこと を示す。 .１. 留保 １.. 留保 Ｉ＿Ｓ＿Ｉｎｆｏ それが含まれている条件トークンによって表される条件
の所与のインスタンスに関連するインスタンス特有情報
（ＩＳＩ）を識別する４バイトのハンドル。ＩＳＩが所
与の条件トークンに関連していない場合、I_S_Infoフィ
ールドは２進０の値を含む。

【００２２】構造ＣＥＥＣＴＯＫの構成図については、
図９を参照のこと。ビット番号付けは、フィールドのサ
イズを示し、特定のビット位置方法を示すものではな
い。構造ＣＥＥＣＴＯＫを宣言するＣコードの１例は、
次の通りである。

【００２３】フィードバック・コードは、条件トークン
（構造ＣＥＥＣＴＯＫ）の１インスタンスである。フィ
ードバック・コードは、呼出し側がそれを保持する区域
に参照をパスした場合に、サービス呼出しから戻され
る。

【００２４】インスタンス特有情報（ＩＳＩ） ＩＳＩの定義：インスタンス特有情報（ＩＳＩ）は、ど
ちらも所定の条件の特定の発生に対して一義的である、
２種のデータから構成されている。このデータは、次の
ように定義される。 １．所与の条件に関連するメッセージに挿入される情報
（すなわち、メッセージ挿入データ）。 ２．所与の条件（すなわち、データ"Q_Data"を修飾する
条件）を具体的に識別するためまたはこれに反応するた
めあるいはその両方のために、条件処理ルーチンによっ
て使用される情報。

【００２５】これらの情報項目のどちらか一方または両
方の存在または使用あるいはその両方が、条件または言
語または適用業務あるいはそのいくつかに特有である。
すなわち、所与のメッセージは、挿入データに対する要
件を有することも有しないこともある。データを修飾す
る条件（Q_Data）の存在、フォーマット及び使用は、条
件の信号発信側と条件を処理する処理側との間の協力規
約による。条件トークンは、そのポインタ長が広範囲に
変動する可能性のある、複数のプラットフォームを横断
して使用されるように設計されているので、ＩＳＩハン
ドル用に使用される４バイトは、ポインタとして定義さ
れていないが、プラットフォームによっては実際にポイ
ンタとなることも可能である。例えば、非ＥＳＡ ＭＶ
Ｓシステムでは、ハンドルは３２ビットのポインタとす
ることができる。一般に、これはＩＳＩデータの記憶位
置を識別する情報であると定義される。間接的参照を行
うための様々な標準的プログラミング技法が使用でき
る。

【００２６】ＩＳＩのフォーマット及び構造はプラット
フォーム特有であるが、ＩＳＩは次のデータ項目を含ん
でいなければならない： ただし、 ＩＳＩ＿Ｈａｎｄｌｅ（ＩＮＴ４） １から（２**３１）−１までの範囲の単調に増加する数
であり、処理レベルで計算され、したがって新しいISI_
Handleを得る際には直列化が必要である。（注： 循環
は許されるが、重大度１の条件が信号で通知される） ＩＳＩ＿Ｆｌａｇ（ＢＩＴＳ：３２） 次のように定義される標識を含む、３２ビットのフィー
ルドである。 ・..........１ −適用業務保護フラグ ・..........１． −環境保護フラグ（このフラグは、条件マネージャによ
ってセットされ管理される。これは条件マネージャに入
るときに（条件マネージャ内で活動状態である条件に関
連するＩＳＩの重ね書きを防止するため）セットされ、
活動状態の条件処理から条件が出るときにリセットされ
る。） ・..........１．． −交差エンクレーブ遷移フラグ 注：このフラグがセットされると、関連する条件トーク
ン及びその関連するＩＳＩがエンクレーブ境界を横切っ
て渡されるよう指示する。 ・その他 −留保され、０の値をもつ。 Ｔｉｍｅ−ｓｔａｍｐ（ＦＬＯＡＴ８） ＩＳＩが生成された時点を示すタイムスタンプ。 Ｑ＿Ｄａｔａ＿Ｔｏｋｅｎ（ＩＮＴ４） 条件処理ルーチンによって使用される３２ビットのデー
タ・オブジェクト。この「データ・オブジェクト」は、
修飾データにアクセスするために使用される。 Ｉｎｓｅｒｔ＿Ｓｅｑ＿Ｎｕｍ（ＩＮＴ４） 挿入順序番号（例えば、挿入１、挿入２）を含む４バイ
トの整数。これは、メッセージ原始ファイル内の挿入識
別子で指定されるものと対応する。 Ｉｎｓｅｒｔ＿Ｄａｔａ＿Ｔｏｋｅｎ（ＩＮＴ４） メッセージ・サービスによって使用される、３２ビット
のデータ・オブジェクト。この「データ・オブジェク
ト」は、メッセージ挿入データにアクセスするのに使用
される３２ビット項目である。（指される挿入データ
は、自己記述式でなければならない。）

【００２７】条件トークン・データ・タイプの利点に
は、次のことがある。 ・フィードバック・コードとして、後で処理するため
に、記憶またはログすることができ、特有のメッセージ
を提供する。 ・指示される重大度が、ビット操作機能のない言語にと
って容易にアクセス可能である。

【００２８】本発明の用途の１つは、ＣＥＥＣＴＯＫの
インスタンスで表される条件に関連する実行時メッセー
ジの生成である。

【００２９】メッセージ処理は、所与の適用業務によっ
て選択される条件処理モデルに密接に関連している。適
用業務プログラマが、サービスがどのように呼び出され
るかに応じて、２つの条件処理モデルのどちらかを選択
できる機能が提供される。これら２つの条件処理モデル
のそれぞれ及び条件を表す条件トークン（ＣＥＥＣＴＯ
Ｋ）を使ってメッセージ処理がどのように行われるかの
概要は次の通りである。 ・ＦＥＥＤＢＡＣＤ＿ＣＯＤＥが呼出し側に戻されるメ
ッセージ処理：適用業務がＦＥＥＤＢＡＣＫ＿ＣＯＤＥ
をサービスから受け取るようにコード化され、呼び出さ
れたサービスによって条件が検出される時は、次のよう
な事象シーケンスが発生し得る。 −サービスが、呼出し可能サービスで条件トークン（構
造ＣＥＥＣＴＯＫ）を構築する。 −サービスが、呼出し可能サービスの使用によって、必
要なメッセージ挿入データまたは修飾データあるいはそ
の両方をインスタンス特有情報（ＩＳＩ）域に入れる。 −検出された条件の重大度が重大（Sev＝4）である場
合、その条件が条件マネージャに信号で通知され、信号
で通知された条件に対して下記のように処理が続行す
る。 −条件の重大度が重大でない（Sev≠4）場合は、次のよ
うに処理が続行する。 −構造ＣＥＥＣＴＯＫが、ＦＥＥＤＢＡＣＫ＿ＣＯＤＥ
としてサービスの呼出し側に戻される。 −適用業務は、ＦＥＥＤＢＡＣＫ＿ＣＯＤＥを調べる
際、次のうちから選択できる。 ・それを無視して、処理を続行する。 ・後で処理するため、条件表現（ＣＥＥＣＴＯＫ）を記
憶する。 ・条件を条件マネージャに信号で通知する。 ・条件を適用業務コードと調和して処理する。とりわ
け、これは、構造ＣＥＥＣＴＯＫに関連するメッセージ
の処理を伴う。メッセージを処理する際、 適用業
務は次のうちから選択できる。 −呼出し可能サービスを用いて、表示のためにメッセー
ジを獲得しフォーマットし指名する。 −フォーマットされたメッセージを含めるのに十分なサ
イズの記憶域を獲得し、呼出し可能サイズを使ってメッ
セージを獲得し（挿入データで）フォーマットし記憶域
に記憶する。 −適用業務は、メッセージを処理するためにセーブし、
あるいは表示するために指名することができる。 ・ＣＡＬＬに対するＦＥＥＤＢＡＣＫ＿ＣＯＤＥのない
メッセージ処理。検出された条件はすべて条件マネージ
ャに信号で通知される。適用業務がすべての条件を条件
マネージャに信号で通知することを選択した時、 ある
いは検出された条件が重大な重大度のものである時、あ
るいは適用業務が 明示的に条件を信号で通知する時
は、メッセージ処理に関して次の事象シーケ ンスが発
生し得る。 −条件を検出したサービスが、その条件用の構造ＣＥＥ
ＣＴＯＫを構築する。 −サービスが、呼出し可能サービスを使って、必要なメ
ッセージ挿入データまたは修飾データあるいはその両方
をインスタンス特有情報域（ＩＳＩ）に入れる。 −検出された条件が条件マネージャに信号で通知され、
構造ＣＥＥＣＴＯＫが条件マネージャに渡される。 −条件マネージャが条件を、適用業務によって記述され
るように処理する。 −条件マネージャまたは条件処理ルーチンが、現条件を
表すメッセージを検索しフォーマットし、表示するため
に指名すると決定した場合、それが、呼出し可能サービ
スを使って行われる。 −条件の処理中に新しい条件が検出された場合、条件マ
ネージャが、新しいまたは格上げされた条件用のＩＳＩ
の新しいインスタンスを用いて、新しいＣＥＥＣＴＯＫ
を構築し、それによって入れ子式のまたは格上げされた
条件用のメッセージ挿入データの喪失を防止する。その
後、呼出し可能サービスを使ってメッセージ処理が実行
できる。

【００３０】同期条件用条件規約：ＣＥＥ呼出し可能サ
ービスは、条件アーキテクチャと次のように相互作用す
る。 １．ＣＥＥ呼出し可能サービスが、要求の成否に関する
情報をフィードバック・コード（構造ＣＥＥＣＴＯＫデ
ータ・タイプ）の形で報告する。この情報は、ＣＥＥ条
件マネージャまたはメッセージ・サービスが使用でき
る。 ２．フィードバック・コード域が、そのサービスに対す
る参照によって最終引数としてパスできる。これは、Ｃ
ＡＬＬステートメント上の任意選択の引数であり、その
有無が次のように処理に影響する。 ・重大条件（重大度＝４）は、必ず条件マネージャに直
接信号で通知される。 ・重大でない条件（重大度≦３）の場合、条件トークン
がフィードバック・コードとして呼出し側に戻すことが
できる。 ・フィードバック・コード域引数が渡されず、呼び出さ
れた機能の結果が完全な成功ではない（条件＝０）場
合、条件を信号で通知することにより、条件トークンが
ＣＥＥ条件マネージャに渡される。 注：任意選択引数法を用いるには、ＣＥＥによってイネ
ーブルされる言語が、 ＣＡＬＬステートメント上の
任意選択引数を許容しなければならない。言語 が任
意選択引数をサポートしない場合は、フィードバック・
コード引数は、 必ず呼出し側によってコード化され
る。 ３．条件アーキテクチャは、条件のタイプに応じて、構
造ＣＥＥＣＴＯＫのフォーマットの４つのケースをサポ
ートする。好ましい実施例では、次の２つのケースだけ
を定義する。 ａ．ケース１−サービス条件 ｂ．ケース２−クラス／原因条件 ４．４つのタイプの条件はすべて、次の特性をもつ。 ５．トークンの最初の４バイト（Condition_ID）がすべ
て（２進）０の場合、次の８バイトも０である。この条
件トークンは、完全な成功を表す。条件トークンの２つ
以上のケースに出会う可能性がある場合は、まずトーク
ンの最初の４バイトを成功かどうか検査すべきである。
トークンが成功した条件を示していない場合は、次にＣ
ａｓｅフィールドを検討すべきである。 ６．成功かどうかの検査を容易にできるように、呼出し
側は少なくとも最初の４バイトを２進数として定義すべ
きである。ただし、最初の４バイトだけを供給するのは
無効である。条件トークンを構造として定義できない言
語は、３成分１次元アレイを使用することもできる。

【００３１】ＣＯＢＯＬのＣａｓｅ１（ケース１）Ｃｏ
ｎｄｉｔｉｏｎ＿ＩＤの例 １ フィードバック Pic x(12) １ Feedback-Detailがフィードバックを定義し直す。 ２ 重大度 Comp Pic 999 ２ Message−Id Comp Pic 999

【００３２】ＦＯＲＴＲＡＮのＣａｓｅ１（ケース１）
Ｃｏｎｄｉｔｉｏｎ＿ＩＤの例 Integer*2 Feedback(6)、Severity、Message_Id Equivalence（Severity, Feedback(1)),(Message_Id, F
eedback(2))

【００３３】適用業務作成者インターフェース（ＡＷ
Ｉ） 呼出し可能サービスＣＥＥＳＧＬは、条件を条件マネー
ジャに提起する、すなわち信号で通知し、この条件のイ
ンスタンス用の修飾データを提供し、任意選択でこの条
件用のインスタンス特有情報を作成する。イネーブルさ
れた各信号通知（重大度が２以上の）条件が、エラー・
カウントを１ずつ増分する。エラーが（ＥＲＲＣＯＵＮ
Ｔ実行時オプションによって決定される）エラー・カウ
ント限界に等しいかまたはそれを越える場合は、条件マ
ネージャが、Termination-Imminentに信号で通知せず
に、エンクレーブを終了させる。格上げされた条件がエ
ラー・カウントを増分することはない。

【００３４】重大度０及び１の条件は、それが処理され
ず、かつ条件が提起されたとき、フィードバック・トー
クンがパスされなかった場合は無視される条件であっ
て、「安全な」条件と見なされる。

【００３５】ＣＥＥＳＧＬ外部呼出し可能サブルーチン
・インターフェースは、Ｃ構文を用いて、次のように定
義される。 void ＣＥＥＳＧＬ（cond_rep,[q_data_token],[fc]）; ＦＥＥＤ＿ＢＡＣＫ *cond_rep, ＩＮＴ４ *q_data_token, ＦＥＥＤ＿ＢＡＣＫ *fc; ただし、 cond_rep(input) 参照によってパスされる条件表現 q_data_token(input/optional) 所与の条件のインスタンスに関連する修飾データにアク
セスするのに使用するために、インスタンス特有情報に
入れられる３２ビットのデータ・オブジェクト。 fc(output/optional) 参照によってパスされ、ＣＥＥＳＧＬの成否を示す任意
選択条件。fc中で戻される条件は次の通りである。 CEE000 Severity=0 Msg_No=何でもよい Message=サービスが首尾よく完了。 CEE069 Severity=0 Msg_No=0201 Message=信号で通知された条件が処理されなかった。 CEE0EE Severity=3 Msg_No=0462 Message=入力条件トークンに関連するＩＳＩが見つから
なかった。 CEE0EB Severity=3 Msg_No=0459 Message=新しいＩＳＩを作成するのに使用可能な記憶域
が不十分 。 CEE0EC Severity=3 Msg_No=0460 Message=ＩＳＩリストが満杯で、新しいエントリが作成
できない 。 CEE0CE Severity=1 Msg_No=0398 Message=新しい入力で再開。 CEE0CF Severity=1 Msg_No=0399 Message=新しい出力で再開。

【００３６】使用上の注意 １．ＣＥＥＳＧＬサービスの呼出し側は、このサービス
に対する呼出しを行う前に、ＩＳＩを（提起されている
条件に関連するメッセージをフォーマットするのに必要
な）何らかの挿入データで充填しなければならない。呼
出し可能サービスからフイードバック・コードを受け取
るとき、ＭＩＢはすでに充填済みである。 ２．このサービスで提起される条件に対してイネーブル
が決定されている。 ３．q_data_tokenは、CCHによって照会されず、４バイ
ト内に含めることのできる任意の値をとることができ
る。 ４．条件が信号で通知されてＣＥＥＳＧＬへの呼出しに
対してq_data_tokenの値を渡し、q_data_token値がすで
に関連するＩＳＩ内に存在する場合は、ＩＳＩ内のq_da
ta_tokenは重ね書きされる。 ５．条件ＣＥＥＯＣＥ及びＣＥＥＯＣＦは、q_data_tok
enによって指示されるデータと一緒に、条件に出会った
ルーチンによってフィックスアップまたは再開あるいは
その両方を行うために使用される。

【００３７】ＣＥＥ条件表現は、次のＡＷＩ呼出し可能
サービスを提供する。 ・ＣＥＥＮＣＯＤ−条件トークン・データ・タイプの１
インスタンスを構築する。 ・ＣＥＥＤＣＯＤ−条件トークン・データ・タイプをそ
の構成部分に分解する。

【００３８】ＣＥＥＮＣＯＤ−条件トークン構築。 void ＣＥＥＮＣＯＤ（C-1,C-2,Case,Severity,Contro
l,Facility_ID, Cond_Token,[fc]); ＩＮＴ２ *C_1; ＩＮＴ２ *C_2; ＩＮＴ２ *Case; ＩＮＴ２ *Severity; ＩＮＴ２ *Control, char (*Facility_ID)[3]; ＩＮＴ２ *Control, struct ＣＥＥＣＴＯＫ *Cond_Token; ＦＥＥＤ＿ＢＡＣＫ *fc; ただし、 Ｃ＿１（入力） Condition_IDの最初の２バイトの値を表す２バイトの２
進整数。ケース１の場合、これは重大度であり、ケース
２の場合、Class_Codeである。 Ｃ＿２（入力） Condition_IDの次の２バイトの値を表す２バイトの２進
整数。ケース１の場合、これはメッセージ番号であり、
ケース２の場合、Cause_Codeである。 Ｃａｓｅ（入力） トークンのCondition_ID部分のフォーマットを定義する
２バイトの２進整数。値１はケース１の条件を識別し、
２の値はケース２の条件を識別する。値０と３は留保さ
れている。 Ｓｅｖｅｒｉｔｙ（入力） 条件の重大度を示す２バイトの２進整数。ケース１の条
件では、このフィールドの値はCondition_IDにおける値
と同じである。ケース１及びケース２の条件では、この
フィールドは必ず条件の重大度をテストするのに使用で
きる。 Ｃｏｎｔｒｏｌ（入力） 前に定義した条件の制御情報を含む２バイトの２進数。 Ｆａｃｉｌｉｔｙ＿ＩＤ（入力） この条件またはフィードバック情報を生成する製品を識
別する、３つの英数字を含む３文字フィールド。ケース
２の条件では、Condition_IDが２つのメッセージを示す
可能性があり、両方のメッセージが挿入データを必要と
する可能性があり、呼出し側が、第１メッセージ用の挿
入データと、それに続いて第２のメッセージに必要なデ
ータとを挿入順に記憶域にロードする。メッセージ・サ
ービスはこれらを１対のメッセージとして扱い、両方の
メッセージに同じメッセージ挿入ブロック（ＣＥＥＭＩ
Ｂ）を使用する。 Ｃｏｎｄ＿Ｔｏｋｅｎ（出力） 組み立てられた条件またはフィードバック情報の８バイ
ト表現。 ｆｃ（出力／任意） 参照によってパスされる任意選択の８バイト・フィード
バック・コード。引数として指定される場合、フィード
バック情報（条件トークン）が呼出し側ルーチンに戻さ
れる。省略され、要求された動作が首尾よく完了しなか
った場合は、 その条件が条件マネージャに信号で通知
される。次の記号条件がこのサービスから得られる。 CEE000 Severity=0 Msg_No=何でもよい Message=サービスが首尾よく完了。 CEE0CH Severity=3 Msg_No=0401 Message=無効なケース・コードが見つかった。 CEE0CJ Severity=3 Msg_No=0403 Message=無効な重大度コードが見つかった。 CEE0CI Severity=3 Msg_No=0402 Message=無効な制御コードが見つかった。 CEE0E4 Severity=3 Msg_No=0452 Message=無効なファシリティ・コードが見つかった。

【００３９】ＣＥＥＤＣＯＤ−条件トークン分解。 void ＣＥＥＤＣＯＤ（Cond_Token,C-1,C-2,Case,Sever
ity,Control,Facility_ID,[fc]); ＣＥＥＣＴＯＫ *Cond_Token, ＩＮＴ２ *C_1, ＩＮＴ２ *C_2, ＩＮＴ２ *Case, ＩＮＴ２ *Sererity, ＩＮＴ２ *Control, ＣＨＡＲ３ *Facility_ID, ＦＥＥＤ＿ＢＡＣＫ *fc; ただし、 Ｃｏｎｄ＿Ｔｏｋｅｎ（入力） 現条件またはフィードバック情報を表す８バイトの条件
トークン（ＣＥＥＣＴＯＫ） Ｃ＿１（出力） Condition_IDの最初の２バイトの値を表す２バイトの２
進整数。 Ｃ＿２（出力） Condition_IDの次の２バイトの値を表す２バイトの２進
整数。 Ｃａｓｅ（出力） トークンのCondition_ID部分のフォーマットを定義する
２バイトの２進整数フィールド。１の値はケース１の条
件を識別し、２の値はケース２の条件を識別する。値０
と３は留保されている。 Ｓｅｖｅｒｉｔｙ（出力） 条件の重大度を表す２バイトの２進整数。 Ｃｏｎｔｒｏｌ（出力） 条件の状態の態様を記述するフラグを含む、１６ビット
のフィールド。 Ｆａｃｉｌｉｔｙ＿ＩＤ（出力） 条件またはフィードバック情報を生成する製品を識別す
る、３つの英数字を含む３文字フィールド。 ｆｃ（出力／任意選択） 参照によってパスされる任意選択の８バイト・フィード
バック・コード。引数として指定される場合、フィード
バック情報（条件トークン）が呼出し側ルーチンに戻さ
れる。引数として指定されず、要求された動作が首尾よ
く完了しなかった場合は、その条件が条件マネージャに
信号で通知される。次の記号条件がこのサービスから得
られる。 CEE000 Severity=0 Msg_No=何でもよい Message=サービスが首尾よく完了。 CEE036 Severity=3 Msg_No=0102 Message=無効な条件トークンがパスされた。

【００４０】コンパイラ作成者インターフェース（ＣＷ
Ｉ） ＣＥＥは、ファシリティＩＤ及びメッセージ番号が与え
られると条件トークンを作成する、ＩＢＭシステム／３
７０特有のＣＷＩを提供する。このサービスの名前はＣ
ＥＥＧＥＴＦＢである。

【００４１】ＣＥＥＧＥＴＦＢ−ファシリティＩＤ及び
メッセージ番号が与えられると、条件トークンを作成す
る。ＣＥＥＧＥＴＦＢは、ファシリティＩＤ及びメッセ
ージ番号が与えられると、ケース１の条件トークンを作
成する。重大度は、そのメッセージ番号を含む適当なメ
ッセージ・ファイルから検索される。 void ＣＥＥＧＥＴＦＢ（facility_id,message_no,cond
_token[fc]); ＣＨＡＲ３ *facility_id, ＩＮＴ４ *message_no ＣＥＥＣＴＯＫ *cond_token, ＦＥＥＤ＿ＢＡＣＫ *fc; ただし、 Ｃｏｎｄ＿Ｔｏｋｅｎ（出力） メッセージ定義を含む適当なファイルから得られるfaci
lity_id、message_no、 Severityから作成される、ケ
ース１のスタイルの８バイト条件トークン（ＣＥ ＥＣ
ＴＯＫ） ｍｅｓｓａｇｅ＿ｎｏ（入力） 結果として得られる条件トークン用のメッセージ番号を
表す４バイトの２進整数。 ｆａｃｉｌｉｔｙ＿ｉｄ（入力） 結果として得られる条件トークンに入れられる３文字の
ファシリティＩＤ。メッセージ定義及びメッセージ・テ
キストを含むファイルを決定するのに使用される。 ｆｃ（出力／任意選択） 参照によってパスされる任意選択の８バイト・フィード
バック・コード。引数として指定される場合、フィード
バック情報（条件トークン）が呼出し側ルーチンに戻さ
れる。引数として指定されておらず、要求された動作が
首尾よく完了しなかった場合は、その条件が条件マネー
ジャに信号で通知される。次の記号条件がこのサービス
から得られる。 CEE000 Severity=0 Msg_No=何でもよい Message=サービスが首尾よく完了。 CEE0EA Severity=3 Msg_No=0458 Message=メッセージ格納場所が見つからない。 CEE3CT Severity=3 Msg_No=3485 Message=指定されたライブラリ内にmessage_noが見つか
らなかった。 CEE0CJ Severity=3 Msg_No=0403 Message=無効な重大度コードが見つかった。

【００４２】共通条件処理（ＣＣＨ）の記述 本発明を完全に実施するために、１組のコンパイラ、条
件マネージャを含む共通条件処理ルーチン（ＣＣＨ）、
及び１組の呼出し可能サービスが作成される。ＣＣＨ
は、複数の高水準言語（ＨＬＬ）で書かれている可能性
のある適用業務プログラム用のより大きな共通実行時環
境の一部分である。図１は、コンピュータ・システム・
ソフトウェア（またはファームウェア）階層におけるＣ
ＣＨの大域的位置を示す。コンパイラ自体及びコンパイ
ラによって適用業務プログラム用に生成されたコード
が、ＣＣＨとインターフェースする。システムの最低レ
ベルは、ハードウェア条件検出手段１０６及びオペレー
ティング・システム１０５である。本明細書では、オペ
レーティング・システムは、ＩＢＭのＭＶＳオペレーテ
ィング・システム内ではサブシステムと呼ばれているプ
ログラムを含む。ＣＣＨ１０４は、オペレーティング・
システム１０５と適用業務プログラム１０１〜１０３を
インターフェースする。この完全な実行時環境を共通実
行環境（ＣＥＥ）と呼ぶ。ＣＥＥは、問題プログラム状
態ではオペレーティング・システムから分離したプログ
ラムとして走行するが、先に指摘したように、本質的な
修正の必要なく、オペレーティング・システムの一部と
して含めることも容易にできる。条件モデルが定義され
る。条件マネージャが条件モデルを実施する。

【００４３】当技術分野では通常のように、ＣＥＥ内の
呼出し可能ルーチンには、ＣＥＥＨＤＬＲなどのラベル
名が割り当てられる。コンパイラ及び他のプログラム
は、その原始言語にかかわらず、ＣＥＥによって提供さ
れるサービスに連係し、そのサービスを使用するように
作成することができる。図２に、ＣＣＨ自体１１０及び
適用業務プログラム１１１が、標準的なプログラミング
技法を用いて、入口または外部ラベル宣言と共に作成さ
れることを示す。これらの外部参照は、組込みオペレー
ティグ・システム手段または標準的連係編集プログラム
１１２の使用によって解決される。ＣＣＨは、通常、シ
ステム・ソフトウェア作成者によって連係可能な目的コ
ードにコンパイルされ、目的コードだけとして、適用業
務作成者またはコンパイラ作成者に売り渡される。した
がって、典型的な場合、ユーザは段階１１１及び１１２
を実行し、段階１１０は予めＣＣＨ作成者によって実行
済みである。オペレーティング・システムがＣＣＨに類
似するコードをロードし実行する方式は色々ある。例え
ば、ＩＢＭのＭＶＳオペレーティング・システムは、連
係パック域（ＬＰＡ）を使用し、必要な時だけ、コード
をＣＣＨからユーザのアドレス空間に動的にコピーす
る。連係に使用される特定のオペレーティング・システ
ムによって提供されるどの機構もうまく働く。

【００４４】ＣＣＨは、条件マネージャとインターフェ
ースするのに必要なプロトコルに従う、高水準言語コン
パイラ、デバッガ、アセンブラ言語ユーザ・ルーチン用
のＣＥＥ実行時環境で、条件を処理する。適用業務、言
語ライブラリ・ルーチン、及びデバッガが、条件が発生
する時に条件マネージャが呼び込むことのできる出口を
確立する。これらの出口は従属条件処理ルーチンと呼ば
れる。

【００４５】本明細書における条件マネージャの議論で
は、特に断らない限り、ＴＲＡＰ（ＯＮ）のＩＢＭオペ
レーティング・システム実行時オプション設定を仮定す
る。

【００４６】条件マネージャは、次の従属条件処理ルー
チンのいずれをもサポートする。 ・言語ライブラリ内の条件処理ルーチン。 ・適用業務の一部である条件処理ルーチン。 ・デバッグ・システムの一部である条件処理ルーチン。

【００４７】条件マネージャによって提供される機能を
以下にリストする。一般に、条件マネージャは、リスト
されている段階をすべて実行する。条件に応じて、いく
つかの段階が省略されたり、繰り返されたりすることが
ある。 ・システム割込みのインターセプト システム割込みは、オペレーティング・システム特有の
出口及びインターフェースを用いて、条件マネージャに
よってインターセプトされる。プログラム例外、システ
ムＡＢＥＮＤ、及びソフトウェアによって検出された条
件は、すべてマネージャによって監視される。 ・条件に関する情報の収集 条件マネージャは、条件に関する情報を収集する。収集
された情報は、条件の記録である。 ・条件（割込み及び例外）のスクリーニング。 条件マネージャは、言語がそう要求する場合、条件を無
視する（それが発生した場所の後に続く命令から実行を
再開する）。言語によっては、その言語の意味論のため
に、割込みまたは例外を扱わないものもある。 ・従属条件処理ルーチンの呼出し 条件マネージャは、従属条件処理ルーチンとして確立さ
れているルーチンを呼び出す。従属条件処理ルーチン
は、取るべき処置を示すリターン・コードを条件マネー
ジャに提供する。 ・訂正不能な条件での終了 従属条件処理ルーチンがエラーを許容または訂正できな
い場合、条件マネージャは条件の重大度に基づいて、次
のいずれかを実行する。 −実行を再開する（「安全な」条件のみ） −スレッドを終了する（その他の全条件）

【００４８】条件マネージャによって提供されるユーザ
外部機構は、各言語製品で供給される従来の条件処理ユ
ーザ外部機構にとって代わることはない。このため、未
修正の適用業務が以前と同様に走行することが可能とな
る。ＣＣＨは、製品のための共通の条件処理ベースを提
供するように意図されている。ＣＣＨによって提供され
る条件処理プリミティブを用いると、各高水準言語が、
それ自体の条件処理の意味論的処置を実施できる。

【００４９】言語のＣＣＨによってイネーブルされたバ
ージョンへの移行は、単一言語ユーザには見えないが、
ＣＣＨの下で使用可能なより強力な条件処理が利用でき
るように、単一言語ユーザが修正を望むことがある。た
だし、複数言語で書かれた適用業務はＣＣＨの下で異な
る挙動を示す可能性がある。

【００５０】基本的条件マネージャは次の特徴をもつ。 ・適当な条件処理動作が、この条件を引き起こした呼込
み（呼出しレベル）の特性に基づいて決定される。 ・条件処理ルーチンが条件を格上げする、すなわち異な
る意味をもつ新しい条件に変換するための手段が提供さ
れる。これは、ＰＬ／Ｉがスタック・フレーム０におけ
る未処理の条件をＥＲＲＯＲ（エラー）に格上げし、処
理カーソルを再開カーソルにリセットする場合、処理ル
ーチンが元の条件の原因を知っているかいないかに基づ
く可能性がある。この場合、この新しい条件が条件処理
ルーチンに提示されることが暗黙のうちに了解されてい
る。処理順序を修正する下記の能力が与えられていると
して、どの処理ルーチンに新しい条件が提示されるかを
定義する際、若干の裁量の余地がある。 ・呼込みに対する条件処理を呼出し側の呼込み用の処理
ルーチンに回復機能委任する（据置かせる）手段が提供
される。このプロセスは、スレッド内の複数の呼込みに
よって繰り返すことができる。 ・条件処理ルーチンは、ＣＥＥＸＴＤを呼び出すことに
より、スレッドの終了を要求できる。 ・条件処理ルーチンが条件を引き起こすことがあり、そ
のための処理ルーチンが定義されている。 ・呼込み用条件処理は、論理的に、処理活動と脱出活動
に分けられる。これら２つの活動は異なる時に起こり得
る。ＨＬＬ終了出口ルーチンは、スタック・フレームと
関連づけられ、したがって、処理が時機尚早に、条件処
理中にあるいはブロック処理からのＧＯＴＯ中に終了す
る場合には、そのスタック・フレームの代りに処理を実
行することができる。 ・ＨＬＬ特有の条件処理ルーチンは、空のこともある
が、各スタック・フレームと関連づけられ、言語設計者
によって供給される。これらの処理ルーチンは、目的コ
ードの形で供給され、関連するコンパイラを用いて作成
されたユーザ・プログラムの実行に繰り返し使用できる
ように、ディスク、テープまたは他の持久メモリに記憶
される。独自の各コンパイラは、それ自体の言語特有の
処理ルーチンを有する。各処理ルーチンは、下記のアー
キテクチャに合致する構造をもたなければならず、ＣＣ
ＨのResume、Percolate、Promote機能ならびにＣＣＨの
その他の機能も利用する。 ・ユーザの条件処理ルーチン用の待ち行列が、各スタッ
ク・フレームごとに設けられる。この待ち行列には、Ｃ
ＣＨ呼出し可能サービスＣＥＥＨＤＬＲの使用によっ
て、条件処理ルーチンの実行の対象となるスタック・フ
レーム内からエントリが挿入される。条件処理ルーチン
は、ＣＥＥＨＤＬＲを呼び出すことにより除去される。
この待ち行列は、空のことがある。 ・スタック・フレームから脱出する際、スタック・フレ
ームに関連するすべての条件処理ルーチンが暗黙のうち
に取り消される。 ・高水準言語またはユーザ条件処理ルーチンによって処
理されないすべての条件に対して定義された省略時条件
処理活動が存在する。どんな省略時指定が選択されるか
は重要ではないが、これらの省略時指定がコンパイラ及
び適用業務作成者にわかっており、それらの省略時指定
がいつ所望の結果を達成するか、及び特別の処理ルーチ
ンがいつ必要とされるかについて判断が下せるようにす
る必要がある。省略時指定を構成する１つの論理的方法
は、条件マネージャを安全条件で再開させ、他のすべて
の条件でスレッドを終了するものである。

【００５１】「２カーソル・モデル」： 本発明の実行
環境条件処理モデルは、２カーソル・モデルで説明する
のが最もわかりやすい。このモデルでは、適用業務の呼
込みプロシージャーが後入れ先出し（ＬＩＦＯ）スタッ
クにあり、２つのポインタ（すなわち「カーソル」）が
スタックの様々な段を指すものと考えている。

【００５２】２カーソル・モデルは、ある条件処理情報
が論理的に各スタック・フレームと関連づけられている
と仮定する。２カーソル・モデルでは、スタック中への
２つのポインタが（少なくとも概念的に）条件処理の状
態を追跡するのに用いられる。 ・処理カーソルは、次にその条件処理活動が実行され
る、スタック・フレーム内の特定の処理ルーチンを指
す。最初、処理カーソルは、例外が発生した、あるいは
そこから検出された条件が信号で通知された、スタック
・フレーム内の最初の処理ルーチンを指す。条件処理が
進行するにつれて、処理カーソルは、フレーム内の後の
処理ルーチンに、あるいは呼出しフレーム中の最初の処
理ルーチンに移動する。条件処理ルーチンは、処理カー
ソルを順序が次でない処理ルーチンに設定する若干の裁
量の余地がある。 ・再開カーソルは、実行を再開するのが適当であると条
件処理ルーチンが判断した場合に実行が再開される、ス
タック・フレームとブロック内の命令とを指す。 再開
カーソルはまた、その命令用のプラットフォーム特有の
機械状態も含んで いる。最初、再開カーソルは、例外
を引き起こした機械命令またはその後、あ るいはその
条件を信号で通知せたＣＥＥＳＧＬへの呼出しの後の位
置にくる。 その後、条件処理ルーチンは、再開カーソ
ルを以前のスタック・フレーム中の ラベルまたは復帰
点に設定できる。

【００５３】次に、ｒｅｓｕｍｅ（再開）、ｐｅｒｃｏ
ｌａｔｅ（回復機能委任）、ｐｒｏｍｏｔｅ（格上げ）
の各動作をこれら２つのカーソルに関して定義する。 ｒｅｓｕｍｅ（再開） 条件処理を終了し、制御を再開カーソルによって指定さ
れる命令及びスタック・フレームに移す。従属条件処理
ルーチンは、ＣＥＥＭＲＣＲ呼出し可能サービスを使っ
て、再開カーソルを修正できる。 ｐｅｒｃｏｌａｔｅ（回復機能委任） 条件が変化しない場合に、条件処理ルーチンを据え置
く。条件処理ルーチンは、条件処理を続行するため、処
理カーソルを次の２つの場所のどちらか一方に設定する
ことができる。 １．現スタック・フレーム用の呼込み待ち行列内の次の
処理ルーチン ２．次の（呼出し側）スタック・フレーム用の待ち行列
内の最初の条件処理ルーチン ｐｒｏｍｏｔｅ（格上げ） 処理カーソルを次の３つの場所のうちの１つに設定する
ことによって、条件を別の条件に変換し、条件処理を続
行する。 １．現スタック・フレーム用の呼込み待ち行列内の次の
処理ルーチン ２．次の（呼出し側）スタック・フレーム用の待ち行列
内の最初の条件処理ルーチン ３．現スタック・フレーム用の最初の処理ルーチン（そ
れらの処理ルーチンを再駆動する）

【００５４】スタック・フレームに関連する条件処理情
報は、論理的に、処理プロセス全体のいくつかの異なる
段階用の処理ルーチンを含んでいる。処理ルーチンとし
ては、次のものが含まれる。 ・言語特有の「イネーブル」処理ルーチン（システム特
有の「イネーブル」処理ルーチンが存在することがある
が、それはこのモデルには見えないことに留意された
い）。１つの言語特有のイネーブル処理ルーチンが、空
のことがあるが、 各スタック・フレームに関連づけら
れている。このルーチンには、高水準言語 条件処理ル
ーチン・インターフェースを介して入る。好ましい実施
例では、イ ネーブル機能は、条件処理を提供するのと
同じルーチンによって提供される。 ・デバッガ条件処理ルーチン。この処理ルーチンに入る
のは、デバッガが活動状態であるか、あるいは条件の重
大度がテスト・レベルに合致するかまたはそれを越える
場合である。 ・ＣＣＨユーザ条件処理ルーチン。この条件処理ルーチ
ンはＣＣＨＤＬＲインターフェースを介して登録され
る。ユーザ条件処理ルーチンの待ち行列は、各スタック
・フレームに関連づけられている。この待ち行列は、空
のこともある。このルーチンには、ユーザ条件処理ルー
チン・インターフェースを介して入る。 これは、ＣＥ
ＥＨＤＬＵインターフェースを介して登録されていない
こともあ る。 ・高水準言語特有の処理ルーチン。この処理ルーチンは
ＰＬ／Ｉ「ＯＮ−条件」処理ルーチンなど言語特有のユ
ーザ処理ルーチンにサービスすることができる。 ま
た、高水準言語またはユーザ処理ルーチンが条件を処理
できない場合に、何 らかの省略時処置をとることもで
きる。１つの高水準言語特有の条件処理ルー チンは、
空のこともあるが、各スタック・フレームに関連づけら
れている。未 確認条件は、変更なしに次の条件処理ル
ーチンに「パス」しなければならない。 このルーチン
には、高水準言語条件処理ルーチン・インターフェース
を介して 入る。 ・終了出口ルーチン。このルーチンは、呼込みから異常
脱出する時にとるべき処置を指定する。現言語は明示的
終了出口ルーチンをサポートしないので、これは言語に
よって供給されるルーチンとＣＣＨによって登録された
ルーチンである。

【００５５】巻戻しは、指定されたスタック・フレーム
用の登録されたすべての終了出口ルーチンを呼び出し、
次いでスタック・フレームに非活動状態のマークをつけ
る動作である。

【００５６】従来の条件処理方式と比較して、上記のリ
ストについて留意すべきいくつかの重要な事柄がある。
まず、イネーブル処理ルーチンが概念上独立の範疇とし
て分離されていたことに留意されたい。前に触れたよう
に、これはシステム間での条件処理の一貫性を確保する
のに必要である。次に、ＣＣＨユーザ処理ルーチンの範
疇が加えられた。これは、すべての言語ユーザに条件処
理へのアクセス権を与え、既存の条件モデルをもつ言語
のユーザが本発明の実行環境条件モデルの全能力及び機
能にアクセスできるようにする。

【００５７】しかし、上記リストの重要な一態様は、終
了脱出処理を別個の活動として分離することである。再
開カーソルとあいまって、終了脱出処理を残りの条件処
理からこう分離することは、本発明の一部である。

【００５８】２カーソル・モデルの簡単な実例： ２カ
ーソル・モデルを、その最も簡単な形で、図３の例に関
して説明する。スタック２０１は、データをコンピュー
タのメモリに時間順に記憶する、一般に使用されている
方法である。スタックの下端は、図に示すように、最も
古いデータを含み、最新のデータは上端にある。このス
タックは、フレーム２０２〜２０５から構成されてい
る。各フレームは、レジスタ値、命令ポインタ及びフラ
グを含むデータ・ブロックを含んでいる。例えば、図４
は、プログラムＡのスタック・フレームに、ユーザ条件
処理ルーチン２１０と高言語条件処理ルーチンの２つの
条件処理ルーチンが関連づけられていることを示してい
る。これらの処理ルーチンは物理的にはスタック上にな
いが、プログラムＡがユーザ処理ルーチンをＣＣＨで登
録し、ＨＬＬ処理ルーチンはプログラムが開始された時
に自動的に登録されたので、スタック・フレームと関連
づけられている。したがって、ＣＣＨと相互動作するプ
ログラムは、プログラムが最初に初期設定される時、及
び異なる言語で書かれたサブルーチンを呼び出す時に、
ＣＥＥを通過しなければならない。これをどう行うか
は、本発明を実施するのに重要ではないが、その条件処
理が正確に機能すべき場合、各スタック・フレーム用の
固有のＨＬＬ処理ルーチンに関する情報をＣＣＨにとっ
て利用可能にすべきである。 １．プログラムＡの実行中にある条件が発生すると仮定
する。条件マネージャがオペレーティング・システムか
らシステムの制御を得る。再開カーソル２０８が、プロ
グラムＡのスタック・フレーム２０５を指すように設定
される。プログラムＡが、その条件が発生した呼込み、
すなわち「所有」スタック・フレームである。再開カー
ソルに関連する「命令アドレス・レジスタ」値は、条件
を引き起こした命令の後に続く命令あるいは条件を引き
起こした命令を論理的に指す。条件の「環境」も再生カ
ーソルと共にセーブされる。 ２．処理カーソル２０９が指す呼込みは、「処理」呼込
みと見なされ、どんな条件処理ルーチンが指定されてい
るかを決定するためにそれが調べられる（この議論で、
条件の発生時に存在するスタック・フレームを参照する
ために、「処理呼込み」「呼び出された呼込み」「呼出
し側呼込み」の用語を使用することに留意されたい。条
件処理ルーチン自体の呼込みは参照しない）。 ３．条件が「新鮮な」（すなわち、現呼込みに由来す
る）ものである場合は、高水準言語条件処理ルーチン２
１１がイネーブルのために呼び出される（理由コード"
２"を使って、呼出しが、以下に見られるように、イネ
ーブル検査用だけのものであることを示す）。その言語
がその条件を「問題でない」と認める場合、ルーチンが
再開される。 ４．デバッガが活動状態であるか、あるいは条件がテス
ト・レベルに合致するかまたはそれを越える場合には、
デバッガが呼び出される。 ５．呼込みに関連するユーザ条件処理ルーチンが、この
スタック・フレームに関して、その１つがこのフレーム
を処理するまで、あるいはすべてが巡回されるまで、後
入れ先出し（ＬＩＦＯ）順に実行される。条件マネージ
ャはまずユーザ条件処理ルーチン２１０を実行する。ユ
ーザ処理ルーチンが存在しない場合、あるいはユーザ処
理ルーチンが条件を処理しない場合は、高水準言語（Ｈ
ＬＬ）条件処理ルーチン２１１が実行される。理由コー
ド"１"が、その呼出しが実際の条件処理のためのもので
あることを示すために使用される。 ６．処理ルーチンのいずれかが、以下に定義されるよう
な再開コードを戻すことによって、条件が処理されたと
見なすべきことを条件処理ルーチンに示すことがある。
条件が処理されていない場合、処理ルーチンは、その条
件が回復機能委任されるべきである（すなわち、同じ条
件が異なる条件処理ルーチンに提示されるべきであ
る）、あるいは条件が格上げされるべきである（すなわ
ち、旧条件の代りに新しい条件を異なる条件処理ルーチ
ンに提示すべきである）と指定することができる。 ７．条件が回復機能委任または格上げされた場合、処理
ルーチンはまた、次に呼び込む処理ルーチンを決定する
ために処理カーソルをどのように修正すべきかを（明示
的に定義された限界内で）指定することもできる。処理
カーソルを、それがスタック中で再開カーソルよりも最
近のスタック・フレームを指すように絶えず修正するこ
とは正しくない。省略時動作は、処理カーソルを呼出し
側呼込み（複数個が定義されている場合には、現呼込み
内の次の処理ルーチン）へと下に移動することである。
処理カーソルは条件マネージャによってだけ移動され
る。 ８．上記のいずれの場合（再開、回復機能委任または格
上げ）でも、条件処理ルーチンはまた、再開カーソルを
どう修正すべきかを指定することもできる。再開カーソ
ルの修正は、「下方」移動（すなわち呼び出される呼込
みから呼出し側呼込みへ）だけに限定され、このような
修正は常に、カーソルが通過する呼込み用の終了出口処
理ルーチンの実行を強制する。再開カーソルを呼込みを
通り過ぎて移動すると、関連する条件処理ルーチンが登
録解除される（これらの動作は、実際には、条件処理ル
ーチンが条件マネージャに戻った後にだけ行われる）。
再開カーソルを０次スタック・フレームを指すように修
正することは許されない。 ９．再開カーソルを修正する際に、処理ルーチンはま
た、再開カーソルに関連する（次の命令アドレスを含む
が、それだけには限定されない）機械状態も修正するこ
ともできる。１つの共通修正は、再開カーソルで表され
る呼込み中の特定の場所（ラベル）で実行を再開させる
ものであろう。ただし、不履行命令を再試行するように
再開カーソルを修正することは、ＩＢＭのＯＳ／２オペ
レーティング・システムでは定義されていない。大部分
の場合、これは不可能である。実際に再開カーソルが示
す呼込み以外のどこかで実行を再開するように機械状態
を修正するのは（必ずしも検出されるエラーではない
が）エラーである。

【００５９】通常条件処理シーケンスは、後のスタック
・フレームからより前のスタック・フレームへとスタッ
クを横断する。スタックがスタック・フレーム０まで横
断された時までに条件が処理されていない場合、条件処
理ルーチンは、０次スタック・フレーム用のＨＬＬ条件
処理ルーチンを呼び出す。処理がスタック・フレーム０
用のものであるという特定の指示が存在する。スタック
・フレーム０の処理後も条件が処理されていない場合に
は、条件マネージャの省略時動作が適用される。省略時
動作は、条件の重大度と、使用可能な追加情報に依存し
ている。いずれかの条件処理ルーチンがスレッドでなく
エンクレーブを終了させるのを望む場合は、ＣＥＥＴＲ
ＥＮを呼び出さなければならない。

【００６０】以下に、この１組の例を通じて使用される
いくつかの概念を提示する。ルーチンの入口で新しいス
タック・フレームが割り当てられる時、ＨＬＬ条件処理
ルーチンが論理的にスタック・フレームに関連づけられ
る。ユーザもまた、任意選択で、そのスタック・フレー
ム用の１つまたは複数の追加の条件処理ルーチンを確立
することができる。ルーチンがその呼出し側に戻り、ス
タック・フレームが割当て解除される時、ＨＬＬ条件処
理ルーチン及びユーザが確立する条件処理ルーチン（も
しあれば）が確立解除される。

【００６１】０次スタック・フレームとは、第１ルーチ
ン用のスタック・フレームに先行するスタック・フレー
ムである。０次スタック・フレームに関連する条件処理
の意味論は、モデルによって定義される省略時動作であ
る。

【００６２】呼出しシーケンスがＰｒｏｃ１呼出しＰｒ
ｏｃ２呼出しＰｒｏｃ３であり、ルーチンＰｒｏｃ３の
実行中にある条件が発生する場合、Ｐｒｏｃ３のスタッ
クは所有スタック・フレームと呼ばれる。すなわち、Ｐ
ｒｏｃ３のスタック・フレームがその条件を所有する。

【００６３】条件が発生する時、条件マネージャ用にあ
るスタック・フレームが割り当てられる。その条件をも
っていたスタック・フレーム用の条件処理ルーチンが、
イネーブル段階用に呼び出される。スタック・フレーム
が有効だという応答の場合、条件マネージャは、所有ス
タック・フレームから始めて、スタック・フレームを１
つずつ０次スタック・フレームに向かって移動して、条
件が（何らかの形で）処理されるかあるいは現呼込みス
タックがなくなるまで、各スタック・フレームを巡回す
る。巡回された各スタック・フレームごとに、そのスタ
ック・フレームに関連するＨＬＬ条件処理ルーチンが呼
び込まれ、高水準言語エラーの意味論が実施される可能
性がある。（呼出し可能サービスを介して確立されるユ
ーザによって定義される条件処理ルーチンについては、
後で論じるが、これはＨＬＬ条件処理ルーチンより前に
実行される。ただし、これらは依然としてスタック・フ
レームに基づくモデルに従う）。ポインタである処理カ
ーソルは、現に制御されている条件処理ルーチンを有す
るスタック・フレームか、あるいはこれから制御を得よ
うとしているスタック・フレームを識別する。

【００６４】各条件処理ルーチンは、次の応答のうちの
一つで条件に応答することができる。 ・ｈａｎｄｌｅｄ（処理済み）（再開） ・ｐｅｒｃｏｌａｔｅ（回復機能委任） ・ｐｒｏｍｏｔｅ（格上げ）

【００６５】定義されているモデルの意味論は、１パス
・スタック・フレームに基づく条件処理ルーチンのそれ
である。これは、適用業務によって作成された各スタッ
ク・フレームが所与の条件で一度だけ巡回されることを
意味する。各スタック・フレームに、条件に反応する機
会が１回与えられる。各スタック・フレームは、条件を
処理し、条件を回復機能委任し、あるいは条件を格上げ
することができる。

【００６６】１パス・モデルに対する例外は、ＰＬ／Ｉ
が所有するスタック・フレームである。条件マネージャ
は、条件がスタック・フレーム０におけるＰＬ／Ｉ条件
処理ルーチンに到達した場合、ＰＬ／Ｉコードを含むす
べてのスタック・フレームを再駆動する。

【００６７】適用業務によって処理されない（すなわち
スタック・フレーム０まで回復機能委任される）どんな
条件も、定義された省略時動作の対象となる。

【００６８】図５を用いて、詳細な一般例について論じ
る。この例では、次のような仮定を行う。 １．Ｐｒｏｃ１が「主」プロシージャであってＰｒｏｃ
２を呼び出し、Ｐｒｏｃ２はＰｒｏｃ３を呼び出す。 ２．再開カーソルは移動されない。 ３．現スタック・フレームは、現在動作中のプロシージ
ャに関連するスタック・フレームである。 ４．「所有」スタック・フレームは、その条件が発生し
たスタック・フレームである。 ５．Ｈａｎｄｌｅ１及びＲｅｓｕｍｅ１は第１条件に適
用され、Ｈａｎｄｌｅ２及びＲｅｓｕｍｅ２は第２条件
に属する。 ６．あらゆる活動状態の条件について条件マネージャ・
スタック・フレームがスタック上に存在する。 ７．すべてのユーザ条件処理ルーチンが、それらを導入
するルーチンと同じ言語で書かれている。これは、必要
条件でなく、この例で便宜上行われている。 ８．開始スタックは次のように現れる。ｕｓｅｒ１，ｕ
ｓｅｒ２，ｕｓｅｒ３，ｕｓｅｒ４がユーザによって導
入された条件処理ルーチンである場合、ＣＭ１は条件マ
ネージャのＨＬＬ条件処理ルーチンであり、Ｃ言語処理
ルーチン、ＦＯＲＴＲＡＮ処理ルーチン、ＰＬ／Ｉ処理
ルーチンがそれぞれ当該のＨＬＬ条件処理ルーチンであ
る。 ９．条件は、Ｐｒｏｃ３内で発生したか、あるいはＰｒ
ｏｃ３によって信号で通知された。条件マネージャによ
るすべての応答はどちらの場合でも同じである。

【００６９】この条件が、条件マネージャのスタック・
フレームをスタック上に置かせた。ｒｅｓｕｍｅ１カー
ソルは、条件が発生した点を「指す」。ｈａｎｄｅｌ１
カーソルは、最後に導入されたユーザ条件処理ルーチン
を「指す」。この場合、それはｕｓｅｒ４である。条件
を処理する際の段階のシーケンスは、次の通りである。 ・この例では、ＰＬ／Ｉの条件処理ルーチンがイネーブ
ルするために呼び出される。それが条件を認識していな
いと仮定しよう。したがって、その条件が有効であると
指示する。 ・この時点で、デバッガが走行中（あるいは少なくとも
初期設定されている）の場合、それに制御が与えられ
る。デバッガが存在する場合、それは条件を回復機能委
任すると仮定しよう。 ・Ｐｒｏｃ３用のスタック・フレームに関連するユーザ
条件処理ルーチンの待ち行列を起動する。ｕｓｅｒ４
は、ルーチンＰｒｏｃ３用の最も最近に導入されたユー
ザ条件処理ルーチンである。したがって、条件を処理す
るためにそれがまず呼び出される。そうでないと仮定し
よう。ｈａｎｄｌｅ１カーソルを次のユーザ条件処理ル
ーチンに移動する。待ち行列内の次のユーザ条件処理ル
ーチンはｕｓｅｒ３である。 ・ｕｓｅｒ３は条件を何か他のものに格上げすると仮定
し、処理を次の条件処理ルーチンに進ませる。ｈａｎｄ
ｌｅ１カーソルを次の条件処理ルーチンに移動する。 ・ｕｓｅｒ３は待ち行列内の最終ユーザ条件処理ルーチ
ンであるので、ＨＬＬ処理ルーチン、この場合はＰＬ／
Ｉ条件処理ルーチンが呼び出される。その条件がユーザ
条件であり、したがってＨＬＬ条件処理ルーチンによっ
て認識されないと仮定しよう。 ・この時、Ｐｒｏｃ３のスタック・フレームに関連する
すべての条件処理ルーチンが呼び出されており、したが
って、ｈａｎｄｌｅ１カーソルをＰｒｏｃ２の最初のユ
ーザ条件処理ルーチン、すなわちｕｓｅｒ２に移動す
る。これでｕｓｅｒ２が呼び出される。 ・ｕｓｅｒ２は新しい条件を信号で通知する。この時、
スタック及びカーソルは図６のようになる。 ・ｒｅｓｕｍｅ２カーソル及びｈａｎｄｌｅ２カーソル
が指示されているように配置されていることに注意され
たい。これから条件マネージャ（番号２）が走行し始め
るが、ｒｅｓｕｍｅ２カーソル及びｈａｎｄｌｅ２カー
ソルで働くだけである。また、ｒｅｓｕｍｅ２がｒｅｓ
ｕｍｅ１よりもスタック・フレーム０により近づく場合
には、第１条件が「失われる」ことに留意されたい。こ
の例（通常の場合である）では、再開カーソルを移動し
ない。 ・条件マネージャ２が、イネーブルのため、ｕｓｅｒ２
用のＨＬＬ条件処理ルーチンを呼び出す。これはｕｓｅ
ｒ信号なので、ＦＯＲＴＲＡＮ ＨＬＬ条件処理ルーチ
ンは条件を認識せず、これをイネーブルする。 ・条件マネージャ２が、ユーザ条件処理ルーチンがある
かどうかｕｓｅｒ２を検査するが、何も見つけない。次
いで、条件を処理しないｕｓｅｒ２用のＨＬＬ条件処理
ルーチンを呼び出す。この時、ｈａｎｄｌｅ２カーソル
は、次のスタック・フレーム、すなわち条件マネージャ
１のスタック・フレームに移動する。 条件マネージャ
１用のユーザ処理ルーチンはない。ｈａｎｄｌｅ２カー
ソルが、 条件を処理しない条件マネージャ１のＨＬＬ
条件処理ルーチン（ＣＭ１）に移 動する。条件マネー
ジャ１のスタック・フレームはｒｅｓｕｍｅ２カーソル
よ り前のスタック・フレーム中のスタック上にあるの
で、それを処理しなければ ならないことに留意された
い。 ・次に、ｈａｎｄｌｅ２カーソルを、Ｐｒｏｃ３用の最
初のユーザ条件処理ルーチン、すなわちｕｓｅｒ４に移
動する。そのスタックをスタック・フレーム０までずっ
と条件の処理を続けることはできないが、この例では、
ｕｓｅｒ４が第２の条件を処理すると仮定している。 ・ｕｓｅｒ４が条件を処理したので、その条件を「信号
で通知した」ルーチン、すなわちｕｓｅｒ２に制御を戻
す。スタックは、条件マネージャ２、ｒｅｓｕｍｅ２カ
ーソル、ｈａｎｄｌｅ２カーソルがなくなっている点を
除けば、図６と同じように見える。ｕｓｅｒ２が次に、
条件を別の条件に格上げして戻ると仮定しよう。 ・次にｈａｎｄｌｅ１が、次の条件処理ルーチン、すな
わちＰｒｏｃ２のＨＬＬ条件処理ルーチン（ＦＯＲＴＲ
ＡＮ用）に移動する。ＦＯＲＴＲＡＮ条件処理ルーチン
は条件を回復機能委任し、ｈａｎｄｌｅ１カーソルは次
の条件処理ルーチン、すなわちＰｒｏｃ１のユーザ条件
処理ルーチン（ｕｓｅｒ１）に移動する。ｕｓｅｒ１は
その条件を承認せず、回復機能委任する。 ・ｈａｎｄｌｅ１カーソルがＰｒｏｃ１のＨＬＬ（例え
ばＣ言語）条件処理ルーチンに移動する。ＨＬＬ条件処
理ルーチンは条件を承認せず、回復機能委任する。 ・Ｐｒｏｃ１はスタック・フレーム０より前の最初のス
タック・フレームなので、 この条件に対してとられる
処置が、省略時動作となる。

【００７０】次に、本発明を実行時ライブラリ・ルーチ
ンと共に使用する例を図７を使って例示する。三角関数
を計算する数学ルーチンが、実行時ライブラリ・ルーチ
ンの１例である。実行時ライブラリ用の条件処理は、呼
出し側の言語環境の意味論を反映しなければならない。
プログラミング言語は、ライブラリ・ルーチンに関する
条件処理意味論動作の点で非常に様々である。条件が内
部でライブラリ・ルーチンによって発見されることもあ
り得（例えば、パラメータ検査が定義域エラーをもたら
す）、あるいは条件マネージャが最初に条件（ハードウ
ェア０除法例外）に気づくこともあり得る。その段階
は、次の通りである。 １．ライブラリ・ルーチンが条件を検出し、フィードバ
ック・コード（ＦＣ）なしで条件マネージャにその旨を
信号で通知する（７１）。 ２．条件マネージャが、イネーブルのために、（適用可
能ならば）ライブラリ・ルーチンが書かれている言語の
ＨＬＬ処理ルーチンを呼び出す（７２）。 ３．条件マネージャが、ライブラリ・ルーチン用のルー
チン特有条件処理ルーチン（ＲＳＣＨ）を（もしあれ
ば）呼び出す（７３）。 ４．ＲＳＣＨがその条件を再び、ただし今度はフィード
バック・コード（ＦＣ）付きで信号で通知する（７４）
（これによって、すべてのフィックスアップ論理がＲＳ
ＣＨ内に存在することが可能になる）。 ５．次いで、条件マネージャが、イネーブルのため、ラ
イブラリ・ルーチンの呼出し側の言語用のＨＬＬ条件処
理ルーチンを呼び出す（７５）。 ６．次いで、条件処理が通常のように進行する（７
６）。

【００７１】ライブラリ・ルーチンがそれ自体のスタッ
ク・フレーム上で走行する時： 条件がハードウェアに
よって検出された場合、次の処置が行われる。 １．制御が条件マネージャに渡され、続いて条件をさら
に定義または修飾しあるいはその両方を行うために、条
件マネージャがルーチン特有の条件処理ルーチンを呼び
出す。 ２．次いで、ルーチン特有の条件処理ルーチンが、ハー
ドウェアで定義された条件を等価なソフトウェア条件に
変換する（これは、個々のライブラリ・ルーチンに対す
る定義されたインターフェースに特有であることがあ
る）。 ３．次いで、ルーチン特有の条件処理ルーチンによっ
て、次の段階がとられる。 ・適当な情報を含むインスタンス特有情報ブロックが、
必要ならば構築される。 ・条件を完全に修飾するのに要するすべての必要なデー
タをアセンブルして修飾データ・ブロックにする。 ・フィードバック域を設けて、変換された条件を信号で
通知せる。

【００７２】ライブラリ・ルーチン自体（すなわち、検
出されたソフトウェア）によって条件が発見された場
合、次の処置が行われる。 １．ライブラリ・ルーチンがフィードバック・コードで
呼び出された場合、適当な条件トークンがフィードバッ
ク域に入れられ、ライブラリ・ルーチンの呼出し側に戻
される。 ２．ライブラリ・ルーチンへの呼出しの際にフィードバ
ック域が提供されていない場合、フィードバック域を提
供せずに、条件が条件マネージャに信号で通知される。 ３．次いで、条件マネージャが、ハードウェアで検出さ
れた条件の場合と同じ処置をとる、ルーチン特有条件処
理ルーチンを呼び出す。条件特有修飾データは、条件を
理解しまたはフィックスアップ動作を行いあるいはその
両方を行うのに必要な何らかの追加データを指すアドレ
スのベクトルの形をとる。ルーチン特有条件処理ルーチ
ンが実行時に登録される。

【００７３】どちらの場合にも、条件の処理は、その
後、下記のように進行する。フィードバック・トークン
として戻されないすべての条件では、次の処置が行われ
る。 １．ライブラリ・ルーチンが書かれている言語用の言語
特有条件処理ルーチンがある場合、イネーブルのため
に、それが呼び出される。 ２．次いで、条件マネージャが、ルーチン特有条件処理
ルーチンを呼び出して、条件を処理する。各ライブラリ
・ルーチンは、ルーチン特有条件処理ルーチンを条件マ
ネージャで登録することができる。このルーチン特有条
件処理ルーチンは、事実上ユーザ処理ルーチンと同様で
ある。ルーチン特有条件処理ルーチンは「完全機能」条
件処理ルーチンであるが、その所期の動作は、再開しイ
ネーブルを回復機能委任すること、またはイネーブルを
回復機能委任し条件を変換することである。動作イネー
ブルを（変換して、または変換せずに）回復機能委任す
る際、ルーチン特有条件処理ルーチンが、条件の連続処
理を可能にするのに必要なメッセージ挿入データ及び条
件特有修飾データを提供する必要がある。 ３．ルーチン特有条件処理ルーチンの応答がイネーブル
を回復機能委任することである場合、条件マネージャ
は、まず条件の以前のイネーブルをリセットし、次いで
イネーブルのためにライブラリ・ルーチンの呼出し側の
言語の言語特有条件処理ルーチンを呼び出す。次に、呼
出し側スタック・フレーム中で通常の条件処理が続行す
る。

【００７４】ライブラリ・ルーチンに起因する条件の処
理中、有効な動作は、フィックスアップと再開である。
この目的で、ライブラリ・ルーチンのルーチン特有条件
処理ルーチンに戻ることのできる２つの条件が設けられ
ている。それは、新しい入力値でフィックスアップし、
新しい出力値で再開することである。定義されたどちら
かのフィックスアップ動作が要求された時、識別フィー
ドバック・トークンがライブラリ・ルーチン特有条件処
理ルーチンに戻される。この処理ルーチンは、ライブラ
リ・ルーチン及びその呼出し側と協同して働き、指示さ
れたフィックスアップ活動を適正に行うのに必要な論理
動作を提供することができる。

【００７５】ライブラリ・ルーチンがその呼出し側のス
タック・フレーム上で走行する時：ライブラリ・コード
がその呼出し側の生成コードと「整列し」置かれた時、
コンパイラの明白な動作の結果として、コンパイラはま
た、生成されたコード内に含まれるライブラリ・ルーチ
ンの各インスタンスごとに、次の情報をモジュール・プ
ロローグに入れなければならない。 ・ライブラリ・ルーチンの開始オフセット ・ライブラリ・ルーチンの長さ ・ライブラリ・ルーチンに関連するルーチン特有条件処
理ルーチンを識別するハンドル

【００７６】条件処理は、ライブラリ・ルーチンがそれ
自体のスタック・フレーム上で走行する場合と同じ一般
的プロセスをたどるが、図８に記載されているような相
違がある。処理段階は、次の通りである。 １．ライブラリ・ルーチンが、条件を検出し、フィード
バック・コードなしで条件マネージャにその旨を信号で
通知する（８１）。 ２．条件マネージャが、イネーブルのためにライブラリ
・ルーチンを含むスタック・フレームを所有する言語の
ＨＬＬ処理ルーチンを呼び出す（８２）。 ３．条件マネージャが、モジュール・プロローグの探索
によって、そのライブラリ・ルーチン用のルーチン特有
条件処理ルーチンがある場合、それを呼び出して、割込
みの位置が、条件の発生時に実行がライブラリ・ルーチ
ン内であったことを示すかどうかを決定する（８３）
（注：これは、ライブラリ・ルーチン内の実行時間に、
ルーチン特有条件処理ルーチンの偽静的登録が行われる
ことを示している）。 ４．ＲＳＣＨが条件を、今度はフィードバック・コード
付きで再度信号で通知する（８４）（これによってすべ
てのフィックスアップ論理がＲＳＣＨ中に存在すること
が可能になる）。 ５．次いで条件マネージャが、新しい条件のイネーブル
のために所有フレームのＨＬＬ条件処理ルーチンを呼び
出す（８５）。 ６．ＨＬＬ条件処理ルーチンは、条件がイネーブルされ
ていることを示し、条件マネージャが最初の「ユーザ」
処理ルーチンであるライブラリ・ルーチン特有条件処理
ルーチンを呼び出す（８６）。 ７．次いで、ＲＳＣＨは条件を回復機能委任して、ユー
ザ条件処理ルーチン、ＵＨ１を呼び出させる（８７）。 ８．次いで、通常のように条件処理が進行する（８
８）。

【００７７】スタック・フレーム０における処理の順
序： 通常の条件処理シーケンスは、スタックを後のフ
レームから前のフレームへと横断する。スタックをスタ
ック・フレーム０まで横断した時までに条件が処理され
ない場合、条件マネージャが予期された動作の制御を獲
得する。現言語省略時条件処理との互換性を保つため、
スタック・フレーム０用の言語特有条件処理ルーチンの
仮想待ち行列が維持される。

【００７８】論理的に、各スレッドごとに１つのスタッ
ク・フレームが存在する。それは、スレッド上の最初の
適用業務ルーチンである。スレッドはそのスタック上に
非ＣＣＨスタック・フレームを有することがあり、ＣＣ
Ｈがそれを迂回するすべはないので、ＣＣＨは、これら
の非ＣＣＨスタック・フレームの一つに出会った時は
「仮想」スタック・フレーム０を仮定する。この時点
で、スタック・フレーム０の処理が、最後に処理された
ＣＣＨスタック・フレームから開始する。この仮想待ち
行列には、３つまでのＨＬＬ条件処理ルーチンが存在す
る。呼び出される最初の処理ルーチンは、非マルチパス
ＨＬＬ条件処理ルーチンであり、スタック・フレーム０
で省略時処理を有したいと望むことがある。次のことが
行われる。 ・言語特有条件処理ルーチンがイネーブルのために呼び
出される通常の条件処理中、これは、そのファシリティ
ＩＤをＣＥＥＣＩＢのＣｏｎｄ＿Ｄｅｆａｕｌｔフィー
ルドに入れる。 ・処理カーソルがスタック・フレーム０に到達すると、
条件マネージャが、ＣＥＥＣＩＢフィールドＣｏｎｄ＿
Ｄｅｆａｕｌｔ中のファシリティＩＤに対するＨＬＬ条
件処理ルーチンを呼び出す。次いで、この条件処理ルー
チンは、言語によって定義される省略時条件処理意味論
を適用することができる。これには通常のすべての処理
ルーチンの動作が含まれる。 ・このルーチンは、登録解除を受けるために、条件マネ
ージャに戻らなければならない。

【００７９】２番目は、スタック上の最も古いＰＬ／Ｉ
またはマルチパスの高水準言語である。次の動作が行わ
れる。 ・条件処理ルーチンがＣＣＨによって導入される。 ・条件がこの導入されたスタック・フレーム０用条件処
理ルーチンに到達する場合、スタック・フレーム０の処
理のため、条件処理ルーチンが呼び出される。スタック
を再巡回することを条件処理ルーチンが決定する場合
は、マルチパス・スタック・フレームだけが再巡回さ
れ、次いでＨＬＬ条件処理ルーチンだけが呼び出され
る。 ・スレッド１用に導入された条件処理ルーチンが適用業
務中のすべてのスレッドに使用される。

【００８０】この待ち行列中の最後の処理ルーチンは、
条件マネージャであり、未処理のすべての条件用の定義
された省略時指定を実施する。

【００８１】未処理条件による終了： 重大度２、３ま
たは４の条件が未処理の場合にスレッドを終了させる条
件マネージャの省略時動作は、ＣＥＥＥＸＴＤサービス
を呼び出すことによって実行される。スレッドが未処理
条件のために終了する結果としてエンクレーブが終了す
る場合、リターン・コードのユーザ・リターン・コード
部分として０の値が使用される（すなわち、どのユーザ
・リターン・コードも無視される）。

【００８２】処理カーソルの動き： 処理カーソルは、
高水準言語またはユーザ条件処理ルーチンによって明示
的に操作されない。その動きは、実際には条件マネージ
ャによって制御されるが、条件マネージャは条件処理ル
ーチンから戻される結果コードを使って、動作を決定す
る。この動きは、条件が格上げされる時以外は、０次ス
タック・フレームに向う。格上げされる場合は、処理カ
ーソルは、再開カーソルが指すスタック・フレーム、あ
るいは条件処理が現在行われているスタック・フレーム
用の現処理ルーチンまたは最初の処理ルーチンを指すこ
とができる。格上げされた条件の処理も、もちろん回復
機能委任された条件の場合と同様に、以前のフレームで
続行できる。

【００８３】再開カーソルの動き： 再開カーソルは、
呼出し可能なサービスＣＥＥＭＲＣＲ及びＣＥＥＭＲＣ
Ｅによって操作される。再開カーソルは、特定のスタッ
ク・フレームまで移動すると、以前の再開点から新しい
再開点まで、ただし後者を含まない、すべてのフレーム
を終了させる効果を有する。上記で指摘したように、こ
れは、こうした終了されたフレームのどれに対しても活
動状態であった条件処理を打ち切る効果をもつことがで
きる。

【００８４】再開カーソルは、再開点を示すので、単に
呼込み（スタック・フレーム）を指すだけでなく、論理
的に、実行がそこから再開される、関連プロシージャ内
の命令をも指す。さらに、これは、論理的に、実行を再
開しようとする場合に適正な実行環境を確立するのに必
要となる１組の機械状態（例えばレジスタ）情報にも関
連している。

【００８５】使用上の規約： 本節では、高水準言語ラ
イブラリ及び適用業務プログラマが従うべき、使用上の
規約について記述する。これらのガイドラインに従う
と、条件処理モデルの一貫したビューを生成するのに必
要な共同的相互作用が増進される。各グループ、すなわ
ち高水準言語ライブラリと適用業務プログラマについて
以下に別々に論じる。

【００８６】高水準言語の規約、要件及び情報： 互い
に協調して働くために、ＨＬＬ条件処理ルーチンが、１
組の規約を守らなければならない。また、条件処理モデ
ルが完成するように、現在の高水準言語エラー処理方式
に若干の拡張を加えることが必要である。そうすること
により、条件処理モデルの一貫した協同的なビューが生
成される。本節では、高水準言語に対するこれらの規約
及び要件、ならびに高水準言語作成者を助けるために提
供される若干の追加情報をリストする。

【００８７】ＨＬＬ条件処理モデルは、基本的に、スタ
ック・フレームに基づくモデル（例えばＰＬ／Ｉ）と大
域エラー・テーブル（Ｇ．Ｅ．Ｔ．）モデル（例えばＩ
ＢＭＦＯＲＴＲＡＮ）の２種類に分かれる。両方のモデ
ルを含む可能性のある複数言語スレッドでの条件処理の
一貫したビューを確保するため、ＨＬＬ条件処理ルーチ
ンの間の協同が必要である。

【００８８】ＨＬＬ条件処理の規則は、次の通りであ
る。 ・すべてのＨＬＬ条件処理ルーチンは、あらゆる未知の
条件を回復機能委任する。 未知の条件とは、高水準言
語がそれに対する定義済みの動作をもっていない条 件
である。 ・ＨＬＬ条件処理ルーチンがイネーブルのために呼び込
まれる時、未知の条件がイネーブルされなければならな
い。 ・重大度０または１のすべての（イネーブルされた）条
件が、フィックスアップを必要とせず、次の順次命令で
の再開を可能にしなければならない。 ・所与の条件に対する動作が「無視」の時は、その条件
はディスエーブルされていると見なされ、それがイネー
ブルのために呼び込まれる時、ＨＬＬ条件処理ルーチン
はイネーブルされずに戻らなければならない。例えば、
Ｃ言語では、signalへの呼出しの際にＳＩＧ＿ＩＧＮを
指定することにより、条件が無視できる。 ・ハードウェア条件によっては、実際にハードウェア条
件を提起する前に、ソフトウェアを介して検出できるも
のである。例えば、ソフトウェアは０除数の有無を調べ
ることによって、ZeroDivide（０除法）条件の有無を検
出することができる。条件が高水準言語によってイネー
ブルされるものと定義され、ソフトウェアが潜在的ハー
ドウェア条件を検出する場合、ＣＥＥＳＧＬを用いて、
等価なＣＣＨ条件が信号で通知されなければならない。 ・上記のことにもかかわらず、ステートメント向き言語
構成体は、直接、高水準言語で処理するのが最も適当で
ある。対応するどんな条件もディスエーブルされるもの
と定義される。例えば、ＣＯＢＯＬ ＤＩＶＩＤＥ動詞
のＯＮ ＳＩＺＥクローズ（実際に条件を提起すること
と論理的に等価なものを含んでいる） からである。 ・大域エラー・テーブル（Ｇ．Ｅ．Ｔ．）モデルを使用
する高水準言語では、Ｇ． Ｅ．Ｔ．モデルの高水準言
語とスタック・フレームに基づくモデルの高水準言 語
を共に含む複数言語適用業務において、この２つのモデ
ルが協調して働くこ とが可能となるように、いくつか
の規則を守らなければならない。これらの規 則には、
次のものがある。 −イネーブルされた条件では、Ｇ．Ｅ．Ｔ．中で定義さ
れている処置は次の２グループに分かれる。 １．フィックスアップ及び再開 ２．フィックスアップと再開以外のこと 省略時処置が「フィックスアップ再開」である場合、所
有スタック・フレームでその処置を取らなければならな
い。 −ユーザが明示的に、Ｇ．Ｅ．Ｔ．内の特定の条件に対
してとる必要のある動作を変更する、例えば省略時動作
をとる代りに、その条件をさばくためにそれ自体の処理
ルーチンを登録する場合は、ユーザ指定の動作をしなけ
ればならない。 −条件が所有スタック・フレーム以外のスタック・フレ
ームに提示される（条件が非Ｇ．Ｅ．Ｔ．言語で発生し
たことを暗示する）か、あるいは省略時動作が「フィッ
クス及び再開」以外の何かである場合には、ＨＬＬ条件
処理ルーチンはその条件を回復機能委任しなければなら
ない。具体的には、終了を指定する既存のＧ．Ｅ．Ｔ．
動作は回復機能委任に変更しなければならない。これら
の規則により、現意味論に従うことが可能になるが、
言語間の協力も可能になる。 −Ｇ．Ｅ．Ｔ．モデル用のＨＬＬ条件処理ルーチンが０
次スタック・フレームに対して呼び込まれる場合、「真
の」システム動作がこの時に実行されなければならな
い。 −すべてのＨＬＬ条件処理ルーチンには、反復して入る
ことができなければならず、したがって、ある条件の処
理中に条件が発生することが可能である。 −Ｇ．Ｅ．Ｔ．を用いる高水準言語は、条件を回復機能
委任することのできる機構を提供しなければならない。
ユーザが回復機能委任動作を指定できなければならな
い。例えば、Ｃ言語は条件を回復機能委任することを意
味するように＿ＳＩＧ＿ＰＥＲＣを定義できるはずであ
る。ＦＯＲＴＲＡＮは、そのエラー任意選択テーブル用
の回復機能委任動作を定義できるはずである。 −各高水準言語は、論理的に０次スタック・フレームに
導入できる条件処理ルーチンを提供すべきである。これ
により、条件が適用業務内のどのスタック・フレームに
よっても処理されない時、第１ルーチンの高水準言語
が、 言語によって定義される省略時システム動作
を指令することが可能になる。 このことは、例え
ばＰＬ／Ｉの最初のルーチンが与えられているとする
と、 ＰＬ／ＩがあらゆるＰＬ／Ｉ条件に対してそ
のシステム動作を実施できる ことを暗示する。さ
らに、大域モデルを有する高水準言語が、０次スタッ
ク・フレームで条件に対する大域言語動作を実施で
きることも暗示する。

【００８９】以下のリストに、高水準言語の実施者に役
立つように意図された、若干の情報及び提案を示す。 −ある条件は、高水準言語特有であると見なされる。例
えば、入出力関係の条件は、通常、高水準言語特有であ
る。その他の高水準言語特有の条件には、ＰＬ／Ｉにお
けるＡＲＥＡ、ＣＯＮＤＩＴＩＯＮ、ＳＩＺＥ、Pascal
におけるrange errorsなどがある。 −条件は、高水準言語特有か、高水準言語及びプラット
フォームの全体にわたって「総称的」かのいずれかであ
る。 −イネーブル段階は、その出所、すなわち−ハードウェ
アかソフトウェアか（例えば、ＣＥＥＳＧＬ）にかかわ
らず、すべての条件に対して実行される。 −イネーブル段階によって、高水準言語がＰＬ／Ｉの前
置条件やＣＯＢＯＬのＯＮ ＳＩＺＥクローズなどの構
成体を実施することが可能となる。（ＣＯＢＯＬは単に
これを検査するためのインライン・コードを生成し、Ｏ
Ｎ ＳＩＺＥを尊重することができるだけで、条件を信
号で通知することはない）。 −高水準言語は、条件表現内に含まれる重大度を有利に
使用すべきである。例えば、ＰＬ／Ｉは、重大度１のＰ
Ｌ／Ｉ ＥＮＤＰＡＧＥ条件を信号で通知することがで
きる。その条件に作用する処理ルーチンがなかった場合
には、条件マネージャは、その信号の後の次の順次命令
で再開される、未処理の重大度１に対する省略時動作を
とることになる。 −ＰＬ／Ｉは、ＡＮＹＣＯＮＤＩＴＩＯＮ条件をサポー
トできるはずである。これがないと、ＰＬ／Ｉは、第１
プロシージャがＰＬ／Ｉでない適用業務でそのシステム
動作を実施することができなくなる。それは、条件処理
モデルが複数のスタック・フレームにわたって単一パス
を実行し、その条件を元の形で提示するからである。条
件がＰＬ／ＩのＥＲＲＯＲ条件でない場合は、ＰＬ／Ｉ
のＥＲＲＯＲオン・ユニットは駆動されない（ＰＬ／Ｉ
適用業務では、ある条件にシステム動作が適用される
時、ＰＬ／ＩのＥＲＲＯＲ条件が提起される）。ＡＮＹ
ＣＯＮＤＩＴＩＯＮを実施すると、ＰＬ／Ｉサブルーチ
ンが単一パス中にすべての条件をさばくことができるよ
うになる。

【００９０】ユーザ条件処理ルーチンの規約： ユーザ
が作成した処理ルーチンも１組の規約及び制限を守らな
ければならない。 ・高水準言語のユーザが作成した条件処理ルーチンに
は、反復して入ることができなければならない。 ・ユーザが作成した条件処理ルーチンは、それが出会う
どんな条件にも渡される。したがって、それらは、すべ
ての未知の条件を回復機能委任すべきである。

【００９１】上記で指摘したように、条件は、ハードウ
ェアまたはオペレーティング・システムによって検出さ
れた問題がない時、プログラムによって信号で通知され
ることがある。ＣＣＨは、信号を生成するための呼出し
可能ＣＥＥＳＧＬサービスを提供する。条件のソースが
ハードウェア、オペレーティング・システムまたはソフ
トウェア信号のいずれであろうと、条件はまず条件マネ
ージャに通信される。次いで、条件マネージャは、条件
処理の処理を続ける従属条件処理ルーチンに制御を渡す
ことができる。

【００９２】従属条件処理ルーチンは、条件を処理する
ために条件マネージャによって呼び込むことができる。
従属条件処理ルーチンは、低水準エラー処理ルーチン、
イネーブル・ルーチン、条件処理ルーチンの３つの範疇
に分かれる。これらのルーチンは、ＣＣＨ条件処理の異
なる段階で呼び出されるもので、以下で説明する。

【００９３】低水準エラー処理ルーチン： 呼び込まれ
た場合、これらのルーチンが条件を処理する。条件マネ
ージャは、条件を引き起こしたプログラム中の（割込み
点の後の）次の順次命令から実行を再開することがで
き、また指定した場所から実行を再開することができ
る。これらのルーチンは低水準エラー処理ルーチンによ
って呼び出される。 ・エミュレート（プログラム・チェックのみ） システム・アーキテクチャによって特定機械での若干の
命令の使用可能性が制限されることがしばしばある。そ
うした機械用のＣＣＨ実施態様では、これらの制限され
た命令に対してエミュレーションを提供することを選ぶ
ことができる。そうした場合、エミュレーションは自動
的であり、割込みを引き起こしたプログラム中の（割込
み点の後の）次の順次命令から実行が再開される。例え
ば、条件マネージャは、拡張浮動小数点除算命令をＳ／
３７０でエミュレートする。 ・シャント（プログラム・チェック） シャント・ルーチンは、言語ライブラリ・ルーチン及び
デバッガ用に意図されている。シャント・ルーチンは、
通常、コードの高性能セグメントが、起こり得る例外か
らそれ自体を保護する必要のある時に使用される。この
ルーチンは、通常、ライブラリ・ルーチンまたはデバッ
ガが適用業務にサービスを提供している短い間に確立さ
れる。シャント・ルーチンが存在する場合、条件マネー
ジャは、シャント・ルーチンを呼び込んだ後、それ以上
処理を実行しない。

【００９４】イネーブル・ルーチン： ある条件（ハー
ドウェアで検出されたエラー、オペレーティング・シス
テムによって検出されたエラー、またはソフトウェアに
よって信号で通知されたエラー）を条件として処理すべ
きかどうかを決定する。さらに、これらのルーチンは、
条件の低水準処理を提供することができる。イネーブル
・ルーチンは、イネーブル段階中に呼び出される。 ・言語特有イネーブル処理ルーチン 言語特有イネーブル処理ルーチンは、適用業務で使用さ
れている特定の言語に関連する。各スタック・フレーム
に１つの言語特有イネーブル処理ルーチンが論理的に関
連づけられている（スタック・フレームはＤＳＡ、すな
わち活動化連鎖上にあるレジスタ保管域である）。空の
言語特有イネーブル処理ルーチンも可能である。スタッ
ク・フレームに関連する言語特有イネーブル処理ルーチ
ンが、ある条件（割込みまたは例外）がＣＣＨ条件とし
て扱えるかどうかを決定する。この決定は、条件マネー
ジャのイネーブル段階中に行われる。換言すれば、これ
らのルーチンは、ハードウェア条件またはソフトウェア
条件がさらに何らかの処置を必要とするかどうかを決定
する。条件がさらに何の動作も必要としない場合は、条
件マネージャは、実行を再開する。すなわち、割込みが
発生した点に続く命令から実行が開始する。条件がさら
に動作を必要とする場合は、それが条件段階中に条件マ
ネージャによって（条件として）処理される。

【００９５】条件処理ルーチン 条件処理ルーチンは、条件の原因を検討し、条件に対し
て必要な処置を実行する。条件マネージャは、条件段階
中に条件処理ルーチンを呼び込む。 ・デバッガ デバッガ・インターフェースは適用業務デバッグ製品へ
の特殊なインターフェースである。デバッガは条件を処
理し、あるいは条件処理が続行すべきことを指示するこ
とができる。条件管理中、デバッガは、条件がイネーブ
ルされると決定された後、及び条件が格上げされた場合
に、潜在的に呼び込まれる。 ・ユーザ条件処理ルーチン ユーザ条件処理ルーチンは、呼出し可能ＣＥＥＨＤＬＲ
サービスで確立される（登録される）。ＣＥＥＨＤＬＲ
サービスは、条件マネージャに、条件が発生する時、ユ
ーザが供給する条件処理ルーチンに制御を渡すよう動的
に要求する。ユーザ条件処理ルーチンは、それが確立さ
れた場所であるスタック・フレームに関連する。ユーザ
条件処理ルーチンの待ち行列を各スタック・フレームに
関連づけることができる。条件段階中、条件マネージャ
は、条件を処理するため、各スタック・フレームにおい
てユーザ条件処理ルーチンを（後入れ先出し順に）呼び
込む。確立されたユーザ条件処理ルーチンが、各スタッ
ク・フレームに関連する言語特有例外処理ルーチンの前
に呼び込まれる。ユーザ条件処理ルーチンは、ＣＥＥＨ
ＤＬＵサービスを用いて明示的に、あるいはユーザ条件
処理ルーチンを登録したルーチンがその呼出し側に戻る
とき明示的に確立解除（登録解除）される。各ユーザ条
件処理ルーチンは、何らかの許容可能な応答で条件マネ
ージャに戻ることができる。 ・言語特有例外処理ルーチン 一般に、言語は、その条件処理意味論を実施するため、
言語特有例外処理ルーチンを使用する。言語特有例外処
理ルーチンは、各スタック・フレームに関連づけること
ができる。言語特有例外処理ルーチンは、条件段階中に
呼び込まれる。条件段階中、条件マネージャは、条件を
処理するため、言語特有例外処理ルーチンを呼び込む。
条件マネージャは、処理カーソルが指すスタック・フレ
ームから始めてスタック・フレーム０に達するまで、次
々に言語特有例外処理ルーチンを呼び込む。各言語特有
例外処理ルーチンは、任意の定義された方式で応答する
ことができる。 ・出口ルーチン 言語は、呼込みから異常脱出する時、すなわち復帰プロ
セスを使用しない場合にとるべき処置を指定することが
できる。これは、出口ルーチンをスタック・フレームと
関連づけることによって行われる。スタック・フレーム
が、時期尚早に、例えば条件処理中に終了する場合、あ
るいは再開カーソルが関連するスタック・フレームを通
り越して移動する場合には、言語特有出口処理ルーチン
の呼込みは、即時には行われず、後続の処理中に行われ
る。

【００９６】上記のリストから、条件マネージャの条件
処理方式の次のような特徴が認められる。 ・ユーザは、ユーザ条件処理ルーチンを用いて、それ自
身の条件処理を実施する。 ・言語は、次のルーチンを用いて、それ自体の条件処理
を実施する。 −シャント・ルーチン −言語特有イネーブル処理ルーチン −言語特有例外処理ルーチン ・イネーブル・ルーチンは、従属条件処理ルーチンの単
独の範疇として分離されている。これによってシステム
間の条件処理の一貫性が保証される。 ・ユーザ条件処理ルーチンの範疇が従属条件処理ルーチ
ンに追加されている。これによって、すべての言語ユー
ザが条件処理にアクセスすることができ、既存の条件モ
デルをもつ言語のユーザがＣＣＨ条件モデルの全能力及
び機能にアクセスすることが可能になる。 ・出口ルーチンの範疇が追加され、出口処理が独立した
活動になっている。この出口処理を条件処理の残りの部
分から分離することは、再開カーソルの概念とあいまっ
て、ＣＣＨ条件処理モデルを以前のモデルから区別し、
これに現在の言語要件を満足するための力を与えなが
ら、同時により強力かつより頑丈な条件処理機構の実施
を可能にするものである。

【００９７】条件に対する応答：従属条件処理ルーチン
は、条件に対して、ｒｅｓｕｍｅ（再開）、ｐｅｒｃｏ
ｌａｔｅ（回復機能委任）、またはｐｒｏｍｏｔｅ（格
上げ）で応答する。従属条件処理ルーチンは、要求され
た動作を実際に実行する条件マネージャに戻らなければ
ならない。再開カーソルは、まずＣＥＥＭＲＣＲ呼出し
可能サービスを使用することによって修正できる。条件
の回復機能委任は、従属条件処理ルーチンが条件を処理
するのを拒否する場合に起こり、呼出し側呼込みにその
条件を処理する機会を与える。このプロセスは、条件が
ある従属条件処理ルーチンによって最終的に処理される
まで、スレッド内で複数の呼込みによって繰り返すこと
ができる。従属条件処理ルーチンがその条件を異なる意
味をもつ新しい条件に変換する時、その条件は格上げさ
れる。従属条件処理ルーチンは、その従属条件処理ルー
チンが元の条件の原因を知っていることや、知っていな
いことを含めて、様々の原因で条件を格上げすることが
できる。後者のケースの例は、ＰＬ／Ｉがスタック・フ
レーム０における未処理条件をＥＲＲＯＲに格上げし、
処理カーソルを再開カーソルにリセットする場合であ
る。また、通常なら異なるソースから来るはずの条件を
シミュレートするために、条件を格上げすることもでき
る。

【００９８】条件が格上げされたあと、条件マネージャ
は、格上げされた条件を処理するために従属条件処理ル
ーチンを呼び込むことにより、処理を続行する。呼込み
の順序については、以下に述べる。さらに、条件マネー
ジャは元の条件に関する情報を保持する。

【００９９】条件管理段階の概要： ある条件が発生す
る時、条件マネージャはその条件を処理するため、個々
の段階に入る。段階とは、従属条件処理ルーチン呼込み
のシーケンスである。特定のタイプのルーチンが各段階
中に呼び込まれる。ルーチンのタイプによっては、特定
の段階中に呼び込まれないことがある。

【０１００】条件処理の諸段階について以下で論じる。 ・低水準エラー処理段階（プログラム・チェック及び異
常終了）。低水準エラー処理段階中、シャント・ルーチ
ンが確立されていた場合、条件マネージャは指示された
アドレスから実行を再開する。再開が行われると、この
条件での条件処理は完了し、残りの段階は行われない。 ・イネーブル段階 イネーブル段階中、条件マネージャは言語特有イネーブ
ル処理ルーチンを呼び込んで条件に作用すべきか、それ
ともそれ以上の動作は必要でないかを決定する。言語特
有イネーブル処理ルーチンは、言語特有の意味論を実施
する責任をもつ。この段階中に、ハードウェアと言語の
衝突が解決される。条件マネージャは、最も最近に活動
化されたＤＳＡに、または構成要素が識別可能であるス
タック・フレームに関連する言語特有イネーブル処理ル
ーチンを呼び込む。イネーブル段階は、呼び込まれた言
語特有イネーブル処理ルーチンが戻る時に終了する。条
件がイネーブルされない場合は、条件処理の他の段階は
省略される。 ・デバッガ段階 実行時オプションの制御下で条件がイネーブルされると
決定された時、デバッガにその条件が通知される。 ・条件段階 条件段階中、ユーザ条件処理ルーチン及び言語特有例外
処理ルーチンが、その条件の原因を調べて、条件に対す
る必要な処置を実行するために呼び出される。より具体
的には、条件マネージャは、処理カーソルが指すスタッ
ク・フレームから始めて、スタック・フレーム０まで、
あるいはユーザ条件処理ルーチンまたは言語特有例外処
理ルーチンが条件を処理する時まで、スタックを（１つ
ずつ）横断する。各スタッフ・フレームで、条件マネー
ジャは、ユーザ条件処理ルーチンを（後入れ先出し順
で）呼び込み、それに続いて、そのスタック・フレーム
に関連する言語特有例外処理ルーチンを呼び込む。ユー
ザ条件処理ルーチン及び言語特有例外処理ルーチンは、
「条件に対する応答」として記載されているいずれかの
方法で条件に応答する。

【０１０１】条件マネージャ段階は、次の特性を有す
る。 ・条件マネージャは、割込み（ハードウェア・エラ
ー）、例外（ソフトウェア・エラー）、または信号通知
済み条件に応答して、これらの段階に入ることができ
る。 ・割込み（ハードウェア・エラー）及び例外（ソフトウ
ェア・エラー）の場合、条件マネージャは、イネーブル
段階の前に低水準エラー処理段階に入る。 ・割込み（ハードウェア・エラー）、例外（ソフトウェ
ア・エラー）及び条件の場合、条件マネージャは、条件
段階に入る前にイネーブル段階に入る。 ・条件が低水準エラー処理段階中に低水準エラー処理ル
ーチンによって処理される場合、条件マネージャは後続
の段階に入らない。 ・言語特有イネーブル処理ルーチンが、条件段階中にあ
る条件を条件として扱うべきでないと決定する場合、条
件マネージャは条件段階に入らない。

【０１０２】条件処理中に複数の条件が発生する時、あ
るいはそれが信号で通知される時、現条件の処理は保留
され、ＣＥＥＣＩＢ中で維持されている条件処理の「状
態」に基づいて次の処置がとられる。入れ子式条件が許
容される場合は、条件マネージャは最近の条件の処理を
開始する。最近の条件に関する条件処理が終了する時、
再開カーソルが指す命令から実行が開始する。再開カー
ソルはその初期設定から移動することができる。

【０１０３】いずれの共通言語においても言語構文の変
更を強制することなく、本発明を実施することが可能で
あるが、好ましい実施例では、便宜上、ＣＯＢＯＬコン
パイラの機能に新しい構成体が追加された。この変更
は、"ＰＲＯＣＥＤＵＲＥ−ＰＯＩＮＴＥＲ"を次のよう
に宣言できるようにすることであった。 pgmptr usage is ＰＲＯＣＥＤＵＲＥ−ＰＯＩＮＴＥＲ ユーザ条件処理ルーチンを登録するのに使用する時は、
以前に宣言された変数"ｐｇｍｐｔｒ"が次のように使用
される。 Ｓｅｔ pgmptr to entry "ＳＩＭＨＤＬＲ". Ｃａｌｌ "ＣＥＥＨＤＬＲ" using pgmptr token fbcod
e.

【０１０４】表１に、ユーザ条件処理ルーチンを登録
し、試験し、登録解除する、ＣＯＢＯＬ試験プログラム
（ＥＸＣＯＮＤ）のサンプルを示す。表２に、ＣＯＢＯ
Ｌで書かれたユーザ条件処理ルーチン（ＳＩＭＨＤＬ
Ｒ）のサンプルを示す。可変な現条件では、最初の８バ
イトが、ＩＢＭのシステム／３７０プログラム割込みコ
ードＯＣ１〜ＯＣＦ用の条件トークンとして宣言され
る。表３に、条件を引き起こすＣＯＢＯＬルーチン（Ｄ
ＩＶＺＥＲＯ）のサンプルを示す。プログラムＥＸＣＯ
ＮＤは、ＳＩＭＨＤＬＲを導入し、ＤＩＶＺＥＲＯを呼
び出すことによってこれを試験する。 [表１] CBL C,RENT,Q,LIST,NODYNAM,TEST(SYM) ** ＩＤ ＤＩＶＩＳＩＯＮ *** Identification Division. Program-id. EXCOND. Author. LEE. Installation. IBM - Santa Teresa Laboratory. ** ＥＮＶＩＲＯＮＭＥＮＴ ＤＥＶＩＳＩＯＮ *** Environment Division. Configuration Section. Input-Output Section. File-control. ** ＤＡＴＡ ＤＩＶＩＳＩＯＮ *** Data Division. File Section. Working-storage Section. 01 fbcode. 02 fb-severity pic 9(4) Binary. 02 fb-detail pic X(10). 77 divisor pic S9(9) Comp. ** ** Declares for condition handling ** 77 token pic X(4). 77 pgmptr usage is PROCEDURE-POINTER. 01 CEE000 PIC X(12). 88 fb-ok value x"000000000000000000000000". Linkage Section. ** ＰＲＯＣ ＤＩＶＩＳＩＯＮ *** Procedure Division. PARA-CND01A. ** ** Register a user condition handler. ** Set pgmptr to entry "SIMHDLR". Move ZERO to token. Call "CEEHDLR" using pgmptr token fbcode. Display "EXCOND: Registered SIMHDLR0." Upon console. ** ** Call DIVZERO to force a zero divide and drive SIMHDLR ** Move 00 to divisor. Call "DIVZERO" using divisor. Display "EXCOND: Resumption after DIVZERO." Upon console. ** Unregister the user condition handler. Call "CEEHDLU" using pgmptr fbcode. Display "EXCOND: Unregistered SIMHDLR." Upon console. Goback. End program EXCOND. [表２] Identification division. Program-id. SIMHDLR. Environment division. Data division. Working-storage section. 1 Misc-Variables. 02 move-type-0 pic s9(9) binary value zero. 01 Feedback. 02 Fb-severity pic 9(4) binary. 02 Fb-detail pic X(10). Linkage section. 1 Current-condition. 2 filler pic x(8). 88 CEE341 value x"00030C8159C3C5C5". 88 CEE342 value x"00030C8259C3C5C5". 88 CEE343 value x"00030C8359C3C5C5". 88 CEE344 value x"00030C8459C3C5C5". 88 CEE345 value x"00030C8559C3C5C5". 88 CEE346 value x"00030C8659C3C5C5". 88 CEE347 value x"00030C8759C3C5C5". 88 CEE348 value x"00030C8859C3C5C5". 88 CEE349 value x"00030C8959C3C5C5". 88 CEE34A value x"00030C8A59C3C5C5". 88 CEE34B value x"00030C8B59C3C5C5". 88 CEE34C value x"00030C8C59C3C5C5". 88 CEE34D value x"00030C8D59C3C5C5". 88 CEE34E value x"00030C8E59C3C5C5". 88 CEE34F value x"00030C8F59C3C5C5". 2 filler pic x(4). 1 Token pic x(4). 1 Result-code pic s9(9) binary. 88 resume value +10. 88 percolate value +20. 88 perc-sf value +21. 88 promote value +30. 88 promote-sf value +31. 1 New-condition pic x(12). Procedure division using current-condition token result-code new-condition. Display ">>> SIMHDLR: Entered User Handler " upon console. If CEE349 then Call "CEEMRCR" using move-type-0 feedback Set resume to true Display ">>> SIMHDLR: Resuming execution" upon console Else Set percolate to true Display ">>> SIMHDLR: Percolating it" upon console End-if. Goback. End program SIMHDLR. [表３] CBL C,RENT,Q,LIST,NODYNAM,TEST(SYM) *********************************************************** ** ＩＤ ＤＩＶＩＳＩＯＮ *** *********************************************************** Identification division. Program-id. DIVZERO. Environment Division. *********************************************************** ** ＤＡＴＡ ＤＩＶＩＳＩＯＮ *** *********************************************************** Data division. Working-storage section. Linkage section. 1 Arg pic S9(9) Comp. *********************************************************** ** ＰＲＯＣ ＤＩＶＩＳＩＯＮ *** *********************************************************** Procedure division using Arg. Display "DIVZERO: Starting." Compute Arg = 1 / Arg. Display "DIVZERO: Returning to its caller." Goback. End program DIVZERO.

【０１０５】コンパイラ作成者インターフェース（ＣＷ
Ｉ）： ＣＣＨによって提供されるこのインターフェー
スは、Ｃ言語サブルーチン定義構文を用いて、次のよう
に記載される。

【０１０６】言語特有処理ルーチンとの間のインターフ
ェース void condition_handler(reason,ceecib,results,new_c
ondition); ＩＮＴ４ *reason, void *ceecib, ＩＮＴ４ *result; ＦＥＥＤＢＡＣＫ *new_condition; ただし、 ｒｅａｓｏｎ（入力） 言語特有処理ルーチンが呼び出された理由。この値は、
参照によって渡される。これは、メンバ事象処理ルーチ
ン用の事象コードである。有効な値は次の通りである。 １．ＣＥＥＣＩＢが表す条件を（スタック・フレーム０
用でなく）処理する。 ２．このスタック・フレームに対するイネーブルを実行
する。 ３．この条件を、言語省略時指定に従って処理する（こ
れはスタック・フレーム０用のものである） ＣＥＥＣＩＢ（入力） 条件処理ルーチンが呼び出される対象となるＣＥＥＣＩ
Ｂ。この値は、参照によって渡される。ｃｏｎｄｉｔｉ
ｏｎ＿ｔｏｋｅｎ、及びその条件が発生したプロシージ
ャ用の機械環境がＣＥＥＣＩＢの一部である。 ｒｅｓｕｌｔｓ（出力） このフィールドは、言語特有処理ルーチンが条件マネー
ジャに条件を処理した結果としてとることを望む処置を
示す命令を含んでいる。このフィールドは参照によって
渡される。有効な応答は次の通りである。 ｒｅｓｕｍｅ １０ 再開カーソルの所から再開する（条件は処理済
み）。 ｐｅｒｃｏｌａｔｅ ２０ 次の条件処理ルーチンに回復機能委任する。 ２１ 次のスタック・フレーム用の最初のユーザ条件処
理ルーチンに回復機能委任する（これは、このスタック
・フレーム用の言語特有例外処理ルーチンならびにこの
スタック・フレームにおける待ち行列内の残りのユーザ
条件処理ルーチンをスキップすることができる）。 ｐｒｏｍｏｔｅ ３０ 次の条件処理ルーチンに格上げする。 ３１ 次のスタック・フレームに格上げする（これは、
このスタック・フレーム用言語特有例外処理ルーチンな
らびにスタック・フレームにおける待ち行列内の残りの
ユーザ条件処理ルーチンをスキップすることができ
る）。 ３２ 再開カーソル位置で指示されるスタック・フレー
ム用の条件処理を格上げし、再始動する。 ３３ 条件処理を格上げして再駆動し、最初のＰＬ／Ｉ
スタック・フレームはＰＬ／１が所有するスタック・フ
レームだけを再駆動する（これは、ＰＬ／Ｉ専用に設け
られており、したがってＰＬ／Ｉ言語エラー処理意味論
が尊重される）。 ｅｎａｂｌｅｍｅｎｔ ４０ 条件を無視する。割込みのあった所からスレッド
が再開される。 ４１ 条件処理のため条件をイネーブルする。 ４２ 条件をイネーブルし、条件を（ｎｅｗ＿ｃｏｎｄ
ｉｔｉｏｎパラメータにより）変換する。 ｐｅｒｃｏｌａｔｅ ｅｎａｂｌｅｍｅｎｔ ５０ イネーブルを呼出し側スタック・フレームに回復
機能委任する。 ５１ 条件を（ｎｅｗ＿ｃｏｎｄｉｔｉｏｎパラメータ
により）変換し、イネーブルを呼出し側スタック・フレ
ームに回復機能委任する。 ｎｅｗ＿ｃｏｎｄｉｔｉｏｎ（出力） 格上げされた条件を表す新しい条件トークン。このフィ
ールドは、回復機能委任を指定する３０、３１、３２、
３３のｒｅｓｕｌｔ値にのみ使用される。

【０１０７】使用上の注意 １．新しい条件トークンを返さずに、条件を格上げする
のは無効である。元の条件がｎｅｗ＿ｃｏｎｄｉｔｉｏ
ｎ中で返される場合、条件マネージャは、２０の結果が
指定されているかのように動作する。 ２．条件が格上げされる前に、メッセージ挿入ブロック
（ＭＩＢ）を必要に応じて、格上げされた条件用の新し
い挿入物で充填しなければならない。 ３．言語特有処理ルーチンは、スタック・フレームによ
って自動的に確立される。条件マネージャが所与のスタ
ック・フレームに関連する言語を決定し、次いでイネー
ブル、条件処理またはスタック・フレーム０の条件処理
のための適当な事象コードで、事象処理ルーチンを呼び
込む。 ４．スタック・フレームが復帰、ブロックからのＧＯＴ
Ｏ、または再開カーソルの移動によって、スタックから
ポップオフされる時、言語特有処理ルーチンは、自動的
に確立解除される。 ５．再開が要求される場合、目標スタック・フレームに
制御を渡す直前に、目標スタック・フレームを所有する
メンバが呼び込まれる。

【０１０８】再開のためのメンバへのインターフェース void resume_in_dsa(event_code,target_dsa); ＩＮＴ４ *event-code; void *target-dsa; ただし、 ｅｖｅｎｔ＿ｃｏｄｅ（入力） 事象処理ルーチンに対するこの呼出しを、条件処理ルー
チンからの再開がｔａｒｇｅｔ＿ｄｓａ内で行われると
識別する、事象コード１０ ｔａｒｇｅｔ＿ｄｓａ（入力） 再開の目標であるＤＳＡ

【０１０９】使用上の注意 １．条件マネージャは、再開の目標であるスタック・フ
レームを所有するメンバを決定する。それが決定される
と、条件マネージャは、スタック・フレームへの再開操
作を実行する直前に、特定のメンバの事象処理ルーチン
を呼び込む。 ２．再開がｔａｒｇｅｔ＿ｄｓａ内で行えるようにする
のに必要な処置を実行することはメンバの責任である。

【０１１０】ＣＥＥＤＨＤＬ：ＣＥＥＤＨＤＬは、条件
が未処理のままである場合に、スタック・フレーム０で
呼び込まれる条件処理ルーチンを登録するのに使用され
る。このサービスは、ＰＬ／Ｉが使用するために提供さ
れており、したがってＰＬ／Ｉは未処理条件に関してス
タック・フレーム０でその意味論動作を適用することが
できる。登録はエンクレーブ全体に影響し、ＣＥＥＵＤ
ＨＤを介して明示的に除去されるまで有効なままとな
る。 void ＣＥＥＤＨＤＬ（routine,[token],[fc]); ＥＮＴＲＹ *routine; ＩＮＴ４ *token; ＦＥＥＤ＿ＢＡＣＫ *fc; ただし、 ｒｏｕｔｉｎｅ（入力） スタック・フレーム０で呼び込まれるルーチン用のエン
トリ変数。このルーチンはメンバ事象処理ルーチンであ
る。 ｔｏｋｅｎ（入力／任意選択） 呼び込まれる時にルーチンに渡される任意選択の３２ビ
ットの情報。これは、スタック・フレーム０処理事象用
の５番目のパラメータとしてメンバ事象処理ルーチンに
渡される。 ｆｃ（出力／任意選択） 参照によって渡される任意選択の条件トークン。呼出し
側への復帰は、条件が検出される時だけ行われる。ｆｃ
中で戻される条件には、次のものがある。 CEE000 Severity=0 Msg_No=0000 Message=成功 CEE080 Severity=2 Msg_No=0256 Message=ルーチンが既に登録済み。何の処置もとらな
い。

【０１１１】使用上の注意 １．初期設定中に、ＰＬ／Ｉは、そのエラー処理意味論
を実施するため、そのメンバ事象処理ルーチンをＣＥＥ
ＤＨＤＬによって登録すると予想される。 ２．ＰＬ／Ｉだけがこのサービスを呼び込むと予想され
る。

【０１１２】ＣＥＥＵＤＨＤ：ＣＥＥＵＤＨＤは、ＣＥ
ＥＤＨＤＬによって登録された条件処理ルーチンを登録
解除するのに使用される。 void ＣＥＥＵＤＨＤ（routine,[fc]); ＥＮＴＲＹ *routine; ＦＥＥＤ＿ＢＡＣＫ *fc; ただし、 ｒｏｕｔｉｎｅ（入力） 登録解除すべきルーチン用の入口変数。 ｆｃ（出力／任意選択） 参照によって渡される任意選択の条件トークン。呼出し
側への復帰は、条件が検出される時だけ行われる。ｆｃ
中で戻される条件には、次のものがある。 CEE000 Severity=0 Msg_No=0000 Message=成功 CEE07S Severity=2 Msg_No=0252 Message=ルーチンがスタック・フレーム０の処理ルーチ
ンとして登録されていない。

【０１１３】使用上の注意 １．初期設定中に、ＰＬ／Ｉは、そのエラー処理意味論
を実施するため、そのメンバ事象処理ルーチンをＣＥＥ
ＤＨＤＬによって登録すると予想される。

【０１１４】適用業務作成者インターフェース（ＡＷ
Ｉ）： 適用業務作成者インターフェースが下記にリス
トされており、次の節でより詳しく論じる。 ・ＣＥＥＨＤＬＲ ユーザ条件処理ルーチンを登録す
る。 ・ＣＥＥＨＤＬＵ ユーザ条件処理ルーチンを登録解除
する。 ・ＣＥＥＭＲＣＲ 再開カーソルをより古いスタック・
フレーム中の復帰点に移動する。 ・ＣＥＥＳＧＬ 条件を提起する。 ・ユーザが作成した条件処理ルーチン。

【０１１５】ＣＥＥＨＤＬＲ：呼出し可能なサービスＣ
ＥＥＨＤＬＲは、現スタック・フレーム用のユーザ条件
処理ルーチンを登録するという１つの機能をもつ。

【０１１６】これらのルーチンを収容するため、各スタ
ック・フレームごとに待ち行列が設けられている。待ち
行列が空のこともある。条件マネージャは待ち行列要素
に後入れ先出し順でアクセスする。

【０１１７】登録されているユーザ条件処理ルーチン
（ＣＥＥＨＤＬＲによって作成され、ＣＥＥＨＤＬＵに
よって登録解除されていない）がある場合、関連するス
タック・フレームがスタックから除去される時、ＣＣＨ
によって自動的に登録解除される。ユーザが登録されて
いるユーザ条件処理ルーチンを除去することを覚えてい
る必要はない。 void ＣＥＥＨＤＬＲ（routine,token,[fc]); ＥＮＴＲＹ *routine, ＩＮＴ４ *token, ＦＥＥＤ＿ＢＡＣＫ *fc; ただし、 ｒｏｕｔｉｎｅ（入力） 条件を処理するために「呼び出す」べきルーチン用の、
参照によって渡される入口変数または定数。 ｔｏｋｅｎ（入力） 参照によって渡され、呼び出されるたびにユーザ条件処
理ルーチンに渡したい３２ビットの情報。これは、ポイ
ンタ、またはユーザが望む他のどんな３２ビットの項目
でもよい。 ｆｃ（出力／任意選択） 参照によって渡される任意選択条件トークン。ｆｃ中で
戻される条件には、次のものがある。 CEE000 Severity=0 Msg_No=何でもよい Message=サービスが首尾よく完了。 CEE080 Severity=2 Msg_No=0256 Message=指定されたルーチンがこのスタック・フレーム
用に既に登録 済み。 CEE081 Severity=2 Msg_No=0257 Message=ルーチンが無効なENTRY変数を含んでいる。

【０１１８】使用上の注意 １．ＣＥＥＨＤＬＲは、その関連するルーチンがＣＣＨ
スタイルのＰＰＡをもち、ＰＰＡ１ ＣＥＥフラグ中の
ビット６（ＰＰＡ１中のオフセット２）が^１^Ｂに設定
された、スタック・フレーム上の条件処理ルーチンを確
立しない。このフラグは、条件管理のすべての段階が、
関連するＤＳＡをスキップすることを示す。これによ
り、ユーザのコードとＣＥＥＨＤＬＲルーチンの間にラ
イブラリ・ルーチンが介在することが可能になる。この
状況は、ＣＯＢＯＬルーチンがＣＡＬＬ変数（または動
的呼出し）をＣＥＥＨＤＬＲに出す時に発生した。ＣＯ
ＢＯＬライブラリ・ルーチンは、ＣＡＬＬ変数を管理す
るため、ユーザのコードとＣＥＥＨＤＬＲの間に置かれ
る。この特定のＣＯＢＯＬライブラリ・ルーチンは、
「条件管理動作」用のＰＰＡフラグを^１^Ｂに設定す
る。

【０１１９】ＣＥＥＨＤＬＵ：呼出し可能なサービスＣ
ＥＥＨＤＬＵは、現スタック・フレーム用のユーザ条件
処理ルーチンを登録解除する、１つの機能をもつ。

【０１２０】登録済みのユーザ条件処理ルーチン（ＣＥ
ＥＨＤＬＲによって作成され、ＣＥＥＨＤＬＵによって
登録解除されていない）がある場合、関連するスタック
・フレームがスタックから除去される時、自動的にＣＣ
Ｈによって登録解除される。ユーザが登録済みユーザ条
件処理ルーチンを除去することを覚えている必要はな
い。 void ＣＥＥＨＤＬＵ（routine,[fc]); ＥＮＴＲＹ *entry_variable, ＦＥＥＤ＿ＢＡＣＫ *fc; ただし、 ｒｏｕｔｉｎｅ（入力） ユーザ条件処理ルーチンとして登録解除すべきルーチン
用の、参照によって渡される入口変数または定数。この
ルーチンは、予めＣＥＥＨＤＬＲによって登録されてい
なければならない。 ｆｃ（出力／任意選択） 参照によって渡される条件トークン。ｆｃ中で戻される
条件には、次のものがある。 CEE000 Severity=0 Msg_No=n/a Message=サービスが首尾よく完了。 CEE07S Severity=2 Msg_No=0252 Message=要求されたユーザ条件処理ルーチンが見つけら
れない。

【０１２１】ＣＥＥＭＲＣＲ：呼び出し可能サービスＣ
ＥＥＭＲＣＲは、再開カーソルを処理カーソルの現位置
に対して相対的に移動する。サポートされる動作には、
次のものがある。 １．再開カーソルを、それに代わって条件処理ルーチン
が実行中であるルーチンの呼出し復帰点に移動する。 ２．再開カーソルを、それに代わって条件処理ルーチン
が実行中であるルーチンの呼出し側に移動する。

【０１２２】最初に、再開カーソルが、その条件を引き
起こした機械命令の後に置かれる。各スタック・フレー
ムが渡されるのに応じて再開カーソルが移動する時、関
連する出口ルーチンが呼び込まれる。この移動によっ
て、関連するユーザ条件処理ルーチンも「取り消さ」れ
る。移動の方向は、常に、より古いスタック・フレーム
に向かい、決してより新しいスタック・フレームに向か
わない。条件処理ルーチンが条件マネージャに戻ってか
ら初めてこの動作が行われる。ＣＥＥＭＲＣＲへの複数
の呼出しは、それらの呼出しの総合的結果をもたらす。
すなわち、２回の呼出しで再開カーソルが異なる場所に
移動する場合、最も限定的な（すなわち、スタック・フ
レーム０へ向かう）呼出しが用いられる。 void ＣＥＥＭＲＣＲ（type_of_move,[fc]); ＩＮＴ４ *type_of_move; ＦＥＥＤ＿ＢＡＣＫ *fc; ただし、 ｔｙｐｅ＿ｏｆ＿ｍｏｖｅ（入力） 再開カーソルの移動目標を示す。 ・０−再開カーソルを処理カーソルのスタック・フレー
ムの呼出し復帰点に移動する。すなわち、ＣＥＥＭＲＣ
Ｒを呼び込む処理ルーチンを登録したスタック・フレー
ム。 ・１−再開カーソルを、処理カーソルのスタック・フレ
ームを進めるスタック・フレームの呼出し復帰点に移動
する。処理カーソルは、新しい再開カーソルの位置が指
すスタック・フレームの最初の条件処理ルーチンに移動
する。 ｆｃ（出力／任意選択） 参照によって渡される条件トークン。ｆｃ中で渡される
条件には、次のものがある。 CEE000 Severity=0 Msg_No=何でもよい Message=サービスが首尾よく完了。 CEE07U Severity=2 Msg_No=0254 Message=無効なtype_of_moveが発見された。 CEE080 Severity=1 Msg_No=0256 Message=処理カーソルと再開カーソルが同じスタック・
フレームを指す。type_of_move=0の場合、何の処置もと
られない。 CEE081 Severity=1 Msg_No=0257 Message=「主」ルーチンからの無効なタイプの移動。

【０１２３】使用上の注意 １．再開が要求される時、そのコードが再開ポインタの
目標となっているメンバの事象処理ルーチンが呼び込ま
れる。これによって、メンバが、再開が行える環境を確
立することが可能になる。

【０１２４】ＣＥＥＳＧＬ： この呼出し可能なサービ
スは、条件を提起しまたは信号で通知し、条件のこのイ
ンスタンス用の修飾データを提供し、任意選択で、この
条件用のインスタンス特有情報を作成する。イネーブル
された各信号通知済み条件（重大度２以上）がエラー・
カウントを１ずつ増分する。エラー・カウントがエラー
・カウント限界（ＥＲＲＣＯＵＮＴ実行時オプションに
よって決定される）に等しくなるか、またはそれを越え
る場合、条件マネージャは、Ｔｅｒｍｉｎａｔｉｏｎ＿
Ｉｍｍｉｎｅｎｔを信号で通知することなく、エンクレ
ーブを終了させる。格上げされた条件は、エラー・カウ
ントを増分しない。

【０１２５】重大度０及び１の条件は、それが処理され
ない場合には無視される条件である、「安全な」条件と
見なされ、条件が提起されたとき、フィードバック・ト
ークンは渡されなかった。 void ＣＥＥＳＧＬ (cond_rep,[q_data_token],[fc]); ＦＥＥＤ＿ＢＡＣＫ *cond_rep, ＩＮＴ４ *q_data_token, ＦＥＥＤ＿ＢＡＣＫ *fc; ただし、 ｃｏｎｄ＿ｒｅｐ（入力） 参照によって渡される条件表現。 ｑ＿ｄａｔａ＿ｔｏｋｅｎ（入力／任意選択） 条件の所与のインスタンスに関連する修飾データにアク
セスする際に使用するため、インスタンス特有情報に入
れられる３２ビットのデータ・オブジェクト。 ｆｃ（出力／任意選択） 参照によって渡される、ＣＥＥＳＧＬの成否を示す任意
選択の条件トークン。ｆｃ中で戻される条件には、次の
ものがある。 CEE000 Severity=0 Msg_No=何でもよい Message=サービスが首尾よく完了。 CEE069 Severity=0 Msg_No=0201 Message=信号通知済み条件が処理されなかった。 CEE0EE Severity=3 Msg_No=0462 Message=入力条件トークンに関連するＩＳＩが見つから
なかった。 CEE0EB Severity=3 Msg_No=0459 Message=新しいＩＳＩを生成するのに使用できる記憶域
が不十分。 CEE0EC Severity=3 Msg_No=0460 Message=ＩＳＩリストが満杯で、新しいエントリが作成
できない。 CEE0CE Severity=1 Msg_No=0398 Message=新しい入力で再開。 CEE0CF Severity=1 Msg_No=0399 Message=新しい出力で再開。

【０１２６】使用上の注意 １．ＣＥＥＳＧＬサービスの呼出し側は、このサービス
を呼び出す前に、ＩＳＩを（提起されている条件に関連
するメッセージをフォーマットするのに必要な）何らか
の挿入データで充填しなければならない。フィードバッ
ク・コードを呼出し可能なサービスから受け取る時、Ｍ
ＩＢは既に充填済みである。 ２．イネーブルは、このサービスで提起された条件に対
して決定される。 ３．ｑ＿ｄａｔａ＿ｔｏｋｅｎはＣＣＨから照会されな
い。これは、４バイト内に含めることのできるどんな値
でもよい。 ４．条件がＣＥＥＳＧＬに対する呼出しの際にｑ＿ｄａ
ｔａ＿ｔｏｋｅｎの値を渡して信号で通知され、ｑ＿ｄ
ａｔａ＿ｔｏｋｅｎ値が既に関連するＩＳＩ中に存在す
る場合には、ＩＳＩ中のｑ＿ｄａｔａ＿ｔｏｋｅｎが重
ね書きされる。 ５．条件ＣＥＥＯＣＥ及びＣＥＥＯＣＦは、ｑ＿ｄａｔ
ａ＿ｔｏｋｅｎが指すデータと共に、その条件を経験し
たルーチンによって、フィックスアップまたは再開ある
いはその両方を行うために使用される。

【０１２７】ユーザ作成条件処理ルーチン： void condition_handler (Ｃ＿ＣＴＯＫ,token,result_
code,new_condition); ＦＥＥＤＢＡＣＫ *Ｃ＿ＣＴＯＫ; ＩＮＴ４ *token; ＩＮＴ４ *results; ＦＥＥＤ＿ＢＡＣＫ *new_condition; ただし、 Ｃ＿ＣＴＯＫ（入力） 処理されている現条件を定義する。 ｔｏｋｅｎ（入力） この条件処理ルーチンを登録したＣＥＥＨＤＬＲへの呼
出しと共に条件マネージャに渡されたトークン。 ｒｅｓｕｌｔ＿ｃｏｄｅ（出力） このフィールドは、ユーザ条件処理ルーチンが条件マネ
ージャにその条件を処理した結果としてとることを望ん
でいる処置を指示する命令を含んでいる。このフィール
ドは参照によって渡される。有効な応答は、次の通りで
ある。 ｒｅｓｕｍｅ １０ 再開カーソルの所から再開する（条件が処理済
み）。 ｐｅｒｃｏｌａｔｅ ２０ 次の条件処理ルーチンに回復機能委任する。 ２１ 次のスタック・フレーム用の最初のユーザ条件処
理ルーチンに回復機能委任する（これは、このスタック
・フレーム用の言語特有例外処理ルーチンならびにこの
スタック・フレームにおける待ち行列内の残りのユーザ
条件処理ルーチンをスキップできる）。 ｐｒｏｍｏｔｅ ３０ 次の条件処理ルーチンに格上げする。 ３１ 次のスタック・フレームに格上げする（これは、
このスタック・フレーム用の言語特有例外処理ルーチン
ならびにこのスタック・フレームにおける待ち行列内の
残りのユーザ条件処理ルーチンをスキップできる）。 ３２ 条件処理を格上げして、処理カーソルのスタック
・フレームの最初の条件処理ルーチンから再始動する。 ｆｉｘ−ｕｐ ａｎｄ ｒｅｓｕｍｅ ６０ フィックスアップして、再開する。６０のｒｅｓ
ｕｌｔ＿ｃｏｄｅが使用される時、ユーザ条件処理ルー
チンから条件マネージャに戻されたｎｅｗ＿ｃｏｎｄｉ
ｔｉｏｎフィールドの内容が、フィードバック・コード
としてＣＥＥＳＧＬの呼出し側に戻される。ＣＥＥＳＧ
Ｌの呼出し側がフィードバック・コードなしに作られる
場合には、フィックスアップが定義されていないルーチ
ン上でフィックスアップを試みるために、条件が提起さ
れる。ＣＥＥＳＧＬの説明中のそれぞれ条件ＣＥＥＯＣ
Ｅ及びＣＥＥＯＣＦの、 「新しい入力で再開」
及び「新しい出力で再開」説明を参照のこと。 注：６０のｒｅｓｕｌｔ＿ｃｏｄｅは、再開カーソルが
移動していない場合にのみ、有効である。 ｎｅｗ＿ｃｏｎｄｉｔｉｏｎ（出力） 格上げされた条件を表す新しい条件トークン。このフィ
ールドは、ｐｒｏｍｏｔｅを示す３０、３１、３２なら
びにｆｉｘ−ｕｐ ａｎｄ ｒｅｓｕｍｅを示す６０の
結果値用にのみ使用される。

【０１２８】使用上の注意 １．新しい条件トークンを戻さずに条件を格上げするこ
とは無効である。元の条件がｎｅｗ＿ｃｏｎｄｉｔｉｏ
ｎ中で戻される場合、条件マネージャは次の条件を信号
で通知する。 新＝旧条件の条件を格上げする試み Symbolic name=CEE086 Severity=3 Msgno=0262 ２．条件を格上げする前に、必要に応じて、ＩＳＩを格
上げされた条件用の新しい挿入物で充填しなければなら
ない。 ３．ユーザ条件処理ルーチンは、ＣＥＥＨＤＬＲによっ
て登録される。 ４．ユーザ条件処理ルーチンは明示的にＣＥＥＨＤＬＵ
によって登録解除される。 ５．復帰、ブロックからのＧＯＴＯ、または再開カーソ
ルの移動によって、スタック・フレームがスタックから
ポップオフされる時、ユーザ条件処理ルーチンは自動的
に登録解除される。 ６．ｒｅｓｕｍｅが要求される場合、制御を目標スタッ
ク・フレームに渡す直前に、目標スタック・フレームを
所有するメンバが呼び込まれる。

【０１２９】条件マネージャに関する様々な話題 ＣＥＥ３ＣＮＣ−制御入れ子式条件（ＡＷＩ）： ＣＥ
Ｅ３ＮＣサービスの機能は、条件処理ルーチンに、ＣＥ
ＥＤＬＲによって登録されたユーザ特有条件処理ルーチ
ン内で入れ子式条件を可能とすることを許容または禁止
することである。条件処理ルーチンに最初に入る時、入
れ子式条件は許容されない。許容されていない時に入れ
子式条件が発生すると、適用業務がＡＢＥＮＤ４０８
７、理由コード２で終了される。ただし、ユーザ内で、
別のユーザ処理ルーチンが（ＣＥＥＨＤＬＲへの呼出し
によって）登録されている場合には、別のユーザ処理ル
ーチンが登録されたままになっているか、あるいは明示
的にＣＥＥ３ＣＮＣによって禁止されている限り、ユー
ザ処理ルーチン内で入れ子式条件が許容される。

【０１３０】このサービスのフォーマットは、次の通り
である。 void ＣＥＥ３ＣＮＣ（allow,[fc]) ＩＮＴ４ *allow; ＦＥＥＤ＿ＢＡＣＫ *fc; ただし、 ａｌｌｏｗ（入力） ａｌｌｏｗが非０の場合、入れ子式条件が許容される。
ａｌｌｏｗが０の場合、 入れ子条件は許容されない。 ｆｃ（出力／任意選択） 動作の成否を示すフィードバック・コード。次のメッセ
ージ識別子及び関連する重大度を、このサービスによっ
てィードバック・コードｆｃ中で戻すことができる。 Ｓｕｃｃｅｓｓ（成功） Symbolic name=CEE000 Severity=0（fc=0) Msgno=0000 Ｎｏ ａｃｔｉｖｅ ｃｏｎｄｉｔｉｏｎ（活動状態の
条件なし） Symbolic name=CEE35S Severity=1 Msgno=3260

【０１３１】ＣＣＨからの離脱とＣＣＨへの復帰： Ｍ
ＶＳの下で実行している間に、システム・エラー処理ト
ラップが確立された（ＥＳＴＡＥ）要求ブロック（Ｒ
Ｂ）とは異なる要求ブロックの下で実行中に、例外が発
生することがある。これは、ＤＦ／ＳＯＲＴ出口が呼び
込まれる時、あるいは入出力サブシステムで実行してい
る時に発生し得る。ＣＣＨによってシステム出口から再
開が要求される時、このような場合にＭＶＳによって定
義される挙動は、ＥＳＴＡＴＥ要求を出した要求ブロッ
クのレベルまでの要求ブロックを除去することである。
とりわけ、この潜在的な要求ブロックの不一致に対処す
るため、ＣＣＨに「ＣＣＨからの実行」及び「ＣＣＨへ
の復帰」を指示する１組のＡＷＩサービスが提供され
る。そのサービスは、ＣＥＥ３ＸＩＴ及びＣＥＥ３ＲＴ
Ｎである。 void ＣＥＥ３ＸＩＴ； void ＣＥＥ３ＲＩＴ；

【０１３２】使用上の注意 １．ＣＥＥ３ＸＩＴは、非ＣＣＨコードへの呼出しが行
われていることをＣＣＨに示す。 ２．ＣＥＥ３ＲＴＮは、非ＣＣＨルーチンがＣＣＨ実行
に戻りつつあることを示す。 ３．ＣＣＨからの実行中に条件がシステムによって提起
される時、ＣＣＨは論理的に実行スレッドの状態をＣＥ
Ｅ３ＸＩＴが出された点にリセットする。 ４．これらのサービスの所期の用途は、一貫した方式で
挙動しないこともあるサービスへの呼出しを、一括して
扱うことにある。例えば、このサービスは、別の要求ブ
ロック・レベルを生成するＬＩＮＫ ＳＶＣを発行する
ことができ、あるいはセーブ域がＤＣＢ出口の場合のよ
うに）呼出し側に戻して連鎖されない。 ５．高水準言語は、（例えば）入出力サービス及びＤＦ
／ＳＯＲＴを呼び込む前に、このサービスを呼び込むこ
とが期待される。 ６．ＣＥＥ３ＸＩＴへの複数の呼出しはスタックされな
い。最後に発行された呼出しが現呼出しと見なされる。

【０１３３】ＣＥＥＲＴＸ：ＣＥＥＲＴＸサービスによ
って提供される機能は、それが登録されるスタック・フ
レームが異常終了または崩壊する時に、実行すべきユー
ザ定義ルーチンを登録することである。 void ＣＥＥＲＴＸ（routine,token,[fc]) ＣＥＥ＿ＥＮＴＲＹ *routine; ＩＮＴ４ *token; ＦＥＥＤ＿ＢＡＣＫ *fc; ただし、 ｒｏｕｔｉｎｅ（入力） このスタック・フレームが異常終了する場合に呼び出さ
れるルーチン用の入口変数及び定数。 ｔｏｋｅｎ（入力） それが呼び出されるたびに、ユーザ出口に渡される３２
ビットの情報。これは、 （そのポインタが３２ビット
の量であるプラットフォーム上の）ポインタまた はユ
ーザが望む他のどんな３２ビット項目でもよい。 ｆｃ（出力／任意） 次の条件を戻すことのできる任意選択の条件トークンで
ある。 Ｓｕｃｃｅｓｓ（成功） Symbolic name=CEE000 Severity=0（fc=0) Msgno=0000 ｉｎｖａｌｉｄ ｒｏｕｔｉｎｅ ｒｅｆｅｒｅｎｃｅ
（無効ルーチン参照） Symbolic name=CEE081 Severity=3 Msgno=0257 ＣＥＥＲＴＸサービスは、ルーチンの開始時に適切なｐ
ｒｏｌｏｇ定数を見つけることができなかった。

【０１３４】使用上の注意 １．複数ユーザ・スタック・フレーム終了ルーチンが、
各スタック・フレームごとに登録できる。 ２．ユーザ・スタック・フレーム終了出口ルーチンの実
行は、後入れ先出し順である。

【０１３５】ＣＥＥＵＴＸ：ＣＥＥＵＴＸによって提供
される機能は、それが登録されているスタック・フレー
ムが異常終了した時に実行される以前に登録されていた
ユーザ定義ルーチンを登録解除することである。ＣＥＥ
ＵＴＸサービスは、ＣＥＥＵＴＸサービスがそこから呼
び出されるスタック・フレームに対して登録されている
ユーザ・スタック・フレーム終了出口に作用する。 void ＣＥＥＵＴＸ（routine,[fc]) ＣＥＥ＿ＥＮＴＲＹ *routine; ＦＥＥＤ＿ＢＡＣＫ *fc; ただし、 ｒｏｕｔｉｎｅ（入力） このスタック・フレームに対して登録解除すべきルーチ
ン用の入口変数または定数である。 ｆｃ（出力／任意選択） 次の条件を返すことのできる任意選択の条件トークンで
ある。 Ｓｕｃｃｅｓｓ（成功） Symbolic name=CEE000 Severity=0（fc=0) Msgno=0000 ｉｎｖａｌｉｄ ｒｏｕｔｉｎｅ ｒｅｆｅｒｅｎｃｅ
（無効なルーチン参照） Symbolic name=CEE081 Severity=3 Msgno=0257 Ａｄｄｉｔｉｏｎａｌ ｒｅｇｉｓｔｒａｔｉｏｎｓ
ｏｆ ｒｏｕｔｉｎｅｒｅｍａｉｎ ｉｎ ｔｈｅ ｑ
ｕｅｕｅ（ルーチンの追加登録が待ち行列中に残ってい
る） Symbolic name=CEE07T Severity=1 Msgno=0253 最も最近に追加された登録は除去されるが、以前の登録
は依然としてスタック・フレームの待ち行列中に残って
いる。

【０１３６】使用上の注意： ユーザが登録した終了ル
ーチンは、それらが登録されているスタック・フレーム
が崩壊する時、自動的に登録解除される。

【０１３７】ユーザ終了ルーチンへのインターフェー
ス：ユーザ・スタック・フレーム終了ルーチンへのイン
ターフェースは、次の通りである。 void termination_routine (Ｔｅｒｍ＿Ｔｏｋｅｎ) ＩＮＴ４ *Ｔｅｒｍ＿Ｔｏｋｅｎ； ただし、 Ｔｅｒｍ＿Ｔｏｋｅｎ（入力） ユーザ・スタック・フレーム終了出口による使用のため
にデータへのアクセスを提供する１組のプラットフォー
ム特有の呼出し可能サービスへの入力として使用される
３２ビットのトークン。

【０１３８】使用上の注意 １．ユーザが、終了されつつある適用業務に対する終結
処置、巻戻し及び回復の動作を実行できるようにするた
めの、ユーザ終了ルーチンが提供される。 ２．適用業務の実行を終了処理ルーチンから再開するこ
とは違法である。

【０１３９】上記の諸技法を用いると、本発明を利用す
るプログラムを、下記のような現行の米国規格情報シス
テム（ＡＮＳＩ）の言語規格をサポートするコンパイラ
を使って書くことができる。 ・米国標準プログラミング言語−ＣＯＢＯＬ、ＡＮＳＩ
Ｘ３．２３−１９８５ ・米国標準プログラミング言語−ＦＯＲＴＲＡＮ、ＡＮ
ＳＩ Ｘ３．９−１９７８及びＸ３．９−１９９０ ・米国標準プログラミング言語−ＣＯＢＯＬ用組込み関
数モジュール、ＡＮＳＩＸ３．２３ａ−１９８９ ・米国標準プログラミング言語−ＰＬ／Ｉ汎用サブセッ
ト、ＡＮＳＩ Ｘ３．７４−１９８７ ・米国標準パスカル計算機プログラミング言語−ＡＮＳ
Ｉ／ＩＥＥＥ ７７０Ｘ３．９７−１９８３ ・米国標準プログラミング言語−Ｃ、ＡＮＳＩ Ｘ３．
１５９−１９８９

【０１４０】上記の仕様を用いて、標準プログラミング
技法を使って本発明を実施することができる。その結果
得られるプログラミングは、ディスク、ディケット、メ
モリ・カード、ＲＯＭまたはその他の何らかの記憶装置
に記憶することができる。実行のため、プログラムをコ
ンピュータのＲＡＭにコピーすることができる。一時的
結果または中間結果はＲＡＭに記憶される。コンピュー
タ科学の専門家なら、上記のように作成されたソフトウ
ェアを、適当な汎用または専用コンピュータ・ハードウ
ェアと組み合わせて、システムを容易に作成できるであ
ろう。本発明の好ましい実施例について詳細に例示して
きたが、当業者なら、頭記の特許請求の範囲に記載され
る本発明の範囲から逸脱することなく、その実施例に対
する修正及び適応を思いつくであろうことは明らかであ
る。

【図面の簡単な説明】

【図１】オペレーティング・システムと適用業務プログ
ラムの間でのＣＣＨの機能上の関係を示す図である。

【図２】適用業務プログラムとＣＣＨを連係する方法を
示す図である。

【図３】ＣＣＨにおけるスタック・フレームの使用を示
す図である。

【図４】ＣＣＨにおける処理ルーチン、カーソル及びス
タック・フレームの間の関係を示す図である。

【図５】第１の例の初期スタック及びカーソルのサンプ
ルを示す図である。

【図６】条件を信号で通知した後の第１の例の初期スタ
ック及びカーソルのサンプルを示す図である。

【図７】第２の例の初期スタック及びカーソルのサンプ
ルを示す図である。

【図８】呼出し側のスタック・フレームを使用するライ
ブラリ・ルーチン条件処理のスタック図である。

【図９】条件トークンの構成図である。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ジェフリー・アレン・グランツ アメリカ合衆国33431、フロリダ州ボカ・ ラトン、セント・クラウド・レーン 104 番地 (72)発明者 スコット・アラン・プレッツァー アメリカ合衆国55901、ミネソタ州ロチェ スター、ザンブロ・ドライブ、ノース・ウ ェスト 2732番地 (72)発明者 ロバート・ミルトン・スミス アメリカ合衆国95037、カリフォルニア州 モーガン・ヒル、コータ・カバニル 455 番地 (72)発明者 ウィリアム・ニコラス・ジョン・ティンダ ル カナダ エム５アール ３エイ６、トロン ト市ウェルズ・ヒル・アベニュー 20番地

Claims (10)

【特許請求の範囲】
1. 【請求項１】コンピュータ・システムにおいてプログラ
   ム実行中に生じる条件を処理するためのコンピュータ・
   プログラム・ルーチンを生成する方法であって、（１）
   外部呼出しをサポートする任意の言語で書かれた適用業
   務プログラムに連係するのに適した外部入口点用の目的
   コードを定義する段階と、（２）条件を条件マネージャ
   に信号で通知し、次いで適用業務プログラムに戻るため
   の目的コードを定義する段階と、（３）後で適用業務プ
   ログラムに連係するために、段階（１）及び（２）から
   の目的コードをコンピュータ・システム内の持久メモリ
   に入力する段階とを含み、 それによって、複数の言語で書かれた適用業務プログラ
   ムが使用できる、条件を条件マネージャに信号で通知す
   るための外部連係可能なルーチンを作成する、方法。
2. 【請求項２】段階（２）がさらに、 Void ＣＥＥＳＧＬ（cond_rep,[q_data_token],[fc]); ＦＥＥＤ＿ＢＡＣＫ *cond_rep, ＩＮＴ４ *q_data_token, ＦＥＥＤ＿ＢＡＣＫ *fc; を含む原始コードをコンパイルし、それによって、対応
   する目的コードを作成する段階を含む、請求項１の方
   法。
3. 【請求項３】原始コードをコンパイルする段階が、
   （１）cond_repを、参照によって渡される条件表現の入
   力として定義する段階と、（２）q_data_tokenを、任意
   選択の入力３２ビット・データ・オブジェクトとして定
   義する段階と、（３）ＣＥＥＳＧＬの成否を示すｆｃ
   を、参照によって渡されるトークン用の任意選択の出力
   として定義する段階とを含む、請求項２の方法。
4. 【請求項４】各条件が量子化された重大度を有する、コ
   ンピュータ・プログラムの実行中に発生する条件を処理
   する方法であって、（１）条件を記述するフィードバッ
   ク・トークンをそこに記憶することのできるアドレス
   を、サブルーチンに渡す段階と、（２）完了するまで、
   あるいは条件が検出されるまで、サブルーチンを実行す
   る段階と、（３）条件の重大度が閾値よりも大きい場合
   には、その条件を条件マネージャに信号で通知し、そう
   でない場合には、フィードバック・トークンをアドレス
   に記憶する段階とを含む方法。
5. 【請求項５】フィードバック・トークンを記憶する段階
   が、さらに、（１）条件識別子を記憶する段階と、
   （２）条件識別子用のフォーマット・コードを記憶する
   段階と、（３）条件に関する重大度コードを記憶する段
   階と、（４）条件のファシリティ識別子用の制御コード
   を記憶する段階と、（５）条件に関するファシリティ識
   別子を記憶する段階とを含む、請求項４の方法。
6. 【請求項６】フィードバック・トークンを記憶する段階
   が、さらに、（１）長さ４バイトの条件識別子を記憶す
   る段階と、（２）条件識別子用の長さ２ビットのフォー
   マット・コードを記憶する段階と、（３）条件に関する
   長さ３ビットの重大度コードを記憶する段階と、（４）
   条件のファシリティ識別子用の長さ３ビットの制御コー
   ドを記憶する段階と、（５）条件に関する長さ３文字の
   ファシリティ識別子を記憶する段階と、（６）条件に関
   するインスタンス特有情報用の長さ４バイトのハンドル
   を記憶する段階とを含む、請求項４の方法。
7. 【請求項７】複数の言語によるプログラムを処理する条
   件マネージャを有するコンピュータ・システムにおいて
   障害を示すサブルーチンからのリターン・コードを検査
   する必要をなくして、プログラムを実行する方法であっ
   て、（１）条件が発生した時に実行するため、ユーザ処
   理ルーチンを条件マネージャで登録する段階と、（２）
   上記プログラム内のルーチンから、Ｐａｓｃａｌ、ＦＯ
   ＲＴＲＡＮまたはＣＯＢＯＬで書かれたサブルーチンを
   呼び出す段階と、（３）条件の有無を検査しながら、完
   了するまで上記サブルーチンを実行する段階と、（４）
   外部連係ルーチンを呼び出すことによって、検出された
   条件を条件マネージャに信号で通知し、それによって条
   件マネージャに制御を移す段階と、（５）登録済みのユ
   ーザ処理ルーチンの実行とともに、条件マネージャを介
   して検出された条件を処理し、その後上記サブルーチン
   に制御を戻す段階と、（６）上記サブルーチンから上記
   プログラム内の上記ルーチンに制御を戻す段階とを含
   む、方法。
8. 【請求項８】コンピュータ・システムにおいて条件を処
   理する方法であって、（１）条件を検出する段階と、
   （２）条件を記述するフィードバック・トークンを記憶
   する段階とを含み、上記トークンが、（ａ）条件識別子
   と、（ｂ）条件識別子用のフォーマット・コードと、
   （ｃ）条件に関する重大度コードと、（ｄ）ファシリテ
   ィ識別子用の制御コードと、（ｅ）ファシリティ識別子
   とを含み、それによって、後で使用するために条件に関
   する情報を記録する、方法。
9. 【請求項９】さらに、プログラム内のルーチンからサブ
   ルーチンを呼び出す準備段階と、上記フィードバック・
   トークンを上記プログラム内の上記ルーチンに戻す最終
   ステップとを含む、請求項８の方法。
10. 【請求項１０】さらに、その条件に関するインスタンス
    特有情報を記憶するステップを含む、請求項８の方法。