JP2004506264A - Ｃ／ｃ＋＋メタモデルを含む共通アプリケーション・メタモデル - Google Patents

Ｃ／ｃ＋＋メタモデルを含む共通アプリケーション・メタモデル Download PDF

Info

Publication number
JP2004506264A
JP2004506264A JP2002517625A JP2002517625A JP2004506264A JP 2004506264 A JP2004506264 A JP 2004506264A JP 2002517625 A JP2002517625 A JP 2002517625A JP 2002517625 A JP2002517625 A JP 2002517625A JP 2004506264 A JP2004506264 A JP 2004506264A
Authority
JP
Japan
Prior art keywords
language
application
metamodel
data
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2002517625A
Other languages
English (en)
Other versions
JP3842213B2 (ja
Inventor
ブロドスキー、ステファン
ホ、シメイ、エフ
リネ、ジェームス、ラッシュ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Publication of JP2004506264A publication Critical patent/JP2004506264A/ja
Application granted granted Critical
Publication of JP3842213B2 publication Critical patent/JP3842213B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/541—Interprogram communication via adapters, e.g. between incompatible applications

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Devices For Executing Special Programs (AREA)
  • Stored Programmes (AREA)
  • Multi Processors (AREA)

Abstract

【課題】共通アプリケーション・メタモデルを提供すること。
【解決手段】エンド・ユーザ・アプリケーションおよびアプリケーション・サーバでのエンタープライズ・アプリケーション（図２、＃２２１）要求を処理する方法およびシステム。これは、第１アプリケーション・プログラムを用いて第１言語でエンド・ユーザ・アプリケーション上のアプリケーション要求を開始することと、アプリケーション要求をサーバに送信することと、アプリケーション要求を第１エンド・ユーザ・アプリケーションの第１言語から（図２、＃２０９）アプリケーション・サーバ上で稼動する言語に変換することと、アプリケーション・サーバ上でアプリケーション要求を処理することと、応答をアプリケーション・サーバからエンド・ユーザ・アプリケーションに送り返すことと、応答をアプリケーション・サーバ上で稼動する言語からエンド・ユーザ・アプリケーションの言語に変換すること（図２、＃２２１）によって達成される。
【選択図】図２

Description

【０００１】
【発明の属する技術分野】
本発明は、データの転送、交換または処理が作動可能であることを知らせるための、またはアプリケーション間でのデータ転送に関する少なくとも１つまたは複数のパラメータを確立するためのアプリケーション間の命令またはデータあるいはその両方の交換と、データの転送および通信を容易にするためのパラメータの制御に関する。本発明は、さらに、たとえば複数のコンピュータ、複数のオペレーティング・システム、複数のアプリケーション・コンポーネント、複数の開発環境、複数の展開環境、または複数のテストおよび処理など、一方があるプラットフォームで実行され他方が別のプラットフォームで実行される異なるアプリケーションの統合と、全体的な目標を達成するためにデータまたはその一部に対するタスクの実行を容易にするためにアプリケーション間でデータまたは命令あるいはその両方を転送するための接続性を確立するためのお互いとのダイアログ（たとえばネゴシエーション）の確立とに関する。パラメータには、１つまたは複数のフォーマット、データ型、データ構造体、またはコマンドを含めることができる。
【０００２】
【従来の技術】
関連出願の相互参照
本願は、米国特許法セクション１１１（ｂ）および１１９（ｅ）の下で、米国仮特許出願第６０／２２３６７１号および米国特許出願第０９／８４９１０７号の利益を主張する。
【０００３】
本願は、本願と同一の日付に出願された下記の米国特許出願にも関する。
米国特許出願第０９／８４９８１３号。
米国特許出願第０９／８４９５６３号。
米国特許出願第０９／８４９１９０号。
米国特許出願第０９／８４９３７７号。
米国特許出願第０９／８４９８１６号。
米国特許出願第０９／８４９１０５号。
米国特許出願第０９／８４９７９３号。
【０００４】
ｅ−ｂｕｓｉｎｅｓｓの成長によって、レガシ・アプリケーションを統合し、インターネットに持ち込む重大な必要が生じた。これは、新しいアプリケーションが、エンド・ユーザ・アプリケーションの構成およびスケーラビリティを単純にするウェブ標準規格を包含するという現在の傾向のゆえである。さらに、新しいアプリケーションが作成される際に、それらを既存のシステムにシームレスに統合しながら、新しいビジネス・プロセスおよびパラダイムの導入を容易にすることが非常に重要である。
【０００５】
既存のアプリケーションとの新しいアプリケーションの統合は、ｅ−ｃｏｍｍｅｒｃｅに特に関連するデータを含む企業データの７０％以上がメインフレーム・コンピュータ上にあると産業アナリストが推定しているので、特にクリティカルである。さらに、多数のｅ−ｃｏｍｍｅｒｃｅトランザクションが、Ｗｉｎｄｏｗｓ（Ｒ）、Ｍａｃ、およびＬｉｎｕｘのエンド・ユーザ・プラットフォームで、さまざまなウェブ・ブラウザを使用して開始され、Ｗｉｎｄｏｗｓ（Ｒ）ＮＴサーバおよびＵｎｉｘ（Ｒ）サーバを介して進むが、これらのトランザクションは、最終的にはメインフレーム・アプリケーションが稼動するメインフレーム・コンピュータで完了し、メインフレーム・データベースに格納されたデータに影響する。
【０００６】
サーバ・レベル・アプリケーションを統合し、インターネットに持ち込むことに関するｅ−ｂｕｓｉｎｅｓｓからの圧力がある。しかし、アプリケーションを統合またはｅ−ｂｕｓｉｎｅｓｓ対応にする完全で簡単な機構はない。統合は、メッセージング、プロシージャ呼出し、またはデータベース照会のどれを介するものであっても、現在のビジネス問題の多数を解決するための鍵である。
【０００７】
レガシ・アプリケーションと新しいソフトウェアの統合は、２つの異なるアプリケーションを結び付ける接続のそれぞれをカスタマイズする必要に大いに起因して、困難かつ高価な作業である。あるアプリケーションが別のアプリケーションによってそれ自体を呼び出されることを可能にする方法を記述する単一の機構はない。
【０００８】
１つの結果が、複数の開発チームによって開発され、異なるプラットフォームで稼動する、異なるデータ型、データ構造体、コマンド、およびコマンド構文を有する複数のアプリケーションのｅ−ｃｏｍｍｅｒｃｅ環境である。この環境は、アプリケーション・プログラム・インターフェースおよびコネクタを用いてつなぎ合わされる。コネクタは、ｅ−ｃｏｍｍｅｒｃｅの総合的なアプリケーション・フレームワークの本質的な部分である。コネクタは、異なるアプリケーションのインターフェース要件を一致させ、異なるインターフェースの間でマッピングを行う。
【０００９】
この新旧のソフトウェア・システムおよびアプリケーションの相互接続の増加によって、特にマークアップ言語（ＨＴＭＬ、ＸＭＬ、Ｄｙｎａｍｉｃ ＨＴＭＬ、ＷＭＬ、および類似物など）の、ＳｍａｌｌＴａｌｋおよびＣ＋＋などのオブジェクト指向言語を介する、レガシ・アプリケーション・サーバ・アプリケーションの言語（ＣＯＢＯＬなど）との相互接続および対話に関する、さまざまなミドル・ウェア・アプリケーションおよびコネクタ・アプリケーション、インターフェース仕様、インターフェース定義、およびコードがもたらされた。これらのインターフェース仕様、定義、およびコードは、言語、ツール、アプリケーション、オペレーティング・システム、およびネットワークにまたがって適用され、その結果、エンド・ユーザが自分の端末で単一のシームレスなアプリケーションのルック、フィール、および応答を経験するようにしなければならない。その代わりに、たとえばｃｏｍｍｏｎｏｂｊｅｃｔ Ｒｅｑｕｅｓｔ Ｂｒｏｋｅｒ（ＣＯＲＢＡ）、Ｃｏｍｍｏｎ Ｏｂｊｅｃｔ Ｍｏｄｅｌ（ＣＯＭ）、オブジェクトのリンクと埋込み（ＯＬＥ）、ＳＯＭ、ＯＲＢＰｌｕｓ、Ｏｂｊｅｃｔ Ｂｒｏｋｅｒ、Ｏｒｂｉｘなどの標準規格、プロトコル、仕様、定義、およびコードの増殖が、その代わりに、ｅ−ｃｏｍｍｅｒｃｅの「バベルの塔」を生み出した。
【００１０】
アプリケーション統合の例が、ユビキタスであり、これは、ＥＲＰシステムのインストールから、ＩＭＳトランザクションを伴うオペレーショナル・データ・ストア（ＯＤＳ）の更新またはＭＱＳｅｒｉｅｓからのＣＲＭシステムの呼出しまでにおよび、これらのそれぞれが、同一の基本ステップを必要とする。第１に、ユーザは、自分が通信したいエンティティを見つけなければならず、その後、ユーザは、そのエンティティを呼び出す方法を見つけなければならず、最後に、ユーザは、あるネイティブ表現から別のネイティブ表現への変換を提供しなければならない。現在、これらのステップは、通常、手動調査およびハンド・コーディングを必要とし、開発者が、アプリケーションの間の維持しにくい接続の混乱状態に煩わされる。
【００１１】
この情況を救済する試みには、アプリケーション・プログラム・インターフェースおよびコネクタが含まれ、これらは、しばしば、インターフェース定義言語に基づいて構築される。インターフェース定義言語は、宣言的であり、インターフェース定義言語によって、アプリケーション・プログラム・インターフェースが定義され、いくつかの場合に、エラー処理などの問題が生じる。ほとんどのインターフェース定義言語は、Ｃ＋＋のサブセットであり、コンポーネントの属性、継承する元の親クラス、それが発生する例外、それが発行する型付きイベント、そのインターフェースがサポートするメソッド、入出力パラメータ、およびデータ型を指定する。コネクタ内のインターフェース定義言語の目標は、ハード・コーディングされたアプリケーション・プログラム・インターフェースなしで、異なるアプリケーションの間のコラボレーションを可能にすることである。
【００１２】
理想的には、インターフェース定義言語およびそれを含むコネクタは、下記などの特徴を介して完全な実行時ソフトウェア・アプリケーション・コラボレーションを促進しなければならない。
・強い型検査を伴うメソッド呼出し、
・より高い柔軟性と実行時バインディングを伴う実行時メソッド呼出し、
・実装から分離されたインターフェースを伴う高水準言語バインディング、
・サーバの関数およびパラメータのリアル・タイム情報を含むインターフェース・リポジトリ。
【００１３】
さらに、コネクタおよびそのインターフェース定義言語は、高速であり、効率的であり、スケーラブルであり、ポータブルであり、メタクラスをサポートし、構文レベルの拡張をサポートし、セマンティック・レベルの拡張をサポートしなければならない。
【００１４】
【発明が解決しようとする課題】
新しいアプリケーション、たとえばｅ−ｃｏｍｍｅｒｃｅアプリケーションの、レガシ・アプリケーションとの統合に関連する問題が、本明細書に記載の共通アプリケーション・メタモデルのツール、方法、およびシステムによって除去される。本発明の共通アプリケーション・メタモデルの方法、ツール、およびシステムは、似ていない異なるアプリケーションの間のツーリング・ソリューション、データ変換、通信およびコラボレーションならびにアプリケーション・サーバ・インターフェース・ドメインとのインターフェースを介する完全な実行時ソフトウェア・アプリケーション・コラボレーションを容易にする。これは、メタデータ交換情報、強い型検査を伴うメソッド呼出し、実行時メソッド呼出し、実行時バインディング、および高水準言語バインディングを介して、実装から分離されたインターフェースと、クライアントおよびサーバのインターフェース・パラメータのリアル・タイム情報を格納するインターフェース・リポジトリとを用いて、達成される。
【００１５】
さらに、本発明のツール、方法、およびシステムは、すべてのツールまたはミドルウェアから独立の、高速であり、効率的であり、スケーラブルである相互接続性を提供し、再利用可能であり、ポータブルであり、メタクラス、構文レベルの拡張、およびセマンティック・レベルの拡張をサポートし、特定のツールまたはミドルウェアから独立である。
【００１６】
共通アプリケーション・メタモデルのツール、方法、およびシステムは、クライアント・アプリケーションとサーバ・アプリケーションの間で両方向であり、たとえばＪａｖａ（Ｒ）、ＨＴＭＬ、ＸＭＬ、Ｃ、またはＣ＋＋アプリケーションと、ＣＯＢＯＬ、ＰＬ／Ｉ、またはＨｉｇｈ ＬｅｖｅｌＡｓｓｅｍｂｌｅｒアプリケーションとの間、ＨＴＭＬまたはＸＭＬアプリケーションとＪａｖａ（Ｒ）、Ｃ、またはＣ＋＋アプリケーションとの間、またはＪａｖａ（Ｒ）アプリケーションとＣまたはＣ＋＋アプリケーションとの間で両方向にコマンドおよびデータを送る、データ・トランスフォーマを提供するのに特に有用である。
【００１７】
【課題を解決するための手段】
本発明の一実施形態は、エンド・ユーザ・アプリケーションおよび１つまたは複数のアプリケーション・サーバで、またはこれらの間でアプリケーション要求を処理する方法である。この方法には、エンド・ユーザ・アプリケーションに対するアプリケーション要求を第１言語で第１アプリケーション・プログラムを用いて開始するステップと、アプリケーション要求をサーバに送信し、アプリケーション要求を第１エンド・ユーザ・アプリケーションの第１言語からアプリケーション・サーバ上で稼動する言語に変換するステップが含まれる。通常、上で説明したように、クライアントは、シン・クライアントまたはウェブ・ブラウザであり、クライアント上で稼動するアプリケーションは、ウェブ・ブラウザ・アプリケーションまたはシン・クライアント接続性アプリケーションであり、クライアント・アプリケーションの言語は、Ｊａｖａ（Ｒ）、Ｃ、Ｃ＋＋、あるいは、ＨＴＭＬまたは、ＸＭＬまたはＤｙｎａｍｉｃ ＨＴＭＬまたはＷＭＬなどのＨＴＭＬの派生物のマークアップ言語であり、サーバ上で稼動する言語は、ＣＯＢＯＬ、ＰＬ／Ｉ、ＨＬＡＳＭ（ＨｉｇｈＬｅｖｅｌ Ａｓｓｅｍｂｌｅｒ）または類似物である。本発明は、アプリケーション要求をエンド・ユーザ・アプリケーションの第１言語からアプリケーション・サーバ上で稼動する言語に変換するトランスフォーマを促進する。変換の後に、変換されたアプリケーション要求が、アプリケーション・サーバ上で処理される。
【００１８】
アプリケーションは、要求を処理し、その後、アプリケーション・サーバからエンド・ユーザ・アプリケーションに応答を送り返す。通常、上で説明したように、アプリケーション・サーバは、ＣＯＢＯＬベースのアプリケーションを実行しており、クライアントは、Ｊａｖａ（Ｒ）またはＣまたはＣ＋＋で記述されたシン・クライアント、もしくは、ＨＴＭＬあるいはＸＭＬまたはＤｙｎａｍｉｃＨＴＭＬまたは類似物などのＨＴＭＬの派生物などのマークアップ言語の、ウェブ・ブラウザ・アプリケーションまたはシン・クライアント接続性アプリケーションを実行するウェブ・ブラウザである。本発明は、１つまたは複数のアプリケーション・サーバ上で稼動する１つまたは複数の言語から第１エンド・ユーザ・アプリケーションの第１言語に応答を変換するデータ・トランスフォーマを提供する。
【００１９】
エンド・ユーザ・アプリケーションおよびアプリケーション・サーバは、その間に少なくとも１つのデータ・トランスフォーマを有する。この形で、（ｉ）ソース言語としての第１エンド・ユーザ・アプリケーションの第１言語からターゲット言語としてのアプリケーション・サーバ上で稼動する言語に要求を変換するステップと、（ｉｉ）後続のソース言語としてのアプリケーション・サーバ上で稼動する言語から後続のターゲット言語としての第１エンド・ユーザ・アプリケーションの第１言語に応答を変換するステップとのそれぞれに、各々のソース言語およびターゲット言語の型記述子および言語メタモデルを呼び出すステップと、各々のソース言語およびターゲット言語のデータ項目および型のそれぞれを用いてメタモデルを移植するステップと、ソース言語をターゲット言語に変換するステップとが含まれる。
【００２０】
エンド・ユーザ・アプリケーションは、ウェブ・ブラウザまたはシン・クライアントであることがしばしばである。エンド・ユーザ・アプリケーションが、ウェブ・ブラウザである時には、エンド・ユーザは、ウェブ・サーバを介してアプリケーション・サーバに接続される。本発明のもう１つの実施形態によれば、ウェブ・サーバに、コネクタまたはデータ・トランスフォーマを含めることができる。ウェブ・サーバに統合されたデータ・トランスフォーマは、要求、アプリケーション要求、またはメッセージを、ブラウザ指向の形からアプリケーション・サーバ言語または、ＸＭＬなどの中間のビジネス指向またはコマース指向のマークアップ言語に直接に変換することができる。
【００２１】
コンバータを構成するのに使用されるＣＡＭメタモデルには、呼出しメタモデル、アプリケーション・ドメイン・インターフェース・メタモデル、言語メタモデル、および型記述子メタモデルが含まれる。例示的な呼出しメタモデルには、メッセージ制御情報と、セキュリティ・データと、トランザクショナル・セマンティクスと、トレースおよびデバッグ情報と、事前条件リソースと、事後条件リソースと、ユーザ・データなどからなる群から選択された情報が含まれる。例示的なアプリケーション・ドメイン・インターフェース・メタモデルには、入力パラメータ・シグニチャ、出力パラメータ・シグニチャ、および戻りの型から選択される情報が含まれる。アプリケーション・ドメイン・インターフェース・メタモデルでは、ＣＯＢＯＬまたはＰＬ／Ｉメタモデルなどの１つまたは複数の言語メタモデルが使用される。
【００２２】
型記述子メタモデルでは、物理的実現、ストレージ・マッピング、データ型、データ構造体、および実現制約が定義される。
【００２３】
本発明の方法は、ソース言語またはターゲット言語の一方がオブジェクト指向であり、ターゲット言語またはソース言語の他方がオブジェクト指向でない情況に適用可能である。この情況では、言語メタモデルおよび型記述子メタモデルが、一緒に、オブジェクト指向言語のカプセル化されたオブジェクトを、オブジェクト指向でない言語のコードおよびデータにマッピングする。さらに、言語メタモデルおよび型記述子メタモデルは、オブジェクト指向言語のオブジェクト継承を、オブジェクト指向でない言語の参照およびポインタにマッピングする。本発明の方法は、異なるオブジェクト指向言語が異なるプラットフォーム上で稼動しており、ソース言語のカプセル化されたオブジェクト（コードおよびデータ）が、ターゲット言語のカプセル化されたオブジェクトにマッピングされる情況にも適用可能である。本発明の方法は、異なる手続き型言語が異なるプラットフォームまたはアプリケーションで稼動しており、ソース手続き型言語のコマンドおよびデータが、ターゲット手続き型言語にマッピングされる場合にも適用可能である。
【００２４】
本発明の方法によれば、垂直（シーケンシャル、条件、または依存）処理用、水平（時間的に並列）処理用、または垂直処理と水平処理の両方の、複数のアプリケーションが存在することができる。これは、処理の複数の階層レベルおよび複数の並列シーケンスへおよびそれらを介するリッチ・トランザクションをサポートするためである。これは、財務、製造、スケジューリング、供給、出荷のデータベースおよびサーバを利用し、さまざまな市販セキュリティ器具を使用する、企業対企業のトランザクションにおいてそうである可能性がある。
【００２５】
本発明のもう１つの態様は、クライアント、サーバ、クライアントと１つまたは複数のサーバの間の少なくとも１つのトランスフォーマを有する、クライアント−サーバ処理システムである。
【００２６】
本発明のもう１つの態様は、クライアント・アプリケーションと相互作用するように構成され、制御される処理システムである。本発明のこの態様では、システムに、サーバと、サーバとクライアント・アプリケーションとの間の少なくとも１つのトランスフォーマが含まれ、クライアントが、エンド・ユーザ・アプリケーションを有し、第１アプリケーション・プログラムを用いて第１言語でサーバに関する要求を開始し、その要求をトランスフォーマを介して１つまたは複数のサーバに送信するように制御され、構成される。サーバは、要求を、第２言語を使用する第２ソフトウェア・アプリケーションで処理し、トランスフォーマを介してクライアントに応答を返す。
【００２７】
本発明のもう１つの態様は、電子メール、ワード・プロセッシング、スプレッドシート、単純なデータベース管理（Ｌｏｔｕｓ ＡｐｐｒｏａｃｈまたはＭｉｃｒｏｓｏｆｔ Ａｃｃｅｓｓなど）、グラフィックスおよびグラフィックス編集、オーディオおよびオーディオ編集、およびコンピュータ・テレフォニ統合（「ＣＴＩ」）などの、複数の電子メール対応エンド・ユーザ・アプリケーションを、クライアント・レベル・コンテンツ・データベース・クライアント・サービスおよびコンテンツ複製クライアント・サービスと共に有するグループウェア・システムである。グループウェアによって、これらの電子メール対応アプリケーションを、１つまたは複数のトランスフォーマと、トランスポート・サービス、ディレクトリ・サービス、およびコンテンツ・サーバと複製サーバとを含むストレージ・サービスとのアプリケーション・プログラム・インターフェースとを介して統合できるようになる。グループウェア・システムは、異なるエンド・ユーザ・アプリケーションの間、異なるサーバの間、および異なるサーバとエンド・ユーザ・アプリケーションの間で通信するように構成され、制御される。グループウェア・システムには、サーバとエンド・ユーザ・アプリケーションの間の少なくとも１つのトランスフォーマが含まれる。エンド・ユーザ・アプリケーションは、第１アプリケーション・プログラムの第１言語でサーバに関係するように制御され、構成され、サーバは、第２プログラムの第２言語でクライアントに関係するように構成され、制御される。
【００２８】
トランスフォーマは、エンド・ユーザ・アプリケーションから要求を受信し、その要求を第１エンド・ユーザ・アプリケーションの第１言語からサーバで稼動する言語に変換するように構成され、制御される。サーバは、変換された要求をトランスフォーマから受信し、サーバに常駐する第２アプリケーション・プログラムを用いて第２言語で要求を処理し、その後、トランスフォーマを介してエンド・ユーザ・アプリケーションに応答を送り返すように構成され、制御される。
【００２９】
本発明のもう１つの実施形態は、リッチ・トランザクション処理の提供である。リッチ・トランザクションは、複数のサーバへ、複数のサーバを介して、または複数のサーバにまたがって、およびあるいはこれらの組合せにスパンする、入れ子になったトランザクションである。入れ子になったサーバにまたがるスパンは、水平すなわち、並列の従属トランザクション、または垂直すなわち直列の従属トランザクションとすることができる。リッチ・トランザクションは、長寿命の進行中のトランザクション、または、複雑な企業対企業のトランザクション、特に複数の依存性または偶発性、大量および即座の支払いディスカウント、配送遅れおよび支払いの遅れのペナルティ、および、電子信用状、電子船荷証券、電子支払い保証、電子支払い、エスクロウ、商品の担保権、および類似物などの財務処理を伴うトランザクションとすることができる。リッチ・トランザクション環境では、いくつかのトランザクション・サーバを、リッチ・トランザクションを構成するあるサブ・トランザクションについて他のトランザクションに関するクライアントとして位置付けることができる。
【００３０】
本発明のもう１つの実施形態は、プログラム製品が、呼出しメタモデル、アプリケーション・ドメイン・インターフェース・メタモデル、および言語メタモデルと、ソース言語メタモデルおよびターゲット言語メタモデルのメタモデル・リポジトリを構築するコンピュータ命令を有するストレージ・メディア（複数のコンピュータの１つの、テープ、フロッピ・ディスク、ＣＤ−ＲＯＭ、または１つまたは複数のハード・ドライブなど）であることを特徴とする、ツールすなわち、ソフトウェア開発者キットである。プログラム製品には、メタモデルからコネクタ・スタブを構築するコンピュータ命令も含まれる。プログラム製品は、さらに、トランスフォーマを構築するコンピュータ命令を担持する。
【００３１】
本発明を、単一のレベルのコネクタを有するものとして要約の形で説明したが、そのようなコネクタが、もちろんたとえばウェブ・クライアントとウェブ・サーバの間、ウェブ・サーバとアプリケーション・サーバの間、アプリケーション・サーバとデータベース・サーバの間、およびアプリケーション・サーバまたはデータベース・サーバもしくはその両方とさまざまな特殊リポジトリの間など、処理階層内のさまざまなレベルに存在することができることを理解されたい。
【００３２】
本発明を個々のクライアントおよび個々のサーバに関して要約したが、グループウェア・アプリケーションによって例示されるように、複数のクライアント、複数のサーバ、およびクライアントとサーバの両方として機能するアプリケーションが存在することができ、リッチ・トランザクションのシステムのように、アプリケーション・サーバ、データ・サーバ、およびデータベースの、複数の並列のラインまたは複数の階層レベルもしくはその両方が存在することができることも理解されたい。
【００３３】
【発明の実施の形態】
定義。本明細書で使用される時に、以下の用語は、示された意味を有する。「ハンドシェーク」は、各接続に先立つ、２つのアプリケーションの間の情報の交換と、その結果の、どの言語、機能、およびプロトコルを使用するかに関する合意である。
【００３４】
「アプリケーション・プログラム・インターフェース」（ＡＰＩ）は、コンピュータ・オペレーティング・システムまたは別のアプリケーション・プログラムによって規定される受動的な特定のメソッドであり、これによって、アプリケーション・プログラムを記述するプログラマが、オペレーティング・システムまたは別のアプリケーションに要求を行うことができる。例が、ＳＡＸ（Ｓｉｍｐｌｅ ＡＰＩ ｆｏｒ ＸＭＬ）、すなわち、プログラマが、Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅを使用するウェブ・ファイルすなわち、データの集合を記述するウェブ・ファイルを解釈できるようにするコネクタである。ＳＡＸは、「イベント駆動」インターフェースである。プログラマは、発生する可能性があるイベントを指定し、そのイベントが実際に発生した場合に、ＳＡＸが、制御を得、その状況を処理する。ＳＡＸは、直接にＸＭＬパーサと共に作動する。
【００３５】
本明細書で使用される「コネクタ」は、ターゲット・プラットフォームまたはプログラムの関数およびパラメータが格納されたプラットフォームの間の動的な実行時インターフェースであり、ターゲット・プラットフォーム・プログラムをリアル・タイムでバインドする。
【００３６】
「スタブ」は、サーバへの静的インターフェースを提供する小さいプログラム・ルーチンである。事前にコンパイルされたスタブによって、クライアントがサーバ上の対応するサービスを呼び出す方法が定義される。スタブは、サーバ上のより長いプログラムに代わり、サーバ・オブジェクトに関するローカル呼出しまたはローカル・プロキシとして働く。スタブは、要求を受け入れ、その後、その要求をリモート・プロシージャに転送する（別のプログラムを介して）。そのプロシージャは、そのサービスを完了した時に、結果または他の状況をスタブに返し、スタブは、要求を行ったプログラムにそれを渡す。サーバ・サービスは、スタブ内で、インターフェース定義言語（「ＩＤＬ」）を使用して定義される。クライアントは、それがアクセスするサーバ・インターフェースごとに１つのＩＤＬスタブを有し、このＩＤＬスタブに、マーシャルを実行するコードが含まれる。サーバ・スタブは、サーバによってエクスポートされる各サービスへの静的インターフェースを提供する。
【００３７】
「ＣＩＣＳ」（顧客情報管理システム）は、ＣＯＢＯＬ（Ｃｏｍｍｏｎ ＢｕｓｉｎｅｓｓＯｒｉｅｎｔｅｄ Ｌａｎｇｕａｇｅ）プログラミング言語と共に、大企業メインフレーム・コンピューティングの世界で顧客トランザクション・アプリケーションを構築するツールの組である、ＩＢＭ社のオンライン・トランザクション処理プログラムである。ＣＩＣＳによって供給されるプログラミング・インターフェースを使用して、ＣＩＣＳ内で顧客レコードおよび他のレコード（注文、在庫額、顧客データなど）を記述することによって、プログラマが、ＩＢＭ社のアクセス・メソッドを直接に使用するのではなく、ＣＩＣＳ機能を使用して、オンライン・ユーザと通信し、データベース（通常は「データ・セット」と称する）から読み取るプログラムを記述することができる。ＣＩＣＳは、トランザクションが完了されることを保証し、そうでない場合には、部分的に完了したトランザクションを元に戻し、その結果、データ・レコードの保全性が維持されるようにすることができる。ＣＩＣＳ製品は、ＯＳ／３９０オペレーティング・システム、ＵＮＩＸ（Ｒ）オペレーティング・システム、およびＩｎｔｅｌＰＣオペレーティング・システム用に供給される。ＣＩＣＳを用いると、エンド・ユーザが、ＩＢＭ社のＴｒａｎｓａｃｔｉｏｎ Ｓｅｒｖｅｒを使用して、インターネット・ユーザからのｅ−ｂｕｓｉｎｅｓｓトランザクションを処理し、これらを、既存のＣＩＣＳ注文および在庫データベースにアクセスするメインフレーム・サーバに転送できるようになる。
【００３８】
「ＩＭＳ」（情報管理システム）は、ＩＢＭ社のエンタープライズ・システム体系（ＩＭＳ／ＥＳＡ）と共に、トランザクション・マネージャおよび階層データベース・サーバを提供する、ＩＢＭ社のシステムである。
【００３９】
「ＭＱ」は、そのコンポーネントが他のソフトウェア・アプリケーションを一緒に結び付けるのに使用され、その結果、それらが一緒に動作できるようにする、ＭＱＳｅｒｉｅｓ　ＩＢＭソフトウェア・ファミリである。このタイプのアプリケーションを、しばしば、ビジネス・インテグレーション・ソフトウェアまたはミドルウェアと称する。機能的には、ＭＱＳｅｒｉｅｓは、異なるプラットフォーム上のアプリケーションの間の通信機構、ビジネス・オペレーション・ルールを集中化し、適用するインテグレータ、および、ビジネス・プロセスの取込、視覚化、および自動化を可能にするワークフロー・マネージャを提供する。ＭＱＳｅｒｉｅｓは、異なった地理的位置にある、似ていないＩＴインフラストラクチャを使用する、異なるコンピュータ・システムを接続し、その結果、シームレスな動作を実行できるようにする。ＩＢＭ社のＭＱＳｅｒｉｅｓは、アプリケーション間および異なるシステム上のユーザおよびアプリケーションの組の間の通信を供給する。さらに、ＭＱＳｅｒｉｅｓのメッセージング方式は、メッセージを受信するアプリケーションが受信を確認することを必要とする。確認が具体化されない場合には、メッセージが、ＭＱＳｅｒｉｅｓによって再送信される。
【００４０】
「Ｒｏｓｅ」は、エンタープライズレベル・ソフトウェア・アプリケーションのビジュアル・モデリングおよびコンポーネント構成に充てられるオブジェクト指向統一モデリング言語（ＵＭＬ）ソフトウェア設計ツールである。Ｒｏｓｅは、ソフトウェア設計者が、記号のドラッグアンドドロップを使用して、シーケンス図でアクタ（スティック人形）、ユース・ケース要素（楕円）、オブジェクト（長方形）、およびメッセージ／関係（矢印）を用いてクラスの輪郭を描くことによって、アプリケーションのフレームワークを視覚的に作成（モデル化）できるようにする。Ｒｏｓｅでは、図が、構成されつつある間に文書化され、その後、Ｃ＋＋、ＶｉｓｕａｌＢａｓｉｃ、Ｊａｖａ（Ｒ）、Ｏｒａｃｌｅ８、Ｃｏｒｂａ、またはデータ定義言語のうちの設計者が選択したもののコードが生成される。
【００４１】
共通アプリケーション・メタモデルの概要。共通アプリケーション・メタモデル（ＣＡＭ）は、図１に示された環境に相互接続性をもたらす。図１には、ＮｅｔｓｃａｐｅまたはＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒブラウザ１０３、Ｓｕｎ Ｓｏｌａｒｉｓサーバ１０７上のＮｅｔ．Ｃｏｍｍｅｒｃｅ１０５、データベース・サーバ１１３上のＯｒａｃｌｅ１０９およびＤＢ２　１１１、ＡＩＸ１１７で稼動するＳＡＰ１１５、ＣＩＣＳ３９０サーバ１１９、ＩＭＳ　３９０サーバ１２１、Ｓ／３９０プラットフォーム１２７上のＤＢ２　１２３およびＤＬ／Ｉ　１２５、Ｗｉｎｄｏｗｓ（Ｒ）２０００クライアント１２９、およびＨＰ　Ｕｎｉｘ（Ｒ）サーバ１３３上で稼動するＢａａｎ１３１を含む、複数のアプリケーション・コンポーネントを有する通常のシステム１０１を示す図である。共通アプリケーション・メタモデル（ＣＡＭ）は、図１内などのエンタープライズ・アプリケーションにソース言語でアクセスし、それらをターゲット言語に変換するのに必要な情報のマーシャルおよび適用のためのメタデータ交換の方法、ツール、およびシステムである。ＣＡＭは、図２に示されているように、言語メタモデルおよびアプリケーション・ドメイン・インターフェース・メタモデルからなり、図２には、エンタープライズ・アプリケーション統合２２１を促進するために共通アプリケーション・メタモデルのメタデータ・リポジトリ２１１への入力としてのメッセージ・セット２０３、ＳＱＬストアド・プロシージャ２０５、レガシ・アプリケーション２０７、およびプログラミング言語２０９の役割が示されている。
【００４２】
例示的なメタモデルには、図３に示されているように、Ｃ、Ｃ＋＋、Ｊａｖａ（Ｒ）、ＣＯＢＯＬ、ＰＬ／Ｉ、ＨＬＡｓｓｅｍｂｌｅｒ、ＩＭＳトランザクション・メッセージ、ＩＭＳ　ＭＦＳ、ＣＩＣＳ　ＢＭＳ、およびＭＱＳｅｒｉｅｓメッセージ・モデルが含まれ、図３には、呼出しメタモデル３０１、アプリケーションドメイン・インターフェース・メタモデル３０３、および言語メタモデル３０５と共に、本発明の共通アプリケーション・メタモデルが示されている。
【００４３】
図４に、ＯＴＭＡ呼出しメタモデル４２１、ＩＭＳトランザクション・メッセージ・メタモデル４２３、ＣＯＢＯＬメタモデル４２５、およびＣメタモデル４２７と共に、ＩＭＳ　ＯＴＭＡアプリケーション・インターフェース・メタモデル４１１を示す。
【００４４】
図５に、既存のアプリケーション５０１からインターフェース５０３を介してアプリケーション・インターフェース・メタデータを含むオブジェクト・モデルへの情報の流れを示す。このアプリケーション・インターフェース・メタモデルは、メタデータ・リポジトリ５０５に格納され、適当な時にメタデータ・リポジトリ５０５から検索され、生成ツール５０９でソース・プログラム５０７と組み合わされ、ＸＭＬファイルとしてのターゲット・ファイル５１１すなわちＸＭＩインスタンス・ファイルの生成に使用される。ＣＡＭは、大いに再利用可能であり、特定のツールまたはミドルウェアから独立である。
【００４５】
開発ステージ。ＣＡＭがあれば、ツーリングによって、エンタープライズ・アプリケーション、たとえばＩＭＳアプリケーションへのアクセスに対する解決策を簡単に提供することができる。各ソース・ファイルを解析し、ＣＡＭモデル、ＣＯＢＯＬコピーブック、ＰＬ／Ｉコピーブック、ＭＦＳソース、ＢＭＳソースなどに基づいてＸＭＬ文書を生成することによって、ツールが、ＩＭＳ、ＣＩＣＳなどに対するコネクタ解決策を提供することができる。
【００４６】
これに関して、図６に、たとえばＣＯＢＯＬメタモデル、ＰＬ／Ｉメタモデル、ＭＦＳメタモデル、ＢＭＳモデル、または類似物などの共通アプリケーション・メタモデルＲｏｓｅファイル６０１が、ツールキット６０３に読み込まれて、ＲｏｓｅモデルのＤＴＤおよびスキーマとＲｏｓｅモデル６０５のＪａｖａ（Ｒ）コードが生成される開発フェーズのシナリオを示す。ＣＯＢＯＬソース・ファイル、ＰＬ／Ｉソース・ファイル、ＭＦＳソース・ファイル、ＢＭＳソース・ファイル、または類似物として、およびＲｏｓｅモデル６０９のＪａｖａ（Ｒ）コードとして、アプリケーションのソース・ファイル６０７が、インポータ６１１に読み込まれる。インポータは、ソース・コードを解析し、出力としてＸＭＩインスタンス・ファイル６１３すなわちアプリケーション・ソース・ファイルのＸＭＬ文書を提供する。
【００４７】
図７に、アプリケーション・インターフェースのＣＡＭメタモデルを示す。この図には、アプリケーション・インターフェース・メタモデル７０７に従って、既存のアプリケーション・プログラムのインターフェース定義を含むインターフェース７０５を介して既存のアプリケーション・プログラム７０３とインターフェースする、呼出し機能および変換機能を有する実行時コネクタ７０１が示されている。アプリケーション・インターフェース・メタデータは、メタデータ・リポジトリ７０９に格納される。
【００４８】
フローおよびメッセージング・ミドルウェア７１３が、アプリケーション・インターフェース７０５を介してアプリケーション７０３を呼び出す。これらのインターフェース７０５は、それを介してすべての入出力がミドルウェア７１３に接続されるアプリケーション７０３へのアクセス点である。インターフェース７０５は、アプリケーション・インターフェース・メタモデルに関して記述される。メタモデルによる変換処理は、ソース／クライアント・アプリケーション、ターゲット・アプリケーション、またはゲートウェイで行うことができる。
【００４９】
ＣＡＭは、データ型およびストレージ・マッピングの物理的表現を提供して、エンタープライズ・アプリケーション統合環境でのデータ変換をもサポートするので、エンタープライズ・アプリケーション用のウェブ・サービスを使用可能にする。開発時に、ＣＡＭは、下記を容易にする情報を取り込む。
ａ）．コネクタまたはコネクタビルダ・ツールあるいはその両方、
ｂ）．アプリケーション生産性および品質保証に関するデータ駆動影響分析、および
ｃ）．開発者によるプログラミング言語データ宣言の考察。
【００５０】
ＣＡＭメタモデル・ファイルは、ＣＡＭモデルを表すＤＴＤファイル、ＸＭＬスキーマ、およびＪａｖａ（Ｒ）クラスの生成に使用されるツールキットへの入力である。インポータは、各ソース・ファイル（たとえばＣＯＢＯＬまたはＰＬ／Ｉコピーブック、ＭＦＳソース、およびＢＭＳなど）を解析し、その後、ＸＭＩ／ＭＯＦ２ツールキットによって生成されたＪａｖａ（Ｒ）クラスに基づいてＸＭＬ文書（すなわちＸＭＬインスタンス・ファイル）を生成する。
【００５１】
実行時。実行時に、ＣＡＭは、それが混合言語間のデータ型マッピングを提供するエンタープライズ・アプリケーション統合環境での変換を容易にする情報を提供し、ある言語およびプラットフォーム・ドメインから別の言語およびプラットフォーム・ドメインへのデータ変換を容易にする。
【００５２】
図８に、実行時中の共通アプリケーション・メタモデルの適用を示す。図からわかるように、ＳＯＡＰ準拠ＸＭＬ文書８０３が、たとえばＩＢＭ ＷｅｂＳｐｈｅｒｅミドルウェア８０５内で受け取られ、このＩＢＭ ＷｅｂＳｐｈｅｒｅミドルウェア８０５は、Ｊａｖａ（Ｒ）用のＩＭＳＣｏｎｎｅｃｔｏｒ８０７を含み、ＸＭＬリポジトリ８０９と接触し、ＸＭＬリポジトリ８０９には、ＣＡＭモデルのＸＭＩインスタンス・ファイルが含まれる。ＩＢＭＷｅｂＳｐｈｅｒｅミドルウェアは、変換されたファイルをＩＭＳシステム８１１に送り、ＩＭＳシステム８１１には、ＩＭＳ接続８１３とＩＭＳトランザクショナル・アプリケーション・プログラム８１５のインスタンスが含まれる。ＣＡＭは、バックエンドのＩＭＳアプリケーション８１５とウェブ・ファイル（たとえばＳＯＡＰ準拠ＸＭＬ文書）８０３の間の接続性を促進する。ＣＡＭは、ＣＡＭモデル情報（リポジトリ８０９からの）を使用して、図示の混合言語環境で、あるプラットフォームから別のプラットフォームへのデータ変換を実行することによって、これを達成する。
【００５３】
ＴｙｐｅＤｅｓｃｒｉｐｔｏｒメタモデル。ＣＡＭによって提供される１つの重要な特徴が、ＴｙｐｅＤｅｓｃｒｉｐｔｏｒメタモデルである。ＴｙｐｅＤｅｓｃｒｉｐｔｏｒメタモデルによって、物理的実現、ストレージ・マッピング、および実現に対する制約（位置調整など）が定義される。このメタモデルによって、所与のデータ構造体の個々のフィールドの物理的表現が提供される。エンタープライズ・アプリケーション統合環境でデータ変換をサポートする時に、このモデルによって、混合言語の間でのデータ型マッピングが提供される。このモデルによって、ある言語およびプラットフォーム・ドメインから別の言語およびプラットフォーム・ドメインへのデータ変換も容易になる。メタモデルは、全体的なデータ構造体名およびフィールド名の言語固有メタモデルを用いる実行時データ変換（またはマーシャル）に使用される。
【００５４】
１．アプリケーション・インターフェースに関する共通アプリケーション・メタモデル
図１に示されたように、異なるオペレーティング・システム、物理プラットフォーム、および物理的実現を有する、異なるソフトウェア・プラットフォームで稼動する異なる似ていないアプリケーションは、相互接続メタデータを組み込んだコネクタを介して達成される。コネクタは、ｅ−ｂｕｓｉｎｅｓｓに関するアプリケーション・フレームワークの中心部分である。エンド・ユーザの要求は、興味を持たれるすべてのものにできる限りすばやくできる限り簡単に接続することである。
【００５５】
アダプタとレガシ・アプリケーションのインターフェース要件を一致させるために、コネクタが必要である。２つのインターフェースの間でのマッピングも必要である。本明細書で提示されるアプリケーション・インターフェースの標準化されたメタモデルを用いると、複数のコネクタ・ツールでの情報の再利用が可能になる。これらの標準化されたメタモデルによって、コネクタを作成する作業が減るだけではなく、コネクタ・ビルダ・ツールを開発するのに必要な作業も減る。
【００５６】
本発明の共通アプリケーション・メタモデルを使用して構築されるコネクタは、既存のアプリケーションとのインターオペラビリティを提供する。コネクタは、既存のアプリケーション・システム内で保持されるデータおよびビジネス・ロジックの活用および再利用をサポートする。コネクタの仕事は、あるアプリケーション・システム・サーバ・「インターフェース」から別のアプリケーション・システム・サーバ・インターフェースに接続することである。したがって、アプリケーションドメイン・インターフェース・メタモデルによって、所与のアプリケーション・システム・ドメイン（たとえばＩＭＳ、ＭＱＳｅｒｉｅｓ）の入出力パラメータのシグニチャおよび戻りの型が記述されるが、これは、特定のＩＭＳアプリケーション・プログラムまたはＭＱＳｅｒｉｅｓアプリケーション・プログラムに関するものではない。メタモデルには、構文インターフェース・メタデータおよびセマンティック・インターフェース・メタデータの両方が含まれる。
【００５７】
１．ａ．共通アプリケーション・メタモデルを使用するエンドツーエンド・コネクタ使用
共通アプリケーション・メタモデル（ＣＡＭ）は、特定のツールまたはミドルウェアから独立の、メッセージ・シグニチャのメタ定義からなる。異なるコネクタ・ビルダ・ツールが、この情報を使用して、これらのアプリケーション・プログラム間での、異なるツール、言語、およびミドルウェアにまたがる「ハンドシェーク」を保証することができる。たとえば、ＭＱＳｅｒｉｅｓアプリケーションを呼び出す必要がある場合には、ＧＵＩツールからのデータを使用してＭＱメッセージを構築し、ＭＱ　ＡＰＩを使用してそのメッセージを送達する必要がある。同様に、ＭＱＳｅｒｉｅｓアプリケーションからメッセージを受け取った時には、ＭＱＳｅｒｉｅｓからバッファを入手し、それを解析し、それをＧＵＩツール・データ構造体に入れる必要がある。これらの機能は、アプリケーション・インターフェースの標準化メタモデルとしてＣＡＭを使用するコネクタ・ビルダ・ツールによって、効率的に設計し、実装することができる。
【００５８】
ＣＡＭを、コピー・ブックを含む多数のソースから移植して、入力を収集し出力を返すＨＴＭＬフォームおよびＪａｖａ（Ｒ） Ｓｅｒｖｅｒ Ｐａｇｅ（ＪＳＰ）を生成することができる。前の図に示されたコネクタの例は、フローおよびメッセージ・ミドルウェアが、コネクタを呼び出すことによってエンタープライズ・アプリケーションへの関数呼出しを行い、このコネクタがエンタープライズ・アプリケーションＡＰＩを呼び出すということである。コネクタは、言語およびデータ型のマッピングを行って、たとえば、ＸＭＬ文書とＣＯＢＯＬ入力の間で変換し、ＣＡＭに基づくデータ構造体を出力する。コネクタおよびＣＡＭは、ミドルウェアとエンタープライズ・アプリケーションの間のエンドツーエンド統合を提供する。
【００５９】
例としてＩＭＳを使用する。自分のデスクトップ機からＩＭＳトランザクション・アプリケーション・プログラムにアカウント番号を渡して、５０．００ドルを引き出さなければならないと仮定する。ＣＡＭおよびコネクタ・ビルダ・ツールがあれば、まず、入力ＨＴＭＬフォームおよび出力ＪＳＰを生成し、要求をサポートするのに必要なミドルウェア・コードを開発することになる。デスクトップ・アプリケーションが、要求データ構造体（すなわち、入力ＨＴＭＬフォーム）に値を書き込み、ミドルウェアを呼び出す。ミドルウェア・サービス・コードは、ＧＵＩツールからデータを受け取り、ＩＭＳ ＣｏｎｎｅｃｔのＸＭＬフォーマットのメッセージを構築し、そのメッセージを、ＴＣＰ／ＩＰを介してＩＭＳゲートウェイ（すなわちＩＭＳＣｏｎｎｅｃｔ）に送達する。ＩＭＳ Ｃｏｎｎｅｃｔは、ＣＡＭに取り込まれたメタデータ定義を使用して、ＸＭＬ文書とＣＯＢＯＬのＩＭＳメッセージ・データ構造体の間で変換する。その後、ＩＭＳＣｏｎｎｅｃｔは、ＩＭＳメッセージ・データ構造体を、Ｏｐｅｎ Ｔｒａｎｓａｃｔｉｏｎ Ｍａｎａｇｅｒ Ａｃｃｅｓｓ（ＯＴＭＡ）を介してＩＭＳに送る。ＩＭＳ　ＣＯＢＯＬアプリケーション・プログラムが、稼動し、ＩＭＳＣｏｎｎｅｃｔを介して出力メッセージをミドルウェア・サービス・コードに返す。ミドルウェア・サービス・コードは、メッセージを入手し、応答データを出力ＪＳＰページ（すなわち、前に生成されたＧＵＩツール応答データ構造体）に移植する。その後、トランザクション出力データが、ユーザに提示される。
【００６０】
２．共通アプリケーション・メタモデル
ＣＡＭは、共通のプログラミング・モデルで開発されたアプリケーションを、他のシステムと簡単に統合するのに必要な情報を記述するのに使用される。ＣＡＭメタモデルは、同期式呼出しと非同期式呼出しの両方に使用することができる。
【００６１】
２．ａ．共通アプリケーション・メタモデル
以下で述べる共通アプリケーション・メタモデルは、呼出しメタモデルと、言語メタモデルを使用するアプリケーションドメイン・インターフェース・メタモデルからなる。所与のアプリケーションドメイン・インターフェース・メタモデルについて、そのメタモデルは、１つまたは複数の言語メタモデルを使用することができるが、０個以上の呼出しメタモデルを設けることができる。
【００６２】
共通コネクタ・メタモデルを、図３に示す。これは、呼出しメタモデル３０１、アプリケーションドメイン・インターフェース・メタモデル３０３、および言語メタモデル３０５を有する。
【００６３】
２．ａ．ｉ．呼出しメタモデル
呼出しメタモデル３０１は、１つまたは複数の下記の可能なメタデータ要素からなる。しかし、特定の呼出しに関して、呼出しメタモデルに、１つまたは複数の下記のメタデータ要素だけを含めることができる。
【００６４】
メッセージ制御情報。これには、メッセージ接続名、メッセージ・タイプ、シーケンス番号（ある場合）、および、応答、コミット確認、および処理オプション（これによって、クライアントまたはサーバが、メッセージ処理を同期式または非同期式になるように制御することができる）に関するさまざまなフラグおよびインジケータなどのメッセージ制御情報が含まれる。
【００６５】
接続名は、すべての入出力を特定のクライアントに関連付けるために、アプリケーション・システム・サーバが使用することができる。メッセージ・タイプによって、メッセージが応答メッセージであること、またはコミットが完了したことが指定される。メッセージ・タイプによって、クライアントへのサーバ出力データまたはサーバへのクライアント入力データを示すこともできる。
【００６６】
セキュリティ・データ　−−　これには、認証機構と、たとえばディジタル証明書、識別、ユーザ名およびパスワードなどのセキュリティ・データが含まれる。これには、ロール・ベースの認証またはＡＣＬ（アクセス制御リスト）ベースの認証を介してデータを許可することができるかどうかを示す認証情報も含めることができる。
【００６７】
トランザクション・セマンティクス　−−　これは、たとえばローカル・トランザクション対グローバル・トランザクション、２フェーズ・コミット対１フェーズ・コミット、およびトランザクション・コンテキストなどのトランザクション情報を搬送する。
【００６８】
トレースおよびデバッグ　−−　トレースおよびデバッグ情報は、メタモデルの一部として指定される。
【００６９】
事前条件リソースおよび事後条件リソース　−−　これによって、アプリケーション状態の事前条件および事後条件の関係が記述される。
【００７０】
ユーザ・データ　−−　これには、クライアントによって要求される特殊な情報のすべてが含まれる。これには、どのようなデータでも含めることができる。
【００７１】
２．ａ．ｉｉ．アプリケーションドメイン・インターフェース・メタモデル
前に述べたアプリケーションドメイン・インターフェース・メタモデル３０３によって、アプリケーション・システム・ドメインに関する、入出力パラメータのシグニチャおよび戻りの型が記述される。
【００７２】
２．ａ．ｉｉｉ．言語メタモデル
たとえばＣＯＢＯＬメタモデルなどの言語メタモデル３０５は、コネクタ・インターフェースを表すデータ構造体（セマンティクス）を定義するために、エンタープライズ・アプリケーション・システムによって使用される。コネクタ開発者に、ソース言語、ターゲット言語、およびこの２つの間のマッピングを見せることが、コネクタ・ツールにとって重要である。ＣＡＭ言語メタモデルには、編集可能でないモデル（すなわち、読取専用モデル）内の宣言テキストも含まれる。コネクタ／アダプタ開発者は、おそらく、コメントおよび宣言の各フィールドによって演じられるビジネス・ロールを理解するのに役立つ他のドキュメンテーションを含めて、ＣＯＢＯＬデータ宣言全体を見ることを好む。
【００７３】
言語メタモデルは、アプリケーションの生産性および品質保証のためのデータ駆動影響分析もサポートする（しかし、コピーブックの複写をサポートすることは、ＣＡＭの意図ではない）。
【００７４】
コネクタ・データを記述する言語メタモデルを、下にリストする。
＊　Ｃ
＊　Ｃ＋＋
＊　ＣＯＢＯＬ
＊　ＰＬ／Ｉ
【００７５】
２．ａ．ｉｖ．ＴｙｐｅＤｅｓｃｒｉｐｔｏｒメタモデル
ＴｙｐｅＤｅｓｃｒｉｐｔｏｒメタモデルは、言語中立であり、このメタモデルによって、物理的実現、ストレージ・マッピング、および位置調整などの実現に対する制約が定義される。このメタモデルによって、所与のデータ構造体の個々のフィールドの物理的表現が提供される。この型記述子メタモデルは、エンタープライズ・アプリケーション統合環境でデータ変換をサポートして、混合言語の間でのデータ型マッピングを提供するためのものである。このメタモデルによって、ある言語およびプラットフォーム・ドメインから別の言語およびプラットフォーム・ドメインへのデータ変換も容易になる。このメタモデルは、全体的なデータ構造体名およびフィールド名の言語固有メタモデルを用いる実行時データ変換（またはマーシャル）の処方として使用される。
【００７６】
３．共通コネクタ・メタモデルの例
ＩＭＳ　ＯＴＭＡ（Ｏｐｅｎ Ｔｒａｎｓａｃｔｉｏｎ Ｍａｎａｇｅｒ Ａｃｃｅｓｓ）は、ＯＳ／３９０シスプレックス環境内のトランザクションベースのコネクションレス・クライアント／サーバ・プロトコルである。ＩＭＳ　ＯＴＭＡトランザクション・メッセージは、ＯＴＭＡプレフィックスと、入力要求および出力要求に関するメッセージ・セグメントからなる。入力メッセージ・セグメントと出力メッセージ・セグメントの両方に、ｌｌｚｚ（すなわち、セグメントの長さと予約済みフィールド）と、アプリケーション・データが含まれる。最初の入力メッセージ・セグメントだけに、アプリケーション・データの前にトランザクション・コードが含まれる。ＩＭＳトランザクション・アプリケーション・プログラムは、ＣＯＢＯＬ、ＰＬ／Ｉ、Ｃ、およびＪａｖａ（Ｒ）などのさまざまな言語で記述することができる。したがって、アプリケーション・データに、これらの言語のどれでも使用することができる。
【００７７】
図４に示されているように、ＩＭＳ　ＯＴＭＡアプリケーション・インターフェース・メタモデル４１１は、ＯＴＭＡ呼出しメタモデル４２１およびＩＭＳトランザクション・メッセージ・メタモデル４２３ならびにＣＯＢＯＬメタモデル４２５およびＣメタモデル４２７からなる。図４に示されているように、ＯＴＭＡ呼出しメタモデル４２１は、ＯＴＭＡプレフィックスであり、ＩＭＳトランザクション・メッセージ・メタモデル４２３は、言語メタモデルを使用するＩＭＳアプリケーション・システムのアプリケーションドメイン・インターフェース・メタモデルである。ＣＯＢＯＬメタモデル４２５およびＣメタモデル４２７が示されている。
【００７８】
４．ＴｙｐｅＤｅｓｃｒｉｐｔｏｒメタモデル
型記述子メタモデルは、配列および構造型を含む実装型を記述する言語独立かつプラットフォーム独立の形を提示する。この情報は、ある言語およびプラットフォーム・ドメインから別の言語およびプラットフォーム・ドメインにデータを変換しなければならない、マーシャルおよびコネクタに必要である。異なる言語の型モデルの検査によって、言語型の一致可能性を判定することができる。たとえば、Ｊａｖａ（Ｒ）のｌｏｎｇ型は、しばしば、ＣＯＢＯＬのｂｉｎａｒｙ型（ｃｏｍｐｕｔａｔｉｏｎａｌ−５）と同一であり、その場合には、これらの型を、副作用なしで相互変換することができる。その一方で、ＣＯＢＯＬのａｌｐｈａｎｕｍｅｒｉｃ型は、サイズが固定されるが、Ｊａｖａ（Ｒ）の型にマッピングされる場合に、この特性が失われる。Ｊａｖａ（Ｒ）からＣＯＢＯＬに再変換される時に、ＣＯＢＯＬの切詰規則が適用されず、計算の例外がもたらされる可能性がある。さらに、サーバ環境で言語を混合するツール（たとえばＣＩＣＳおよびＩＭＳのＪａｖａ（Ｒ）およびＣＯＢＯＬ）は、ある言語がどれほど忠実に別の言語の型を表現できるかを判定する方法としてこれが有用であることを見出すに違いない。したがって、型記述子メタモデルのインスタンスでは、特定のプラットフォームおよびコンパイラに関する特定のデータ型の物理的表現を記述する。
【００７９】
４．ａ．ＴＤＬａｎｇメタモデル
ＴＤＬａｎｇメタモデルは、ＴｙｐｅＤｅｓｃｒｉｐｔｏｒメタモデルとすべてのＣＡＭ言語メタモデルとの間の抽象のレイヤを提供することによって、ＣＡＭ言語メタモデルに対する基本クラスとして働く。ＴＤＬａｎｇクラスのすべてが、抽象クラスであり、すべてのＣＡＭ言語メタモデルに共通である。ＴＤＬａｎｇクラス間のすべての関連が、その関連が言語メタモデルから派生したことを反映するために、”ｖｏｌａｔｉｌｅ”、”ｔｒａｎｓｉｅｎｔ”、または”ｄｅｒｉｖｅｄ”としてマークされる。ＴＤＬａｎｇモデルは、独力では何の機能も提供しないが、ＴｙｐｅＤｅｓｃｒｉｐｔｏｒメタモデルから言語メタモデルへの関連の型ターゲットである。
【００８０】
図９に、ＴＤＬａｎｇＣｌａｓｓｉｆｉｅｒ９０１、ＴＤＬａｎｇＣｏｍｐｏｓｅｄＴｙｐｅ９０３、およびＴＤＬａｎｇＥｌｅｍｅｎｔ９０５と共にＴＤＬａｎｇメタモデルの構造を示す。
【００８１】
ＴＤＬａｎｇ基本クラスと共に、ＴｙｐｅＤｅｓｃｒｉｐｔｏｒメタモデルを、全体的なデータ構造体名およびフィールド名の言語固有メタモデルを用い、言語モデルに存在する集約関連を複製せずに、実行時データ変換（またはマーシャル）の処方として使用することができる。
【００８２】
４．ｂ．ＴｙｐｅＤｅｓｃｒｉｐｔｏｒメタモデル
このメタモデルは、Ｍ２レベルのＭＯＦクラスのインスタンスである。図１０、図１１、および図１２に、ＰｌａｔｆｏｒｍＣｏｍｐｉｌｅｒＴｙｐｅ、ＩｎｓｔａｎｃｅＴＤＢａｓｅ、ＡｒｒａｙＴＤ、ＡｇｇｒｅｇａｔｅＩｎｓｔａｎｃｅＴＤ、ＳｉｍｐｌｅＩｎｓｔａｎｃｅＴＤ、およびＩｎｓｔａｎｃｅＴｙｐｅを含む、型記述子メタモデル内の関係を示す。ＩｎｓｔａｎｃｅＴｙｐｅには、ＳｔｒｉｎｇＴＤ、ＡｄｄｒｅｓｓＴＤ、ＮｕｍｂｅｒＴＤ、およびＦｌｏａｔＴＤの定義が含まれる。図１３に、ＴＤＬａｎｇｕａｇｅＥｌｅｍｅｎｔ１１００とＰｌａｔｆｏｒｍＣｏｍｐｉｌｅｒＴｙｐｅ１１０１の高水準ビューを示す。図１４に、ｓｉｇｎＣｏｄｉｎｇ１２０１、ｌｅｎｇｔｈＥｎｃｏｄｉｎｇ１２０３、ｆｌｏａｔＴｙｐｅ１２０５、ａｃｃｅｓｓｏｒ１２０７、ｐａｃｋｅｄＤｅｃｉｍａｌＳｉｇｎ１２０９、およびｂｉｔＭｏｄｅＰａｄ１２１１の列挙を示す。
【００８３】
４．ｃ．ＴｙｐｅＤｅｓｃｒｉｐｔｏｒおよび言語モデル
ＴｙｐｅＤｅｓｃｒｉｐｔｏｒモデルは、ＴＤＬａｎｇＥｌｅｍｅｎｔとＩｎｓｔａｎｃｅＴＤＢａｓｅの間のナビゲート可能な関連によってＣＡＭ言語モデルに接続される。ＴＤＬａｎｇＥｌｅｍｅｎｔは、宣言されたデータ項目すなわち型のインスタンスを表すのに使用される基本言語モデル型である。ＩｎｓｔａｎｃｅＴＤＢａｓｅは、この同一の宣言されたデータ項目の実装固有インスタンスを表すのに使用される基本ＴｙｐｅＤｅｓｃｒｉｐｔｏｒモデル型である。ＩｎｓｔａｎｃｅＴＤＢａｓｅは、抽象クラスであり、そのサブタイプの１つだけをインスタンス化することができる。
【００８４】
プログラミング言語で宣言されたデータ項目が、異なる実装を有することができる可能性がある。これらの相違は、ハードウェア・プラットフォーム、システム・プラットフォーム、およびコンパイラの相違によって誘発される。この可能性は、ＰｌａｔｆｏｒｍＣｏｍｐｉｌｅｒＴｙｐｅモデル型によってモデル化される。ＴＤＬａｎｇＥｌｅｍｅｎｔとＰｌａｔｆｏｒｍＣｏｍｐｉｌｅｒＴｙｐｅの間の関連は、多対１であり、ＰｌａｔｆｏｒｍＣｏｍｐｉｌｅｒＴｙｐｅとＩｎｓｔａｎｃｅＴＤＢａｓｅの間の関連は、１対１である。言語モデルからナビゲートするために、どのＰｌａｔｆｏｒｍＣｏｍｐｉｌｅｒＴｙｐｅが前提になっているかを知る必要がある。実装において、モデル・インスタンスをインポートする際に、重要でないＰｌａｔｆｏｒｍＣｏｍｐｉｌｅｒＴｙｐｅインスタンスをモデルから除去することが望まれる可能性がある。ＴＤＬａｎｇＥｌｅｍｅｎｔとＩｎｓｔａｎｃｅＴＤＢａｓｅの間の関連を、この形でモデル化して、ハードウェア・プラットフォーム、システム・プラットフォーム、およびコンパイラをより完全に記述する新しい型とＰｌａｔｆｏｒｍＣｏｍｐｉｌｅｒＴｙｐｅの間の関連を含むようにモデルを拡張できるようにする。
【００８５】
データ要素インスタンスを、繰り返されるグループまたは配列として定義することができる。これは、ＩｎｓｔａｎｃｅＴＤＢａｓｅとＡｒｒａｙＴＤモデル型の間の１対多関連としてモデル化することができる。データ要素の次元、添字、または独立のインデックスのそれぞれについて、この関連に１つのＡｒｒａｙＴＤインスタンスがある。これらのインスタンスは、限界およびアクセス計算に関する情報を保持する。
【００８６】
関連は、言語モデル内の対応する関連と同一の順序で順序付けられ、プログラミング言語によって定義されるインデックスの構文的な順序付けを反映する。この選択の根本的な理由は、その結果の、言語モデルとＴｙｐｅＤｅｓｃｒｉｐｔｏｒモデルの間のナビゲーションおよび処理アルゴリズムの同等性である。おそらくマーシャル・エンジンにより有利なもう１つの選択は、インデックスの順序付けを、最小のストライドから最大のストライドにすることである。これによって、配列が普通の連続的な形で配置されると仮定して、マーシャル・エンジンが、配列を自然なストレージ順序で処理できるようになる。マーシャル・エンジンは、望まれる場合に、ストライド式に従って関連ターゲットをソートし直すことによって、この順序を計算することができる。
【００８７】
配列情報は、データ要素またはその型の複雑な特性になる可能性があり、さまざまな言語およびプログラミングの実践が、このどちらかに含まれると思われる。ＣおよびＣ＋＋のｔｙｐｅｄｅｆ機能を用いると、ｔｙｐｅｄｅｆからのいくつかの配列型の定義が可能であるが、これは、配列定義が、ｔｙｐｅｄｅｆ集約の最上位要素に適用される場合に限られる。たとえば、次のｔｙｐｅｄｅｆを検討されたい。
Figure 2004506264
このｔｙｐｅｄｅｆを使用して、固定サイズの配列の新しいｔｙｐｅｄｅｆ、たとえば
ｔｙｐｅｄｅｆ Ｘ Ｑ［１０］；
を作成することができる。しかし、Ｘのサブコンポーネントのどれか、たとえばＤまたはＥを配列にする新しいｔｙｐｅｄｅｆを、Ｘから作成することは不可能である。この例および多数の他の例によって、型付き言語での配列定義の不明瞭な状況が示される。
【００８８】
ＩｎｓｔａｎｃｅＴＤＢａｓｅ型は、２つの具象サブタイプ、ＳｉｍｐｌｅＩｎｓｔａｎｃｅＴＤおよびＡｇｇｒｅｇａｔｅＩｎｓｔａｎｃｅＴＤを有する。ＳｉｍｐｌｅＩｎｓｔａｎｃｅＴＤは、サブコンポーネントなしのデータ要素をモデル化し、ＡｇｇｒｅｇａｔｅＩｎｓｔａｎｃｅＴＤは、サブコンポーネントを有するデータ要素をモデル化する。ＡｇｇｒｅｇａｔｅＩｎｓｔａｎｃｅＴＤのサブコンポーネントを見つけるためには、ＣＡＭ言語モデルの対応するデータ要素宣言まで逆にナビゲートしなければならない。そこで、集約型とそのサブコンポーネントの間の関連をナビゲートすることができ、これがサブコンポーネント・データ要素の組につながり、そのそれぞれが、ＴｙｐｅＤｅｓｃｒｉｐｔｏｒモデルの１つまたは複数のインスタンスを有する。これによって、ある程度のモデル・ナビゲーションの複雑さが導入されるが、言語モデルとＴｙｐｅＤｅｓｃｒｉｐｔｏｒモデルの両方での集約階層の重複が回避される。トラバーサルの追加の処理の複雑さは、大きくはなく、モデルを修正して集約にサブコンポーネントを追加、削除、または再配置するアルゴリズムで、かなりの単純化が得られる。
【００８９】
ＳｉｍｐｌｅＩｎｓｔａｎｃｅＴＤモデル型も、ＢａｓｅＴＤモデル型に１対１で関連する。ＢａｓｅＴＤモデル型は、同一の言語型のすべてのデータ要素に共通する実装情報を保持するように特殊化される。したがって、特定のハードウェア／ソフトウェア・プラットフォームでの３２ビット符号付き２進整数を記述する情報は、この型を用いてどれほど多数のデータ要素が宣言されるかに無関係に、所与のモデル・インスタンス化において１回だけインスタンス化される。
【００９０】
ＴＤＬａｎｇＥｌｅｍｅｎｔとＩｎｓｔａｎｃｅＴＤＢａｓｅの間の関連に一致する、ＴＤＬａｎｇＣｌａｓｓｉｆｉｅｒとＢａｓｅＴＤの間の関連を企図することができる。しかし、これには、言語が単純型（たとえばストリング）とみなす構造が、単純なハードウェア／ソフトウェア型に直接にマッピングされない可能性があるという点で問題がある。ストリング実装を記述するためにＴｙｐｅＤｅｓｃｒｉｐｔｏｒモデルにより多くの機構を導入するのではなく、共通のストリング実装を記述するＢａｓｅＴＤの特殊化を使用する。ＴｙｐｅＤｅｓｃｒｉｐｔｏｒモデルのさまざまな属性に、ストリング”ｆｏｒｍｕｌａ”の接尾辞が付けられている。これらの属性には、いくつかの場合に実行時にのみ作成されるデータにアクセスしなければ計算が不可能である可能性がある情報が含まれる。１つの例が、可変サイズ配列の現在の上限、またはサイズが実行時にのみ既知になる別の要素に続く要素へのオフセットである。そのような情報は、モデル・インスタンスに値として含めることができるが、これは、実行時インスタンスごとに１つのモデル・インスタンスを必要とし、モデルを実行時にのみ構成できることを意味し、モデル定義で、実行時にモデル・インスタンスを作成するためにファクトリおよび他の装置を含めることが必要になることを意味する。プラットフォームおよびコンパイラの知識から構成できるモデルは、はるかに有用であり、数式によって、実行時情報が使用可能である時に具象的な値を定義する方法が提供される。これらの数式は、マーシャル・エンジンによって解釈することができ、あるいは、数式を使用して、マーシャル・エンジンによってオンデマンドでロードされ実行されるマーシャル・コードを生成することができる。
【００９１】
４．ｄ．数式
数式に関して使用される時に、「フィールド」は、ＴｙｐｅＤｅｓｃｒｉｐｔｏｒモデルによって記述される言語データ構造体の構成要素を指し、「属性」は、モデルの部分を指し、フィールドの「特性」を表す値を有する。したがって、フィールドの値は、言語データ構造体の特定のインスタンスの実行時値を意味し、属性の値は、言語データ構造体のフィールドの記述の一部であり、そのデータ構造体のすべてのインスタンスに適用され、データ構造対がモデル化される時に決定される。ＴｙｐｅＤｅｓｃｒｉｐｔｏｒモデルのインスタンスのほとんどの属性について、属性の値は、インスタンスが構築される時に既知である。というのは、データ構造体内のサイズおよびオフセットなど、記述されるフィールドの特性が、不変であるからである。しかし、データ構造体のフィールドが、ＣＯＢＯＬのＯＣＣＵＲＳＤＥＰＥＮＤＩＮＧ ＯＮ構造またはＰＬ／ＩのＲｅｆｅｒ構造を使用して定義される場合には、フィールドのいくつかの特性（およびそのフィールドの値に依存する他のフィールドの特性）を、モデル・インスタンスが構築される時に判定できない。
【００９２】
これらの言語構造を使用して定義できる特性が、ストリング長および配列の限界である。これらの言語構造に間接的に依存する可能性がある特性が、フィールドが可変サイズのフィールドに続く場合の、構造体内のフィールドのオフセットである。
【００９３】
これらの言語構造を処理するために、これらの構造（したがって、対応する属性の値）に依存する可能性があるフィールドの特性を、モデルが使用される時に評価できる数式を指定するストリングを用いて定義する。
【００９４】
しかし、あるフィールドの特性が、モデル・インスタンスが構築される時に既知である場合には、属性数式によって、単純に整数値が指定される。たとえば、ストリングが長さ１７を有する場合には、その長さの数式が”１７”になる。
【００９５】
上で述べた数式は、下記に制限される。
＊符号なし整数
＊下記の算術整数関数
ｎｅｇ（ｘ） ：＝ −ｘ　　　　　　　　／／　プレフィックス否定
ａｄｄ（ｘ、ｙ） ：＝ ｘ＋ｙ　　　　　／／　　インフィックス加算
ｓｕｂ（ｘ、ｙ） ：＝ ｘ−ｙ　　　　　／／　　インフィックス減算
ｍｐｙ（ｘ、ｙ） ：＝ ｘ＊ｙ　　　　　／／　インフィックス乗算
ｄｉｖ（ｘ、ｙ） ：＝ ｘ／ｙ　　　　　／／　　インフィックス除算
ｍａｘ（ｘ、ｙ） ：＝ ｍａｘ（ｘ、ｙ）
ｍｉｎ（ｘ、ｙ） ：＝ ｍｉｎ（ｘ、ｙ）
ｍｏｄ（ｘ、ｙ） ：＝ ｘ ｍｏｄ ｙ
ｍｏｄ関数は、ｍｏｄ（ｘ、ｙ）　＝　ｒとして定義され、ここで、ｒは、ｘ−ｒがｙによって割り切れるようになる最小の非負の整数である。したがって、ｍｏｄ（７、４）は３であるが、ｍｏｄ（−７、４）は１である。ｙが２のべきである場合には、ｍｏｄ（ｘ、ｙ）は、ｘとｙ−１のビット単位の論理ＡＮＤに等しい。
＊　ｖａｌ関数
ｖａｌ関数は、モデルによって記述されるフィールドの値を返す。ｖａｌ関数は、１つまたは複数の引数をとり、第１引数は、フィールドを含むレベル−１データ構造体を参照し、
＊言語モデル内のレベル−１データ構造体の名前、または
＊可変サイズ・フィールドのレベル−１親を示す整数１
のいずれかでなければならない。後者の場合に、可変サイズ・フィールドと、そのサイズを指定するフィールドが、同一のデータ構造体内にあり、したがって、共通のレベル−１親を有する。
後続の引数は、参照解除されなければならない（サブ）フィールドのサブ構造体内での序数を指定する整数である。
【００９６】
デフォルトで、構造体内のＣＯＢＯＬデータ・フィールドは、ストレージ内で型固有の境界に位置合せされない。たとえば、４バイト整数の「自然な」位置合せは、フルワード・ストレージ境界である。そのような位置合せは、宣言でＳＹＮＣＨＲＯＮＩＺＥＤ文節を使用することによって指定することができる。そうでない場合には、データ・フィールドは、構造体内の先行するフィールドの末尾の直後から始まる。ＣＯＢＯＬは、ビット・データを有しないので、フィールドは、必ずバイト全体の境界から始まる。
【００９７】
ＰＬ／Ｉの場合に、状況はより複雑になる。位置合せは、Ａｌｉｇｎｅｄ宣言属性およびＵｎＡｌｉｇｎｅｄ宣言属性によって制御される。ＣＯＢＯＬとは違って、データのほとんどの型、特に２進数および浮動小数点数が、デフォルトで自然な境界に位置合せされる。
【００９８】
４．ｄ．ｉ）数式の例
４．ｄ．ｉ）ａ）ＣＯＢＯＬ
この例では、ドラフト規格からの提案されたインライン・コメント・インジケータ”＊＞”を使用する。これは、まだ正当なＣＯＢＯＬの使用法ではない。
【００９９】
１．下記のデータ記述を検討されたい。
Figure 2004506264
Ｍｏｄｅｌのオフセットは、単純であり、数式”３６”によって与えられる。Ｃｌａｉｍｓのオフセットもそうであり、”１１２”である。
【０１００】
しかし、配列Ｃｌａｉｍは、変化する回数だけ現れる可能性があるので、構造体Ｈｉｓｔｏｒｙは、可変サイズ・フィールドである。したがって、Ｃｌａｉｍｓの直後のＰｒｉｃｅのオフセットは、配列ストライド（特定の次元に沿って連続する要素の間の距離）を含む、より複雑な数式を必要とする。Ｃｌａｉｍについて、１つの次元だけがあり、そのストライドの数式は”１５４”である。したがって、Ｐｒｉｃｅのオフセットの数式は、次のようになる。
”ａｄｄ（１１２，ｍｐｙ（ｖａｌ（１，２，２），１５４））”
【０１０１】
ｖａｌ関数の第１引数は１であり、これは、実行時に値を含むフィールドＮｕｍＣｌａｉｍｓが、数式によってオフセットが指定されるフィールドＰｒｉｃｅと同一のレベル−１構造体Ｕｓｅｄ−Ｃａｒ内にあることを意味する。他の２つの引数は、２と２である。第１の２は、Ｕｓｅｄ−Ｃａｒの第２の即値サブコンポーネントＨｉｓｔｏｒｙを指す。第２の２は、参照解除されるフィールドが、Ｈｉｓｔｏｒｙの第２コンポーネントすなわち、ＮｕｍＣｌａｉｍｓであることを意味する。
【０１０２】
ＯＣＣＵＲＳ ＤＥＰＥＮＤＩＮＧ ＯＮオブジェクトが、別の構造体、たとえばレベル−１構造体Ｃａｒ−Ｄａｔａの第３サブコンポーネント内にある場合には、ｖａｌ関数が、”ｖａｌ（Ｃａｒ−Ｄａｔａ、３）”になる。
【０１０３】
ＣＯＢＯＬの構造体マッピングは、トップダウンであるが、この方向は、ＳＹＮＣＨＲＯＮＩＺＥＤ文節がデータ宣言で指定されない限り、影響を生じない。ＳＹＮＣＨＲＯＮＩＺＥＤを指定することによって、個々のフィールドがその自然な境界に位置合せされ、したがって、構造体マッピングに「ギャップ」が導入される。下のデータ構造体を参照されたい。これは、ＳＹＮＣＨＲＯＮＩＺＥＤ文節を除いて、上の例と同一である。
Figure 2004506264
【０１０４】
２進フィールドを適当なハーフワード・ストレージ境界またはフルワード・ストレージ境界に位置決めするために、ＣＯＢＯＬでは、「遊びバイト」と称する埋込みを構造体に導入する。トップダウンで作業して、この埋込みが、位置合わせを必要とするフィールドの直前に導入される。したがって、ＭｉｌｅａｇｅとＮｕｍＣｌａｉｍｓの間に１バイトの埋込みがある。
【０１０５】
Ｃｌａｉｍなどの配列について、ＣＯＢＯＬは、要素内の埋込みを調整するだけではなく、配列の各要素の位置合わせも調整する。この例では、Ｃｌａｉｍの最初の出現が、フルワード境界の１バイト後に開始される。フィールドＣｌａｉｍＮｏは、正確にフルワードの長さなので、フルワード境界の１バイト後で終り、したがって、ＣＯＢＯＬでは、２進数フルワード整数ＣｌａｉｍＡｍｔの直前に３バイトの埋込みが挿入される。また、後続の出現を位置合わせし、その結果、それらも最初の出現のようにフルワード境界の１バイト後から始まり、したがって、同一の構成を有することができるようにするために、ＣＯＢＯＬでは、各出現の末尾に３バイトの埋込みを追加する。
【０１０６】
最後に、埋込みの後に、Ｃｌａｉｍの各出現が、フルワード境界の１バイト後で（始まり、）終わるので、ＣＯＢＯＬでは、２進フィールドＰｒｉｃｅの後に３バイトの埋込みが置かれる。これらの余分なバイトのすべての結果として、Ｐｒｉｃｅのオフセットの数式は、位置合わせされない例からかなり変更され、次のようになる。
”ａｄｄ（ａｄｄ（１１３，ｍｐｙ（ｖａｌ（１，２，２），１６０）），３）”
【０１０７】
ＯＣＣＵＲＳ ＤＥＰＥＮＤＩＮＧ ＯＮ構成とＰＬ／ＩのＲｅｆｅｒオプションの間に、複数の相違がある。ＣＯＢＯＬ構造体のストレージは、必ず最大サイズで割り振られるが、ＰＬ／Ｉ構造体は、Ｒｅｆｅｒオプションによって指定される実際のサイズで割り振られる。可変サイズＣＯＢＯＬ配列の特定のインスタンスでの出現の数を変更することが、正しく、普通であり、これは、その配列に続くすべてのフィールドの位置およびオフセットが変化するという影響を有する。ＰＬ／Ｉについて、構造体の特定のインスタンスのＲｅｆｅｒオブジェクトの値は、実行中に固定されることを意図される。したがって、可変サイズ・フィールドに続く位置合わせされるオブジェクトは、必ず、構造体の各インスタンスについて正しく位置合わせされる。というのは、埋込みの量が、Ｒｅｆｅｒオプションによって決定されるように、インスタンスごとに一意に計算されるからである。対照的に、可変サイズＣＯＢＯＬ配列に続くすべての位置合わせされるフィールドの埋込みの量は、最大配列サイズを仮定して計算され、コンパイル時に固定される。配列が、その最大サイズより小さい場合には、位置合わせが、通常は不正になる。たとえば、ＣＯＢＯＬでは、次の例で、
Figure 2004506264
ｃとｄの間に１バイトが挿入される。したがって、ｄの位置合わせは、ｂの２つの値すなわち、最大値５と２だけについて正しい。
【０１０８】
上で注記したように、数式は、構造体内のフィールドのオフセットだけではなく、境界およびストライドなど、配列の特性も記述する。ＣＯＢＯＬでは、要素参照に、複数の添字が使用されるが、真の多次元配列がない。その代わりに、ＣＯＢＯＬには、次の簡単な例のように、配列の配列がある。
Figure 2004506264
【０１０９】
プログラムは、たとえばｄ１（２）またはｄ２（３、４）など、上位コンテナ・フィールドを添字にすることによって配列のスライスを参照することができるが、普通の種類の参照は、たとえばｅｌ（４、５、６）など、添字のフル・シーケンスを使用して、下位レベルに対して行われる。このストライド数式を使用して要素ｅｌ（ｍ、ｎ、ｏ）を突き止めるためには、ａのアドレスをとり、それを（ｍ−１）×１６８＋（ｎ−１）×２８＋（ｏ−１）×４に加算する。ＣＯＢＯＬの場合に、配列添字の下限は、必ず１である。すなわち最初の要素は必ずＥｌｅｍｅｎｔ（１）であり、逆も同様である。
【０１１０】
言うまでもなく、配列のすべての次元が、ＯＣＣＵＲＳ ＤＥＰＥＮＤＩＮＧ ＯＮ文節を有することができ、配列に他のフィールドを続けることができ、これによって数式が非常に複雑になる。次の例を検討されたい。
Figure 2004506264
【０１１１】
特定の要素のアドレスの計算に、まだストライド数式が含まれるが、もはや単純な整数はない。上の例の要素ｅｌ（ｍ、ｎ、ｏ）のアドレスは、ａのアドレスをとり、次式に加算することによって与えられる。
（ｍ−１）＊ｓｔｒｉｄｅ（１） ＋（ｎ−１）＊ｓｔｒｉｄｅ（２） ＋ （ｏ−１）＊ｓｔｒｉｄｅ（３）， すなわち、
（ｍ−１）＊４＊ｖａｌ（１，３）＊ｖａｌ（１，２） ＋ （ｎ−１）＊４＊ｖａｌ（１，３） ＋ （ｏ−１）＊４．
【０１１２】
同様に、これらのストライド数式は、ｂのオフセットに関する下記の数式に使用される。
”ａｄｄ（６，ｍｐｙ（ｖａｌ（１，１），ｍｐｙ（ｖａｌ（１，２），ｍｐｙ（４，ｖａｌ（１，３）））））”
【０１１３】
４．ｄ．ｉ）．ｂ）．ＰＬ／Ｉ
１．下記の構造体を与える
Figure 2004506264
ｃ３のオフセットは、単純な数式”４”によって与えられるが、ｃ１０のオフセットは、下の数式によって与えられる。
”ａｄｄ（２４，ｖａｌ（１，２，３））”
【０１１４】
上のｖａｌ関数の第１引数は１であり、これは、現在の構造体ｃを示す。後続の引数は２と３であり、第２のレベル−２フィールドｃ４の第３引数ｃ７が、参照解除されるフィールドであることを示す。
【０１１５】
ｃ１１のオフセットは、ｃ１０のオフセットにｃ１０の長さを加えたものに等しく、次の数式によって与えられる。
”ａｄｄ（ａｄｄ（２４，ｖａｌ（１，２，３））， ６）”
【０１１６】
ＰＬ／Ｉ構造体マッピングは、トップダウンではなく、これは、次の構造体のマッピングを調べることによって示すことができる。
Figure 2004506264
【０１１７】
ｂ１の値は、ｖａｌ（１、１、１）によって与えられ、ｃ２を４バイト境界に置くために、ＰＬ／Ｉでは、ｃの前（ｃ１とｃ２の間ではなく）に、必要な埋込みのすべてを置き、したがって、ｃのオフセットが、次の数式によって与えられる。
”ａｄｄ（８，ｍｏｄ（ｎｅｇ（ｖａｌ（１，１，１）），４））”
【０１１８】
したがって、ｂ１に値３が含まれる場合に、この数式は、ａｄｄ（８、ｍｏｄ（ｎｅｇ（３）、４））になり、これは９と評価される。すなわち、構造体ｂと構造体ｃの間に１バイトの埋込みがある。
【０１１９】
このモデルでは、配列の境界およびストライドの指定にもこれらの数式が使用され、ここで、ストライドは、配列内の２つの連続する要素の間の距離として定義される。
【０１２０】
たとえば、下の構造体では、ａ．ｅの第２次元が、数式”４”によって指定されるストライドを有し、第１次元が、数式”２０”によって指定されるストライドを有する。
Figure 2004506264
【０１２１】
これは、要素ａ．ｅ（ｍ、ｎ）を突き止めるために、ａ．ｅのアドレスをとり、
（ｍ−１）＊２０ ＋ （ｎ−１）＊４
に加算することを意味する。
【０１２２】
上の例がわずかに変更されて、
Figure 2004506264
になる場合に、ｄとｅの間に埋込みがあるが、型記述子のユーザは、全く気付かず、単にストライドとオフセットの数式を使用して、所与の配列要素を突き止めることができる。ａのストライドは”４０”であり、ｅのストライドは”４”であり、ｅのオフセットは”２０”である。これは、要素ａ（ｍ）．ｅ（ｎ）を突き止めるために、ａのアドレスをとり、（ｍ−１）×４０＋２０＋（ｎ−１）×４に加算することを意味する。
【０１２３】
最後に、上の例がまた変更されて、
Figure 2004506264
になる場合に、ａ．ｅの計算は、上と同一であるが、ａ．ｃの計算が、興味深いものになる。
【０１２４】
ａのストライドは、まだ”４０”であり、ｃのストライドは、”４”であり（この”４”は、ビットのカウントであってバイトではない）、ｃのオフセットは”４”である。要素ａ（ｍ）．ｃ（ｎ）を突き止めるためには、バイト・アドレスとビット・オフセットの両方が必要である。バイト・アドレスについては、ａのアドレスをとり、（ｍ−１）×４０＋４＋（（ｎ−１）×４）／８に加算する。ａ（ｍ）．ｃ（ｎ）のビット・アドレスは、ｍｏｄ（（ｎ−１）×４、８）によって与えられる。
【０１２５】
４．ｅ．ＴｙｐｅＤｅｓｃｒｉｐｔｏｒの仕様
４．ｅ．ｉ．ＴＤＬａｎｇメタモデル仕様
ＴＤＬａｎｇクラス　−　全般的な概要。ＴＤＬａｎｇクラスは、すべてのＣＡＭ言語モデルとＴｙｐｅＤｅｓｃｒｉｐｔｏｒモデルの間の抽象の１レイヤとして働く。
【０１２６】
どのＣＡＭ言語モデルでも、ＴＤＬａｎｇモデルにプラグ・インすることができるので、ＴｙｐｅＤｅｓｃｒｉｐｔｏｒモデルは、ＣＡＭ言語モデルにアクセスするために、ＴＤＬａｎｇとインターフェースする方法を理解するだけでよい。
【０１２７】
ＴＤＬａｎｇモデルは、独力では全く機能を提供せず、したがって、言語モデルに接続される時に限って意味を持つ。ＴＤＬａｎｇは、すべてのＣＡＭ言語モデルに共通し、ＴｙｐｅＤｅｓｃｒｉｐｔｏｒモデルから言語モデルへの関連の型ターゲットである。
【０１２８】
すべてのＴＤＬａｎｇクラスが、抽象クラスであり、言語メタモデルの基本クラスとして働くことに留意されたい。
【０１２９】
ＴＤＬａｎｇＣｌａｓｓｉｆｉｅｒ。ＴＤＬａｎｇＣｌａｓｓｉｆｉｅｒは、すべての言語固有ＣｌａｓｓｉｆｉｅｒクラスおよびＴＤＬａｎｇＣｏｍｐｏｓｅｄＴｙｐｅの親クラスである。ＴＤＬａｎｇＳｈａｒｅｄＴｙｐｅ関連は、ＥｌｅｍｅｎｔクラスからＣｌａｓｓｉｆｅｒクラスへの言語の”＋ＳｈａｒｅｄＴｙｐｅ”関連から派生する。関連は、その関連が言語モデルから派生したことを反映するために、”ｖｏｌａｔｉｌｅ”、”ｔｒａｎｓｉｅｎｔ”、または”ｄｅｒｉｖｅｄ”としてマークされなければならない。ＴＤＬａｎｇＣｌａｓｓｉｆｉｅｒは、ＴＤＬａｎｇＭｏｄｅｌＥｌｅｍｅｎｔから派生する。
【０１３０】
ＴＤＬａｎｇＥｌｅｍｅｎｔ。ＴＤＬａｎｇＥｌｅｍｅｎｔは、すべての言語固有Ｅｌｅｍｅｎｔクラスの親クラスである。ｔｄＬａｎｇＴｙｐｅｄＥｌｅｍｅｎｔ関連は、ＣｌａｓｓｉｆｉｅｒクラスからＥｌｅｍｅｎｔクラスへの言語の”＋ＴｙｐｅｄＥｌｅｍｅｎｔ”関連から派生する。関連は、その関連が言語モデルから派生したことを反映するために、”ｖｏｌａｔｉｌｅ”、”ｔｒａｎｓｉｅｎｔ”、または”ｄｅｒｉｖｅｄ”としてマークされなければならない。
【０１３１】
ｔｄＬａｎｇＥｌｅｍｅｎｔ関連は、ＣｌａｓｓｉｆｉｅｒクラスからＥｌｅｍｅｎｔクラスへの言語の”＋Ｅｌｅｍｅｎｔ”関連から派生する。関連は、その関連が言語モデルから派生したことを反映するために、”ｖｏｌａｔｉｌｅ”、”ｔｒａｎｓｉｅｎｔ”、または”ｄｅｒｉｖｅｄ”としてマークされなければならない。
【０１３２】
ＴＤＬａｎｇＣｏｍｐｏｓｅｄＴｙｐｅ。ＴＤＬａｎｇＣｏｍｐｏｓｅｄＴｙｐｅは、すべての言語固有ＣｏｍｐｏｓｅｄＴｙｐｅｓの親クラスである。ＴＤＬａｎｇＧｒｏｕｐ関連は、ＥｌｅｍｅｎｔクラスからＣｏｍｐｏｓｅｄＴｙｐｅクラスへの言語の”＋ｇｒｏｕｐ”関連から派生する。関連は、その関連が言語モデルから派生したことを反映するために、”ｖｏｌａｔｉｌｅ”、”ｔｒａｎｓｉｅｎｔ”、または”ｄｅｒｉｖｅｄ”としてマークされなければならない。ＴＤＬａｎｇＣｏｍｐｏｓｅｄＴｙｐｅは、ＴＤＬａｎｇＣｌａｓｓｉｆｉｅｒから派生する。
【０１３３】
４．ｅ．ｉｉ．ＴｙｐｅＤｅｓｃｒｉｐｔｏｒメタモデル仕様
ＴｙｐｅＤｅｓｃｒｉｐｔｏｒパッケージでは、データ項目型の物理的実装を記述するモデルが定義される。このモデルは、言語中立であり、多数の言語の型を記述するのに使用することができる。異なる言語の型モデルの検査によって、言語型の一致可能性を判定することができる。たとえば、Ｊａｖａ（Ｒ）のｌｏｎｇ型は、しばしば、ＣＯＢＯＬのｂｉｎａｒｙ型と同一であり、その場合には、これらの型を、副作用なしで相互変換することができる。その一方で、ＣＯＢＯＬのａｌｐｈａｎｕｍｅｒｉｃ型は、サイズが固定されるが、Ｊａｖａ（Ｒ）の型にマッピングされる場合に、この特性が失われる。Ｊａｖａ（Ｒ）からＣＯＢＯＬに再変換される時に、ＣＯＢＯＬの切詰規則が適用されず、計算の例外がもたらされる可能性がある。
【０１３４】
ＡｇｇｒｅｇａｔｅＩｎｓｔａｎｃｅＴＤ。集約のインスタンスごとに、このクラスのインスタンスがある。この集約の子を探すためにには、関連を言語Ｃｌａｓｓｉｆｉｅｒまで逆にナビゲートし、言語ＣｏｍｐｏｓｅｄＴｙｐｅにダウンキャストし、その子への関連に従わなければならない。
ＩｎｓｔａｎｃｅＴＤＢａｓｅから派生
パブリック属性：
ｕｎｉｏｎ ： ｂｏｏｌｅａｎ ＝ ｆａｌｓｅ
集約が包含的（たとえば構造体）または排他的（たとえば共用体）のどちらであるかを区別する。
ｕｎｉｏｎ ＝ ｔｒｕｅの場合には、ストレージがオーバーレイされ、その結果として内容の解釈が不確実になる可能性がある。
【０１３５】
ＡｒｒａｙＴＤ。ＡｒｒａｙＴＤは、配列型の情報を保持する。
パブリック属性：
ａｒｒａｒｙＡｌｉｇｎ ： ｉｎｔ
配列内の各要素のアドレス可能単位での位置合わせ要件。
ｓｔｒｉｄｅＦｏｒｍｕｌａ ： ｓｔｒｉｎｇ
インデックスを与えられて、配列内の要素の変位アドレスを計算するのに使用することができる数式。
ｓｔｒｉｄｅＩｎＢｉｔ ： ｂｏｏｌｅａｎ
真は、ｓｔｒｉｄｅＦｏｒｍｕｌａ値がビット単位であることを示す。
偽は、ｓｔｒｉｄｅＦｏｒｍｕｌａ値がバイト単位であることを示す。
ｕｐｐｅｒＢｏｕｎｄＦｏｒｍｕｌａ ： Ｓｔｒｉｎｇ
この値が変数によって参照される時に、インスタンスのＳｔｒｉｎｇとして宣言される。この属性は、可変サイズ配列の上限値を供給する。
上限は、構造体全体を逆にトラバースする時に必要になる。
ｌｏｗｅｒＢｏｕｎｄＦｏｒｍｕｌａ ： Ｓｔｒｉｎｇ
この値が変数によって参照される時に、インスタンスのＳｔｒｉｎｇとして宣言される。この属性は、可変サイズ配列の下限値を供給する。
【０１３６】
ＩｎｓｔａｎｃｅＴＤＢａｓｅ。ＩｎｓｔａｎｃｅＴＤＢａｓｅは、宣言された変数および構造体要素ごとにインスタンスを有する。
インスタンスの親（インスタンスが親を有する場合に）を見つけるためには、関連をＴＤＬａｎｇＥｌｅｍｅｎｔまで逆にナビゲートし、ＴＤＬａｎｇＣｌａｓｓｉｆｉｅｒへの関連に従って親を突き止め、その後、ＴｙｐｅＤｅｓｃｒｉｐｔｏｒモデルへ逆に関連に従わなければならない。
パブリック属性：
ｏｆｆｓｅｔＦｏｒｍｕｌａ ： ｓｔｒｉｎｇ
このインスタンスの先頭へのオフセットを計算する数式。
この属性は、このフィールドが必ず整数値であるとは限らないので、Ｓｔｒｉｎｇである。たとえば、（ｖａｌｕｅ（ｎ）＋４）が、可能な値になる可能性がある。
注：オフセット値は、最上位の親から計算される（たとえば、２進木Ａ→Ｂ、Ａ→Ｃ、Ｂ→Ｄ、Ｂ→Ｅについて、Ｄへのオフセットは、ＢからＤではなく、ＡからＤへ計算される）。
ｃｏｎｔｅｎｔＳｉｚｅＦｏｒｍｕｌａ ： ｓｔｒｉｎｇ
内容の現在のサイズを計算する数式。
ａｌｌｏｃＳｉｚｅＦｏｒｍｕｌａ ： ｓｔｒｉｎｇ
インスタンスの割り振られたサイズを計算する数式。
ｆｏｒｍｕｌａＩｎＢｉｔ ： ｂｏｏｌｅａｎ
真は、ｏｆｆｓｅｔＦｏｒｍｕｌａ、ｃｏｎｔｅｎｔＳｉｚｅＦｏｒｍｕｌａ、およびａｌｌｏｃＳｉｚｅＦｏｒｍｕｌａの値がビット単位であることを示す。
偽は、ｏｆｆｓｅｔＦｏｒｍｕｌａ、ｃｏｎｔｅｎｔＳｉｚｅＦｏｒｍｕｌａ、およびａｌｌｏｃＳｉｚｅＦｏｒｍｕｌａの値がバイト単位であることを示す。
ｄｅｆａｕｌｔＥｎｃｏｄｉｎｇ ： Ｓｔｒｉｎｇ
物理的エンコーディング　−　コード・ポイントのエンコードに何ビットが使用され、コード・ポイントがビット・パターンにどのようにマッピングされるか　ストリング内容がどのようにエンコードされるかに関する情報：ＥＢＣＤＩＣ、ＡＳＣＩＩ、ＵＮＩＣＯＤＥ、ＵＴＦ−８、ＵＴＦ−１６、コードページ番号などが格納される。
ａｃｃｅｓｓｏｒ ： ｅｎｕｍｅｒａｔｉｏｎ
この要素のアクセス権を指定する。
ｄｅｆａｕｌｔＢｉｇＥｎｄｉａｎ ： ｂｏｏｌｅａｎ
この要素がビッグ・エンディアン・フォーマットである場合に真。
ｆｌｏａｔＴｙｐｅ ： ｅｎｕｍｅｒａｔｉｏｎ
この要素の浮動型を指定する。
【０１３７】
ＰｌａｔｆｏｒｍＣｏｍｐｉｌｅｒＴｙｐｅ。特定のプラットフォームおよびコンパイラに関する特定のデータ型。
注：プラットフォームおよびコンパイラを識別する何らかの方法が必要である。
このクラスは、特殊化されるか属性を有することができ、あるいは、属性をＩｎｓｔａｎｃｅＴＤＢａｓｅに置くことによって単純化することができる。
パブリック属性：
ｐｌａｔｆｏｒｍＣｏｍｐｉｌｅｒＴｙｐｅ ： Ｓｔｒｉｎｇ
この属性は、言語モデル内のデータを作成するのに使用されたコンパイラの型を指定する。このストリングの使用法は、次の通りである。
”ベンダ名、言語、ＯＳ、ハードウェア・プラットフォーム”（たとえば、”ＩＢＭ，ＣＯＢＯＬ， ＯＳ３９０， ３９０”または”ＩＢＭ， ＰＬＩ， ＷｉｎＮＴ， Ｉｎｔｅｌ”）。
【０１３８】
ＳｉｍｐｌｅＩｎｓｔａｎｃｅＴＤ。言語モデルのＳｉｍｐｌｅ型のインスタンス。
ＩｎｓｔａｎｃｅＴＤＢａｓｅから派生する。
【０１３９】
ＮｕｍｂｅｒＴＤ
すべての数の表現。
現在は、ＩｎｔｅｇｅｒとＰａｃｋｅｄ Ｄｅｃｉｍａｌが含まれる。
Ｎｕｍｂｅｒのこれらの型に必要なフィールドに留意されたい：
＊Ｉｎｔｅｇｅｒ＊
Ｂａｓｅ＝２
ＭＳＢＵ＝０または　１
Ｓｉｇｎｅｄ／Ｕｎｓｉｇｎｅｄ
サイズ（バイト単位）＝１、２、４、８（１６）
＊Ｐａｃｋｅｄ Ｄｅｃｉｍａｌ＊
Ｂａｓｅ＝１０
ＭＳＢＵ＝０
Ｓｉｇｎｅｄ
幅＝１−６３
＊Ｆｌｏａｔ＊
Ｂａｓｅ＝２（ＩＥＥＥ）、１６（Ｈｅｘ）
ＭＳＢＵ＝０または１
Ｓｉｇｎｅｄ
サイズ（バイト単位）＝４、８、１６
エンコーディングの詳細
ＢａｓｅＴＤから派生する
パブリック属性：
ｂａｓｅ ： ｉｎｔ
この数の基数表現。２＝２進、１０＝１０進、１６＝１６進、など
ｂａｓｅＷｉｄｔｈ ： ｉｎｔ
基数を表すのに使用されるビット数
たとえば、２進数＝１、１０進数＝８、パック＝４
ｂａｓｅＩｎＡｄｄｒ ： ｉｎｔ
アドレス可能記憶単位内のｂａｓｅＷｉｄｔｈ単位の数。たとえば、アドレス可能単位がバイトの場合に、１０進＝１、パック＝２、２進＝８。アドレス可能単位が３２ビット・ワードである場合には、１０進が４、パックが８、２進が３２になる。
ｂａｓｅＵｎｉｔｓ ： ｉｎｔ
数のｂａｓｅ単位の数。これとｂａｓｅｗｉｄｔｈの積は、ｗｉｄｔｈとａｄｄｒＵｎｉｔの積以下でなければならない。
たとえば、右に位置合わせされる３２ビット・ワードの２４ビット・アドレスは、ｂａｓｅ＝１、ｂａｓｅｗｉｄｔｈ＝２４、ｂａｓｅＩｎＡｄｄｒ＝８、ｗｉｄｔｈ＝４を有する。
ｓｉｇｎＣｏｄｉｎｇ ： ｅｎｕｍｅｒａｔｉｏｎ
列挙の組すなわち、２進数の場合に２の補数、１の補数、および符号絶対値、１０進数の場合に０符号、パック１０進数、符号なし２進数、および符合なし１０進数の場合にパック符号。
ｃｈｅｃｋＶａｌｉｄｉｔｙ ： ｂｏｏｌｅａｎ
ピクチャ・ストリング・サポートのために言語モデルが必要な場合に真。
ｐａｃｋｅｄＤｅｃｉｍａｌＳｉｇｎ ： ｅｎｕｍｅｒａｔｉｏｎ
ＣＯＢＯＬ１０進数の符号のコード・ポイントを決定するのに使用される。符号は、先頭の数字または末尾の数字と組み合わされる。
【０１４０】
ＦｌｏａｔＴＤ
浮動小数点
ＢａｓｅＴＤから派生する
パブリック属性：
ｆｌｏａｔＴｙｐｅ ： ｅｎｕｍｅｒａｔｉｏｎ
この要素の浮動型を指定する。
【０１４１】
ＳｔｒｉｎｇＴＤ
英数字型
ＢａｓｅＴＤから派生する
パブリック属性：
ｅｎｃｏｄｉｎｇ ： Ｓｔｒｉｎｇ
物理的エンコーディング　−　コード・ポイントのエンコードに何ビットが使用され、コード・ポイントがビット・パターンにどのようにマッピングされるか　ストリング内容がどのようにエンコードされるかに関する情報：ＥＢＣＤＩＣ、ＡＳＣＩＩ、ＵＮＩＣＯＤＥ、ＵＴＦ−８、ＵＴＦ−１６、コードページ番号などが格納される。
ｌｅｎｇｔｈＥｎｃｏｄｉｎｇ ： ｅｎｕｍｅｒａｔｉｏｎ
ｌｅｎｇｔｈＥｎｃｏｄｉｎｇの可能な値：
−固定長（全長が宣言されたストリング長と等しい）
−長さプレフィックス付き（全長が、ストリングの長さとヘッダ・バイトの長さの和に等しい。ヘッダ・バイトは、通常は１バイト、２バイト、または４バイトである）。
−ヌル終端（ＰＬ／ＩではｖａｒｙｉｎｇＺストリングと称する）（ヌル記号がストリングの末尾に追加される。したがって、最大長さは、宣言されたストリング長と、ヌル記号を表す１バイトの合計までになる）
ｍａｘＬｅｎｇｔｈＦｏｒｍｕｌａ ： Ｓｔｒｉｎｇ
このストリングの最大長さを指定する数式。
ｃｈｅｃｋＶａｌｉｄｉｔｙ ： ｂｏｏｌｅａｎ
ピクチャ・ストリング・サポートのために言語モデルが必要な場合に真。
ｔｅｘｔＴｙｐｅ ： Ｓｔｒｉｎｇ ＝ Ｉｍｐｌｉｃｉｔ
値は、’Ｉｍｐｌｉｃｉｔ’または’Ｖｉｓｕａｌ’である
ｏｒｉｅｎｔａｔｉｏｎ ： ＳｔｒｉｎｇＴＤ ＝ ＬＴＲ
値は、’ＬＴＲ’、’ＲＴＬ’、’Ｃｏｎｔｅｘｔｕａｌ ＬＴＲ’、または’ＣｏｎｔｅｘｔｕａｌＲＴＬ’であり、ここで、ＬＴＲ＝Ｌｅｆｔ ｔｏ Ｒｉｇｈｔ（左から右へ）であり、ＲＴＬ＝Ｒｉｇｈｔ ｔｏ Ｌｅｆｔ（右から左へ）である。
Ｓｙｍｍｅｔｒｉｃ ： ｂｏｏｌｅａｎ ＝ ｔｒｕｅ
対称スワッピングが許可される場合に真
ｎｕｍｅｒａｌＳｈａｐｅｓ ： Ｓｔｒｉｎｇ ＝ Ｎｏｍｉｎａｌ
値は、’Ｎｏｍｉｎａｌ’、’Ｎａｔｉｏｎａｌ’、または’Ｃｏｎｔｅｘｔｕａｌ’
ｔｅｘｔＳｈａｐｅ ： Ｓｔｒｉｎｇ ＝ Ｎｏｍｉｎａｌ
値は、’Ｎｏｍｉｎａｌ’、’Ｓｈａｐｅｄ’、’Ｉｎｉｔｉａｌ’、’Ｍｉｄｄｌｅ’、’Ｆｉｎａｌ’、または’Ｉｓｏｌａｔｅｄ’である
【０１４２】
ＡｄｄｒｅｓｓＴＤ
ポインタ／アドレスを表す型
このクラスの理論的根拠：
アドレスは、ＮｕｍｂｅｒＴＤクラスとは別に考慮されなければならない。というのは、ある計算機（たとえばＩＢＭ４００）上のいくつかの言語が、アクセス権タイプ（ＮｕｍｂｅｒＴＤクラスでは表現されない）などの追加情報を伴うアドレスを表すからである。
ＢａｓｅＴＤから派生する
パブリック属性：
ｐｅｒｍｉｓｓｉｏｎ ： Ｓｔｒｉｎｇ
このアドレスのアクセス権を表す。主にＡＳ／４００システムで使用される。
ｂｉｔＭｏｄｅＰａｄ ： ｅｎｕｍｅｒａｔｉｏｎ
このアドレスのビット数を指定する。埋込みの計算に使用される。
【０１４３】
ＢａｓｅＴＤ
ＴｙｐｅＤｅｓｃｒｉｐｔｏｒの基本クラス。
ＢａｓｅＴＤモデル型は、同一の言語型のすべてのデータ要素に共通する実装情報を保持するように特殊化される。したがって、特定のハードウェア／ソフトウェア・プラットフォームの３２ビット符号付き２進整数を記述する情報は、この型を用いていくつのデータ要素が宣言されるかに無関係に、所与のモデル・インスタンス化で１回だけインスタンス化される。
パブリック属性：
ａｄｄｒＵｎｉｔ ： ｅｎｕｍｅｒａｔｉｏｎ
ストレージ・アドレス可能単位（ｂｉｔ／ｂｙｔｅ／ｗｏｒｄ／ｄｗｏｒｄ）でのビット数
ｗｉｄｔｈ ： ｉｎｔ
記述される型でのアドレス可能ストレージ単位の数。１ビット、８ビット、１６ビット、３２ビットにすることができる。
ａｌｉｇｎｍｅｎｔ ： ｉｎｔ
アドレス空間で型に必要な位置合わせ　−　たとえば、ワード位置合わせされる３２ビット整数は、４のａｌｉｇｎｍｅｎｔを有する。
ｎｉｃｋｎａｍｅ ： ｉｎｔ
基本要素の名前。これは、属性の組合せに基づく論理ではなく名前に基づく論理を可能にするために、単純型のインスタンスを一意に識別しなければならない。たとえば、３２ビットＳ／２９０非拡大縮小２進整数は”Ｓ３９０Ｂｉｎａｒｙ３１＿０”である。
ｂｉｇＥｎｄｉａｎ ： ｂｏｏｌｅａｎ
この要素がビッグ・エンディアン・フォーマットである場合に真。
【０１４４】
ステレオタイプ
ｂｉｔＭｏｄｅＰａｄ
パブリック属性：
１６ｂｉｔ ：
２４ｂｉｔ ：
３１ｂｉｔ ：
３２ｂｉｔ ：
６４ｂｉｔ ：
１２８ｂｉｔ ：
ｓｉｇｎＣｏｄｉｎｇ
このモデルに、下記のＣＯＢＯＬ使用が含まれないことに留意されたい：
１ ＰＯＩＮＴＥＲ
ＰＲＯＣＥＤＵＲＥ−ＰＯＩＮＴＥＲ
ＯＢＪＥＣＴ ＲＥＦＥＲＥＮＣＥ
パブリック属性：
ｔｗｏｓＣｏｍｐｌｅｍｅｎｔ ：
ｏｎｅｓＣｏｍｐｌｅｍｅｎｔ ：
ｓｉｇｎＭａｇｎｉｔｕｄｅ ：
ｚｏｎｅＳｉｇｎｓ ：
ｐａｃｋｅｄＳｉｇｎｓ ：
ｕｎｓｉｇｎｅｄＢｉｎａｒｙ ：
ｕｎｓｉｇｎｅｄＤｅｃｉｍａｌ ：
ｌｅｎｇｔｈＥｎｃｏｄｉｎｇ
パブリック属性：
ｆｉｘｅｄＬｅｎｇｔｈ ：
ｌｅｎｇｔｈＰｒｅｆｉｘｅｄ ：
ｎｕｌｌＴｅｒｍｉｎａｔｅｄ ：
ｆｌｏａｔＴｙｐｅ
パブリック属性：
Ｕｎｓｐｅｃｉｆｉｅｄ ：
ＩＥＥＥｅｘｔｅｎｄｅｄＩｎｔｅｌ ：
Ｉｎｔｅｌプラットフォームで稼動するＩＥＥＥ拡張浮動小数点
ＩＥＥＥｅｘｔｅｎｄｅｄＡＩＸ ：
ＡＩＸプラットフォームで稼動するＩＥＥＥ拡張浮動小数点
ＩＥＥＥｅｘｔｅｎｄｅｄＯＳ３９０ ：
ＯＳ／３９０プラットフォームで稼動するＩＥＥＥ拡張浮動小数点
ＩＥＥＥｅｘｔｅｎｄｅｄＡＳ４００ ：
ＡＳ４００プラットフォームで稼動するＩＥＥＥ拡張浮動小数点
ＩＥＥＥｎｏｎｅｘｔｅｎｄｅｄ ：
ＩＥＥＥ非拡張浮動小数点
ＩＢＭ３９０Ｈｅｘ ：
ＩＢＭ　ＯＳ／３９０で稼動する１６進浮動小数点
ＩＢＭ４００Ｈｅｘ ：
ＩＢＭ　ＡＳ４００で稼動する１６進浮動小数点
ａｃｃｅｓｓｏｒ
パブリック属性：
ＲｅａｄＯｎｌｙ ：
ＷｒｉｔｅＯｎｌｙ ：
ＲｅａｄＷｒｉｔｅ ：
ＮｏＡｃｃｅｓｓ ：
ｐａｃｋｅｄＤｅｃｉｍａｌＳｉｇｎ
パブリック属性：
ＭＶＳ ：
ＭＶＳＣｕｓｔｏｍ ：
ＮＴ／ＯＳ２／ＡＩＸ ：
【０１４５】
５．言語メタモデル
５．ａ．ＣＯＢＯＬメタモデル
ＣＯＢＯＬメタモデルは、コネクタ・インターフェースを表すデータ構造体（セマンティクス）を定義するために、エンタープライズ・アプリケーション・プログラムによって使用される。
【０１４６】
図１５、および図１６に、コネクタ・インターフェースを表すデータ構造体セマンティクスを定義するためのＣＯＢＯＬメタモデルを示す。このメタモデルは、Ｍ２レベルのＭＯＦクラス・インスタンスでもある。図１７に、ＴＤＬａｎｇＣｌａｓｓｉｆｉｅｒ、ＴＤＬａｎｇｕａｇｅＣｏｍｐｏｓｅｄＴｙｐｅ、およびＴＤＬａｎｇＥｌｅｍｅｎｔである、ＣＯＢＯＬメタモデルとＴＤＬａｎｇ基本クラスの間の関連を示す。図１８に、ＣＯＢＯＬメタモデルのＣＯＢＯＬ使用値の列挙を示す。
【０１４７】
このＣＯＢＯＬモデルの目標は、Ｄａｔａ Ｄｉｖｉｓｉｏｎで見つかるはずの情報を取り込むことである。このモデルは、ＣＯＢＯＬのｄａｔａｄｉｖｉｓｉｏｎをそのＸＭＬ同等物に変換するために、読取専用としてのみ使用されることを予定されている。このモデルは、ＸＭＬコードからＣＯＢＯＬのｄａｔａｄｉｖｉｓｉｏｎの同等物へのコンバータとして使用されることを予定されていない。その結果、要素のｉｎｉｔｉａｌＶａｌｕｅは、このモデルには取り込まれない。
【０１４８】
ＣＯＢＯＬＳｉｍｐｌｅＴｙｐｅ
ＣＯＢＯＬＳｉｍｐｌｅＴｙｐｅは、ＣＯＢＯＬ言語のすべての単純型によって共用される属性を含む抽象クラスである。
ＣＯＢＯＬＣｌａｓｓｉｆｉｅｒから派生する
パブリック属性：
ｕｓａｇｅ ： ＣＯＢＯＬＵｓａｇｅＶａｌｕｅｓ
ｕｓａｇｅには、ＣＯＢＯＬＵｓａｇｅＶａｌｕｅｓで定義されるデータ型が含まれる。
ｕｓａｇｅでは、メモリ内のデータのフォーマットが定義される。ＣＯＢＯＬソースで何も指定されていない場合には、デフォルトは”ｄｉｓｐｌａｙ”である。よく使われるＣＯＭＰ−３が、パック１０進数の同等物であることに留意されたい。
ｐｉｃｔｕｒｅＳｔｒｉｎｇ ： Ｓｔｒｉｎｇ
これは、ソースで指定されるピクチャ・ストリングの正規形式である。これは、必ずしもプログラムで与えられるピクチャ・ストリングと同一「ではない」！
ピクチャ・ストリングの正規形式に達する手順は次の通りである：
１．括弧で囲まれた文字のすべてを展開する
２．４文字より長い同一の文字のすべてのシーケンスについて、括弧で囲まれた表現を構成する。
たとえば：
ＸＸＸ９９９（３）から開始する
ステップ１の後に、ＸＸＸ９９９９９が得られる
ステップ２の後に、ＸＸＸ９（５）が得られる
この正規形式は、最短の同等なピクチャ・ストリングをもたらす。正規形式は、同等性検査に有益である。
Ｓｙｎｃｈｒｏｎｉｚｅｄ ： Ｂｏｏｌｅａｎ ＝ ｆａｌｓｅ
このブール属性は、要素について任意選択として指定することができるＳＹＮＣＨＲＯＮＩＺＥＤ文節またはＳＹＮＣ文節に対応する。
ＣＯＢＯＬ言語で、ＳＹＮＣＨＲＯＮＩＺＥＤ文節に続けることができる追加の文節ＲＩＧＨＴ／ＬＥＦＴが定義されていることに留意されたい。しかし、ＣＯＢＯＬのＩＢＭの実装では、この追加の文節が、文書化のみとしてサポートされ、ＳＹＮＣＨＲＯＮＩＺＥＤとして定義されたすべての要素が、自動的に左に同期化される。
パブリック動作：
ｇｅｔＣａｎｏｎｉｃａｌＰｉｃｔｕｒｅＳｔｒｉｎｇ （ｐｉｃｔｕｒｅＳｔｒｉｎｇ ：Ｓｔｒｉｎｇ） ： Ｓｔｒｉｎｇ
このストリングの圧縮された値を返す。たとえば、ｐｉｃｔｕｒｅＳｔｒｉｎｇ属性に、９９９９ｖ９９のピクチャ・ストリングを含めることができるが、ｇｅｔＣａｎｏｎｉｃａｌＰｉｃｔｕｒｅＳｔｒｉｎｇ（）は、値として９（４）ｖ９（２）を返す。
【０１４９】
ＣＯＢＯＬＥｌｅｍｅｎｔ
ＣＯＢＯＬＥｌｅｍｅｎｔは、ＣＯＢＯＬプログラム内のすべてのデータ定義を表す。
たとえば：
０１ ＥＭＰＬＯＹＥＥ
０３ ＳＥＲＩＡＬ−ＮＵＭＢＥＲ ＰＩＣ ９（５）．
０３ ＤＥＰＡＲＴＭＥＮＴ ＰＩＣ （５）．
ＥＭＰＬＯＹＥＥ、ＳＥＲＩＡＬ−ＮＵＭＢＥＲ、およびＤＥＰＡＲＴＭＥＮＴのすべてが、ＣＯＢＯＬＥｌｅｍｅｎｔｓである。
ＴＤＬａｎｇＥｌｅｍｅｎｔから派生する
パブリック属性：
ｌｅｖｅｌ ： Ｓｔｒｉｎｇ
ｌｅｖｅｌは、この要素が宣言されたデータ番号を指す。
ｒｅｄｅｆｉｎｅｄ ： Ｂｏｏｌｅａｎ ＝ ｆａｌｓｅ
【０１５０】
ＣＯＢＯＬＶａｒｉａｂｌｅＬｅｎｇｔｈＡｒｒａｙ
ＣＯＢＯＬＶａｒｉａｂｌｅＬｅｎｇｔｈＡｒｒａｙは、ＣＯＢＯＬＥｌｅｍｅｎｔのソースが下記の構文を有する時に、必ずインスタンス化されなければならない。
ＬＥＶＥＬ ＥＬＥＭＥＮＴＮＡＭＥ１ ＯＣＣＵＲＳ Ｘ１ ＴＯ Ｘ２ ＴＩＭＥＳＤＥＰＥＮＤＩＮＧ ＯＮ ＥＬＥＭＥＮＴＮＡＭＥ２．
ここで、Ｘ１およびＸ２は、０以上のすべての整数とすることができ、Ｘ２＞Ｘ１である。ＥＬＥＭＥＮＴＮＡＭＥ２は、ＥＬＥＭＥＮＴＮＡＭＥ１の前に定義されていなければならない。
ＣＯＢＯＬＶａｒｉａｂｌｅＬｅｎｇｔｈＡｒｒａｙは、この配列がどの要素に依存するかを指定する、単一の必要な関連を有する。
ＣＯＢＯＬＦｉｘｅｄＬｅｎｇｔｈＡｒｒａｙから派生する
パブリック属性：
ｍｉｎＵｐｐｅｒ ： Ｉｎｔｅｇｅｒ
ｍａｘＵｐｐｅｒ（最大上限）がＶａｒｉａｂｌｅＡｒｒａｙに属する場合に、ｍａｘＵｐｐｅｒは、メモリ内で割り振ることができる配列の絶対上限を示す。実際の最大値は、それが参照する要素の値によって示され、これは、”ｄｅｐｅｎｄｉｎｇＯｎ”関連を呼び出すことによって入手される。
ｍｉｎＵｐｐｅｒ（最小上限）は、ＯＣＣＵＲＳ ４ ｔｏ ７ ＴＩＭＥＳＤＥＰＥＮＤＩＮＧ ＯＮ Ｘ１の形のＣＯＢＯＬ構文を取り込むのに使用される。この場合に、ｍｉｎＵｐｐｅｒは４に等しく、ｍａｘＵｐｐｅｒは７に等しく、実際の上限は、Ｘ１の値に依存する。
ｌｏｗｅｒ（下限）は、ＣＯＢＯＬの場合には必ず１であるが、他の言語との一貫性および明瞭さのために含まれる。
【０１５１】
ＣＯＢＯＬＲｅｄｅｆｉｎｉｎｇＥｌｅｍｅｎｔ
ＲＥＤＥＦＩＮＥＳ文節を用いると、同一のコンピュータ・ストレージ域を記述する異なるデータ記述項目を使用できるようになる。
この文節の使用の例は次の通りである：
１ ＴＥＳＴ
２ Ｙ ＰＩＣ Ｘ（４）
２ ＹＲＲＥＤＥＦＩＮＥＳ Ｙ ＢＩＮＡＲＹ ＰＩＣ ９（５）
Ｔｙｐｅｄｅｆ＝再定義／共用体の場合に偽
ＣＯＢＯＬＥｌｅｍｅｎｔから派生する
【０１５２】
ＣＯＢＯＬＣｏｍｐｏｓｅｄＴｙｐｅ
ＣＯＢＯＬＣｏｍｐｏｓｅｄＴｙｐｅクラスは、追加要素を含む入れ子になった宣言を表す。ＣＯＢＯＬＣｏｍｐｏｓｅｄＴｙｐｅは、ＣＯＢＯＬＥｌｅｍｅｎｔｓの集約である。
ＣＯＢＯＬＣｏｍｐｏｓｅｄＴｙｐｅは、ＣＯＢＯＬＲｅｄｅｆｉｎｅの親クラスでもある。
たとえば：
０１ ＳＴＵＤＥＮＴ．
０５ ＣＬＡＳＳＥＳ ＯＣＣＵＲＳ ５．
１０ ＣＬＡＳＳＮＡＭＥ ＰＩＣ Ｘ（２０）．
１０ ＣＬＡＳＳＮＵＭ ＰＩＣ ９（４）．
ＳＴＵＤＥＮＴは、ＣＯＢＯＬＣｏｍｐｏｓｅｄＥｌｅｍｅｎｔによって定義される。その集約は、ＣＯＢＯＬＥｌｅｍｅｎｔであるＣＬＡＳＳＥＳ項目だけを指す。ＣＬＡＳＳＥＳ自体は、ＣＯＢＯＬＣｏｍｐｏｓｅｄＥｌｅｍｅｎｔによって定義される。
ＣＯＢＯＬＣｌａｓｓｉｆｉｅｒ、ＴＤＬａｎｇＣｏｍｐｏｓｅｄＴｙｐｅから派生する
【０１５３】
ＣＯＢＯＬ８８Ｅｌｅｍｅｎｔ
ＣＯＢＯＬ８８Ｅｌｅｍｅｎｔは、ＣＯＢＯＬ　８８データ・レベルを表す。
たとえば：
１ ＴＥＳＴＸ ＰＩＣ．
８８ ＴＲＵＥＸＶＡＬＵＥ ’Ｔ’ ’ｔ’． ＊（ＴＲＵＥＸは２つの値を有する）
８８ ＦＡＬＳＥＸＶＡＬＵＥ ’Ｆ’ ’ｆ’． ＊（ＦＡＬＳＥＸは２つの値を有する）
ここで、ＴＲＵＥＸおよびＦＡＬＳＥＸは、それぞれ、値が（’Ｔ’または’ｔ’）または（’Ｆ’または’ｆ’）と等しい場合のＴＥＳＴＸ変数の条件名である。
したがって、ＴＥＳＴＸ＝’Ｔ’または’ｔ’の場合には、ＴＲＵＥＸ＝ＴＲＵＥかつＦＡＬＳＥＸ＝ＦＡＬＳＥであり、
ＴＥＳＴＸ＝’Ｆ’または’ｆ’の場合には、ＦＡＬＳＥＸ＝ＴＲＵＥかつＴＲＵＥＸ＝ＦＡＬＳＥである
パブリック属性：
ｎａｍｅ ： Ｓｔｒｉｎｇ
ＣＯＢＯＬ８８Ｅｌｅｍｅｎｔの名前またはハンドルを指定する。
【０１５４】
ＣＯＢＯＬ８８ＥｌｅｍｅｎｔＶａｌｕｅ
このクラスの使用の例は次の通りである：
１ ＴＥＳＴＸ ＰＩＣ Ｘ．
８８ ＴＲＵＥＸＶＡＬＵＥ ’Ｔ’ ’ｔ’． ＊（ＴＲＵＥＸは２つの値を有する）
８８ ＦＡＬＳＥＸＶＡＬＵＥ ’Ｆ’ ’ｆ’． ＊（ＦＡＬＳＥＸは２つの値を有する）
８８ ＵＡ ＶＡＬＵＥ’Ａ’ ＴＨＲＵ ’Ｉ’ ’Ｊ’ ＴＨＲＵ ’Ｒ’ ’Ｓ’ ＴＨＲＵ ’Ｚ’ ’＆’ ’−’．
＊ＵＡは５つの値を有し、最初の３つは範囲である
このクラスの理論的根拠：
・このクラスが存在するのは、各ＣＯＢＯＬ８８Ｅｌｅｍｅｎｔに複数の値を含めることができるからである。たとえば、ＴＲＵＥＸには、２つの値、’Ｔ’および’ｔ’が含まれる。したがって、このクラスは、ＣＯＢＯＬ８８Ｅｌｅｍｅｎｔ（したがって、１…＊基数）ごとに複数（だが少なくとも１回）インスタンス化することができる。
・ＵＡの’Ａ’　ＴＨＲＵ　’Ｉ’などの範囲値について、ｌｏｗｅｒＬｉｍｉｔ＝’Ａ’、ｕｐｐｅｒＬｉｍｉｔ＝’Ｉ’であり、ｒａｎｇｅ＝ｔｒｕｅである。また、ＴＨＲＵキーワードを使用する時に、ｌｏｗｅｒＬｉｍｉｔがｕｐｐｅｒＬｉｍｉｔ未満でなければならないことに留意されたい。
・’Ｔ’および’ｔ’などの非範囲値について、ｌｏｗｅｒＬｉｍｉｔフィールドを使用して値を表すと決定した。
パブリック属性：
ｌｏｗｅｒＬｉｍｉｔ ： Ｓｔｒｉｎｇ
ｌｏｗｅｒＬｉｍｉｔは、ＴＨＲＯＵＧＨ範囲の下限を指す
ｕｐｐｅｒＬｉｍｉｔ ： Ｓｔｒｉｎｇ
ｕｐｐｅｒＬｉｍｉｔは、ＴＨＲＯＵＧＨ範囲の上限を指す
ｒａｎｇｅ ： Ｂｏｏｌｅａｎ
ｒａｎｇｅに真がセットされる場合には、関連付けられたデータ項目がウィンドウ化日付フィールドでない限り、リテラル−１がリテラル−２未満でなければならない。
【０１５５】
ＣＯＢＯＬＡｌｐｈａｎｕｍｅｒｉｃＴｙｐｅ
ＰＩＣＴＵＲＥ文字列は、下記のいずれかからなることが必要である：
・記号
・記号Ａ、Ｘ、および９の組合せ（すべてＡまたはすべて９を含む文字列は、英数字項目を定義しない。）
他の文節：ＵＳＡＧＥ ＤＩＳＰＬＡＹが指定されるか、暗黙指定されなければならない。
すべての関連するＶＡＬＵＥ文節で、非数字リテラルまたは表意定数を指定しなければならない。
ＣＯＢＯＬＳｉｍｐｌｅＴｙｐｅから派生する
パブリック属性：
ＪｕｓｔｉｆｙＲｉｇｈｔ ： Ｂｏｏｌｅａｎ ＝ ｆａｌｓｅ
このブール値は、ＪＵＳＴＩＦＩＥＤ（またはＪＵＳＴ）文節に対応する。ＪＵＳＴとＪＵＳＴ　ＲＩＧＨＴが同一の意味を持つことに留意されたい。
【０１５６】
ＣＯＢＯＬＮｕｍｅｒｉｃＥｄｉｔｅｄＴｙｐｅ
ＰＩＣＴＵＲＥ文字列には、下記の記号を含めることができる：
Ｂ Ｐ Ｖ Ｚ ９ ０ ／ ， ． ＋ − ＣＲ ＤＢ ＊ ｃｓ
他の文節：ＵＳＡＧＥ ＤＩＳＰＬＡＹが指定されるか、暗黙指定されなければならない。
すべての関連するＶＡＬＵＥ文節で、非数字リテラルまたは表意定数を指定しなければならない。リテラルは、正確に指定されたままで扱われ、編集は行われない。
編集される型（Ｅｄｉｔｅｄ Ｔｙｐｅｓ）は、数字が、編集される型の場合にメモリに保管され、編集されない型では保管されないという点で、編集されない型と異なる。
ＣＯＢＯＬＳｉｍｐｌｅＴｙｐｅから派生する
パブリック属性：
ＢｌａｎｋＷｈｅｎＺｅｒｏ ： Ｂｏｏｌｅａｎ
このブール値は、ＢＬＡＮＫ ＷＨＥＮ ＺＥＲＯ文節に対応する。
ＢＬＡＮＫ ＷＨＥＮ ＺＥＲＯの場合に真。
ｃｕｒｒｅｎｃｙＳｉｇｎ ： Ｓｔｒｉｎｇ
このストリングは、たとえば＄、£、ＤＭなど、世界で使用される異なる通貨記号を表す。
Ｄｅｃｉｍａｌ ： Ｂｏｏｌｅａｎ
Ｄｅｃｉｍａｌブール値は、ピクチャ・ストリングおよび数値のピリオドおよびコンマの機能を入れ替える。
真の場合には、１０進数が使用される（たとえば１，２３４．５６）
偽の場合には、コンマが使用される（たとえば、１．２３４，５６）
【０１５７】
ＣＯＢＯＬＮｕｍｅｒｉｃＴｙｐｅ
数値項目の型は、次の通りである：
・２進数
・パック１０進数（内部１０進数）
・ゾーン１０進数（外部１０進数）
ＰＩＣＴＵＲＥ文字列には、記号９、Ｐ、Ｓ、およびＶだけを含めることができる。数値データ・フィールドの場合に、ＰＩＣＴＵＲＥ文字列に、記号９およびＳだけを含めることができる。
有効な範囲の例
ＰＩＣＴＵＲＥ　有効な値の範囲
９９９９　　　　０から９９９９まで
Ｓ９９　　　　　−９９から＋９９まで
Ｓ９９９Ｖ９　　−９９９．９から＋９９９．９まで
ＰＰＰ９９９　　０から．０００９９９まで
Ｓ９９９ＰＰＰ　−１０００から−９９９０００までおよび＋１０００から＋９９９０００までまたは０
他の文節：項目のＵＳＡＧＥは、ＤＩＳＰＬＡＹ、ＢＩＮＡＲＹ、ＣＯＭＰＵＴＡＴＩＯＮＡＬ、ＰＡＣＫＥＤ−ＤＥＣＩＭＡＬ、ＣＯＭＰＵＴＡＴＩＯＮＡＬ−３、ＣＯＭＰＵＴＡＴＩＯＮＡＬ−４、またはＣＯＭＰＵＴＡＴＩＯＮＡＬ−５とすることができる。
このクラスの可能な使用値は、’ｂｉｎａｒｙ’、’ｐａｃｋｅｄＤｅｃｉｍａｌ’、および’ｄｉｓｐｌａｙ’であり、これらは、それぞれｃｏｍｐ−１宣言およびｃｏｍｐ−２宣言によって表される。
ＣＯＢＯＬＳｉｍｐｌｅＴｙｐｅから派生する
パブリック属性：
Ｓｉｇｎｅｄ ： Ｂｏｏｌｅａｎ
このブール値は、ＳＩＧＮ文節に対応する。
数が符号付きである場合に真。
ＳｉｇｎＬｅａｄｉｎｇ ： Ｂｏｏｌｅａｎ
この属性は、ＬＥＡＤＩＮＧ（ＴＲＡＩＬＩＮＧに対する）文節に対応する。
ＬＥＡＤＩＮＧの場合に真。
ＳｉｇｎＳｅｐａｒａｔｅ ： Ｂｏｏｌｅａｎ
このブール値は、ＳＥＰＡＲＡＴＥ文節に対応する。
ＳＥＰＡＲＡＴＥの場合に真。
ｃｕｒｒｅｎｃｙＳｙｍｂｏｌ ： ｃｈａｒ
この文字は、ＣＯＢＯＬでｃｕｒｒｅｎｃｙＳｉｇｎを表すのに使用される記号（たとえば、＄＝＄、Ｌ＝£、Ｄ＝ＤＭなど）を表す。
ｔｒｕｎｃ ： Ｓｔｒｉｎｇ
Ｔｒｕｎｃオプションによって、２進データ項目について１０進数ピクチャ制約を順守しなければならないかどうかが決定される。
Ｔｒｕｎｃの値は次の通りである：
ＳＴＤ、ＯＰＴ、およびＢＩＮ
ＴＲＵＮＣ（ＳＴＤ）は、ＣＯＢＯＬ　８５標準規格に準拠するが、ＴＲＵＮＣ（ＯＰＴ）およびＴＲＵＮＣ（ＢＩＮ）は、ＩＢＭ拡張である。
Ｔｒｕｎｃ属性に関するさらなる情報については、「ＣＯＢＯＬ／ＶＳＥＰｒｏｇｒａｍｍｉｎｇ Ｇｕｉｄｅ」を参照されたい。
ｎｕｍｐｒｏｃ ： Ｓｔｒｉｎｇ
Ｎｕｍｐｒｏｃ（ＰＤＦ）は、１０進符号値に関するより厳格な標準規格を負わせる。
Ｎｕｍｐｒｏｃの値は次の通りである：
ＮＯＰＤＦ、ＰＤＦ、およびＭＩＧ。
コンパイラに無効な符号の処理を実行させたい場合には、ＮＵＭＰＲＯＣ（ＮＯＰＦＤ）を使用する。このオプションは、ＮＵＭＰＲＯＣ（ＰＦＤ）ほど効率的ではない。オブジェクト・コード・サイズが増え、すべての符号付きデータを検証するために実行時オーバーヘッドが増える可能性がある。
ＮＵＭＰＲＯＣ（ＮＯＰＦＤ）およびＮＵＭＰＲＯＣ（ＭＩＧ）は、ＣＯＢＯＬ　８５標準規格に準拠する。
Ｄｅｃｉｍａｌ ： Ｂｏｏｌｅａｎ
Ｄｅｃｉｍａｌブール値は、ピクチャ・ストリングおよび数値のピリオドおよびコンマの機能を入れ替える。
真の場合には、１０進数が使用される（たとえば１，２３４．５６）
偽の場合には、コンマが使用される（たとえば、１．２３４，５６）
【０１５８】
ＣＯＢＯＬ６６Ｅｌｅｍｅｎｔ
ＣＯＢＯＬ６６Ｅｌｅｍｅｎｔは、ＣＯＢＯＬ　６６データ・レベルを表す。
たとえば：
Figure 2004506264
この例で、ＳＵＢ−ＤＡＴＡは、ＤＡＴＡ１およびＤＡＴＡ２の内容を参照する。
パブリック属性：
ｎａｍｅ ： Ｓｔｒｉｎｇ
ＣＯＢＯＬ６６Ｅｌｅｍｅｎｔの名前またはハンドルを指定する。
【０１５９】
ＣＯＢＯＬＦｉｘｅｄＬｅｎｇｔｈＡｒｒａｙ
ＣＯＢＯＬＦｉｘｅｄＬｅｎｇｔｈＡｒｒａｙは、ＣＯＢＯＬＥｌｅｍｅｎｔのソースが下記の構文を有する時に、必ずインスタンス化されなければならない：
ＬＥＶＥＬ ＥＬＥＭＥＮＴＮＡＭＥ ＯＣＣＵＲＳ Ｘ ＴＩＭＥＳ．
ここで、Ｘは、１以上の任意の整数とすることができる。
ｍａｘＵｐｐｅｒ（最大上限）がＦｉｘｅｄＡｒｒａｙに属する場合に、ｍａｘＵｐｐｅｒは、メモリ内で割り振られる配列の上限を示す。
ｌｏｗｅｒ（下限）は、ＣＯＢＯＬの場合には必ず１であるが、他の言語との一貫性および明瞭さのために含まれる。
【０１６０】
ＣＯＢＯＬＤＢＣＳＴｙｐｅ
ＰＩＣＴＵＲＥ文字列に、記号Ｇ、ＧおよびＢ、またはＮを含めることができる。Ｇ、Ｂ、またはＮのそれぞれが、単一のＤＢＣＳ文字位置を表す。ＤＢＣＳリテラルの文字の範囲全体を使用することができる。
他の文節：ＰＩＣＴＵＲＥ文節記号Ｇが使用される時には、ＵＳＡＧＥ ＤＩＳＰＬＡＹ−１を指定しなければならない。
ＰＩＣＴＵＲＥ文節記号Ｎが使用される時には、ＵＳＡＧＥ ＤＩＳＰＬＡＹ−１が、仮定され、指定する必要ない。
すべての関連するＶＡＬＵＥ文節で、ＤＢＣＳリテラルまたは表意定数ＳＰＡＣＥ／ＳＰＡＣＥＳを指定しなければならない。
ＤＢＣＳＴｙｐｅは、１文字ごとに２バイトを占有する。
ＣＯＢＯＬＳｉｍｐｌｅＴｙｐｅから派生する
【０１６１】
ＣＯＢＯＬＡｌｐｈａｎｕｍｅｒｉｃＥｄｉｔｅｄＴｙｐｅ
ＰＩＣＴＵＲＥ文字列に、下記の記号を含めることができる：
Ａ Ｘ ９ Ｂ ０ ／
ストリングには、少なくとも１つのＡまたはＸが含まれ、少なくとも１つのＢまたは０（ゼロ）または／が含まれなければならない。
標準データ・フォーマットの項目の内容は、コンピュータの文字セットからの２つ以上の文字でなければならない。
他の文節：ＵＳＡＧＥ ＤＩＳＰＬＡＹが指定されるか、暗黙指定されなければならない。
すべての関連するＶＡＬＵＥ文節で、非数字リテラルまたは表意定数を指定しなければならない。リテラルは、正確に指定されたままで扱われ、編集は行われない。
編集される型は、数字が、編集される型の場合にメモリに保管され、編集されない型では保管されないという点で、編集されない型と異なる。
ＣＯＢＯＬＳｉｍｐｌｅＴｙｐｅから派生する
【０１６２】
ＣＯＢＯＬＣｌａｓｓｉｆｉｅｒ
ＣＯＢＯＬＣｌａｓｓｉｆｉｅｒクラスは、ＣＯＢＯＬＣｏｍｐｏｓｅｄＴｙｐｅおよびＣＯＢＯＬＳｉｍｐｌｅＴｙｐｅの親クラスであり、’ｔｙｐｅｄｅｆ’属性を含む。
ＣＯＢＯＬでのＴＹＰＥＤＥＦの影響を考える最も良い方法は、単純なＣマクロに似た字句置換である。ＴＹＰＥ文節を、ＴＹＰＥＤＥＦキーワードに続くすべてのものに置換する。その後、レベル番号を適当に調整した後に、結果が、正しいＣＯＢＯＬにならなければならない（調整されるレベル番号自体（４９を超えることができる）を除く）。実際のルールは、予想されるであろうように非常に複雑であり、したがって、説明するのではなく、例を示す：
財務データに関するショップ・スタンダードを実施する単純な方法：
定義：
１ ｕｎｉｆｏｒｍ−ａｍｏｕｎｔ ｔｙｐｅｄｅｆｕｓａｇｅ ｃｏｍｐ ｐｉｃ ｓ９（６）ｖ９９ ｓｙｎｃｈｒｏｎｉｚｅｄ．
参照：
１ ａｃｃｏｕｎｔ−ｒｅｃｏｒｄ．
．．．
５ ｐｒｉｏｒ−ｂａｌａｎｃｅｔｙｐｅ ｕｎｉｆｏｒｍ−ａｍｏｕｎｔ．
５ ｃｕｒｒｅｎｔ−ｂａｌａｎｃｅｔｙｐｅ ｔｏ ｕｎｉｆｏｒｍ−ａｍｏｕｎｔ．
．．．
ＴＤＬａｎｇＣｌａｓｓｉｆｉｅｒから派生する
パブリック属性：
Ｔｙｐｅｄｅｆ ： ｂｏｏｌｅａｎ
ユーザ定義型は、ＴＹＰＥＤＥＦ属性を使用することによって導入され、ＴＹＰＥ文節によって参照される。型がユーザ定義である場合に、’ｔｙｐｅｄｅｆ’＝真である。
Ｔｙｐｅｄｅｆ＝再定義／共用体の場合にＦａｌｓｅ
ｎａｍｅ ： Ｓｔｒｉｎｇ
ＣＯＢＯＬＣｌａｓｓｉｆｉｅｒの名前またはハンドルを指定する。
【０１６３】
ＣＯＢＯＬＡｌｐｈａｂｅｔｉｃＴｙｐｅ
ＰＩＣＴＵＲＥ文字列に、記号Ａだけを含めることができる。
標準データ・フォーマットの項目の内容は、英語アルファベットの文字およびスペース文字のいずれかからなる必要がある。
他の文節：ＵＳＡＧＥ ＤＩＳＰＬＡＹが指定されるか、暗黙指定されなければならない。
すべての関連するＶＡＬＵＥ文節で、アルファベット文字、スペース、または表意定数の値としての記号文字だけを含む非数値リテラルを指定しなければならない。
ＣＯＢＯＬＳｉｍｐｌｅＴｙｐｅから派生する
パブリック属性：
ＪｕｓｔｉｆｙＲｉｇｈｔ ： Ｂｏｏｌｅａｎ ＝ ｆａｌｓｅ
このブール値は、ＪＵＳＴＩＦＩＥＤ（またはＪＵＳＴ）文節に対応する。ＪＵＳＴとＪＵＳＴ　ＲＩＧＨＴが同一の意味を持つことに留意されたい。
【０１６４】
ＣＯＢＯＬＯｂｊｅｃｔＲｅｆｅｒｅｎｃｅＴｙｐｅ
このオブジェクト参照型は、ＣＯＢＯＬでＵＳＡＧＥ ＩＳ ＩＮＤＥＸ ＯＢＪＥＣＴＲＥＦＥＲＥＮＣＥ ＭＥＴＡＣＬＡＳＳ ＯＦ ｃｌａｓｓ−ｎａｍｅ−１（ｃｌａｓｓ−ｎａｍｅ−１は任意選択である）として宣言されたオブジェクトをポイントする。
ＣＯＢＯＬＳｉｍｐｌｅＴｙｐｅから派生する
パブリック属性：
ｃｌａｓｓＮａｍｅ ： Ｓｔｒｉｎｇ
このインスタンスが参照するオブジェクトの名前を参照する。
【０１６５】
ＣＯＢＯＬＳｏｕｒｃｅＴｅｘｔ
このクラスには、ソース・コード全体（コメントを含む）およびそれに関連する行番号が含まれる。
パブリック属性：
ｓｏｕｒｃｅ ： Ｓｔｒｉｎｇ
ｆｉｌｅＮａｍｅ ： Ｓｔｒｉｎｇ
【０１６６】
ＣＯＢＯＬＵｎｉｃｏｄｅＴｙｐｅ
このユニコード型は、ユニコード・フォーマットで保管されたデータを表す。
ＣＯＢＯＬＳｉｍｐｌｅＴｙｐｅから派生する
【０１６７】
ＣＯＢＯＬＩｎｔｅｒｎａｌＦｌｏａｔＴｙｐｅ
ＣＯＢＯＬＩｎｔｅｒｎａｌＦｌｏａｔ型は、浮動小数点がメモリ内で表される形を取り込む。たとえば、値１２３．４５は、内部的に１２３４５と表され、暗黙の小数部が、３と４の間でマークされる。
このクラスの可能な使用値は、’ｆｌｏａｔ’および’ｄｏｕｂｌｅ’であり、これは、それぞれｃｏｍｐ−１宣言およびｃｏｍｐ−２宣言によって表される。
ＣＯＢＯＬＳｉｍｐｌｅＴｙｐｅから派生する
【０１６８】
ＣＯＢＯＬＥｘｔｅｒｎａｌＦｌｏａｔＴｙｐｅ
ＣＯＢＯＬＥｘｔｅｒｎａｌＦｌｏａｔ型は、浮動小数点がユーザに表示される形を取り込む。ＣＯＢＯＬＥｘｔｅｒｎａｌＦｌｏａｔＴｙｐｅｓは、ＰＩＣが、仮数および指数の前に＋／−符号を有する点を除いて、ＣＯＢＯＬＮｕｍｅｒｉｃＥｄｉｔｅｄＴｙｐｅｓと同一である。たとえば、値１２３．４５は、ＥｘｔｅｒｎａｌＦｌｏａｔＴｙｐｅでは＋１２３４５Ｅ −２として表される。
このクラスの可能な使用値は、’ｂｉｎａｒｙ’、’ｐａｃｋｅｄＤｅｃｉｍａｌ’、および’ｄｉｓｐｌａｙ’である。
ＣＯＢＯＬＳｉｍｐｌｅＴｙｐｅから派生する
【０１６９】
ＣＯＢＯＬＡｄｄｒｅｓｓｉｎｇＴｙｐｅ
ＣＯＢＯＬＡｄｄｒｅｓｓｉｎｇＴｙｐｅは、インデックス値、ポインタ値、およびｐｒｏｃｅｄｕｒｅＰｏｉｎｔｅｒ値に使用される。
このクラスの可能な使用値は、’ｉｎｄｅｘ’、’ｐｏｉｎｔｅｒ’ 、および’ｐｒｏｃｅｄｕｒｅＰｏｉｎｔｅｒ’である。
ＣＯＢＯＬＳｉｍｐｌｅＴｙｐｅから派生する
【０１７０】
ＣＯＢＯＬＥｌｅｍｅｎｔＩｎｉｔｉａｌＶａｌｕｅ
ＴＤＬａｎｇＥｌｅｍｅｎｔから派生する
パブリック属性：
ｉｎｉｔＶａｌ ： Ｓｔｒｉｎｇ
ｖａｌｕｅＫｉｎｄ ： ＣＯＢＯＬＩｎｉｔｉａｌＶａｌｕｅＫｉｎｄ ＝ｓｔｒｉｎｇ＿ｖａｌｕｅ
【０１７１】
総計：
１論理パッケージ
２３クラス
論理パッケージ構造
論理ビュー
ｃｏｂｏｌ
ＴＤＬａｎｇ
【０１７２】
５．ｂ．ＰＬ／Ｉメタモデル
ＰＬ／Ｉ言語メタモデルは、コネクタ・インターフェースを表すデータ構造体（セマンティクス）を定義するために、エンタープライズ・アプリケーション・プログラムによって使用される。このメタモデルは、Ｍ２レベルのＭＯＦクラス・インスタンスである。図１９、図２０、および図２１に、コネクタ・インターフェースを表すデータ構造体を定義するためにアプリケーション・プログラムによって使用可能なＰＬ／Ｉ言語メタモデルを示す。このメタモデルは、Ｍ２レベルのＭＯＦクラス・インスタンスである。図２２に、ＰＬ／ＩメタモデルのＴＤＬａｎｇＣｌａｓｓｉｆｉｅｒ、ＴＤＬａｎｇｕａｇｅＣｏｍｐｏｓｅｄＴｙｐｅ、およびＴＤＬａｎｇｕａｇｅＥｌｅｍｅｎｔを示す。図２３に、ＰＬ／ＩメタモデルのＭｏｄｅＶａｌｕｅｓ、ＢａｓｅＶａｌｕｅｓ、ＬｅｎｇｔｈＴｙｐｅｓ、およびＳｔｒｉｎｇＴｙｐｅＶａｌｕｅｓの列挙を示す。
【０１７３】
５．ｂ．ｉ．ＰＬ／Ｉメタモデル仕様
ＰＬ／Ｉ
ＰＬ／Ｉ言語メタモデルは、コネクタ・インターフェースを表すデータ構造体（セマンティクス）を定義するために、エンタープライズ・アプリケーション・プログラムによって使用される。
このＰＬ／Ｉの言語モデルは、ＰＡＲＡＭＥＴＥＲ、ＳＴＡＴＩＣ、またはＢＡＳＥＤのいずれかのストレージ・クラスを有するＰＬ／Ｉ宣言を記述することを試みる。ＣＯＮＴＲＯＬＬＥＤ、ＡＵＴＯＭＡＴＩＣ、およびＤＥＦＩＮＥＤはサポートされない。
ＰＬ／Ｉ言語では、エクステント（すなわち、ストリング長、区域サイズ、および配列の限界）が、一般に、定数として、実行時に評価される式として、アスタリスクとして、またはＲＥＦＥＲオプションを介して定義されるものとして、宣言されるが、これらの選択肢のどれもが、すべてのストレージ・クラスに対して有効ではない。
エクステントが定数でなく、ＲＥＦＥＲオプションを介して定義されるのでない基底付き変数は、エクステントがアスタリスクを介して指定されるパラメータと同様に、このモデルから除外される。
ＩＮＩＴＩＡＬ属性（どの場合にもパラメータについては無効である）は、このモデルでは無視される。
【０１７４】
ＰＬＩＳｉｍｐｌｅＴｙｐｅ
ＰＬＩＳｉｍｐｌｅＴｙｐｅは、ＰＬ／Ｉ言語のすべての単純型によって共用される属性を含む抽象クラスである。
ＰＬＩＣｌａｓｓｉｆｉｅｒから派生する
【０１７５】
ＰＬＩＥｌｅｍｅｎｔ
＊ＰＬＩＤｅｃｌａｒａｔｉｏｎは、ＰＬ／Ｉプログラムのすべてのデータ定義を表す。
＊たとえば：
Figure 2004506264
ここで、Ｅｅｍｐｌｏｙｅｅ、Ｎａｍｅ、Ｌａｓｔ、Ｆｉｒｓｔ、およびＤｅｐａｒｔｍｅｎｔのすべてがＰＬＩＥｌｅｍｅｎｔｓである。
ＴＤＬａｎｇＥｌｅｍｅｎｔから派生する
パブリック属性：
ｌｅｖｅｌ ： Ｓｔｒｉｎｇ
【０１７６】
ＰＬＩＣｏｍｐｏｓｅｄＴｙｐｅ
ＰＬＩＣｏｍｐｏｓｅｄＴｙｐｅは、構造体、共用体、または基本的な変数および配列とすることができる、メンバ要素の集合である。ＰＬＩＣｏｍｐｏｓｅｄＴｙｐｅは、この構成の一部であるすべての要素を含む単一の集約を有する。
構造体は、その要素が同一の属性を有する必要がないデータ集約である。配列と同様に、構造体全体に、データの集約全体を参照するのに使用することができる名前が与えられる。しかし、配列と異なって、構造体の各要素も名前を有する。
構造体は、異なるレベルを有する。第１レベルでは、構造体名が、主構造と呼ばれる。より深いレベルでは、構造体の名前を、小構造と呼ぶ。最も深いレベルでは、要素の名前を要素名と呼ぶ。構造体の要素名は、配列を表すことができ、この場合に、その要素は、要素変数ではなく配列変数である。
構造体の編成は、関連する名前に先立つレベル番号の使用を介して、ＤＥＣＬＡＲＥステートメントで指定され、レベル番号は、整数でなければならない。主構造名は、レベル番号１を用いて宣言される。
小構造および要素名は、１より大きいレベル番号を用いて宣言される。
主構造名の記述は、下記の１つによって終了する：
レベル番号１を有するもう１つの項目の宣言
レベル番号がないもう１つの項目の宣言
ＤＥＣＬＡＲＥステートメントを終了するセミコロン
区切り文字（通常はブランク）によって、レベル番号とそれに関連する名前を区切らなければならない。たとえば、従業員名簿（ｐａｙｒｏｌｌ）の項目を、次のように宣言することができる：
Figure 2004506264
字下げは、読みやすくするためのものでしかない。ステートメントは、ＤＥＣＬＡＲＥ　１　ＰＡＹＲＯＬＬ、　２　ＮＡＭＥ、　３　ＬＡＳＴＣＨＡＲ（２０）、などとして、連続するストリングで記述することができる。
ＰＡＹＲＯＬＬは、小構造ＮＡＭＥ、ＨＯＵＲＳ、およびＲＡＴＥを含む主構造として宣言される。各小構造に、２つの要素名が含まれる。この構造体全体を、名前ＰＡＹＲＯＬＬによって参照することができ、また、この構造体の部分を、小構造体名によって参照することができる。要素は、要素名を引用することによって参照することができる。
連続するより深いレベルについて選択されるレベル番号は、連続的である必要がない。レベルｎの小構造に、その小構造名とｎ以下のレベル番号を有する次の名前との間にある、ｎを超えるレベル番号を有するすべての名前が含まれる。ＰＡＹＲＯＬＬを、下記のように宣言することができる。
Figure 2004506264
この宣言は、前の宣言と正確に同一の構造化をもたらす。
ＰＬＩＣｌａｓｓｉｆｉｅｒ、ＴＤＬａｎｇＣｏｍｐｏｓｅｄＴｙｐｅから派生する
パブリック属性：
Ｕｎｉｏｎ ： Ｂｏｏｌｅａｎ
【０１７７】
ＰＬＩＥｌｅｍｅｎｔＩｎｉｔｉａｌＶａｌｕｅ
ＩＮＩＴＩＡＬ属性によって、ストレージが割り振られる時に変数に割り当てられる１つまたは複数の初期値が指定される。要素変数については、１つの初期値だけを指定することができる。配列変数については、複数を指定することができる。構造体変数または共用体変数は、要素変数であれ配列変数であれ、要素名の別々の初期化によってのみ初期化することができる。ＩＮＩＴＩＡＬ属性は、定数、定義されるデータ、非制御パラメータでないパラメータ、および非ＬＩＭＩＴＥＤ静的項目変数に与えることができない。
ＩＮＩＴＩＡＬ属性は、３つの形を有する。
１．第１の形、ＩＮＩＴＩＡＬでは、初期定数、式、または関数参照が指定され、これらについて、変数にストレージが割り振られる時に、変数に値が割り当てられる。
２．第２の形、ＩＮＩＴＩＡＬ ＣＡＬＬでは、プロシージャが初期化を実行するために呼び出されることが（ＣＡＬＬオプションを用いて）指定される。変数は、呼び出されるルーチンの実行中の割当によって初期化される（このルーチンは、呼び出し点に値を返す関数としては呼び出されない）。
３．第３の形、ＩＮＩＴＩＡＬ ＴＯでは、ポインタ（またはポインタの配列）が、ＩＮＩＴＩＡＬＬＩＳＴで指定された文字列のアドレスを用いて初期化されることが指定される。このストリングは、ＴＯキーワードによって示される属性も有する。
ＴＤＬａｎｇＥｌｅｍｅｎｔから派生する
パブリック属性：
ｉｎｉｔｉａｌＶａｌｕｅ ： Ｓｔｒｉｎｇ
ＶａｌｕｅＴｙｐｅ ： ＰＬＩＩｎｉｔａｌＶａｌｕｅＴｙｐｅ
【０１７８】
ＰＬＩＣｌａｓｓｉｆｉｅｒ
ＰＬＩ型
ＴＤＬａｎｇＣｌａｓｓｉｆｉｅｒから派生する
【０１７９】
ＰＬＩＳｏｕｒｃｅＴｅｘｔ
このクラスには、ソース・コード全体（コメントを含む）およびそれに関連する行番号が含まれる。
パブリック属性：
ｓｏｕｒｃｅ ： Ｓｔｒｉｎｇ
ｆｉｌｅＮａｍｅ ： Ｓｔｒｉｎｇ
【０１８０】
ＰＬＩＣｏｍｐｕｔａｔｉｏｎａｌＴｙｐｅ
計算型は、所望の結果を作るために計算に使用される値を表す。算術データおよびストリング・データが、計算データを構成する。
ＰＬＩＳｉｍｐｌｅＴｙｐｅから派生する
【０１８１】
ＰＬＩＡｒｉｔｈｍｅｔｉｃＴｙｐｅ
算術データは有理数である
ＰＬＩＣｏｍｐｕｔａｔｉｏｎａｌＴｙｐｅから派生する
パブリック属性：
ｍｏｄｅ ： ＭｏｄｅＶａｌｕｅｓ
【０１８２】
ＰＬＩＳｔｒｉｎｇＴｙｐｅ
ストリングは、連続する文字、ビット、ｗｉｄｅｃｈａｒ、およびｇｒａｐｈｉｃの、単一のデータ項目として扱われるシーケンスである。
ＰＬＩＣｏｍｐｕｔａｔｉｏｎａｌＴｙｐｅから派生する
【０１８３】
ＰＬＩＩｎｔｅｇｅｒＴｙｐｅ
Ｆｉｘｅｄ Ｂｉｎとして宣言される。精度とスケール・ファクタを有する。精度は、総桁数であり、スケールは、２進小数点の右側の桁数である。
例
ＤＣＬ ｂｉｎｄａｔａ ＢＩＮＡＲＹ ＦＩＸＥＤ （７，３）
は、７データ・ビットであり、そのうちの３ビットが２進小数点の右にある数、１０１１．１１１Ｂを表すのに使用することができる。
ＰＬＩＡｒｉｔｈｍｅｔｉｃＴｙｐｅから派生する
パブリック属性：
ｐｒｅｃｉｓｉｏｎ ： Ｉｎｔｅｇｅｒ
ｓｃａｌｅ ： Ｉｎｔｅｇｅｒ
Ｓｉｇｎｅｄ ： Ｂｏｏｌｅａｎ
ＢｉｇＥｎｄｉａｎ ： Ｂｏｏｌｅａｎ ＝ ｔｒｕｅ
【０１８４】
ＰＬＩＦｌｏａｔＴｙｐｅ
は、＝Ａを有する。１０進浮動小数点定数は、仮数とそれに続く指数である。仮数は、１０進固定小数点定数である。指数は、文字Ｅと、それに続く任意選択として符号付きの整数であり、これは１０のべきを指定する。１０進浮動小数点定数は、精度（ｐ）を有し、このｐは、仮数の桁数である。
例は次の通りである：
１５Ｅ−２３　　は精度＝２を有する
１５Ｅ２３　　は精度＝２を有する
４Ｅ−３　　は精度＝１を有する
１．９６Ｅ＋０７　　　は精度＝３を有する
４３８Ｅ０　　　は精度＝３を有する
３１４１５９３Ｅ−６　　　　　は精度＝７を有する
．００３１４１５９３Ｅ３　　　　　　　は精度＝９を有する
最後の２つの例は、同一の値を表す（精度は異なる）。
１０進浮動小数点変数の宣言に関するデータ属性は、ＤＥＣＩＭＡＬおよびＦＬＯＡＴである。たとえば：
ＤＥＣＬＡＲＥＬＩＧＨＴ＿ＹＥＡＲＳ ＤＥＣＩＭＡＬ ＦＬＯＡＴ（５）；
ＬＩＧＨＴ＿ＹＥＡＲＳは、少なくとも５つの１０進数字を有する１０進浮動小数点データ項目を表す。
２進浮動小数点定数は、仮数とそれに続く指数および文字Ｂである。仮数は、２進数固定小数点定数である。指数は、文字Ｅと、それに続く任意選択として符号付きの１０進整数であり、これは２のべきを指定する。２進浮動小数点定数は、精度（ｐ）を有し、このｐは、仮数の２進数字の数である。例は次の通りである：
１０１１０１Ｅ５Ｂ　　　　は精度＝６を有する
１０１．１０１Ｅ２Ｂ　　　　は精度＝６を有する
１１１０１Ｅ−２８Ｂ　　　　は精度＝５を有する
１１．０１Ｅ＋４２Ｂ　　　　は精度＝４を有する
２進浮動小数点変数の宣言に関するデータ属性は、ＢＩＮＡＲＹおよびＦＬＯＡＴである。たとえば：
ＤＥＣＬＡＲＥ Ｓ ＢＩＮＡＲＹ ＦＬＯＡＴ （１６）；
Ｓは、１６個の２進数の精度を有する２進浮動小数点データ項目を表す。
デフォルトの精度は（２１）である。指数は、１０進数３個を超えることができない。２進浮動小数点データは、正規化された１６進浮動小数点として保管される。宣言された精度が（２１）以下である場合には、ｓｈｏｒｔ浮動小数点形が使用される。宣言された精度が（２１）を超え、（５３）以下である場合には、ｌｏｎｇ浮動小数点形が使用される。宣言された精度が（５３）を超える場合には、ｅｘｔｅｎｄｅｄ浮動小数点形が使用される。
ＰＬＩＡｒｉｔｈｍｅｔｉｃＴｙｐｅから派生する
パブリック属性：
ｂａｓｅ ： ＢａｓｅＶａｌｕｅｓ
ｐｒｅｃｉｓｉｏｎ ： Ｉｎｔｅｇｅｒ
ＩＥＥＥ ： Ｂｏｏｌｅａｎ ＝ ｆａｌｓｅ
ＢｉｇＥｎｄｉａｎ ： Ｂｏｏｌｅａｎ ＝ ｔｒｕｅ
【０１８５】
ＰＬＩＰａｃｋｅｄＴｙｐｅ
１０進固定小数点変数の宣言に関するデータ属性は、ＤＥＣＩＭＡＬおよびＦＩＸＥＤである。たとえば：
ｄｅｃｌａｒｅ Ａ ｆｉｘｅｄ ｄｅｃｉｍａｌ （５，４）；
では、Ａが５桁の１０進固定小数点データを表し、５桁のうちの４桁が、小数点の右にあることが指定される。
次の２つの例：
ｄｅｃｌａｒｅ Ｂ ｆｉｘｅｄ （７，０） ｄｅｃｉｍａｌ；
ｄｅｃｌａｒｅ Ｂｆｉｘｅｄ ｄｅｃｉｍａｌ（７）；
の両方で、Ｂが７桁の整数を表すことが指定される。
次の例
ｄｅｃｌａｒｅ Ｃ ｆｉｘｅｄ （７，−２） ｄｅｃｉｍａｌ；
では、Ｃが−２の位取り係数を有することが指定される。これは、Ｃが、１００の増分で範囲−９９９９９９９×１００から９９９９９９９×１００までの７桁を保持することを意味する。
次の例
ｄｅｃｌａｒｅ Ｄ ｄｅｃｉｍａｌ ｆｉｘｅｄ ｒｅａｌ（３，２）；
では、Ｄが、３桁の固定小数点データを表し、３桁のうちの２桁が小数であることが指定される。
ＰＬＩＡｒｉｔｈｍｅｔｉｃＴｙｐｅから派生する
パブリック属性：
ｐｒｅｃｉｓｉｏｎ ： Ｉｎｔｅｇｅｒ
ｓｃａｌｅ ： Ｉｎｔｅｇｅｒ
【０１８６】
ＰＬＩＰｉｃｔｕｒｅＴｙｐｅ
数字ピクチャ・データは、文字形式で保持される数値データである
ＰＬＩＡｒｉｔｈｍｅｔｉｃＴｙｐｅから派生する
パブリック属性：
ｐｉｃｔｕｒｅＳｔｒｉｎｇ ： Ｓｔｒｉｎｇ
【０１８７】
ＰＬＩＣｏｄｅｄＳｔｒｉｎｇＴｙｐｅ
ＰＬＩＳｔｒｉｎｇＴｙｐｅから派生する
パブリック属性：
ｔｙｐｅ ： ＳｔｒｉｎｇＴｙｐｅＶａｌｕｅｓ
ｖａｒｙｉｎｇ ： ＬｅｎｇｔｈＴｙｐｅ
【０１８８】
ＰＬＩＰｉｃｔｕｒｅＳｔｒｉｎｇＴｙｐｅ
文字ピクチャ指定では、固定小数点文字データ項目が記述され、データ項目内の任意の位置に、使用可能な文字の完全な組のあるサブセットからの文字だけが含まれることを指定する追加機能がある。
文字ピクチャ指定は、ＡまたはＸのピクチャ指定文字の出現によって認識される。文字ピクチャ指定で有効な文字は、Ｘ、Ａ、および９だけである。これらのそれぞれによって、文字値内の１つの文字位置の存在が指定され、これには、下記を含めることができる：
Ｘ　８ビット・バイトによって表される２５６個の可能なビット組合せのすべての文字。
Ａ　英数字文字、＃、＠、＄、またはブランク。
９　任意の数字またはブランク（数値文字指定での９ピクチャ指定文字は、対応する文字が数字だけである点で異なることに留意されたい）。
文字値がピクチャ形式文字データ項目に割り当てられるか転送される時に、各位置の特定の文字が、対応するピクチャ指定文字による指定に従って有効性を検査され、無効な文字についてＣＯＮＶＥＲＳＩＯＮ状態が発生する（しかし、レコード指向伝送を介するか別名を使用することのいずれかによって値が変更される場合には、検査はない）。
たとえば：
ＤＥＣＬＡＲＥ ＰＡＲＴ＃ ＰＩＣＴＵＲＥ ’ＡＡＡ９９Ｘ’；
ＰＵＴ ＥＤＩＴ （ＰＡＲＴ＃） （Ｐ’ＡＡＡ９９Ｘ’）；
次の値は、ＰＡＲＴ＃について有効である：
Figure 2004506264
次の値は、ＰＡＲＴ＃について有効でない（無効な文字に下線を付ける）：
Figure 2004506264
ＰＬＩＳｔｒｉｎｇＴｙｐｅから派生する
パブリック属性：
ｐｉｃｔｕｒｅＳｔｒｉｎｇ ： Ｓｔｒｉｎｇ
【０１８９】
ＰＬＩＮｏｎＣｏｍｐｕｔａｔｉｏｎａｌＴｙｐｅ
プログラムの実行を制御するのに使用される値を表す。次のデータ型からなる。ａｒｅａ、ｅｎｔｒｙ、ｌａｂｅｌ、ｆｉｌｅ、ｆｏｒｍａｔ、ｐｏｉｎｔｅｒ、およびｏｆｆｓｅｔ。
ＰＬＩＳｉｍｐｌｅＴｙｐｅから派生する
【０１９０】
ＰＬＩＬａｂｅｌＴｙｐｅ
ラベルは、ラベル定数またはラベル変数の値である。
ラベル定数は、ステートメントのラベル・プレフィックス（ＰＲＯＣＥＤＵＲＥ、ＥＮＴＲＹ、ＰＡＣＫＡＧＥ、またはＦＯＲＭＡＴ以外）として記述され、その結果、実行中に、それへの参照を介してプログラム制御をそのステートメントに転送することができる名前である。次のコードの行では、たとえば、Ａｂｃｄｅがラベル定数である。
Ａｂｃｄｅ： Ｍｉｌｅｓ ＝ Ｓｐｅｅｄ＊Ｈｏｕｒｓ；
ラベル付きステートメントは、命令の通常のシーケンシャル実行、またはプログラム内の他の点からそのステートメントに制御を転送するためのＧＯ ＴＯステートメントの使用のいずれかによって実行することができる。
ラベル変数に、もう１つのラベル変数またはラベル定数を割り当てることができる。そのような割当が行われる時に、ソース・ラベルの環境が、ターゲットに割り当てられる。ラベルの静的配列が初期値を有するように宣言された場合には、その配列は、非割当可能として扱われる。
ＧＯ ＴＯステートメントに使用されるラベル変数は、その値として、ＧＯ ＴＯが実行される時にアクティブであるブロック内で使用されるラベル定数を有しなければならない。次の例を検討されたい：
Figure 2004506264
Ｌｂｌ＿ａおよびＬｂｌ＿ｂは、ラベル定数であり、Ｌｂｌ＿ｘは、ラベル変数である。Ｌｂｌ＿ａをＬｂｌ＿ｘに割り当てることによって、ステートメントＧＯ ＴＯ　Ｌｂｌ＿ｘによって制御がＬｂｌ＿ａステートメントに転送される。このプログラムの他の場所に、Ｌｂｌ＿ｂをＬｂｌ＿ｘに割り当てるステートメントを含めることができる。その場合に、Ｌｂｌ＿ｘへの参照は、どれもがＬｂｌ＿ｂへの参照と同一になる。Ｌｂｌ＿ｘの値は、別の値が割り当てられるまで保持される。ラベル変数が無効な値を有する場合に、そのようなエラーの検出は保証されない。次の例では、転送が、Ｉの値に基づいて配列Ｚの特定の要素に対して行われる。
Figure 2004506264
Ｚ（２）が省略される場合に、Ｉ＝２の時のＧＯ ＴＯ　Ｚ（Ｉ）は、ＥＲＲＯＲ状態を発生させる。Ｉ＜ＬＢＯＵＮＤ（Ｚ）またはＩ＞ＨＢＯＵＮＤ（Ｚ）の時のＧＯＴＯ　Ｚ（Ｉ）は、ＳＵＢＳＣＲＩＰＴＲＡＮＧＥ条件がディスエーブルされている場合に、予測不能な結果を引き起こす。
ＰＬＩＮｏｎＣｏｍｐｕｔａｔｉｏｎａｌＴｙｐｅから派生する
【０１９１】
ＰＬＩＦｏｒｍａｔＴｙｐｅ
リモート（またはＲ）フォーマット項目は、ＦＯＲＭＡＴステートメント内のフォーマット・リストを使用しなければならないことを指定する。
Ｒフォーマット項目および指定されたＦＯＲＭＡＴステートメントは、同一のブロックの中にある必要があり、そのブロックの同一の呼出しの中になければならない。
リモートＦＯＲＭＡＴステートメントに、ラベル参照としてそれ自体を参照するＲフォーマット項目を含めることはできず、元のＦＯＲＭＡＴステートメントを参照することになる別のリモートＦＯＲＭＡＴステートメントを参照することもできない。
ＧＥＴステートメントまたはＰＵＴステートメントについてイネーブルされる条件は、参照されるリモートＦＯＲＭＡＴステートメントについてもイネーブルされなければならない。ＧＥＴステートメントまたはＰＵＴが、ＯＮユニットの単一のステートメントである場合には、そのステートメントはブロックであり、リモート・フォーマット項目を含めることができない。
たとえば：
Figure 2004506264
ＳＷＩＴＣＨは、ラベル変数として宣言されており、第２のＧＥＴステートメントは、２つのＦＯＲＭＡＴステートメントの一方と共に動作するようにすることができる。
データ・フォーマット項目によって、単一のデータ項目の文字またはグラフィック表現が記述される。それらは：
Ａ − 文字
Ｂ − ビット
Ｃ − 複合
Ｅ − 浮動小数点
Ｆ − 固定小数点
Ｇ − グラフィック
Ｐ − ピクチャ
リモート・フォーマット項目では、その値がほかの位置にあるＦＯＲＭＡＴステートメントのラベル定数であるラベル参照が指定される。ＦＯＲＭＡＴステートメントには、リモートに配置されたフォーマット項目が含まれる。ラベル参照項目は、Ｒである。
最初のデータ・フォーマット項目は、最初のデータ・リスト項目に関連し、２番目のデータ・フォーマット・項目は、２番目のデータ・リスト項目に関連し、以下同様である。フォーマット・リストに、関連するデータ・リストの項目より少ない数のデータ・フォーマット項目が含まれる場合には、フォーマット・リストが再利用される。フォーマット項目が多すぎる場合には、無視される。
フォーマット・リストに、５つのデータ・フォーマット項目が含まれ、それに関連するデータ・リストで、送信される１０個の項目が指定されると仮定する。データ・リストの６番目の項目は、最初のデータ・フォーマット項目に関連し、以下同様である。フォーマット・リストに１０個のデータ・フォーマット項目があり、それに関連するデータ・リストで、５つの項目だけが指定されると仮定する。６番目から１０番目までのフォーマット項目が、無視される。
例：
ＧＥＴ ＥＤＩＴ （ＮＡＭＥ， ＤＡＴＡ， ＳＡＬＡＲＹ）（Ａ（Ｎ）， Ｘ（２）， Ａ（６）， Ｆ（６，２））；
この例では、ストリーム内の最初のＮ文字が、文字列として扱われ、ＮＡＭＥに割り当てられることが指定される。次の２文字は、スキップされる。次の６文字は、文字フォーマットでＤＡＴＡに割り当てられる。次の６文字は、任意選択として符号付きの１０進固定小数点定数とみなされ、ＳＡＬＡＲＹに割り当てられる。
ＰＬＩＮｏｎＣｏｍｐｕｔａｔｉｏｎａｌＴｙｐｅから派生する
【０１９２】
ＰＬＩＥｎｔｒｙＴｙｐｅ
入り口データは、入り口定数または入り口変数の値とすることができる。
入り口定数は、ＰＲＯＣＥＤＵＲＥステートメントまたはＥＮＴＲＹステートメントに対するラベル・プレフィックスとして記述された名前、またはＶＡＲＩＡＢＬＥ属性ではなくＥＮＴＲＹ属性を用いて宣言された名前、または数学組込み関数の名前である。
入り口定数を、入り口変数に割り当てることができる。たとえば：
Figure 2004506264
Ｐ、Ｅ１、およびＥ２が、入り口定数である。ＥＶは、入り口変数である。最初のＣＡＬＬステートメントは、入口点Ｅ１を呼び出す。２番目のＣＡＬＬは、入口点Ｅ２を呼び出す。
次の例には、添字付きの入り口参照が含まれる：
Figure 2004506264
５つの入り口Ａ、Ｂ、Ｃ、Ｄ、およびＥは、それぞれ、パラメータＸ、Ｙ、およびＺを用いて呼び出される。
内部プロシージャの入口点である入り口定数が、入り口変数に割り当てられる時に、割り当てられる値は、入り口定数が内部にあったブロックがアクティブである（および、再帰プロシージャの場合にカレントである）限り、有効なままになる。
ＥＮＴＲＹＡＤＤＲ組込み関数および擬似変数を用いると、入り口変数のＰＲＯＣＥＤＵＲＥまたはＥＮＴＲＹの入口点のアドレスを入手するか設定することができるようになる。入口点のアドレスは、入り口が呼び出された場合に実行される最初の命令のアドレスである。たとえば：
ＰＴＲ１ ＝ＥＮＴＲＹＡＤＤＲ（ＥＮＴＲＹ＿ＶＢＬ）；
では、入り口点のアドレスが得られ、
ＥＮＴＲＹＡＤＤＲ（ＥＮＴＲＹ＿ＶＢＬ） ＝ ＰＴＲ２；
である。
ＰＬＩＮｏｎＣｏｍｐｕｔａｔｉｏｎａｌＴｙｐｅから派生する
パブリック属性：
Ｌｉｍｉｔｅｄ ： Ｂｏｏｌｅａｎ
【０１９３】
ＰＬＩＡｒｅａＴｙｐｅ
区域変数では、基底付き変数の割振りのために予約されるストレージの区域が記述される。この予約されるストレージは、ＡＬＬＯＣＡＴＥステートメントによって基底付き変数に割り振り、ＦＲＥＥステートメントによって基底付き変数から解放することができる。区域変数は、任意のストレージ・クラスを有することができ、位置合わせされなければならない。
基底付き変数が割り振られ、区域が指定されない時に、ストレージは、使用可能であればどこからでも獲得される。その結果、割り振られる基底付き変数が、主記憶域全体に広く分散する可能性がある。これは、項目がポインタを使用して簡単にアクセスされるので、内部動作にとっては重要でない。しかし、これらの割振りが、データ・セットに送られる場合には、項目を一緒に収集しなければならない。区域変数を用いて割り振られる項目は、既に収集されており、別々の識別を保ちながら１単位として送るか割り振ることができる。
区域変数内の、区域変数の先頭に対する相対的な基底付き変数の位置を識別したい場合がある。オフセット変数が、この目的のために設けられている。区域を、それに含まれる割当を完備して割当または送信することができ、したがって、基底付き割振りの組を、各割当の個々の識別を保持しながら、割当および入出力に関する１単位として扱うことができる。
区域のサイズは、ストリング長または配列の限界と同じ形で調整可能であり、したがって、式またはアスタリスク（被制御区域または被制御パラメータの場合）またはＲＥＦＥＲオプション（基底付き区域の場合）によって指定することができる。
ストレージ・クラスＡＵＴＯＭＡＴＩＣまたはＣＯＮＴＲＯＬＬＥＤを有する区域の区域サイズは、その整数値によって予約されるバイト数が指定される式によって与えることができる。区域がＢＡＳＥＤ属性を有する場合に、その区域が基底付き構造体のメンバであり、ＲＥＦＥＲオプションが使用される場合を除いて、区域サイズは整数でなければならない。
静的ストレージ・クラスの区域のサイズは、整数として指定しなければならない。ＡＲＥＡ宣言の例は次の通りである：
ＤＥＣＬＡＲＥ ＡＲＥＡ１ ＡＲＥＡ（２０００），
ＡＲＥＡ２ ＡＲＥＡ；
宣言されたサイズのほかに、余分な１６バイトの制御情報が、区域の予約されたサイズの前に置かれる。この１６バイトに、使用中のストレージの量などの詳細が含まれる。
実際に使用されている予約済みストレージの量を、区域のエクステントと称する。区域変数は、割り振られる時に、空である、すなわち、区域エクステントが０である。最大エクステントは、区域サイズによって表される。基底付き変数は、実行中にいつでも区域内で割り振り、解放することができ、したがって、区域のエクステントが変化する。
基底付き変数が解放される時に、それが占有したストレージが、他の割振りに使用可能になる。ある区域内の使用可能なストレージのチェーンが、維持され、このチェーンの先頭は、１６バイトの制御情報内に保持される。不可避的に、異なるストレージ要件を有する基底付き変数が、割り振られ、解放されるので、割振りが使用可能なスペースと一致しない時に、区域内にギャップが生じる。これらのギャップは、区域のエクステントに含まれる。
比較を含めてどの演算子も、区域変数に適用することはできない。
ＰＬＩＮｏｎＣｏｍｐｕｔａｔｉｏｎａｌＴｙｐｅから派生する
【０１９４】
ＰＬＩＰｏｉｎｔｅｒＴｙｐｅ
ポインタ変数は、基底付き変数の宣言内に、ロケータ修飾子として、ＢＡＳＥＤ属性内に、あるいは、ＡＬＬＯＣＡＴＥステートメント、ＬＯＣＡＴＥステートメント、またはＲＥＡＤステートメントのＳＥＴオプション内に現れる場合に、コンテキスト的に宣言される。ポインタ変数を明示的に宣言することもできる。
ＰＬＩＮｏｎＣｏｍｐｕｔａｔｉｏｎａｌＴｙｐｅから派生する
【０１９５】
ＰＬＩＦｉｌｅＴｙｐｅ
ＦＩＬＥ属性によって、関連する名前がファイル定数またはファイル変数であることが指定される。
ＦＩＬＥ属性は、ファイル記述属性のいずれかによってファイル定数について暗黙指定することができる。名前を、入力ステートメントまたは出力ステートメントのＦＩＬＥオプション内、または入力／出力条件に関するＯＮステートメント内の出現を介して、ファイル定数としてコンテキスト的に宣言することができる。
ＰＬＩＮｏｎＣｏｍｐｕｔａｔｉｏｎａｌＴｙｐｅから派生する
【０１９６】
ＰＬＩＯｆｆｓｅｔＴｙｐｅ
区域変数内の、区域変数の先頭に対する相対的な基底付き変数の位置を識別したい場合がある。オフセット変数は、この目的のために設けられる。
ＰＬＩＮｏｎＣｏｍｐｕｔａｔｉｏｎａｌＴｙｐｅから派生する
パブリック属性：
ＢｉｇＥｎｄｉａｎ ： Ｂｏｏｌｅａｎ ＝ ｔｒｕｅ
【０１９７】
ＰＬＩＡｌｉａｓ
別名は、明示的なデータ型が許容される場所であればどこでも使用することができる型名である。ＤＥＦＩＮＥ ＡＬＩＡＳステートメントを使用して、データ属性の集合の別名を定義することができる。この形で、意味のある名前をデータ型に割り当て、プログラムの理解される能力を改善することができる。別名を定義することによって、データ属性の組のより短い表記を供給することもでき、これによってタイプの誤りを減らすことができる。
例
Figure 2004506264
ＰＬＩＮａｍｅｄＴｙｐｅから派生する
【０１９８】
Ａｔｔｒｉｂｕｔｅ
指定することができる属性は、関数が返すことができる変数の属性のいずれかである（たとえば、ＲＥＴＵＲＮＳオプションおよび属性で有効な属性）。すなわち、配列または構造化された属性リストの別名を指定することはできない。しかし、ＤＥＦＩＮＥＯＲＤＩＮＡＬステートメントまたはＤＥＦＩＮＥ ＳＴＲＵＣＴＵＲＥステートメントあるいは別のＤＥＦＩＮＥ ＡＬＩＡＳステートメントで定義された型の別名を指定することができる。また、ＲＥＴＵＲＮＳオプションおよび属性と同様に、ストリング長または区域サイズは、制限付き式でなければならない。
欠けているデータ属性は、ＰＬ／Ｉデフォルトを使用して供給される。
パブリック属性：
ａｔｔｒｉｂｕｔｅ ： Ｓｔｒｉｎｇ
【０１９９】
ＰＬＩＯｒｄｉｎａｌ
序数は、順序付きの値の名前付きの組である。ＤＥＦＩＮＥ ＯＲＤＩＮＡＬステートメントを使用して、序数を定義し、その組を参照するのに使用される意味のある名前を割り当てることができる。たとえば、「ｃｏｌｏｒ」と呼ばれる序数を定義することができる。「ｃｏｌｏｒ」序数に、メンバ「ｒｅｄ」、「ｙｅｌｌｏｗ」、「ｂｌｕｅ」などを含めることができる。「ｃｏｌｏｒ」組のメンバを、関連する固定された２進値によるのではなく、これらの名前によって参照することができ、コードがはるかに自己文書化的になる。さらに、序数型を用いて宣言された変数は、同一の型の序数またはその序数型のメンバだけを割り当てることができ、比較することができる。この自動的な検査によって、よりよいプログラムの信頼性がもたらされる。
下の例では、Ｒｅｄが値０を有し、Ｏｒａｎｇｅが値１を有するなどである。しかしＬｏｗは値２を有し、Ｍｅｄｉｕｍは値３を有する。
例
Figure 2004506264
ＰＬＩＮａｍｅｄＴｙｐｅから派生する
パブリック属性：
ｐｒｅｃｉｓｉｏｎ ： ｉｎｔ
ｉｓＳｉｇｎｅｄ ： ｂｏｏｌｅａｎ
【０２００】
ＯｒｄｉｎａｌＶａｌｕｅ
ＯｒｄｉｎａｌＶａｌｕｅでは、組内の特定のメンバの値を指定する。最初のメンバについてＶＡＬＵＥ属性が省略された場合には、０の値が使用される。他のメンバについてＶＡＬＵＥ属性が省略された場合には、次に大きい整数値が使用される。
所与の（または仮定される）ＶＡＬＵＥ属性の値は、整数でなければならず、符号付きとすることができ、厳密に増分しなければならない。所与の（または仮定される）ＶＡＬＵＥ属性の値は、ＸＮ定数として指定することもできる。
例
ｄｅｆｉｎｅ ｏｒｄｉｎａｌ Ｉｎｔｅｓｉｔｙ （ｌｏｗ ｖａｌｕｅ（２）， ｍｉｄｄｌｅ， ｈｉｇｈ ｖａｌｕｅ （５））；
は、ｌｏｗに２の値、ｍｉｄｄｌｅに３の値、ｈｉｇｈに５の値を与える。
パブリック属性：
ｎａｍｅ ： Ｓｔｒｉｎｇ
ｖａｌｕｅ ： ｉｎｔ
【０２０１】
ＰＬＩＳｔｒｕｃｔｕｒｅ
構造体は、構造体、共用体、または基本的な変数および配列とすることができるメンバ要素の集合である。共用体は、互いに重なり合い、同一のストレージを占めるメンバ要素の集合である。共用体は、通常は共通部分、セレクタ部分、および可変部分を含む可変レコードを宣言するのに使用することができる。
ＤＥＦＩＮＥ ＳＴＲＵＣＴＵＲＥステートメントが、名前付きの構造体または共用体を指定するのに使用される。構造体は、強く型付けされる。すなわち、構造体として宣言された変数だけを、構造体として宣言された変数またはパラメータに割り当てることができる。
ＰＬＩＮａｍｅｄＴｙｐｅ、ＰＬＩＣｏｍｐｏｓｅｄＴｙｐｅから派生する
【０２０２】
ＰＬＩＨａｎｄｌｅＴｙｐｅ
変数を構造体型へのポインタとして宣言するには、ＨＡＮＤＬＥを使用する。ハンドルは、強く型付けされる、すなわち、同一の構造体型のハンドルに割り当てるかそれと比較することができる。
ＰＬＩＮｏｎＣｏｍｐｕｔａｔｉｏｎａｌＴｙｐｅから派生する
パブリック属性：
ｓｔｒｕｃｔｕｒｅ ： ｔＰＬＩＳｔｒｕｃｔｕｒｅ
【０２０３】
ＰＬＩＮａｍｅｄＴｙｐｅ
ＰＬ／Ｉでは、組込みデータ型を使用して、ユーザ自身が命名した型を定義することができる。これには、ユーザ定義型（別名、序数、構造体、および共用体）、これらの型を有する変数の宣言、ハンドル、および型関数が含まれる。
ＰＬＩＣｌａｓｓｉｆｉｅｒから派生する
【０２０４】
ＰＬＩＡｒｒａｙ
配列は、同一の属性を有する要素のｎ次元集合である。
例
ｄｃｌ Ｌｉｓｔ ｆｉｘｅｄ ｄｅｃｉｍａｌ（３） ｄｉｍｅｎｓｉｏｎ（８）
は、８つの固定小数点１０進要素の１次元配列である。
ｄｃｌ ｔａｂｌｅ （４，２） ｆｉｘｅｄ ｄｅｃ （３）
は、３つの固定小数点１０進要素の２次元配列であり、ｔａｂｌｅの２次元は、１つの次元に関して１の下界と４の上界を有し、他方の次元に関して１の下界と２の上界を有する。
ＲＥＦＥＲオプションは、構造体の割振り時に、式の値が、構造体内の変数に割り当てられ、構造体内の別の変数の長さ、限界、またはサイズを表すことを指定するために、基底付き構造体の宣言で使用される。ＲＥＦＥＲオプションを用いる長さ、限界、またはサイズの構文は、次の通りである：
ｅｘｐｒｅｓｓｉｏｎ ＲＥＦＥＲ （ ｖａｒｉａｂｌｅ ）
ｖａｒｉａｂｌｅは、ＲＥＦＥＲオプションのオブジェクトと称するが、宣言される構造体のメンバでなければならない。ＲＥＦＥＲオブジェクトは、下記の規則に従わなければならない。
ＲＥＡＬ ＦＩＸＥＤ ＢＩＮＡＲＹ（ｐ，０）でなければならない。
ＲＥＦＥＲオプションを有するか、ＲＥＦＥＲオプションを有する要素を含む、最初のレベル２要素の前に置かなければならない。
ロケータ修飾または添字付きであってはならない。
配列の一部であってはならない。
たとえば：
Figure 2004506264
この宣言では、基底付き構造体ＳＴＲが、配列Ｙおよび要素Ｘからなることが
指定される。ＳＴＲが割り振られる時に、上界にＬの現在の値がセットされ、これがＸに割り当てられる。ＰをセットするＲＥＡＤステートメントなど、Ｙへの他の参照について、限界の値は、Ｘからとられる。
同一のメンバについて、ＲＥＦＥＲオプションとＩＮＩＴＩＡＬ属性の両方が使用される場合には、ＲＥＦＥＲのオブジェクトが値を割り当てられた後に、初期化が行われる。
下記の制約の少なくとも１つが満足されるならば、任意の数のＲＥＦＥＲオプションを、構造体の宣言に使用することができる：
ＲＥＦＥＲオプションのすべてのオブジェクトが、論理レベル２で宣言される、すなわち、小構造内で宣言されない。たとえば：
Figure 2004506264
この構造体が割り振られる時に、ＩおよびＪに割り振られる値によって、２次元配列ＡＲＲの限界がセットされる。
構造体のメンバの間で埋込みが発生しないように構造体が宣言される。たとえば：
Figure 2004506264
この構造体は、ＵＮＡＬＩＧＮＥＤ属性を有するので、すべての項目が、バイト位置合わせだけを必要とする。したがって、ＢおよびＤ（ＲＥＦＥＲオブジェクト）の値に無関係に、埋込みは行われない。Ｄが、小構造内で宣言されていることに留意されたい。
ＲＥＦＥＲオプションが、構造体宣言で１回だけ使用される場合に、下記が成り立つならば前の２つの制約を無視することができる：
ストリング長または区域サイズに関して、オプションが、構造体の最後の要素に適用される。
配列の限界に関して、オプションが、構造体の最後の要素または最後の要素を含む小構造のいずれかに適用される。配列の限界は、先行する次元の上界でなければならない。たとえば：
Figure 2004506264
配列の先行する次元は、上位レベルから継承することができる。上の例でＳＴＲ（４）を宣言した場合に、先行する次元は、ＳＴＲ（４）から継承され、したがって、ＤでＲＥＦＥＲオプションを使用することが不可能になる。
この宣言は、前の２つの制約を満足しない。ＲＥＦＥＲオブジェクトＭは、小構造内で宣言され、埋込みが行われる。しかし、ＲＥＦＥＲオプションが、最後の要素を含む小構造に適用されるので、この制約は満足される。
次の例も有効である：
Figure 2004506264
ＲＥＦＥＲオプションのオブジェクトの値が、プログラム中で変更される場合には：
オブジェクトが、割り振られた時に有した値に復元されるまで、構造体を解放してはならない。
オブジェクトが、割り振られた時より大きい値を有する間は、構造体を書き出してはならない。
オブジェクトが、割り振られた時以下の値を有する時には、構造体を書き出すことができる。実際に書き込まれる要素の数、ストリング長、または区域サイズは、オブジェクトの現在の値によって示される値である。たとえば：
Figure 2004506264
では、８６要素のＲＥＣが書き込まれる。この時点でＲＥＣを解放する試みは、エラーになる。というのは、Ｎが、割り振られた時に有した値（すなわち１００）に復元されなければならないからである。Ｎに１００を超える値が割り当てられる場合には、ＷＲＩＴＥステートメントに出会った時にエラーが発生する。
ＲＥＦＥＲオブジェクトの値が変更される時に、構造体への次の参照が、再マッピングを引き起こす。たとえば：
Figure 2004506264
Ｂの割当の後のＡへの次の参照によって、構造体が再マッピングされて、Ｃの上界が１０から５に減り、ＤのストレージがＣの新しい最後の要素に直接に続くように割り振られる。構造体は再マッピングされるが、データの再割当は行われず、ストレージのうちで構造体Ａによって元々占有されていた部分の内容は、変更されない。再マッピングを考慮しない場合には、エラーが発生する可能性がある。次の例を検討されたい。この例では、１つの構造体に２つのＲＥＦＥＲオプションがある：
Figure 2004506264
Ｂ＝１０およびＢ＝５のＡのマッピングは、次のようになる：
Figure 2004506264
Ｄは、現在、元々は文字列変数Ｃに割り当てられていた部分のデータを参照する。このデータは、Ｄの属性すなわち固定小数点２進数に従って解釈され、得られる値がＥの長さになる。したがって、Ｅの長さは予測不能である。
【０２０５】
ＰＬＩＦｉｘｅｄＬｅｎｇｔｈＳｔｒｉｎｇ
ＰＬＩＣｏｄｅｄＳｔｒｉｎｇＴｙｐｅから派生する
パブリック属性：
ｌｅｎｇｔｈ ： Ｉｎｔｅｇｅｒ
【０２０６】
ＰＬＩＶａｒｉａｂｌｅＬｅｎｇｔｈＳｔｒｉｎｇ
ＰＬＩＣｏｄｅｄＳｔｒｉｎｇＴｙｐｅから派生する
パブリック属性：
ｌｅｎｇｔｈＴｏＡｌｌｏｃａｔｅ ： Ｓｔｒｉｎｇ
【０２０７】
ＰＬＩＦｉｘｅｄＬｅｎｇｔｈＡｒｅａ
ＰＬＩＡｒｅａＴｙｐｅから派生する
プライベート属性：
ｌｅｎｇｔｈ ： Ｉｎｔｅｇｅｒ
【０２０８】
ＰＬＩＶａｒｉａｂｌｅＬｅｎｇｔｈＡｒｅａ
区域のサイズは、ストリング長または配列の限界と同一の形で調整可能であり、したがって、式またはアスタリスク（被制御区域または被制御パラメータの場合）またはＲＥＦＥＲオプション（基底付き区域の場合）によって指定することができる。
ＰＬＩＡｒｅａＴｙｐｅから派生する
プライベート属性：
ｌｅｎｇｔｈＴｏＡｌｌｏｃａｔｅ ： Ｓｔｒｉｎｇ
【０２０９】
ＰＬＩＦｉｘｅｄＢｏｕｎｄＡｒｒａｙ
ＰＬＩＡｒｒａｙから派生する
パブリック属性：
ｌｂｏｕｎｄ ： Ｉｎｔｅｇｅｒ
ｕｂｏｕｎｄ ： Ｉｎｔｅｇｅｒ
【０２１０】
ＰＬＩＦｉｘｅｄＬｂｏｕｎｄＡｒｒａｙ
ＰＬＩＡｒｒａｙから派生する
パブリック属性：
ｌｂｏｕｎｄ ： Ｉｎｔｅｇｅｒ
ＨｂｏｕｎｄｔｏＡｌｌｏｃａｔｅ ： Ｓｔｒｉｎｇ
【０２１１】
ＰＬＩＨｂｏｕｎｄＡｒｒａｙ
ＰＬＩＡｒｒａｙから派生する
パブリック属性：
ＬｂｏｕｎｄｔｏＡｌｌｏｃａｔｅ ： Ｓｔｒｉｎｇ
ｕｂｏｕｎｄ ： Ｉｎｔｅｇｅｒ
【０２１２】
ＰＬＩＶａｒｉａｂｌｅＢｏｕｎｄＡｒｒａｙ
ＰＬＩＡｒｒａｙから派生する
パブリック属性：
ＬｂｏｕｎｄＴｏＡｌｌｏｃａｔｅ ： Ｓｔｒｉｎｇ
ＨｂｏｕｎｄＴｏＡｌｌｏｃａｔｅ ： Ｓｔｒｉｎｇ
【０２１３】
総計：
１論理パッケージ
３９クラス
論理パッケージ構造
論理ビュー
ＰＬＩ
ＴＤＬａｎｇ
【０２１４】
５．ｃ．Ｃメタモデル
Ｃ ＭａｉｎおよびＵｓｅｒ Ｔｙｐｅｓ（すなわちユーザ定義型）を含むＣメタモデルは、Ｍ２レベルのＭＯＦクラス・インスタンスである。図２４にＣ言語メタモデルを示す。図２５に、Ｃ言語メタモデルのＴＤＬａｎｇＣｌａｓｓｉｆｉｅｒ、ＴＤＬａｎｇＣｏｍｐｏｓｅｄＴｙｐｅ、およびＴＤＬａｎｇＥｌｅｍｅｎｔを示す。図２６に、Ｃ言語メタモデルのＴｙｐｅｄＥｌｅｍｅｎｔ態様を示す。図２７に、Ｃ言語メタモデルでのユーザ定義データ型を含むデータ型を示す。図２８に、Ｃ言語メタモデルでのＤａｔａｔｙｐｅ−ＳｔｒｉｎｇおよびＤａｔａｔｙｐｅ−Ｉｎｔｅｇｅｒ、ならびにＤｉｒｅｃｔｉｏｎＫｉｎｄの引数および戻り値の列挙およびＢｏｏｌｅａｎデータ型のｔｒｕｅおよびｆａｌｓｅの列挙を示す。
【０２１５】
５．ｃ．ｉ．Ｃメタモデル仕様
Ｃメタモデル仕様は、コネクタ・インターフェースを表すデータ構造体を定義するために、エンタープライズ・アプリケーション・プログラムによって使用される。
【０２１６】
Ｃｌａｓｓｉｆｉｅｒ
型指定子は、宣言されつつあるオブジェクトまたは関数の型を示す。
基本データ型は次の通りである：
文字
浮動小数点数
整数
列挙
Ｖｏｉｄ
これらの型から、ユーザは下記を導出することができる：
ポインタ
配列
構造体
共用体
関数
整数型は、ｃｈａｒ、ｗｃｈａｒ＿ｔ（Ｃ＋＋のみ）、およびすべてのサイズのｉｎｔである。浮動小数点数は、型ｆｌｏａｔ、ｄｏｕｂｌｅ、またはｌｏｎｇ　ｄｏｕｂｌｅを有することができる。整数型と浮動小数点型を、集合的に算術型と呼ぶことができる。Ｃ＋＋のみにおいて、下記も導出することができる：
参照
クラス
メンバへのポインタ
Ｃ＋＋では、列挙が、整数型ではないが、整数拡張の対象になり得る。これは、ＣＭａｉｎで型を定義する基本クラスである。
列挙は、それに含まれるＦｅａｔｕｒｅｓの組を介するインスタンスの分類を提供する。
分類子は、主にＦｅａｔｕｒｅｓの構成によって定義される。
ＴＤＬａｎｇＣｌａｓｓｉｆｉｅｒから派生する
パブリック属性：
ｎａｍｅ ： Ｓｔｒｉｎｇ
【０２１７】
Ｓｔｒｕｃｔｕｒｅｄ
これは、構造型の抽象クラスである。
Ｃｌａｓｓｉｆｉｅｒ、ＴＤＬａｎｇＣｏｍｐｏｓｅｄＴｙｐｅ、ＤｅｒｉｖａｂｌｅＴｙｐｅ、ＳｔｒｕｃｔｕｒｅＣｏｎｔｅｎｔｓから派生する
【０２１８】
Ｓｔｒｕｃｔ
構造体には、データ・オブジェクトの順序付きグループが含まれる。配列の要素とは違って、構造体内のデータ・オブジェクトは、さまざまなデータ型を有することができる。構造体内の各データ・オブジェクトは、メンバまたはフィールドである。
構造体を使用して、論理的に関係するオブジェクトをグループ化する。たとえば、１つの住所の構成要素のストレージを割り振るために、次の変数を定義する：
Figure 2004506264
複数の住所のストレージを割り振るためには、構造体データ型と、その構造体データ型を有するのに必要なだけの変数を定義することによって、各住所の構成要素をグループ化する。
次の例では、行１から７で、構造体タグａｄｄｒｅｓｓを宣言している：
Figure 2004506264
変数ｐｅｒｍ＿ａｄｄｒｅｓｓおよびｔｅｍｐ＿ａｄｄｒｅｓｓは、構造体データ型ａｄｄｒｅｓｓのインスタンスである。この両方に、ａｄｄｒｅｓｓの宣言で記述されたメンバが含まれる。ポインタｐ＿ｐｅｒｍ＿ａｄｄｒｅｓｓは、ａｄｄｒｅｓｓの構造体を指し、ｐｅｒｍ＿ａｄｄｒｅｓｓを指すように初期化される。
ドット演算子（．）を伴う構造体変数名または矢印演算子（−＞）を伴うポインタとメンバ名を指定することによって、構造体のメンバを参照する。たとえば、下記の両方で、ストリング”Ｏｎｔａｒｉｏ”へのポインタを、構造体ｐｅｒｍ＿ａｄｄｒｅｓｓに含まれるポインタｐｒｏｖに割り当てている：
ｐｅｒｍ＿ａｄｄｒｅｓｓ．ｐｒｏｖ ＝”Ｏｎｔａｒｉｏ”；
ｐ＿ｐｅｒｍ＿ａｄｄｒｅｓｓ −＞ｐｒｏｖ ＝ ”Ｏｎｔａｒｉｏ”；
構造体への参照のすべてを、完全に修飾しなければならない。この例では、４番目のフィールドをｐｒｏｖだけで参照することができない。このフィールドは、ｐｅｒｍ＿ａｄｄｒｅｓｓ．ｐｒｏｖによって参照しなければならない。
同一のメンバを有するが異なる名前の構造体は、互換ではなく、互いに割り当てることができない。構造体は、ストレージを節約することを意図されていない。バイト・マッピングの直接制御が必要な場合には、ポインタを使用する。
Ｓｔｒｕｃｔｕｒｅｄから派生する
【０２１９】
Ｕｎｉｏｎ
共用体は、名前付きメンバの組のどの１つでも保持することができるオブジェクトである。名前付きの組のメンバは、任意のデータ型とすることができる。Ｃ／Ｃ＋＋は、ストレージ内でメンバをオーバーレイする。
共用体に割り振られるストレージは、共用体の最大のメンバに必要なストレージ（と、共用体がその最も厳密なメンバの自然な境界で終わるようにするのに必要な埋込み）である。
Ｃ＋＋の注記：
１．Ｃ＋＋では、共用体が、コンストラクタおよびデストラクタを含むメンバ関数を有することができるが、仮想メンバ関数を有することはできない。共用体を基本クラスとして使用することも、基本クラスから共用体を派生させることもできない。
２．Ｃ＋＋の共用体メンバは、コンストラクタ、デストラクタ、またはオーバーロードされるコピー代入演算子を有するクラス・オブジェクトとすることができない。Ｃ＋＋では、キーワードｓｔａｔｉｃを用いて共用体のメンバを宣言することができない。
Ｓｔｒｕｃｔｕｒｅｄから派生する
【０２２０】
ＢｅｈａｖｉｏｒａｌＦｅａｔｕｒｅ
これによって、これを含むＭｏｄｅｌＥｌｅｍｅｎｔの動的特性が定義される。ＢｅｈａｖｉｏｒａｌＦｅａｔｕｒｅは、ＦｅａｔｕｒｅとＮａｍｅｓｐａｃｅの両方である。
パブリック属性：
ｎａｍｅ ： Ｓｔｒｉｎｇ
【０２２１】
ＴｙｐｅｄＥｌｅｍｅｎｔ
これは、定義に型指定を必要とする属性、パラメータおよび定数の基本クラスである。ＴｙｐｅＥｌｅｍｅｎｔ型は、定義の一部として型を必要とする、ＭｏｄｅｌＥｌｅｍｅｎｔｓの抽象である。ＴｙｐｅＥｌｅｍｅｎｔは、それ自体で型を定義するのではなく、Ｃｌａｓｓｉｆｉｅｒに関連する。
ＴＤＬａｎｇＥｌｅｍｅｎｔから派生する
【０２２２】
ＳｔｒｕｃｔｕｒａｌＦｅａｔｕｒｅ
それを含むＭｏｄｅｌＥｌｅｍｅｎｔの静的特性を定義する。
ＴｙｐｅｄＥｌｅｍｅｎｔ、ＳｔｒｕｃｔｕｒｅＣｏｎｔｅｎｔｓから派生する
パブリック属性：
ｎａｍｅ ： Ｓｔｒｉｎｇ
【０２２３】
Ｐａｒａｍｅｔｅｒ
Ｐａｒａｍｅｔｅｒは、動作および他のＢｅｈａｖｉｏｒａｌＦｅａｔｕｒｅｓとの通信の手段を提供する。パラメータによって、その定義された型の値が渡されるか通信される。
関数宣言子に、関数に命名する識別子と、関数パラメータのリストが含まれる。必ずプロトタイプ関数宣言子を使用すべきである。というのは、これによって関数パラメータを検査できるからである。Ｃ＋＋関数は、プロトタイプ関数宣言子を有しなければならない。
プロトタイプ関数宣言子：関数宣言子内で各パラメータを宣言すべきである。関数への呼出しでは、宣言にあるパラメータと同数の引数を渡さなければならない。
非プロトタイプ関数宣言子：宣言子に続くパラメータ宣言リストで各パラメータを宣言すべきである。パラメータを宣言しない場合には、そのパラメータは型ｉｎｔを有する。
コンパイラは、ｃｈａｒパラメータおよびｓｈｏｒｔパラメータをｉｎｔに拡幅し、ｆｌｏａｔパラメータをｄｏｕｂｌｅに拡幅する。コンパイラは、プロトタイプ宣言されていない関数の引数の型とパラメータの型の間の型検査を実行しない。また、コンパイラは、引数の数がパラメータの数と一致することを保証するための検査を行わない。
宣言に続くプロトタイプ宣言されない関数定義のパラメータ宣言リストで、関数が受け取る値のそれぞれの値を宣言すべきである。
パラメータ宣言によって、ストレージ・クラス指定子と値のデータ型が決定される。
Ｃ／Ｃ＋＋が許容する唯一のストレージ・クラス指定子が、ｒｅｇｉｓｔｅｒストレージ・クラス指定子である。これは、パラメータのすべての型指定子を受け入れる。ｒｅｇｉｓｔｅｒストレージ・クラス指定子を指定しない場合には、パラメータは、ａｕｔｏストレージ・クラス指定子を有する。Ｃのみにおいて、型指定子を省略し、関数の定義にプロトタイプ形式を使用していない場合には、パラメータは、次のように型ｉｎｔを有する：
Figure 2004506264
Ｃのみにおいて、あるパラメータが宣言子にリストされていない場合に、パラメータ宣言リストでそのパラメータを宣言することはできない。
ＴｙｐｅｄＥｌｅｍｅｎｔから派生する
パブリック属性：
ｄｉｒｅｃｔｉｏｎ ： Ｄｉｒｅｃｔｉｏｎｋｉｎｄ
プライベート属性：
ｎａｍｅ ： Ｓｔｒｉｎｇ
【０２２４】
Ｄａｔａｔｙｐｅ
これは、データ型および内部型を表す。
Ｃｌａｓｓｉｆｉｅｒから派生する
【０２２５】
Ｄｅｒｉｖｅｄ
ＤｅｒｉｖａｂｌｅＴｙｐｅ、Ｃｌａｓｓｉｆｉｅｒから派生する
【０２２６】
Ｆｉｅｌｄ
Ｆｉｅｌｄは属性である。
ＳｔｒｕｃｔｕｒａｌＦｅａｔｕｒｅから派生する
【０２２７】
Ｆｕｎｃｔｉｏｎ
ＢｅｈａｖｉｏｒａｌＦｅａｔｕｒｅ、ＤｅｒｉｖａｂｌｅＴｙｐｅから派生する
パブリック属性：
ｉｓＶａｒＡｒｇ ： Ｂｏｏｌｅａｎ
【０２２８】
ＳｔｒｕｃｔｕｒｅＣｏｎｔｅｎｔｓ
Ｓｔｒｕｃｔｕｒｅｄ
これは、ｓｔｒｕｃｔｕｒｅｄ型の抽象クラスである。
Ｃｌａｓｓｉｆｉｅｒ、ＴＤＬａｎｇＣｏｍｐｏｓｅｄＴｙｐｅ、ＤｅｒｉｖａｂｌｅＴｙｐｅ、ＳｔｒｕｃｔｕｒｅＣｏｎｔｅｎｔｓから派生する
【０２２９】
ＴｙｐｅｄＥｌｅｍｅｎｔ
これは、定義に型指定を必要とする属性、パラメータ、および定数の基本クラスである。ＴｙｐｅＥｌｅｍｅｎｔ型は、定義の一部として型を必要とするＭｏｄｅｌＥｌｅｍｅｎｔｓの抽象である。ＴｙｐｅＥｌｅｍｅｎｔは、それ自体で型を定義するのではなく、Ｃｌａｓｓｉｆｉｅｒに関連する。
ＴＤＬａｎｇＥｌｅｍｅｎｔから派生する
【０２３０】
Ｔｙｐｅｄｅｆ
Ｄｅｒｉｖｅｄから派生する
【０２３１】
Ｄｅｒｉｖｅｄ
ＤｅｒｉｖａｂｌｅＴｙｐｅ、Ｃｌａｓｓｉｆｉｅｒから派生する
【０２３２】
Ａｒｒａｙ
配列は、データ・オブジェクトの順序付きグループである。各オブジェクトを要素と呼ぶ。配列内のすべての要素が、同一のデータ型を有する。
配列の定義または宣言では、任意の型指定子を使用する。配列要素は、関数またはＣ＋＋の参照以外のどのデータ型にもすることができる。しかし、関数へのポインタの配列を宣言することはできる。
Ｄｅｒｉｖｅｄから派生する
パブリック属性：
ｄｉｍｅｎｓｉｏｎ ： Ｉｎｔｅｇｅｒ
【０２３３】
Ｐｏｉｎｔｅｒ
ポインタ型変数は、データ・オブジェクトまたは関数のアドレスを保持する。ポインタは、ビット・フィールドおよび参照を除くすべてのデータ型のオブジェクトを参照することができる。さらに、Ｃでは、ポインタが、ｒｅｇｉｓｔｅｒ記憶クラスのオブジェクトを指すことができない。
ポインタの一般的な用途の一部を下に示す：
リンク・リスト、ツリー、キューなどの動的データ構造体にアクセスするため。
配列の要素、構造体のメンバ、またはＣ＋＋クラスのメンバにアクセスするため。
ストリングとして文字の配列にアクセスするため。
変数のアドレスを関数に渡すため（Ｃ＋＋では、参照を使用してこれを行うこともできる）。アドレスを介して変数を参照することによって、関数がその変数の内容を変更することができる。
Ｄｅｒｉｖｅｄから派生する
【０２３４】
Ｆｕｎｃｔｉｏｎ
ＢｅｈａｖｉｏｒａｌＦｅａｔｕｒｅ、ＤｅｒｉｖａｂｌｅＴｙｐｅから派生する
パブリック属性：
ｉｓＶａｒＡｒｇ ： Ｂｏｏｌｅａｎ
【０２３５】
ＤｅｒｉｖａｂｌｅＴｙｐｅ
【０２３６】
５．ｄ．Ｃ＋＋メタモデル
書籍「ＡＮＮＯＴＡＴＥＤ Ｃ＋＋ ＲＥＦＥＲＥＮＣＥ ＭＡＮＵＡＬ」（ＭａｒｇａｒｅｔＡ．Ｅｌｌｉｓ，Ｂｊａｒｎｅ Ｓｔｏｕｓｔｒｕｐ著、１９９０年、「注解Ｃ＋＋リファレンスマニュアル」足立高徳／小山裕司訳）に基づくＣ＋＋メタモデルは、Ｍ２レベルのＭＯＦクラス・インスタンスである。Ｃ＋＋メタモデルは、Ｃ＋＋Ｍａｉｎと、下に記載のモデル型からなる。
【０２３７】
５．ｄ．ｉ．Ｃ＋＋ Ｍａｉｎメタモデル：
このメタモデルは、Ｃ Ｍａｉｎメタモデルから継承する。図２９に、Ｃ＋＋メタモデルのＤｅｒｉｖｅｄ、Ｓｔｒｕｃｔｕｒｅｄ、ＢｅｈａｖｉｏｒａｌＦｅａｔｕｒｅｓ、Ｆｉｅｌｄ、およびＤｅｒｉｖａｂｌｅＴｙｐｅｓを含むＣ＋＋Ｍａｉｎメタモデルを示す。図３０に、Ｃ＋＋メタモデルの可視性型の列挙を示す。Ｃ＋＋が、オブジェクト指向言語であり、オブジェクト指向プログラミングに有用であり、ｐｕｂｌｉｃ、ｐｒｉｖａｔｅ、およびｐｒｏｔｅｃｔｅｄの可視性をサポートすることに留意されたい。
Ｍｏｄｅｌ Ｔｙｐｅｓメタモデル：
【０２３８】
５．ｄ．ｉｉ．Ｃ＋＋メタモデル仕様
Ｃ＋＋
Ｃ＋＋メタモデルは、コネクタ・インターフェースを表すデータ構造体を定義するために、エンタープライズ・アプリケーション・プログラムによって使用される。
【０２３９】
Ｃｌａｓｓ
Ｃ＋＋クラスは、Ｃ言語構造体の拡張である。構造体とクラスの唯一の相違は、構造体メンバがデフォルトでｐｕｂｌｉｃアクセスを有するが、クラス・メンバがデフォルトでｐｒｉｖａｔｅアクセスを有することである。その結果、キーワードｃｌａｓｓまたはｓｔｒｕｃｔを使用して、同等のクラスを定義することができる。
／／ この例では、クラスＸが構造体Ｙと同等である
Figure 2004506264
構造体を定義し、その後、キーワードｃｌａｓｓを使用してその構造体のオブジェクトを宣言する場合に、オブジェクトのメンバは、まだデフォルトでｐｕｂｌｉｃである。次の例では、Ｘがキーワードｃｌａｓｓを使用してして宣言されているが、ｍａｉｎ（）がＸのメンバにアクセスできる。
Ｓｔｒｕｃｔｕｒｅｄから派生する
パブリック属性：
ｉｓＡｂｓｔｒａｃｔ ： Ｂｏｏｌｅａｎ
ｉｓＶｏｌａｔｉｌｅ ： Ｂｏｏｌｅａｎ
プライベート属性：
ｖｉｓｉｂｉｌｉｔｙ ： ＶｉｓｉｂｉｌｉｔｙＫｉｎｄ
【０２４０】
Ｍｅｍｂｅｒ
データ・メンバには、基本型ならびに、ポインタ、参照、配列型、およびユーザ定義型を含む他の型のどれかを用いて宣言されるメンバが含まれる。データ・メンバは、変数と同一の形で宣言することができる。しかし、クラス定義の中に明示的な初期化指定子を配置することはできない。
配列をｓｔａｔｉｃでないクラス・メンバとして宣言する場合には、すべての配列次元を指定しなければならない。
Ｆｉｅｌｄ、ＤｅｒｉｖａｂｌｅＴｙｐｅから派生する
パブリック属性：
ｉｓＳｔａｔｉｃ ： Ｂｏｏｌｅａｎ
プライベート属性：
ｉｓＶｏｌａｔｉｌｅ ： Ｂｏｏｌｅａｎ
ｉｓＲｅｇｉｓｔｅｒ ： Ｂｏｏｌｅａｎ
ｖｉｓｉｂｉｌｉｔｙ ： ＶｉｓｉｂｉｌｉｔｙＫｉｎｄ
【０２４１】
Ｒｅｆｅｒｅｎｃｅ
Ｄｅｒｉｖｅｄから派生する
【０２４２】
Ｏｐｅｒａｔｏｒ
ＢｅｈａｖｉｏｒａｌＦｅａｔｕｒｅ、ＳｔｒｕｃｔｕｒｅＣｏｎｔｅｎｔｓから派生する
プライベート属性：
ｉｓＩｎｌｉｎｅ ： Ｂｏｏｌｅａｎ
ｖｉｓｉｂｉｌｉｔｙ ： ＶｉｓｉｂｉｌｉｔｙＫｉｎｄ
【０２４３】
Ｏｐｅｒａｔｉｏｎ
Ｆｕｎｃｔｉｏｎ、ＳｔｒｕｃｔｕｒｅＣｏｎｔｅｎｔｓから派生する
パブリック属性：
ｉｓＳｔａｔｉｃ ： Ｂｏｏｌｅａｎ
ｉｓＥｘｔｅｒｎ ： Ｂｏｏｌｅａｎ
ｉｓＩｎｌｉｎｅ ： Ｂｏｏｌｅａｎ
ｉｓＶｉｒｔｕａｌ ： Ｂｏｏｌｅａｎ
ｉｓＰｕｒｅ ： Ｂｏｏｌｅａｎ
ｖｉｓｉｂｉｌｉｔｙ ： ＶｉｓｉｂｉｌｉｔｙＫｉｎｄ
ｉｓＣｔｏｒ ： Ｂｏｏｌｅａｎ
プライベート属性：
ｉｓＤｔｏｒ ： Ｂｏｏｌｅａｎ
【０２４４】
Ｅｘｔｅｒｎ
Ｅｘｔｅｒｎは、Ｄｅｒｉｖｅｄ型の一種である。Ｃとの関連付けに使用される。
Ｄｅｒｉｖｅｄから派生する
プライベート属性：
ｌｉｎｋａｇｅ ： Ｓｔｒｉｎｇ
【０２４５】
Ｇｅｎｅｒａｌｉｚａｔｉｏｎ
プライベート属性：
ｖｉｓｉｂｉｌｉｔｙ ： ＶｉｓｉｂｉｌｉｔｙＫｉｎｄ
ｉｓＶｉｒｔｕａｌ ： Ｂｏｏｌｅａｎ
【０２４６】
Ｃｏｎｓｔ
Ｄｅｒｉｖｅｄから派生する
【０２４７】
Ｔｅｍｐｌａｔｅ
テンプレート宣言内の宣言では、下記の１つを定義または宣言しなければならない：
クラス
関数
テンプレート・クラスのｓｔａｔｉｃメンバ
型の識別子は、テンプレート宣言のスコープ内でｔｙｐｅ＿ｎａｍｅになる。テンプレート宣言は、グローバル宣言としてのみ行うことができる。
テンプレート引数（区切り文字＜と＞の中）によって、テンプレートをインスタンス化する時に指定しなければならないテンプレート内の型および定数を指定する。
下のテンプレートを与えられたものとして：
Figure 2004506264
この宣言によって、次のオブジェクトが作成される：
型Ｋｅｙ＜ｉｎｔ＞のｉ
型Ｋｅｙ＜ｃｈａｒ＊＞のｃ
型Ｋｅｙ＜ｍｙｔｙｐｅ＞のｍ
この３つのクラスが、異なる名前を有することに留意されたい。かぎ括弧（＜＞）に含まれる型は、クラス名に対する引数ではなく、クラス名自体の一部である。Ｋｅｙ＜ｉｎｔ＞およびＫｅｙ＜ｃｈａｒ＊＞はクラス名である。この例のコンテキスト内で、Ｋｅｙと呼ばれるクラス（テンプレート引数リストなし）は、未定義である。
Ｃ＋＋では、下記の条件の下でテンプレート引数のデフォルト初期化指定子が許容される：
ｎｏｎｔｙｐｅテンプレート引数だけに適用される。
関数のように、後端の引数だけに適用される。
後続のテンプレート宣言では、デフォルト初期化指定子を追加することができるが、既存のデフォルト初期化指定子を再定義することはできない。
関数テンプレート宣言ではなく、クラス・テンプレート宣言だけに適用される。
注：Ｃ＋＋は、クラス・テンプレートのメンバ関数を定義するテンプレートを、関数テンプレートとみなす。そのようなテンプレートは、デフォルト初期化指定子を有することができない。
Ｄｅｒｉｖｅｄから派生する
【０２４８】
５．ｅ．ＨＬＡＳＭ（Ｈｉｇｈ Ｌｅｖｅｌ Ａｓｓｅｍｂｌｅｒ）
これは、ＯＳ３９０用のＨＬＡＳＭである。図３７に、コネクタ・インターフェースを表すデータ構造体セマンティクスを定義するＨｉｇｈＬｅｖｅｌ Ａｓｓｅｍｂｌｙ Ｌａｎｇｕａｇｅ（ＨＬＡＳＭ）メタモデルを示す。図３８に、ＴＤＬａｎｇＣｌａｓｓｉｆｉｅｒ、ＴＤＬａｎｇｕａｇｅＣｏｍｐｏｓｅｄＴｙｐｅ、およびＴＤＬａｎｇＥｌｅｍｅｎｔである、ＨＬＡＳＭメタモデルとＴＤＬａｎｇ基本クラスの間の関連を示す。図３９に、ＨＬＡＳＭメタモデルでのＨＬＡＳＭ使用値の列挙を示す。
【０２４９】
ｈｌａｓｍ
ＨＬＡＳＭＤｅｃｉｍａｌ
ＨＬＡＳＭＤｅｃｉｍａｌ型は、１０進数命令によって使用される。
コードは、１０進数型（計算機フォーマット：パック１０進数フォーマット）の場合に’Ｐ’である。
コードは、１０進数型（計算機フォーマット：ゾーン１０進数フォーマット）の場合に’Ｚ’である。
例：
ＡＰ ＡＲＥＡ，ＰＣＯＮ
ＰＣＯＮ ＤＣ Ｐ’１００’
ＡＲＥＡ ＤＳ Ｐ
ＨＬＡＳＭＳｉｍｐｌｅＴｙｐｅから派生する
プライベート属性：
ｅｘｐｏｎｅｎｔ ： ｉｎｔ
ｅｘｐｏｎｅｎｔ修飾子は、１０進定数の公称値が、内部２進数表現に変換される前に乗算される１０のべきを指定する。
ｐａｃｋｅｄ ： ｂｏｏｌｅａｎ
このブール値は、１０進数型の計算機フォーマットに対応する。
真はパック（コードはＰ）である
偽はゾーン（コードはＺ）である
ｓｃａｌｅ ： ｉｎｔ
ｓｃａｌｅ修飾子は、１０進定数についてユーザが望む内部スケーリングの量を指定する。
【０２５０】
ＨＬＡＳＭＡｄｄｒｅｓｓ
ＨＬＡＳＭＡｄｄｒｅｓｓは、主に固定小数点命令および他の命令の使用に関するアドレス情報を保持する。
コードは、アドレス型（計算機フォーマット：アドレスの値；通常はフルワード）の場合に、’Ａ’である。
コードは、アドレス型（計算機フォーマット：アドレスの値；通常はダブルワード）の場合に、’ＡＤ’である。
コードは、アドレス型（計算機フォーマット：アドレスの値；通常はハーフワード）の場合に、’Ｙ’である。
コードは、アドレス型（計算機フォーマット：基底レジスタおよび変位値；ハーフワード）の場合に、’Ｓ’である。
コードは、アドレス型（計算機フォーマット：外部シンボルアドレス用に予約された空間；通常はフルワード）の場合に、’Ｖ’である。
コードは、アドレス型（計算機フォーマット：クラスの長さまたはＤＸＤ用に予約された空間；通常はフルワード）の場合に、’Ｊ’である。
コードは、アドレス型（計算機フォーマット：外部ダミー・セクション・オフセット用に予約された空間）の場合に、’Ｑ’である。
コードは、アドレス型（計算機フォーマット：ＰＳＥＣＴアドレス用に予約された空間；通常はフルワード）の場合に、’Ｒ’である。
例：
Ｌ ５，ＡＤＣＯＮ
ＡＤＣＯＮ ＤＣ Ａ（ＳＯＭＷＨＥＲＥ）
ＨＬＡＳＭＳｉｍｐｌｅＴｙｐｅから派生する
プライベート属性：
ｔｙｐｅ ： ＨＬＡＳＭＡｄｄｒｅｓｓＴｙｐｅ
この要素のアドレス型を指定する。
【０２５１】
ＨＬＡＳＭＢｉｎａｒｙ
ＨＬＡＳＭＢｉｎａｒｙでは、ビット・パターンが定義される。
コードは、バイナリ形式（計算機フォーマット：２進フォーマット）の場合に、’Ｂ’である。
例：
ＦＬＡＧ ＤＣ Ｂ’０００１００００’
ＨＬＡＳＭＳｉｍｐｌｅＴｙｐｅから派生する
プライベート属性：
ｅｘｐｏｎｅｎｔ ： ｉｎｔ
ｅｘｐｏｎｅｎｔ修飾子は、２進定数の公称値が、内部２進数表現に変換される前に乗算される１０のべきを指定する。
ｓｃａｌｅ ： ｉｎｔ
ｓｃａｌｅ修飾子は、２進定数についてユーザが望む内部スケーリングの量を指定する。
【０２５２】
ＨＬＡＳＭＣｈａｒａｃｔｅｒ
ＨＬＡＳＭＣｈａｒａｃｔｅｒでは、文字列またはメッセージを定義する。
コードは、文字型（計算機フォーマット：文字ごとに８ビット）の場合に、’Ｃ’である。
コードは、ユニコード文字型（計算機フォーマット：文字ごとに１６ビット・コード）の場合に、’ＣＵ’である。
コードは、グラフィック型（計算機フォーマット：文字ごとに１６ビット・コード）の場合に、’Ｇ’である。
例：
ＣＨＡＲ ＤＣ Ｃ’ｓｔｒｉｎｇ ｏｆｃｈａｒａｃｔｅｒｓ’
ＨＬＡＳＭＳｉｍｐｌｅＴｙｐｅから派生する
プライベート属性：
ｇｒａｐｈｉｃ ： ｂｏｏｌｅａｎ
要素がグラフィックであるか否かを指定する。
グラフィックの場合に真（コードは’Ｇ’）。
通常の文字型の場合に偽。
ｔｙｐｅ ： ＨＬＡＳＭＣｈａｒａｃｔｅｒＴｙｐｅ
この要素の文字型を指定する。
【０２５３】
ＨＬＡＳＭＦｉｘｅｄＰｏｉｎｔ
ＨＬＡＳＭＦｉｘｅｄＰｏｉｎｔ型は、固定小数点命令および他の命令によって使用される。
コードは、固定小数点型（計算機フォーマット：符号付き固定小数点２進フォーマット；通常はフルワード）の場合に、’Ｆ’である。
コードは、固定小数点型（計算機フォーマット：符号付き固定小数点２進フォーマット；通常はダブルワード）の場合に、’ＦＤ’である。
コードは、固定小数点型（計算機フォーマット：符号付き固定小数点２進フォーマット；通常はハーフワード）の場合に、’Ｈ’である。
例：
Ｌ ３，ＦＣＯＮ
ＦＣＯＮ ＤＣ Ｆ’１００’
ＨＬＡＳＭＳｉｍｐｌｅＴｙｐｅから派生する
プライベート属性：
ｅｘｐｏｎｅｎｔ ： ｉｎｔ
ｅｘｐｏｎｅｎｔ修飾子は、固定小数点定数（Ｈ、Ｆ）の公称値が、内部２進数表現に変換される前に乗算される１０のべきを指定する。
ｅｘｐｏｎｅｎｔ修飾子は、Ｅｎとして記述され、このｎは、１０進自己定義項目または括弧で囲まれた絶対式のいずれかである。この１０進自己定義項目または式の前に、符号を置くことができ、符号がない場合には、プラスの符号が仮定される。ｅｘｐｏｎｅｎｔ修飾子の範囲は、−８５から＋７５まである。浮動小数点定数を定義するために型拡張を使用する場合には、ｅｘｐｏｎｅｎｔ修飾子を、−２３１から２３１−１までの範囲内とすることができる。公称値を正確に表現することができない場合には、警告メッセージが発行される。
ｓｃａｌｅ ： ｉｎｔ
ｓｃａｌｅ修飾子は、固定小数点定数（Ｈ、Ｆ）の２進数についてユーザが望む内部スケーリングの量すなわち、固定小数点定数の公称値が２進表現に変換される前で、最終的なスケーリングされた形に組み立てられる前に、固定小数点定数に乗算しなければならない２のべきを指定する。スケーリングによって、２進小数点が、右端のビット位置の右にある仮定される固定された位置から移動される。
定数のそれぞれの型の範囲は：
固定小数点定数Ｈ
−１８７から１５まで
固定小数点定数Ｆ
−１８７から３０まで
ｓｃａｌｅ修飾子は、Ｓｎとして記述され、このｎは、１０進自己定義項目または括弧で囲まれた絶対式のいずれかである。
この修飾子の値ｎの両方の形の前に符号を置くことができ、符号が存在しない場合には、プラスの符号が仮定される。
注：
１．ｓｃａｌｅ修飾子は、正の値を有する時に、２進数の小数部分が占める２進位置の数を示す。
２．ｓｃａｌｅ修飾子は、負の値を有する時に、２進数の整数部分から削除される２進位置の数を示す。
３．スケーリングのゆえに（またはスケーリングが行われないので）下位の桁が失われる時に、失われる位置の左端のビットで丸めが行われる。丸めは、保存される右端の位置に反映される。
【０２５４】
ＨＬＡＳＭＦｌｏａｔｉｎｇＰｏｉｎｔ
ＨＬＡＳＭＦｌｏａｔｉｎｇＰｏｉｎｔ型は、浮動小数点命令によって使用される。
コードは、浮動小数点型（計算機フォーマット：ｓｈｏｒｔ浮動小数点フォーマット：通常はフルワード）の場合に、’Ｅ’である。
コードは、浮動小数点型（計算機フォーマット：ｌｏｎｇ浮動小数点フォーマット：通常はダブルワード）の場合に、’Ｄ’である。
コードは、浮動小数点型（計算機フォーマット：ｅｘｔｅｎｄｅｄ浮動小数点フォーマット：通常は複数のダブルワード）の場合に、’Ｌ’である。
例：
ＬＥ ２，ＥＣＯＮ
ＥＣＯＮＤＣ Ｅ’１００．５０’
ＨＬＡＳＭＳｉｍｐｌｅＴｙｐｅから派生する
プライベート属性：
ｅｘｐｏｎｅｎｔ ： ｉｎｔ
ｅｘｐｏｎｅｎｔ修飾子は、浮動小数点定数（Ｅ、Ｄ、およびＬ）の公称値が、内部２進数表現に変換される前に乗算される１０のべきを指定する。
ｅｘｐｏｎｅｎｔ修飾子は、Ｅｎとして記述され、このｎは、１０進自己定義項目または括弧で囲まれた絶対式のいずれかである。
この１０進自己定義項目または式の前に、符号を置くことができ、符号がない場合には、プラスの符号が仮定される。ｅｘｐｏｎｅｎｔ修飾子の範囲は、−８５から＋７５まである。浮動小数点定数を定義するために型拡張を使用する場合には、ｅｘｐｏｎｅｎｔ修飾子を、−２３１から２３１−１までの範囲内とすることができる。公称値を正確に表現することができない場合には、警告メッセージが発行される。
ｒｏｕｎｄ ： ＨＬＡＳＭＦｌｏａｔｉｎｇＰｏｉｎｔＲｏｕｎｄＴｙｐｅ
この要素の浮動小数点丸めタイプを指定する。
ｓｃａｌｅ ： ｉｎｔ
ｓｃａｌｅ修飾子は、浮動小数点定数（Ｅ、Ｄ、およびＬ）の１６進数についてユーザが望む内部スケーリングの量すなわち、浮動小数点定数の公称値が２進表現に変換される前で、最終的なスケーリングされた形に組み立てられる前に、浮動小数点定数に乗算しなければならない２のべきを指定する。スケーリングによって、２進小数点が、右端のビット位置の右にある仮定される固定された位置から移動される。
定数のそれぞれ型の範囲は：
浮動小数点定数Ｅ
０から５まで
浮動小数点定数Ｄ
０から１３まで
浮動小数点定数Ｌ
０から２７まで
ｓｃａｌｅ修飾子は、Ｓｎとして記述され、このｎは、１０進自己定義項目または括弧で囲まれた絶対式のいずれかである。
この修飾子の値ｎの両方の形の前に符号を置くことができ、符号が存在しない場合には、プラスの符号が仮定される。
１６進浮動小数点定数のｓｃａｌｅ修飾子：１６進浮動小数点定数のｓｃａｌｅ修飾子は、正の値を有しなければならない。このｓｃａｌｅ修飾子は、浮動小数点定数の２進表現の小数部分を右にシフトする、１６進位置の数を指定する。１６進小数点は、小数フィールド内の左端の位置の左に固定されるものと仮定される。スケーリングを指定する時には、正規化されない１６進小数が組み立てられることになる（正規化されないとは、小数の左端の位置に１６進数の０が含まれることを意味する）。定数の指数部の指数が、それ相応に上に調整されるので、定数の大きさが保存される。非０の１６進数位置が失われる時に、失われる部分の左端の１６進数位置で丸めが行われる。丸めは、保存される右端の位置に反映される。
ｔｙｐｅ ： ＨＬＡＳＭＦｌｏａｔｉｎｇＰｏｉｎｔＴｙｐｅ
この要素の浮動小数点型を指定する。
【０２５５】
ＨＬＡＳＭＨｅｘａｄｅｃｉｍａｌ
ＨＬＡＳＭＨｅｘａｄｅｃｉｍａｌでは、大きいビット・パターンを定義する。
コードは、１６進数型（計算機フォーマット：１６進数ごとに４ビット・コード）の場合に、’Ｘ’である。
例：
ＰＡＴＴＥＲＮ ＤＣ Ｘ’ＦＦ００ＦＦ００’
ＨＬＡＳＭＳｉｍｐｌｅＴｙｐｅから派生する
【０２５６】
ＨＬＡＳＭＣｌａｓｓｉｆｉｅｒ
ＨＬＡＳＭＣｌａｓｓｉｆｉｅｒは、ＨＬＡＳＭＣｏｍｐｏｓｅｄＴｙｐｅおよびＨＬＡＳＭＳｉｍｐｌｅＴｙｐｅの抽象親クラスである。
ＴＤＬａｎｇＣｌａｓｓｉｆｉｅｒから派生する
【０２５７】
ＨＬＡＳＭＥｌｅｍｅｎｔ
ＨＬＡＳＭＥｌｅｍｅｎｔは、ＨＬＡＳＭプログラムのすべてのＤＣ命令を表す。
たとえば：
ＣＨＡＲ ＤＣＣ’ｓｔｒｉｎｇ ｏｆ ｃｈａｒａｃｔｅｒｓ’
ＰＣＯＮ ＤＣＰ’１００’
ＰＡＴＴＥＲＮ ＤＣ Ｘ’ＦＦ００ＦＦ００’
ＣＨＡＲ、ＰＣＯＮ、およびＰＡＴＴＥＲＮのすべてが、ＤＣ命令である
ＴＤＬａｎｇＥｌｅｍｅｎｔから派生する
【０２５８】
ＨＬＡＳＭＳｉｍｐｌｅＴｙｐｅ
ＨＬＡＳＭＳｉｍｐｌｅＴｙｐｅは、ＨＬＡＳＭ言語のすべての単純型によって共用される属性を含む抽象クラスである。
ＨＬＡＳＭＣｌａｓｓｉｆｉｅｒから派生する
プライベート属性：
ｌｅｎｇｔｈ ： ｉｎｔ
ｌｅｎｇｔｈ修飾子は、定数がその中に組み立てられるストレージのバイト数を示す。これは、Ｌｎとして記述され、このｎは、１０進自己定義項目または括弧で囲まれた絶対式のいずれかである。これは、正の値を有しなければならない。
ｌｅｎｇｔｈ修飾子が指定される時には：
その値によって、定数に割り振られるストレージのバイト数が決定される。したがって、ｌｅｎｇｔｈ修飾子によって、割り振られる空間におさまるように、定数の公称値を埋め込むか切り捨てる必要があるかどうかが決定される。
定数の型に従う境界位置合わせは、行われない。
その値は、定義される定数のさまざまな型について許容される最大長さを超えてはならない。
ｌｅｎｇｔｈ修飾子が、Ｃ型定数でダブルバイト・データを切り捨ててはならない。
ｌｅｎｇｔｈ修飾子は、Ｇ型またはＣＵ型の定数では２の倍数でなければならない。
文字定数（Ｃ）、グラフィック定数（Ｇ）、１６進定数（Ｘ）、２進定数（Ｂ）、および１０進定数（ＰおよびＺ）について長さが指定されない時に、定数全体が、その暗黙の長さに組み立てられる。
ｓｉｚｅ ： ＨＬＡＳＭＳｉｚｅＴｙｐｅ
この要素の境界位置合わせを指定する。
【０２５９】
ＨＬＡＳＭＣｏｍｐｏｓｅｄＴｙｐｅ
ＨＬＡＳＭＣｏｍｐｏｓｅｄＴｙｐｅクラスは、追加の要素を含む入れ子になった宣言を表す。ＨＬＡＳＭＣｏｍｐｏｓｅｄＴｙｐｅは、ＨＬＡＳＭＥｌｅｍｅｎｔの集約である。ＨＬＡＳＭＣｏｍｐｏｓｅｄＴｙｐｅは、ＨＬＡＳＭＵｎｉｏｎの親である。
ＨＬＡＳＭＣｌａｓｓｉｆｉｅｒ、ＴＤＬａｎｇＣｏｍｐｏｓｅｄＴｙｐｅから派生する
プライベート属性：
ｕｎｉｏｎ ： ｂｏｏｌｅａｎ
要素が共用体であるか否かを指定する。
共用体の場合に真。
そうでない場合に偽。
【０２６０】
ＨＬＡＳＭＡｒｒａｙ
ＨＬＡＳＭＡｒｒａｙは、配列命令に関する情報を保持する。
プライベート属性：
ｓｉｚｅ ： ｉｎｔ
ｓｉｚｅは、メモリ内で割り振られる配列の１次元サイズを表す。
【０２６１】
ＨＬＡＳＭＥｌｅｍｅｎｔＩｎｉｔｉａｌＶａｌｕｅ
このクラスには、ＨＬＡＳＭＥｌｅｍｅｎｔの初期値が含まれる。
ＴＤＬａｎｇＥｌｅｍｅｎｔから派生する
プライベート属性：
ｉｎｉｔＶａｌ ： Ｓｔｒｉｎｇ
要素の初期値を指定する。例：’ＭＩＮ’、’ＭＡＸ’など
【０２６２】
ＨＬＡＳＭＳｏｕｒｃｅＴｅｘｔ
このクラスには、ソース・コード全体（コメントを含む）およびそれに関連する行番号が含まれる。
パブリック属性：
ｓｏｕｒｃｅ ： Ｓｔｒｉｎｇ
ソース・ファイル・ストリングを指定する。
ｆｉｌｅＮａｍｅ ： Ｓｔｒｉｎｇ
ソース・ファイルのパスを指定する。
【０２６３】
総計：
１論理パッケージ
１４クラス
論理パッケージ構造
論理ビュー
ＴＤＬａｎｇ
ｈｌａｓｍ
【０２６４】
６．アプリケーションドメイン・インターフェース・メタモデル
６．ａ．ＩＭＳトランザクション・メッセージ・メタモデル
ＩＭＳトランザクション・メッセージ・メタモデルは、図３１に示されているように（図３１に、３種類のトランザクション・メッセージすなわち、プレフィックス付きのＩＭＳ−ＯＴＭＡメッセージ、デフォルトＯＴＭＡプレフィックスをＩＭＳが構築することができるプレフィックスなしのＩＭＳメッセージ、およびアプリケーション・プログラムに直接に送ることができるＩＭＳ基本メッセージを含む、ＩＭＳトランザクション・メッセージのメタモデルを示す）３種類のＩＭＳトランザクション・メッセージすなわち：
＊プレフィックス付きのＩＭＳ−ＯＴＭＡメッセージ
＊デフォルトＯＴＭＡプレフィックスをＩＭＳが構築することができるプレフィックスなしのＩＭＳメッセージ
＊アプリケーション・プログラムに直接に送ることができるＩＭＳ基本メッセージ
を含む。
【０２６５】
６．ａ．ｉ．ＩＭＳ　ＯＴＭＡプレフィックス
ＩＭＳ　ＯＴＭＡメッセージ・プレフィックスは、下記のコンポーネントから構成される。図３２に、ＯＴＭＡプレフィックス・メタデータ・モデルを示す。図３３に、制御データ定義データ型のＯＴＭＡプレフィックスを示す。図３４に、状態定義データ型のＯＴＭＡプレフィックスを示す。図３５に、セキュリティ定義型のＯＴＭＡプレフィックスを示す。図３６に、ＩＭＳメタモデルのＩＭＳメッセージ・プリミティブを示す。
＊制御データ：このセクションには、トランザクションパイプ名、メッセージ・タイプ、シーケンス番号、フラグ、およびインジケータが含まれる。
＊状態データ：このセクションには、宛先オーバーライド、マップ名、同期レベル、コミット・モード、トークン、およびサーバ状態が含まれる。
＊セキュリティ・データ：このセクションには、ユーザＩＤ、ユーザ・トークン、およびセキュリティ・フラグが含まれる。
＊ユーザ・データ：このセクションには、クライアントが必要とする特殊な情報のすべてが含まれる。
【０２６６】
ＯＴＭＡプレフィックス・メタモデルは、下記の特徴を有する。
１）ＯＴＭＡ Ｐｒｅｆｉｘ　−　制御データ定義型
２）ＯＴＭＡ Ｐｒｅｆｉｘ　−　状態データ定義型
３）ＯＴＭＡ Ｐｒｅｆｉｘ　−　セキュリティ・データ定義型
【０２６７】
６．ａ．ｉｉ．ＩＭＳメッセージ・プリミティブ型
６．ａ．ｉ．ａ）．ＩＭＳＴｒａｎｓａｃｔｉｏｎＭｅｓｓａｇｅメタモデル仕様
ＩＭＳＴｒａｎｓａｃｔｉｏｎＭｅｓｓａｇｅメタモデルには、下記のＩＭＳメッセージ・シナリオが含まれる：
・プレフィックス付きのＩＭＳ　ＯＴＭＡメッセージ
・プレフィックスなしのＩＭＳ　ＯＴＭＡメッセージ
・アプリケーション・プログラムに直接に送られるＩＭＳ基本メッセージ。
プライベート属性：
ＯＴＭＡＰｒｅｆｉｘＦｏｒｍａｔ ： ＯＴＭＡＰｒｅｆｉｘＦｏｒｍａｔｓ ＝ ｏｎｅ
ＳｔａｎｄａｒｄＦｉｅｌｄｓＦｌａｇ ： ｂｏｏｌｅａｎ
【０２６８】
ＯＴＭＡＰｒｅｆｉｘＦｏｒｍａｔｓ
プライベート属性：
ｏｎｅ ：
ｔｗｏ ：
【０２６９】
ＳｔａｎｄａｒｄＦｉｅｌｄｓ
ＳｔａｎｄａｒｄＦｉｅｌｄｓ（ＬＬ、ＺＺ、およびトランザクション・コードを含む）は、下記のシナリオには含まれない。
・ＩＭＳトランザクション・アプリケーション・プログラムへのＸＭＬ文書の直接送信
・ＩＭＳアプリケーションへのＡＣＫメッセージまたはＮＡＫメッセージ
プライベート属性：
Ｌｅｎｇｔｈ ： ＴｗｏＢｙｔｅＦｉｅｌｄ
ＬＬとも称する。
ＲｅｓｅｒｖｅｄＦｉｅｌｄ ： ＴｗｏＢｙｔｅＦｉｅｌｄ
ＺＺとも称する。
ＴｒａｎｓａｃｔｉｏｎＣｏｄｅ ： ＶａｒｉａｂｌｅＬｅｎｇｔｈＦｉｅｌｄ
ＴｒａｎｓａｃｔｉｏｎＣｏｄｅフィールドは、１バイトから８バイトまでの長さとすることができる。
ＴｒａｎｓａｃｔｉｏｎＣｏｄｅは、入力メッセーの最初のセグメントだけに現れる。
ＴｒａｎｓａｃｔｉｏｎＣｏｄｅは、ＬＬＺＺの後に来る。
【０２７０】
ＯＴＭＡＰｒｅｆｉｘ
ＩＭＳ　ＯＴＭＡプレフィックスは、すべてのメッセージ・セグメントの前、またはメッセージの最初のセグメントの前だけのいずれかに現れることができる。しかし、ＯＴＭＡプレフィックスは、任意選択である。これが指定されない場合には、ＩＭＳゲートウェイが、要求のデフォルトのプレフィックスを構築する。
【０２７１】
ＣｏｎｔｒｏｌＤａｔａ
制御データは、メッセージ制御情報である。これには、トランザクションパイプ名、メッセージ・タイプ、シーケンス番号、フラグ、およびインジケータが含まれる。
プライベート属性：
ＡｒｃｈｉｔｅｃｔｕｒｅＬｅｖｅｌ ： ＯｎｅＢｙｔｅＦｉｅｌｄ
ＯＴＭＡアーキテクチャ・レベルを指定する。クライアントが、アーキテクチャ・レベルを指定し、サーバは、それが使用しているアーキテクチャ・レベルを応答メッセージで示す。クライアントとサーバによって使用されるアーキテクチャ・レベルは、一致しなければならない。
ＩＭＳバージョン６では、有効な値はＸ’０１’だけである。
すべてのメッセージについて必須。
ＭｅｓｓａｇｅＴｙｐｅ ： ＴＭｅｓｓａｇｅＴｙｐｅ
メッセージ・タイプを指定する。すべてのＯＴＭＡメッセージで、メッセージ・タイプの値が指定されなければならない。値は、相互排他的ではない。たとえば、サーバが、クライアントがサブミットしたトランザクションに対するＡＣＫメッセージを送信する時に、トランザクション・フラグと応答フラグの両方がセットされる。
ＲｅｓｐｏｎｓｅＦｌａｇ ： ＯｎｅＢｙｔｅＦｉｅｌｄ
メッセージが応答メッセージであること、または応答が必要であることのいずれかを指定する。
トランザクションに対する肯定応答には、トランザクションで拡張応答要求が指定された場合に限って、メッセージ・プレフィックスのアプリケーションデータ・セクションに属性（そのトランザクションの）が含まれる。
ＣｏｍｍｉｔＣｏｎｆｉｒｍａｔｉｏｎＦｌａｇ ：ＴＣｏｍｍｉｔＣｏｎｆｉｒｍａｔｉｏｎＦｌａｇ
コミット要求の成功を指定する。コミット確認メッセージ内で、サーバによってクライアントに送信される。これらのメッセージは、送信後コミット（ｓｅｎｄ−ｔｈｅｎ−ｃｏｍｍｉｔ）トランザクションに関してのみ適用可能であり、メッセージ・プレフィックスの状態データ・セクションの同期レベル・フラグによって影響されない。
ＣｏｍｍａｎｄＴｙｐｅ ： ＴＣｏｍｍａｎｄＴｙｐｅ
ＯＴＭＡプロトコル・コマンド・タイプを指定する。
ＩＭＳ　ＭＴＯコマンドは、メッセージのアプリケーションデータ・セクションで指定される。
ＰｒｏｃｅｓｓｉｎｇＦｌａｇ ： ＴＰｒｏｃｅｓｓｉｎｇＦｌａｇ
クライアントまたはサーバがそれによってメッセージ処理を制御できるオプションを指定する。
ＴｐｉｐｅＮａｍｅ ： ＥｉｇｈｔＢｙｔｅＦｉｅｌｄ
トランザクションパイプ名を指定する。ＩＭＳの場合、この名前が、入出力ＰＣＢ上のＬＴＥＲＭ名をオーバーライドするのに使用される。このフィールドは、すべてのトランザクション・メッセージ・タイプ、データ・メッセージ・タイプ、およびコミット確認メッセージ・タイプに適用可能である。このフィールドは、いくつかの応答メッセージ・タイプおよびコマンド・メッセージタイプにも適用可能である。
ＣｈａｉｎＦｌａｇ ： ＴＣｈａｉｎＦｌａｇ
メッセージに含まれるセグメント数を指定する。このフラグは、トランザクション・メッセージ・タイプおよびデータ・メッセージ・タイプに適用可能であり、複数セグメント・メッセージに必須である。
ＰｒｅｆｉｘＦｌａｇ ： ＴＰｒｅｆｉｘＦｌａｇ
ＯＴＭＡメッセージに付加されるメッセージ・プレフィックスのセクションを指定する。すべてのメッセージが、メッセージ制御情報セクションを有しなければならないが、他のセクションの任意の組合せを、ＯＴＭＡメッセージと共に送信することができる。
ＳｅｎｄＳｅｑｕｅｎｃｅＮｕｍｂｅｒ ： ＦｏｕｒＢｙｔｅＦｉｅｌｄ
トランザクション・パイプのシーケンス番号を指定する。このシーケンス番号は、メッセージまたはトランザクションを送信する時に、クライアントおよびサーバによって更新される。
推奨：トランザクション・パイプごとに別々に番号を増分されたい。
この番号は、ＡＣＫメッセージまたはＮＡＫメッセージを、肯定応答される指定されたメッセージと一致させるのにも使用することができる。
ＳｅｎｓｅＣｏｄｅ ： ＴｗｏＢｙｔｅＦｉｅｌｄ
ＮＡＫメッセージに付随するセンス・コードを指定する。
ＲｅａｓｏｎＣｏｄｅ ： ＴｗｏＢｙｔｅＦｉｅｌｄ
ＮＡＫメッセージに付随する理由コードを指定する。このコードが、さらに、センス・コードを修飾することができる。
ＲｅｃｏｖｅｒａｂｌｅＳｅｑｕｅｎｃｅＮｕｍｂｅｒ ： ＦｏｕｒＢｙｔｅＦｉｅｌｄ
トランザクション・パイプの回復可能シーケンス番号を指定する。
同期化されるトランザクション・パイプを使用する回復可能メッセージの送信ごとに増分される。クライアントとサーバの両方が、回復可能シーケンス番号を増分し、送信シーケンス番号とは別に維持する。
ＳｅｇｍｅｎｔＳｅｑｕｅｎｃｅＮｕｍｂｅｒ ： ＴｗｏＢｙｔｅＦｉｅｌｄ
複数セグメント・メッセージのセグメントのシーケンス番号を指定する。
この番号は、セグメントごとに更新されなければならない。というのは、メッセージが、必ずしもＸＣＦによってシーケンシャルに送達されるのではないからである。
この番号は、メッセージが１つだけセグメントを有する場合に、０（ゼロ）の値を有しなければならない。
Ｒｅｓｅｒｖｅｄ ： ＴｗｏＢｙｔｅＦｉｅｌｄ
【０２７２】
ＤｅｆｉｎｅｄＴｙｐｅｓ
ＴＭｅｓｓａｇｅＴｙｐｅ
プライベート属性：
Ｄａｔａ ： Ｓｔｒｉｎｇ
データ（値Ｘ’８０’）
クライアントに送信されるサーバ出力を指定する。クライアントが、メッセージ・プレフィックスの状態データ・セクションで同期レベルＣｏｎｆｉｒｍを指定する場合に、サーバも、応答フラグの応答要求をセットする。クライアントが同期レベルを指定しない場合には、サーバは、デフォルトのＣｏｎｆｉｒｍを使用する。
Ｔｒａｎｓａｃｔｉｏｎ ： Ｓｔｒｉｎｇ
トランザクション（値Ｘ’４０’）
サーバへの入力データを指定する。
Ｒｅｓｐｏｎｓｅ ： Ｓｔｒｉｎｇ
応答（値Ｘ’２０’）
メッセージが応答メッセージであることを指定し、このメッセージがそれに対する応答であるメッセージで応答フラグの応答要求が指定される場合に限ってセットされる。
このフラグがセットされる場合には、応答フラグでＡＣＫまたはＮＡＫのいずれかを指定する。
送信シーケンス番号が、元のデータ・メッセージおよび応答メッセージに関して一致しなければならない。サーバへのチェーン・トランザクション入力メッセージでは、必ず、次のトランザクション（特定のトランザクション・パイプに関する）が送信される前に、応答を要求しなければならない。
Ｃｏｍｍａｎｄ ： Ｓｔｒｉｎｇ
コマンド（値Ｘ’１０’）　ＯＴＭＡプロトコル・コマンドを指定する。ＯＴＭＡコマンドでは、必ず、応答フラグの応答要求を指定しなければならない。
ＣｏｍｍｉｔＣｏｎｆｉｒｍａｔｉｏｎ ： Ｓｔｒｉｎｇ
ＣｏｍｍｉｔＣｏｎｆｉｒｍａｔｉｏｎ（値Ｘ’０８’）　コミットが完了することを指定する。これは、同期点が完了した時にサーバによって送信され、送信後コミット・トランザクションについてのみ適用可能である。コミット確認フラグもセットされる。
【０２７３】
ＴＲｅｓｐｏｎｓｅＦｌａｇ
プライベート属性：
ＡＣＫ ： Ｓｔｒｉｎｇ
ＡＣＫ（値Ｘ’８０’）　肯定の応答を指定する。
ＮＡＫ ： Ｓｔｒｉｎｇ
ＮＡＫ（値Ｘ’４０’）　否定の応答を指定する。
ＮＡＫの理由に関する情報については、センス・コード・フィールドを参照されたい。
ＲｅｓｐｏｎｓｅＲｅｑｕｅｓｔｅｄ ： Ｓｔｒｉｎｇ
応答要求（値Ｘ’２０’）　このメッセージに関して応答が要求されることを示す。これは、データ、トランザクション、またはコマンドのメッセージ・タイプについてセットすることができる。
送信後コミットＩＭＳコマンド出力を送信する時に、ＩＭＳは、同期レベルに無関係に、ＡＣＫを要求しない。
ＥｘｔｅｎｄｅｄＲｅｓｐｏｎｓｅＲｅｑｕｅｓｔｅｄ ： Ｓｔｒｉｎｇ
拡張要求応答（値Ｘ’１０’）　このメッセージに関して拡張応答が要求されることを指定する。クライアントによって、トランザクションについてのみ（またはトランザクション・コードではなくＩＭＳコマンドを指定するトランザクションについて）セットすることができる。このフラグが、トランザクションについてセットされる場合に、ＩＭＳは、ＡＣＫメッセージのアプリケーションデータ・セクションで、そのトランザクションの設計済み属性を返す。このフラグが、コマンドについてセットされる場合に、ＩＭＳは、ＡＣＫメッセージのアプリケーションデータ・セクションで設計済み属性を返す。このフラグは、ＩＭＳコマンド／ＤＩＳＰＬＡＹ ＴＲＡＮＳＡＣＴＩＯＮおよび／ＤＩＳＰＬＡＹ ＴＲＡＮＳＡＣＴＩＯＮ ＡＬＬについてセットすることができる。
【０２７４】
ＴＣｏｍｍｉｔＣｏｎｆｉｒｍａｔｉｏｎＦｌａｇ
プライベート属性：
Ｃｏｍｍｉｔｔｅｄ ： Ｓｔｒｉｎｇ
コミット済み（値Ｘ’８０’）　サーバが成功裡にコミットしたことを指定する。
Ａｂｏｒｔｅｄ ： Ｓｔｒｉｎｇ
打切り（値Ｘ’４０’）　サーバがコミットを打ち切ったことを指定する。
【０２７５】
ＴＣｏｍｍａｎｄＴｙｐｅ
プライベート属性：
ＣｌｉｅｎｔＢｉｄ ： Ｓｔｒｉｎｇ
クライアント送信権要求（値Ｘ’０４’）　クライアントがＯＴＭＡサーバに送信する最初のメッセージを指定する。このコマンドによって、メッセージ・プレフィックスのメッセージ制御情報セクションの応答要求フラグおよびセキュリティ・フラグもセットされる。適当な状態データ・フィールド（たとえばＭｅｍｂｅｒ Ｎａｍｅ）もセットされなければならない。セキュリティデータ・プレフィックスでは、ＯＴＭＡサーバがＯＴＭＡクライアントとして働くためのクライアントの権限を検証できるように、Ｕｔｏｋｅｎフィールドを指定しなければならない。サーバは、クライアント送信権要求要求に応答することができるので、このメッセージは、クライアントがデータ・メッセージの受け入れを開始する準備ができるまで、送信してはならない。
ＳｅｒｖｅｒＡｖａｉｌａｂｌｅ ： Ｓｔｒｉｎｇ
サーバ使用可能（値Ｘ’０８’）　サーバがクライアントに送信する最初のメッセージを指定する。これは、クライアントが接続される前に、サーバがＸＣＦグループに接続した時に送信される。クライアントは、サーバ使用可能メッセージに対して、クライアント送信権要求要求を用いて応答する。適当な状態データ・フィールド（たとえばＭｅｍｂｅｒ Ｎａｍｅ）もセットされなければならない。クライアントは、初めて接続する場合に、サーバが接続した時にＸＣＦによって通知され、クライアント送信権要求要求を用いて処理を開始する。
ＣＢｒｅｓｙｎｃｈ ： Ｓｔｒｉｎｇ
ＣＢｒｅｓｙｎｃｈ（値Ｘ’０Ｃ’）　再同期のためのクライアントによる要求を伴うクライアント送信権要求要求メッセージを指定する。このコマンドは、任意選択であり、サーバに、ＳＲＶｒｅｓｙｎｃｈメッセージをクライアントに送信させる。ＣＢｒｅｓｙｎｃｈコマンドは、クライアントがＩＭＳとの再同期を試み、既存の同期化されたＴｐｉｐｅｓがそのクライアントのために存在する時に、クライアントがＯＴＭＡサーバに送信する最初のメッセージである。メッセージ・プレフィックス内のＣＢｒｅｓｙｎｃｈメッセージ・インジケータ以外の、メッセージ・プレフィックスに必要な情報は、クライアント送信権要求要求コマンドと同一でなければならない。ＩＭＳが、クライアントに関するクライアント送信権要求要求を受信し、ＩＭＳが、既存の同期化されたＴｐｉｐｅｓを知っている場合に、ＩＭＳは、情報メッセージＤＦＳ２３９４ＩをＭＴＯに発行する。ＩＭＳは、すべての同期化されたＴｐｉｐｅｓについて、回復可能送信シーケンス番号または回復可能受信シーケンス番号を０（ゼロ）にリセットする。
ＳｕｓｐｅｎｄＰｒｏｃｅｓｓｉｎｇＦｏｒＡｌｌＴｐｉｐｅｓ ： Ｓｔｒｉｎｇ
すべてのＴｐｉｐｅｓに関する処理の延期（値Ｘ’１４’）　サーバが、クライアントとのすべてのメッセージ・アクティビティを延期しようとしていることを指定する。すべての後続のデータ入力で、サーバからのＮＡＫメッセージが受信される。同様に、クライアントは、すべての後続のサーバ・メッセージに関してＮＡＫメッセージを送信しなければならない。クライアントは、特定のトランザクション・パイプに関して処理を延期することを望む場合には、ＯＴＭＡメッセージとして／ＳＴＯＰＴＰＩＰＥコマンドをサブミットしなければならない。
ＲｅｓｕｍｅＰｒｏｃｅｓｓｉｎｇＦｏｒＡｌｌＴｐｉｐｅｓ ： Ｓｔｒｉｎｇ
すべてのＴｐｉｐｅｓに関する処理の再開（値Ｘ’１８’）　サーバが、クライアントとのメッセージ・アクティビティを再開しようとしていることを指定する。クライアントは、停止された特定のトランザクション・パイプに関する処理を再開することを望む場合に、ＯＴＭＡメッセージとして／ＳＴＡＲＴＴＰＩＰＥコマンドをサブミットしなければならない。
ＳｕｓｐｅｎｄＩｎｐｕｔＦｏｒＴｐｉｐｅ ： Ｓｔｒｉｎｇ
Ｔｐｉｐｅの入力延期（値Ｘ’１Ｃ’）　サーバが、過負荷であり、トランザクション・パイプに関する入力を一時的に延期しようとしていることを指定する。すべての後続のクライアント入力で、メッセージ・プレフィックスのメッセージ制御情報セクションで指定されたトランザクション・パイプに関するＮＡＫメッセージが受信される。このコマンドに関して、応答は不要である。この設計済みコマンドは、マスタ端末オペレータが／ＳＴＯＰＴＰＩＰＥコマンドを入力した時にも、ＩＭＳによって送信される。
ＲｅｓｕｍｅＩｎｐｕｔＦｏｒＴｐｉｐｅ ： Ｓｔｒｉｎｇ
Ｔｐｉｐｅの入力再開（値Ｘ’２０’）　サーバが、前のＴｐｉｐｅの入力延期コマンドの後に、クライアント入力を再開する準備ができたことを指定する。このコマンドに関して、応答は不要である。このコマンドは、ＩＭＳマスタ端末オペレータが／ＳＴＡＲＴＴＰＩＰＥコマンドを入力した時にも、ＩＭＳによって送信される。
ＳＲＶｒｅｓｙｎｃｈ ： Ｓｔｒｉｎｇ
ＳＲＶｒｅｓｙｎｃｈ（値Ｘ’２Ｃ’）　クライアントのＣＢｒｅｓｙｎｃｈコマンドに対するサーバの応答を指定する。このコマンドでは、サーバ内の同期化されたトランザクション・パイプの状態（送信シーケンス番号および受信シーケンス番号）を指定する。このコマンドは、単一のメッセージ（単一または複数のセグメントを有する）として送信され、ＡＣＫが要求される。
ＲＥＱｒｅｓｙｎｃｈ ： Ｓｔｒｉｎｇ
ＲＥＱｒｅｓｙｎｃｈ（値Ｘ’３０’）　特定のＴｐｉｐｅの送信シーケンス番号および受信シーケンス番号を指定する。ＲＥＱｒｅｓｙｎｃｈは、ＩＭＳからクライアントに送信される。
ＲＥＰｒｅｓｙｎｃｈ ： Ｓｔｒｉｎｇ
ＲＥＰｒｅｓｙｎｃｈ（値Ｘ’３４’）　Ｔｐｉｐｅに関するクライアントの所望の状態情報を指定する。クライアントは、ＩＭＳから受信したＲＥＱｒｅｓｙｎｃｈコマンドに応答して、ＩＭＳにＲＥＰｒｅｓｙｎｃｈコマンドを送信する。
ＴＢｒｅｓｙｎｃｈ ： Ｓｔｒｉｎｇ
ＴＢｒｅｓｙｎｃｈ（値Ｘ’３８’）　クライアントが、ＩＭＳからＲＥＱｒｅｓｙｎｃｈコマンドを受信する準備ができていることを指定する。
【０２７６】
ＴＰｒｏｃｅｓｓｉｎｇＦｌａｇ
プライベート属性：
ＳｙｎｃｈｒｏｎｉｚｅｄＴｐｉｐｅ ： Ｓｔｒｉｎｇ
同期化されたＴｐｉｐｅ（値Ｘ’４０’）　トランザクション・パイプが同期化されることを指定する。障害がある場合に、クライアントがトランザクション・パイプを再同期化できるようにする。コミット後送信トランザクションについてのみ有効。このフラグは、入力および出力のシーケンス番号がトランザクション・パイプに関して維持されるようにする。そのトランザクション・パイプを介して経路指定されるすべてのトランザクションが、矛盾がないように（オンまたはオフのいずれか）このフラグを指定しなければならない。
ＡｓｙｎｃｈｒｏｎｏｕｓＯｕｔｐｕｔ： Ｓｔｒｉｎｇ
非同期出力（値Ｘ’２０’）　サーバが、非送信請求待機出力をクライアントに送信しつつあることを指定する。これは、ＩＭＳが、代替ＰＣＢにメッセージを挿入する時に発生する可能性がある。いくつかのＩＭＳコマンドは、コミット後送信としてサブミットされる時に、ＩＭＳに、このフラグをセットされた出力をクライアントに送信させる場合がある。この場合に、ＯＴＭＡプレフィックスに、出力を元のコマンド・メッセージに相関させるのにクライアントが使用できる識別情報が含まれない。これらのコマンド出力データ・メッセージは、単に、トランザクションパイプ名を識別する。ＩＭＳは、トランザクションパイプ名だけを有する非送信請求エラー・メッセージを送信することもできる。
ＥｒｒｏｒＭｅｓｓａｇｅＦｏｌｌｏｗｓ ： Ｓｔｒｉｎｇ
エラー・メッセージが続く（値Ｘ’１０’）　このメッセージにエラー・メッセージが続くことを指定する。このフラグは、サーバからのＮＡＫメッセージについてセットされる。その後、追加のエラー・メッセージが、クライアントに送信される。非同期出力フラグは、エラー・データ・メッセージではセットされない。というのは、この出力がＩＭＳアプリケーションによって生成されないからである。
【０２７７】
ＴＣｈａｉｎＦｌａｇ
プライベート属性：
ＦｉｒｓｔＩｎＣｈａｉｎ ： Ｓｔｒｉｎｇ
先頭チェーン（値Ｘ’８０’）　複数セグメント・メッセージを含むセグメントのチェーンの最初のセグメントを指定する。このメッセージの後続セグメントは、メッセージ・プレフィックスのメッセージ制御情報セクションだけを必要とする。他の適用可能なプレフィックス・セグメント（たとえば、トランザクション・メッセージ上でクライアントによって指定されるもの）は、最初のセグメントと共に送信されるだけである（先頭チェーン・フラグをセットされて）。ＯＴＭＡメッセージが、１つのセグメントだけを有する場合には、チェーン内での最後フラグもセットされなければならない。
ＭｉｄｄｌｅＩｎＣｈａｉｎ ： Ｓｔｒｉｎｇ
中間チェーン（値Ｘ’４０’）　複数セグメント・メッセージを含むセグメントのチェーンの最初でも最後でもないセグメントを指定する。これらのセグメントは、メッセージ・プレフィックスのメッセージ制御情報セクションだけを必要とする。
制約：クライアント・トークンおよびサーバ・トークンが、メッセージ・プレフィックスの状態データ・セクションにあるので、これらを使用して、セグメント化されたメッセージを相関させ、組み合わせることはできない。トランザクションパイプ名および送信シーケンス番号を、この目的に使用することができる。これは、各セグメントのメッセージ・プレフィックスのメッセージ制御情報セクションにある。
ＬａｓｔＩｎＣｈａｉｎ ： Ｓｔｒｉｎｇ
チェーン内での最後（値Ｘ’２０’）　複数セグメント・メッセージの最後のセグメントを指定する。
ＤｉｓｃａｒｄＣｈａｉｎ ： Ｓｔｒｉｎｇ
チェーン破棄（値Ｘ’１０’）　複数セグメント・メッセージのチェーン全体を破棄しなければならないことを指定する。チェーン内での最後フラグもセットしなければならない。
【０２７８】
ＴＰｒｅｆｉｘＦｌａｇ
プライベート属性：
ＳｔａｔｅＤａｔａ ： Ｓｔｒｉｎｇ
状態データ（値Ｘ’８０’）　このメッセージに、メッセージ・プレフィックスの状態データ・セクションが含まれることを指定する。
ＳｅｃｕｒｉｔｙＤａｔａ ： Ｓｔｒｉｎｇ
セキュリティ（値Ｘ’４０’）　このメッセージに、メッセージ・プレフィックスのセキュリティデータ・セクションが含まれることを指定する。
ＵｓｅｒＤａｔａ ： Ｓｔｒｉｎｇ
ユーザ・データ（値Ｘ’２０’）　このメッセージに、メッセージ・プレフィックスのユーザデータ・セクションが含まれることを指定する。
ＡｐｐｌｉｃａｔｉｏｎＤａｔａ ： Ｓｔｒｉｎｇ
アプリケーション・データ（値Ｘ’１０’）　このメッセージに、メッセージ・プレフィックスのアプリケーションデータ・セクションが含まれることを指定する。
【０２７９】
ＳｔａｔｅＤａｔａ
ＳｔａｔｅＤａｔａ
これには、宛先オーバーライド、マップ名、同期レベル、コミット・モード、トークン、およびサーバ状態が含まれる。これが、トランザクションに関する状態データであることに留意されたい。ＯＴＭＡは、サーバ使用可能コマンド、クライアント送信権要求コマンド、ＳＲＶｒｅｓｙｎｃｈコマンド、ＲＥＱｒｅｓｙｎｃｈコマンド、ＲＥＰｒｅｓｙｎｃｈコマンドに関する状態データ・ヘッダもサポートする。しかし、これらのコマンドは、絶対にクライアント装置によって生成されず、したがって、コマンド・メッセージが、絶対にＩＭＳ接続インターフェースに入らず、したがって、これらをモデル化する必要はない。
プライベート属性：
Ｌｅｎｇｔｈ ： ＴｗｏＢｙｔｅＦｉｅｌｄ
ＳｅｒｖｅｒＳｔａｔｅ ： ＴＳｅｒｖｅｒＳｔａｔｅ　トランザクションが実行されているモードを指定する。
ＳｙｎｃｈｒｏｎｉｚａｔｉｏｎＦｌａｇ ： ＴＳｙｎｃｈｒｏｎｉｚａｔｉｏｎＦｌａｇ　トランザクションのコミット・モードを指定する。このフラグによって、クライアントとサーバの間のデータの流れが制御され、同期化される。
ＳｙｎｃｈｒｏｎｉｚａｔｉｏｎＬｅｖｅｌ ：ＴＳｙｎｃｈｒｏｎｉｚａｔｉｏｎＬｅｖｅｌ　トランザクション同期化レベルすなわち、クライアントとサーバのトランザクション・プログラム（たとえばＩＭＳアプリケーション・プログラム）がプログラム出力メッセージと対話する形を指定する。デフォルトはＣｏｎｆｉｒｍである。ＩＭＳは、コミット後送信出力をクライアントに送信する時に、必ず応答を要求する。
Ｒｅｓｅｒｖｅｄ ： ＯｎｅＢｙｔｅＦｉｅｌｄ
ＭａｐＮａｍｅ ： ＥｉｇｈｔＢｙｔｅＦｉｅｌｄ　出力データ・ストリーム（たとえば３２７０データ・ストリーム）をマッピングするのにサーバによって使用されるフォーマット設定マップを指定する。ＯＴＭＡは、ＭＦＳサポートを提供しないが、ユーザは、マップ名を指定して、出力データ・ストリームを定義することができる。名前は、入出力ＰＣＢ内に配置される８バイトＭＯＤ名である。ＩＭＳは、メッセージが挿入される時に、プレフィックス内のこのフィールドを、入出力ＰＣＢ内のマップ名に置換する。
マップ名は任意選択である。
ＳｅｒｖｅｒＴｏｋｅｎ ： ＳｉｘｔｅｅｎＢｙｔｅＦｉｅｌｄ　サーバ名を指定する。サーバ・トークンが、応答メッセージ（ＡＣＫまたはＮＡＫ）でクライアントによってサーバに返されなければならない。会話型トランザクションの場合には、サーバ・トークンが、後続の会話入力でもクライアントによって返されなければならない。
ＣｏｒｒｅｌａｔｏｒＴｏｋｅｎ ： ＳｉｘｔｅｅｎＢｙｔｅＦｉｅｌｄ　入力を出力に相関させるクライアント・トークンを指定する。このトークンは、任意選択であり、サーバによって使用されることはない。
推奨：クライアントは、トランザクションの管理を助けるためにこのトークンを使用すべきである。
ＣｏｎｔｅｘｔＩＤ ： ＳｉｘｔｅｅｎＢｙｔｅＦｉｅｌｄ
ＳＹＮＣＬＶＬ＝０２および保護会話と共に使用されるＲＲＳ／ＭＶＳトークンを指定する。
ＤｅｓｔｉｎａｔｉｏｎＯｖｅｒｒｉｄｅ ： ＥｉｇｈｔＢｙｔｅＦｉｅｌｄ　ＩＭＳアプリケーション・プログラムの入出力ＰＣＢ内のＬＴＥＲＭ名をオーバーライドするのに使用されるＬＴＥＲＭ名を指定する。このオーバーライドは、クライアントが、入出力ＰＣＢ内のＬＴＥＲＭ名をトランザクションパイプ名にオーバーライドしたくない場合に使用される。この任意選択のオーバーライドは、ブランクから開始される場合に、使用されない。
ＳｅｒｖｅｒＵｓｅｒＤａｔａＬｅｎｇｔｈ ： ＴｗｏＢｙｔｅＦｉｅｌｄ　サーバ・ユーザ・データがある場合に、その長さを指定する。サーバ・ユーザ・データの最大長は、２５６バイトである。
ＳｅｒｖｅｒＵｓｅｒＤａｔａ ： ＶａｒｉａｂｌｅＬｅｎｇｔｈＦｉｅｌｄ　サーバが必要とするデータを指定する。クライアントによってトランザクション・メッセージに含められる場合に、これは、出力データ・メッセージ内でサーバによって返される。
【０２８０】
ＤｅｆｉｎｅｄＴｙｐｅｓ
ＴＳｅｒｖｅｒＳｔａｔｅ
プライベート属性：
ＣｏｎｖｅｒｓａｔｉｏｎａｌＳｔａｔｅ ： Ｓｔｒｉｎｇ
会話状態（値Ｘ’８０’）　会話モード・トランザクションを指定する。サーバは、会話モード・トランザクションを処理する時に、この状態をセットする。この状態は、クライアントによって、後続ＩＭＳ会話データ・メッセージをＩＭＳに送信する時にもセットされる。
ＲｅｓｐｏｎｓｅＭｏｄｅ ： Ｓｔｒｉｎｇ
応答モード（値Ｘ’４０’）　応答モード・トランザクションを指定する。応答モード・トランザクションを処理する時に、サーバによってセットされる。ＯＴＭＡはセッションまたは端末を使用しないので、この状態は、ＯＴＭＡサーバにとってほとんど意味がない。
【０２８１】
ＴＳｙｎｃｈｒｏｎｉｚａｔｉｏｎＦｌａｇ
プライベート属性：
ＣｏｍｍｉｔＴｈｅｎＳｅｎｄ ： Ｓｔｒｉｎｇ
コミット後送信（値Ｘ’４０’）　コミット後送信トランザクションを指定する。サーバは、出力を送信する前にコミットする；たとえば、ＩＭＳが、ＩＭＳメッセージ・キューに出力を挿入する。
ＳｅｎｄＴｈｅｎＣｏｍｍｉｔ ： Ｓｔｒｉｎｇ
送信後コミット（値Ｘ’２０’）　送信後コミット・トランザクションを指定する。サーバは、出力をコミットする前にクライアントに送信する。
【０２８２】
ＴＳｙｎｃｈｒｏｎｉｚａｔｉｏｎＬｅｖｅｌ
プライベート属性：
Ｎｏｎｅ ： Ｓｔｒｉｎｇ
なし（値Ｘ’００’）　同期化が不要であることを指定する。サーバ・アプリケーション・プログラムは、クライアントに出力を送信する時に、ＡＣＫメッセージを要求しない。Ｎｏｎｅは、送信後コミット・トランザクションに限って有効である。
Ｃｏｎｆｉｒｍ ： Ｓｔｒｉｎｇ
確認（値Ｘ’０１’）　同期化が必要であることを指定する。サーバは、メッセージ・プレフィックスのメッセージ制御情報セクションの応答フラグに応答要求をセットして出力を送信する。確認は、コミット後送信トランザクションまたは送信後コミット・トランザクションのいずれかに使用することができる。
ＳＹＮＣＰＴ ： Ｓｔｒｉｎｇ
ＳＹＮＣＰＴ（値Ｘ’０２’）　プログラムが、ＲＲＳ／ＭＶＳ回復プラットフォームの下での変換中に更新されるリソースに対する整合コミット処理に参加することを指定する。このレベルとの会話を、保護会話とも称する。
【０２８３】
ＳｅｃｕｒｉｔｙＤａｔａ
ＳｅｃｕｒｉｔｙＤａｔａ
これには、ユーザＩＤ、ユーザ・トークン、およびセキュリティ・フラグが含まれる。
セキュリティデータ・セクションは、すべてのトランザクションに必須であり、ＯＴＭＡコマンド・メッセージのために存在することができる。
プライベート属性：
Ｌｅｎｇｔｈ ： ＴｗｏＢｙｔｅＦｉｅｌｄ　メッセージ・プレフィックスのセキュリティデータ・セクションの、長さフィールドを含む長さを指定する。
ＳｅｃｕｒｉｔｙＦｌａｇ ： ＴＳｅｃｕｒｉｔｙＦｌａｇ　実行されるセキュリティ検査のタイプを指定する。ユーザＩＤおよびパスワードが既に検証されていると仮定する。
ＬｅｎｇｔｈＯｆＳｅｃｕｒｉｔｙＦｉｅｌｄｓ ： ＯｎｅＢｙｔｅＦｉｅｌｄ　セキュリティ・データ・フィールドすなわちユーザＩＤ、プロファイル、およびＵｔｏｋｅｎの長さを指定する。この３つのフィールドは、任意の順序とすることができ、省略することができる。それぞれが、次の構造体を有する：Ｌｅｎｇｔｈフィールド、その後のＦｉｅｌｄタイプ、およびその後のＤａｔａフィールド。ユーザＩＤまたはプロファイルの実際の長さは、各フィールドの長さについて指定された値未満になってはならない。長さは、０にすることができる。
ｔｏｋｅｎＬｅｎｇｔｈ ： ＯｎｅＢｙｔｅＦｉｅｌｄ
ユーザ・トークンの長さを指定する。
長さには、長さフィールド自体は含まれない。
ＵｔｏｋｅｎＴｙｐｅ ： ＯｎｅＢｙｔｅＦｉｅｌｄ　このフィールドにユーザ・トークンが含まれることを指定する（値Ｘ’００’）。
Ｕｔｏｋｅｎ ： ＶａｒｉａｂｌｅＬｅｎｇｔｈＦｉｅｌｄ　ユーザ・トークンを指定する。ユーザＩＤおよびプロファイルが、ユーザ・トークンの作成に使用される。ユーザ・トークンは、ＩＭＳ依存領域に渡される。クライアントは、既にＲＡＣＦを呼び出している場合に、フィールド・タイプＸ’００’を有するＵｔｏｋｅｎを渡し、その結果、ＲＡＣＦがもう一度呼び出されないようにしなければならない。
１バイトから８０バイトまでの可変長。
ＵｓｅｒＩＤＬｅｎｇｔｈ ： ＯｎｅＢｙｔｅＦｉｅｌｄ　ユーザＩＤの長さを指定する。長さには、長さフィールド自体は含まれない。
ＵｓｅｒＩＤＴｙｐｅ ： ＯｎｅＢｙｔｅＦｉｅｌｄ　このフィールドにユーザＩＤが含まれることを指定する（値Ｘ’０２’）。
ＵｓｅｒＩＤ ： ＶａｒｉａｂｌｅＬｅｎｇｔｈＦｉｅｌｄ　実際のユーザＩＤを指定する。
１バイトから１０バイトまでの可変長。
ＰｒｏｆｉｌｅＬｅｎｇｔｈ ： ＯｎｅＢｙｔｅＦｉｅｌｄ　プロファイルの長さを指定する。長さには、長さフィールド自体は含まれない。
ＰｒｏｆｉｌｅＴｙｐｅ ： ＯｎｅＢｙｔｅＦｉｅｌｄ　このフィールドにプロファイルが含まれることを指定する（値Ｘ’０３’）。
Ｐｒｏｆｉｌｅ ： ＶａｒｉａｂｌｅＬｅｎｇｔｈＦｉｅｌｄ　システム許可機能（ＳＡＦ）プロファイルを指定する。ＲＡＣＦに関して、これはグループ名である。
１バイトから１０バイトまでの可変長。
【０２８４】
ＤｅｆｉｎｅｄＴｙｐｅｓ
ＴＳｅｃｕｒｉｔｙＦｌａｇ
プライベート属性：
ＮｏＳｅｃｕｒｉｔｙ ： Ｓｔｒｉｎｇ
セキュリティなし（値Ｘ’Ｎ’）　セキュリティ検査が行われないことを指定する。
Ｃｈｅｃｋ ： Ｓｔｒｉｎｇ
検査（値Ｘ’Ｃ’）　トランザクションおよびコマンドのセキュリティ検査を実行しなければならないことを指定する。
Ｆｕｌｌ ： Ｓｔｒｉｎｇ
完全（値Ｘ’Ｆ’）
トランザクション、コマンド、およびＭＰＰ領域のセキュリティ検査を実行しなければならないことを指定する。
【０２８５】
ＵｓｅｒＤａｔａ
ＵｓｅｒＤａｔａ
これには、クライアントが必要とする特殊な情報のすべてが含まれる。
ユーザデータ・セクションは、可変長であり、メッセージ・プレフィックスのセキュリティデータ・セクションに続く。ユーザデータ・セクションには、どのようなデータでも含めることができる。
プライベート属性：
Ｌｅｎｇｔｈ ： ＴｗｏＢｙｔｅＦｉｅｌｄ
メッセージ・プレフィックスのユーザデータ・セクションの、長さフィールドを含む長さを指定する。ユーザ・データの最大長は、１０２４バイトである。
ＵｓｅｒＤａｔａ ： ＶａｒｉａｂｌｅＬｅｎｇｔｈＦｉｅｌｄ
任意選択のユーザ・データを指定する。このデータは、クライアントによって管理され、ＤＦＳＹＤＲＵ０出口ルーチンを使用して作成し、更新することができる。サーバは、すべての出力メッセージの最初のセグメントとして、このセクションを無変更でクライアントに返す。
【０２８６】
Ｐｒｉｍｉｔｉｖｅｓ
ＯｎｅＢｙｔｅＦｉｅｌｄ
ＴｗｏＢｙｔｅＦｉｅｌｄ
ＦｏｕｒＢｙｔｅＦｉｅｌｄ
ＥｉｇｈｔＢｙｔｅＦｉｅｌｄ
ＳｉｘｔｅｅｎＢｙｔｅＦｉｅｌｄ
ＳｉｘＢｙｔｅＦｉｅｌｄ
ＶａｒｉａｂｌｅＬｅｎｇｔｈＦｉｅｌｄ
【０２８７】
ＡｐｐｌｉｃａｔｉｏｎＤａｔａ
ＡｐｐｌｉｃａｔｉｏｎＤａｔａ
アプリケーション・データ・クラスには、ＬＬ、ＺＺ、およびトランザクション・コードを除くすべてのメッセージ・データが含まれる。
注：このモデルは、メッセージ・セグメントの概念を取り込まない。このモデルを使用する時には、使用しているシステムが、最大セグメント・サイズなどの制限を有するかどうかをユーザが憶えていなければならない。ＩＭＳコネクタ（ＯＴＭＡまたはＳＮＡを介する）は、「アプリケーション・データ」をＩＭＳメッセージ・セグメントに分解する機能をサポートしなければならない。たとえば、ユーザが、このＸＭＬメッセージをＩＭＳメッセージ・キューに直接に送信し、メッセージ・キューが３２ｋの制限を有する場合に、ユーザは、ＸＭＬメッセージをとり、３２ｋチャンクに分解しなければならない。ＩＭＳ上のアプリケーションは、３２ｋチャンクを１つずつ寄せ集めなければならない。ＸＭＬ文書を直接に受信するＩＭＳの新しいアプリケーションは、複数のセグメントでＸＭＬ文書を受信することができなければならない。ＡＣＫメッセージまたはＮＡＫメッセージに関して、メッセージに含まれるアプリケーション・データはない。
【０２８８】
Ｆｉｅｌｄ
アプリケーション・データのコピーブック内で定義される各データ・フィールドは、データ型の型記述子に関連する。
【０２８９】
６．ｂ．ＣＩＣＳ　ＢＭＳ（基本マッピング・サポート）メタモデル
図４０に、コネクタ・インターフェースを表すデータ構造体を定義するためにアプリケーション・プログラムによって使用可能なＢＭＳ言語メタモデルを示す。図４１、および図４２に、ＢＭＳメタモデルの属性、フィールド、属性値、およびマップを示す。
【０２９０】
ＢＭＳＦｉｅｌｄＡｔｔｒｉｂｕｔｅｓ
プライベート属性：
Figure 2004506264
【０２９１】
ＢＭＳＭａｐ
ＤＦＨＭＤＩマクロによって実装される
ＭＡＰＮＡＭＥは、マップの名前であり、１つから７つまでの文字からなる。
ＣＯＬＵＭＮは、マップが配置される行内の桁を指定する、すなわち、左または右のマップ・マージンを確立する。
ＪＵＳＴＩＦＹは、マップおよびページのマージン選択および桁カウントが、ページの左側または右側のどちらから行われるかを制御する。指定されたマップ・マージンとページ・マージンの間の桁は、マップに含まれる行に関してそのページでの後続の使用に利用可能ではない。
ＮＵＭＢＥＲは、左または右のページ・マージンから、左または右のマップ・マージンが確立される桁である。
ＮＥＸＴは、左または右のマップ・マージンが、現在の行の左または右からの次に使用可能な桁に配置されることを示す。
ＳＡＭＥは、左または右のマップ・マージンが、ＣＯＬＵＭＮ＝Ｎｕｍｂｅｒを指定した最後に使用された非ヘッダ・マップまたは非トレーラ・マップと同一の桁で、このマクロと同一のＪＵＳＴＩＦＹオペランドで確立されることを示す。入力動作に関して、マップは、ＪＵＳＴＩＦＹ＝ＬＥＦＴまたはＪＵＳＴＩＦＹ＝ＲＩＧＨＴのどちらが指定されたかに応じて、左端または右端に位置決めされる。
ＬＩＮＥは、マップのデータがフォーマットされるページの開始行を指定する。
ＮＵＭＢＥＲは、開始行番号を指定する、１から２４０までの範囲の値である。前のＢＭＳコマンドに応答してフォーマットされたデータを、行および列にマップする要求によって、現在のページが完了したかのように扱われる。新しいデータは、新しいページの要求された行および列でフォーマットされる。
ＮＥＸＴは、データのフォーマットが、次に使用可能な完全に空の行で開始されることを指定する。ＬＩＮＥ＝ＮＥＸＴがＤＦＨＭＤＩマクロで指定される場合には、入力動作に関してそれが無視され、ＬＩＮＥ＝１が仮定される。
ＳＡＭＥは、データのフォーマットが、前のＢＭＳコマンドに使用されたものと同一の行で開始されることを指定する。ＣＯＬＵＭＮ＝ＮＥＸＴが指定された場合に、入力動作についてはこれが無視され、ＣＯＬＵＭＮ＝１が仮定される。データが同一行におさまらない場合には、そのデータは、完全に空の次に使用可能な行に配置される。
ＳＩＺＥ（ａｒｇ１，ａｒｇ２）は、マップのサイズを指定する。ａｒｇ２＝ｌｉｎｅは、１から２４０までの範囲の値であり、行数としてマップの奥行きを指定する。ａｒｇ１＝ｃｏｌｕｍｎは、１から２４０までの範囲の値であり、桁数としてマップの幅を指定する。
このオペランドは、次の場合に必要である：
ＰＯＳオペランドに関連するＤＦＨＭＤＦマクロが使用される。
マップが、ＡＣＣＵＭオプション付きのＳＥＮＤ ＭＡＰコマンドで参照される。
マップが、３２７０端末以外からの入力データをＲＥＣＥＩＶＥ ＭＡＰコマンドで参照する時に使用される。
ＳＯＳＩから、フィールドにＥＢＣＤＩＣデータとＤＢＣＳデータの混合が含まれる可能性があることが示される。ＥＢＣＤＩＣフィールド内のＤＢＣＳサブフィールドは、ＳＯ（シフト・アウト）文字およびＳＩ（シフト・イン）文字によって区切られる。ＳＯとＳＩの両方が、単一の画面位置を占める（通常はブランクとして表示される）。これらは、正しく対にされる場合に、出力の非ＤＢＣＳフィールドに含めることができる。端末ユーザは、これらがフィールドに既に存在する場合に、これらをインバウンドに送信できるが、これらをＥＢＣＤＩＣフィールドに追加できるのは、そのフィールドがＳＯＳＩ属性を有する場合に限られる。
ＴＩＯＡＰＦＸは、ＢＭＳが、未使用のＴＩＯＡプレフィックスを可能にするために記号記述マップに充てん文字を含めなければならないことを指定する。このオペランドは、ＤＦＨＭＳＤマクロについて指定されたＴＩＯＡＰＦＸオペランドをオーバーライドする。
ＹＥＳは、充てん文字が、記号記述マップに含まれなければならないことを指定する。ＴＩＯＡＰＦＸ＝ＹＥＳが指定される場合には、マップセット内のすべてのマップが、充てん文字を有する。ＴＩＯＡＰＦＸ＝ＹＥＳは、コマンドレベル・アプリケーション・プログラムに必ず使用されなければならない。
ＮＯは、デフォルトであり、充てん文字が含まれないことを指定する。
ＢＭＳＳｔａｔｅｍｅｎｔから派生する
プライベート属性：
Figure 2004506264
【０２９２】
ＢＭＳＭａｐｓｅｔ
ＤＦＨＭＳＤマクロによって実装される
このマクロのプログラミング属性
ｔｙｐｅ＝ＤＳＥＣＴ｜ＭＡＰ｜ＦＩＮＡＬ。
必須、これは、ＢＭＳエンティティの２ビットを生成する。
ｍｏｄｅ＝ＯＵＴ｜ＩＮ｜ＩＮＯＵＴ。
ＯＵＴがデフォルトである。ＩＮＯＵＴは、ＩＮおよびＯＵＴの両方の処理を指す。ＩＮの場合に、Ｉがマップ名に付加され、ＯＵＴの場合に、Ｏがマップ名に付加される。
ｌａｎｇ＝ＡＳＭ｜ＣＯＢＯＬ｜ＣＯＢＯＬ２｜ＰＬＩ｜Ｃ。
ＡＳＭがデフォルトである。
ｆｏｌｄ＝ＬＯＷＥＲ｜ＵＰＰＥＲ。
ＬＯＷＥＲがデフォルトである。Ｃだけに適用される。
ｄｓｅｃｔ＝ＡＤＳ｜ＡＤＳＬ。
ＡＤＳがデフォルトである。ＡＤＳＬはｌａｎｇ＝Ｃを必要とする。
ｔｒｉｇｒａｐｈ＝ＹＥＳ
ｌａｎｇ＝Ｃだけに適用される。
ＢＡＳＥは、同一のストレージ・ベースが、複数のマップセットからの記号記述マップに使用されることを指定する。同一の名前が、同一のストレージ・ベースを共用するマップセットごとに指定される。
同一のベースを有するすべてのマップセットが、同一のストレージを記述するので、前に使用されたマップセットに関連するデータは、新しいマップセットが使用される時に上書きされる可能性がある。同一のマップセット内の異なるマップも、互いにオーバーレイする。
このオペランドは、アセンブラ言語プログラムには有効でなく、ＳＴＯＲＡＧＥ＝ＡＵＴＯが指定された時に使用することはできない。
ｔｅｒｍ＝ｔｙｐｅ　各端末タイプが、１文字によって表される。３２７０は、デフォルトであり、ブランクである。ＭＡＰＳＥＴ名に追加されるか、ｓｕｆｆｉｘ＝Ｎｕｍｃｈａｒであり、これが、やはりマップセット名に追加される。
ＣＵＲＳＬＯＣは、３２７０端末上でこのマップを使用するすべてのＲＥＣＥＩＶＥＭＡＰ動作について、ＢＭＳが、カーソルが位置するフィールドのアプリケーション・データ構造体要素内のフラグをセットすることを示す。
ＳＴＯＲＡＧＥ
このオペランドの意味は、下記のように、アプリケーション・プログラムが記述された言語に依存する：
ＣＯＢＯＬプログラムの場合に、ＳＴＯＲＡＧＥ＝ＡＵＴＯは、マップセット内の記号記述マップが、ストレージの別々の（すなわち、再定義されない）区域を占めることを指定する。このオペランドは、記号記述マップが、作業記憶セクションにコピーされ、マップセット内の別々のマップのストレージが、並列に使用される時に使用される。
Ｃプログラムの場合に、ＳＴＯＲＡＧＥ＝ＡＵＴＯは、記号記述マップが、自動ストレージ・クラスを有するものとして定義されることを指定する。ＳＴＯＲＡＧＥ＝ＡＵＴＯが指定されない場合には、記号記述マップが、ポインタとして宣言される。同一のマップセットについてＢＡＳＥ＝ｎａｍｅとＳＴＯＲＡＧＥ＝ＡＵＴＯの両方を指定することはできない。
ＳＴＯＲＡＧＥ＝ＡＵＴＯが指定され、ＴＩＯＡＰＦＸが指定されない場合には、ＴＩＯＡＰＦＸ＝ＹＥＳが仮定される。
ＰＬ／Ｉプログラムの場合に、ＳＴＯＲＡＧＥ＝ＡＵＴＯは、記号記述マップが、ＡＵＴＯＭＡＴＩＣストレージ・クラスを有するものとして宣言されることを指定する。ＳＴＯＲＡＧＥ＝ＡＵＴＯが指定されない場合には、記号記述マップが、ＢＡＳＥＤとして宣言される。同一のマップセットについてＢＡＳＥ＝ｎａｍｅとＳＴＯＲＡＧＥ＝ＡＵＴＯの両方を指定することはできない。ＳＴＯＲＡＧＥ＝ＡＵＴＯが指定され、ＴＩＯＡＰＦＸが指定されない場合には、ＴＩＯＡＰＦＸ＝ＹＥＳが仮定される。
アセンブラ言語プログラムの場合に、ＳＴＯＲＡＧＥ＝ＡＵＴＯは、マップセット内の個々のマップが、互いにオーバーレイするのではなく、ストレージの別々の区域を占めることを指定する。
ＢＭＳＳｔａｔｅｍｅｎｔから派生する
プライベート属性：
Figure 2004506264
【０２９３】
ＢＭＳＦｉｅｌｄ
ＤＦＨＭＤＦマクロによって実装される。
ＧＲＰＮＡＭＥは、記号ストレージ定義を生成し、１つのグループ名の下で特定のフィールドを組み合わせるのに使用される名前である。同一のグループ名が、グループに属するフィールドごとに指定されなければならない。名前の長さは、３０文字までであるが、コンパイラ・マニュアルを参照して、長さに対する他の制約がないことを確認されたい。
このオペランドが指定される場合には、ＯＣＣＵＲＳオペランドを指定することはできない。
グループ内のフィールドは、連続しなければならない。グループ内のフィールドの間に、ギャップを置くことはできるが、グループの外からの他のフィールドは置けない。フィールド名は、グループに属するすべてのフィールドについて指定されなければならず、フィールドが互いに続くことを保証するために、ＰＯＳオペランドも指定されなければならない。グループのフィールドを定義するＤＦＨＭＤＦマクロのすべてが、一緒に配置されなければならず、正しい順序（ＰＯＳ値の数字の昇順）でなければならない。
たとえば、マップの最初の６行の最初の２０桁を、最初の５行の残りの桁がフィールドして定義されない限り、６フィールドのグループとして定義することができる。
グループの最初のフィールドに対して指定されるＡＴＴＲＢオペランドは、グループ内のすべてのフィールドに適用される。
ＬＥＮＧＴＨは、フィールドまたはフィールドのグループの長さ（１から２５６バイト）を指定する。この長さは、フィールドに入力されるアプリケーション・プログラム・データに必要な最大長さでなければならず、後続処理での使用のためにＣＩＣＳによってフィールドに付加される１バイト属性インジケータを含んではならない。１グループ内の各個々のサブフィールドの長さが、２５６バイトを超えてはならない。ＰＩＣＩＮまたはＰＩＣＯＵＴが指定される場合には、ＬＥＮＧＴＨを省略することができるが、それ以外の場合にはＬＥＮＧＴＨが必要である。ＤＦＨＭＤＦマクロでラベル（フィールド名）を省略する場合に限って、０の長さを指定することができる。すなわち、フィールドは、アプリケーション・データ構造体の一部ではなく、アプリケーション・プログラムが、フィールドの属性を変更することはできない。０の長さのフィールドを使用して、マップの入力フィールドを区切ることができる。
マップを定義するＤＦＨＭＤＩマクロのＳＩＺＥオペランドで指定されるマップ寸法は、端末に関して定義される実際のページ・サイズまたは画面サイズより小さいものにすることができる。
ＤＦＨＭＤＦマクロのＬＥＮＧＴＨ指定によって、同一行のマップによって定義される境界を超える場合には、出力画面のフィールドは、ラップによって継続される。
ＯＣＣＵＲＳは、フィールドの示された数の項目が、マップ内で生成されることと、フィールドが行列または配列の項目としてアドレス可能な形でマップ定義が生成されることを指定する。これによって、フィールドごとに一意の名前を生成せずに、複数のデータ・フィールドを同一の名前（添字付き）によってアドレッシングできるようになる。
ＯＣＣＵＲＳとＧＲＰＮＡＭＥは、相互に排他的である、すなわち、ＯＣＣＵＲＳは、フィールドがグループ名の下で定義された時には使用することができない。このオペランドが省略される場合には、ＯＣＣＵＲＳ＝１の値が仮定される。
ＰＩＣＩＮ（ＣＯＢＯＬおよびＰＬ／Ｉのみ）は、ＩＮマップまたはＩＮＯＵＴマップの入力フィールドに適用されるピクチャを指定する。このピクチャは、アプリケーション・プログラムに渡される編集指定として働き、したがって、ユーザがＣＯＢＯＬまたはＰＬ／Ｉの編集機能を利用できるようになる。ＢＭＳは、指定された文字がマップの言語の有効なピクチャ指定であることを検査する。
しかし、入力データの有効性は、マップが使用される時には、ＢＭＳまたは高水準言語によって検査されず、したがって、所望の検査のすべてを、アプリケーション・プログラムが実行しなければならない。「値」に関連するデータの長さは、ＬＥＮＧＴＨが指定される場合に、ＬＥＮＧＴＨオペランドで指定されるものと同一でなければならない。ＰＩＣＩＮとＰＩＣＯＵＴの両方が使用される場合には、その計算された長さが一致しない場合に、エラー・メッセージが作られ、２つの長さの短い方が使用される。フィールド定義についてＰＩＣＩＮまたはＰＩＣＯＵＴがコード化されない場合には、ＡＴＴＲＢ＝ＮＵＭなど、コード化される他のオペランドに無関係に、フィールドの文字定義が自動的に生成される。
注：ＣＯＢＯＬ入力マップの有効なピクチャ値は次の通りである：
Ａ Ｐ Ｓ Ｖ Ｘ ９ ／　および　（
ＰＬ／Ｉ入力マップの有効なピクチャ値は次の通りである：
Ａ Ｂ Ｅ Ｆ Ｇ Ｈ Ｉ Ｋ Ｍ Ｐ Ｒ Ｓ Ｔ Ｖ Ｘ Ｙ　および　Ｚ
１ ２ ３ ６ ７ ８ ９ ／ ＋ − ， ． ＊ ＄　および　（
ＰＬ／Ｉの場合に、通貨記号をピクチャ文字として使用することができる。この記号は、たとえば＜ＤＭ＞など、＜と＞に囲まれた文字の任意のシーケンスとすることができる。
ＰＩＣＴＵＲＥ属性の正しい構文については、適当な言語リファレンス・マニュアルを参照されたい。
ＰＩＣＯＵＴ（ＣＯＢＯＬおよびＰＬ／Ｉのみ）は、ＯＵＴマップまたはＩＮＯＵＴマップ内の出力フィールドに適用されるピクチャが生成されることを除いて、ＰＩＣＩＮに類似する。
ＣＯＢＯＬ出力マップの有効なピクチャ値は次の通りである：
Ａ Ｂ Ｅ Ｐ Ｓ Ｖ Ｘ Ｚ ０ ９ ， ． ＋ − ＄ ＣＲ ＤＢ ／　および　（
ＰＬ／Ｉ出力マップの有効なピクチャ値は次の通りである：
Ａ Ｂ Ｅ Ｆ Ｇ Ｈ Ｉ Ｋ Ｍ Ｐ Ｒ Ｓ Ｔ Ｖ Ｘ Ｙ　および　Ｚ
１ ２ ３ ６ ７ ８ ９ ／ ＋ − ， ． ＊ ＄ ＣＲ ＤＢ　および　（
ＰＬ／Ｉの場合、通貨記号をピクチャ文字として使用することができる。この記号は、たとえば＜ＤＭ＞など、＜と＞に囲まれた文字の任意のシーケンスとすることができる。
ＰＩＣＴＵＲＥ属性の正しい構文については、適当な言語リファレンス・マニュアルを参照されたい。
注：ＣＯＢＯＬは、ＰＩＣＴＵＲＥ指定で、複数の通貨符号および複数文字の通貨符号をサポートする。
デフォルト通貨記号は、ドル記号（＄）であり、これは国の通貨記号を表す；たとえば、ドル（＄）、ポンド（£）、または円（￥）。
デフォルトの通貨ピクチャ記号を、ＳＰＥＣＩＡＬ ＮＡＭＥＳ文節で定義された異なる通貨ピクチャ記号に置換することができる。ピクチャ記号によって表される通貨符号は、同一の文節で定義される。たとえば：
Figure 2004506264
１を超える長さの通貨符号に置換される、通貨記号を含むＣＯＢＯＬピクチャがＰＩＣＯＵＴで指定される場合に、ＬＥＮＧＴＨを指定しなければならない。
ＰＯＳは、フィールドの位置を指定する。このオペランドは、フィールドに先行する属性バイトが位置決めされる、マップ内の個々のアドレス可能文字位置を指定する。
Ｎｕｍｂｅｒは、定義されるマップの先頭からの変位（０に対する相対変位）を指定する。
（ｌｉｎｅ、ｃｏｌｕｍｎ）は、定義されるマップ内の行および桁（０に対する相対値）を指定する。
出力媒体上のデータの位置も、ＤＦＨＭＤＩオペランドに依存する。
フィールドの最初の位置は、属性バイトのために予約される。非３２７０装置からの入力マッピングについてデータを供給する時に、入力データは、この属性バイトのスペースを許容しなければならない。入力データは、桁１から開始してはならず、桁２から開始することができる。
ＰＯＳオペランドには、フィールド内の最初の位置の場所が含まれ、これは、通常は、３２７０と通信する時には属性バイトである。グループの２番目以降のフィールドでは、ＰＯＳオペランドが、実際の属性バイトが必要でない場合であっても、データの先頭の前の、仮定される属性バイト位置を指す。フィールドが、互いに直接に連続する場合には、ＰＯＳオペランドは、グループ内の前のフィールドの最後の文字位置を指さなければならない。
３２７０の最後の文字位置を表す位置番号が指定される時には、２つの特別な規則が適用される：
ＡＴＴＲＩＢ＝ＩＣをコード化してはならない。カーソルは、ＳＥＮＤ ＭＡＰコマンド、ＳＥＮＤＣＯＮＴＲＯＬコマンド、またはＳＥＮＤ ＴＥＸＴコマンドのＣＵＲＳＯＲオプションを使用することによって、位置０にセットすることができる。
フィールドが、ＳＥＮＤ ＭＡＰコマンドのＭＡＰ＝ＤＡＴＡＯＮＬＹを伴う出力マッピング動作に使用される場合には、そのフィールドの属性バイトが、アプリケーション・プログラムによって記号マップ・データ構造体で供給されなければならない。
ＰＳは、プログラム式記号が使用されることを指定する。これは、ＤＦＨＭＤＩマクロまたはＤＦＨＭＳＤマクロによってセットされるＰＳオペランドのすべてをオーバーライドする。
ＢＡＳＥは、デフォルトであり、基本記号セットが使用されることを指定する。
ｐｓｉｄは、使用されるプログラム式記号セットを識別する、単一のＥＢＣＤＩＣ文字、またはＸ’ｎｎ’の形の１６進コードを指定する。
ＰＳオペランドは、端末がプログラム式記号をサポートしない限り無視される。
ＳＯＳＩは、フィールドにＥＢＣＤＩＣデータとＤＢＣＳデータの混合が含まれる可能性があることを示す。ＥＢＣＤＩＣフィールド内のＤＢＣＳサブフィールドは、ＳＯ（シフト・アウト）文字およびＳＩ（シフト・イン）文字によって区切られる。ＳＯとＳＩの両方が、単一の画面位置を占める（通常はブランクとして表示される）。これらは、正しく対にされる場合に、出力の非ＤＢＣＳフィールドに含めることができる。端末ユーザは、これらがフィールドに既に存在する場合に、これらをインバウンドに送信できるが、これらをＥＢＣＤＩＣフィールドに追加できるのは、そのフィールドがＳＯＳＩ属性を有する場合に限られる。
ＴＲＡＮＳＰは、英数字フィールドの背景が透明または不透明のどちらであるか、すなわち、下にある（グラフィック）表示スペースが文字の間で可視であるかどうかを決定する。
ＢＭＳＳｔａｔｅｍｅｎｔから派生する
プライベート属性：
ａｔｔｒｉｂｕｔｅｓ ： ＢＭＳＡｔｔｒｉｂｕｔｅｓＴｙｐｅ
ｃａｓｅ ： ｂｏｏｌｅａｎ
ｃｏｌｏｒ ： ＢＭＳＣｏｌｏｒＴｙｐｅ
ｇｒｏｕｐ ： Ｓｔｒｉｎｇ
ｈｉｇｈｌｉｇｈｔｉｎｇ ： ＢＭＳＨｉｇｈｌｉｇｈｔｉｎｇＴｙｐｅ
ｉｎｉｔｉａｌＶａｌｕｅ ： Ｓｔｒｉｎｇ
ｊｕｓｔｉｆｙ ： ＢＭＳＪｕｓｔｉｆｙＴｙｐｅ
ｌｅｎｇｔｈ ： ｉｎｔ
ｏｃｃｕｒｓ ： ｉｎｔ
ｏｕｔｌｉｎｉｎｇ ： ＢＭＳＯｕｔｌｉｎｉｎｇＴｙｐｅ
ｐｉｃｔｕｒｅＩｎｐｕｔ ： Ｓｔｒｉｎｇ
ｐｉｃｔｕｒｅＯｕｔｐｕｔ ： Ｓｔｒｉｎｇ
ｐｏｓｉｔｉｏｎ ： ＢＭＳＰｏｓｉｔｉｏｎＴｙｐｅ
ｐｒｏｇｒａｍｍｅｄＳｙｍｂｏｌ ： Ｓｔｒｉｎｇ
ｓｈｉｆｔＯｕｔＳｈｉｆｔＩｎ ： Ｓｔｒｉｎｇ
ｔｒａｎｓｐａｒｅｎｔ ： ｂｏｏｌｅａｎ
ｖａｌｉｄａｔｉｏｎ ： ＢＭＳＶａｌｉｄａｔｉｏｎＴｙｐｅ
【０２９４】
ＢＭＳＳｔａｔｅｍｅｎｔ
プライベート属性：
ｌａｂｅｌ ： Ｓｔｒｉｎｇ
ｃｏｍｍｅｎｔｓ ： Ｓｔｒｉｎｇ
【０２９５】
総計：
１論理パッケージ
４クラス
論理パッケージ構造
論理ビュー
ｂｍｓ
【０２９６】
６．ｃ．ＩＭＳ　ＭＦＳ（メッセージ形式サービス）
図４３に、コネクタ・インターフェースを表すデータ構造体を定義するためにアプリケーション・プログラムによって使用可能なＭＦＳ言語メタモデルを示す。図４４に、ＭＦＳメタモデルのＴＤＬａｎｇＣｌａｓｓｉｆｉｅｒ、ＴＤＬａｎｇｕａｇｅＣｏｍｐｏｓｅｄＴｙｐｅ、およびＴＤＬａｎｇｕａｇｅＥｌｅｍｅｎｔである、ＭＦＳメタモデルとＴＤＬａｎｇ基本クラスの間の関連を示す。図４５、および図４６に、ＭＦＳメタモデルのＭｏｄｅＶａｌｕｅｓ、ＢａｓｅＶａｌｕｅｓ、ＬｅｎｇｔｈＴｙｐｅｓ、およびＳｔｒｉｎｇＴｙｐｅＶａｌｕｅｓの列挙を示す。
【０２９７】
ＭＦＳのパッケージ文書化
下記の装置がサポートされる：
−　３２７０および３２７０−Ａｎ
−　３２７０Ｐ
下記の装置タイプはサポートされない：
−　２７４０または２７４１
−　３６００または４７００
−　ＦＩＮ
−　ＦＩＤＳ、ＦＩＤＳ３、ＦＩＤＳ４、またはＦＩＤＳ７
−　ＦＩＪＰ、ＦＩＰＢ、またはＦＩＦＰ
−　ＳＣＳ１
−　ＳＣＳ２
−　ＤＰＭ−Ａｎ
−　ＤＰＭ−Ｂｎ
パーサを介して暗黙のうちにサポートされるステートメント：
−　ＡＬＰＨＡ
−　ＣＯＰＹ
−　ＤＯ
−　ＥＮＤ
−　ＥＮＤＤＯ
−　ＥＱＵ
−　ＦＭＴＥＮＤ
−　ＭＳＧＥＮＤ
−　ＲＥＳＣＡＮ
−　ＴＡＢＬＥＥＮＤ
許容されるステートメント：
−　ＥＪＥＣＴ
−　ＰＤ
−　ＰＤＢ
−　ＰＤＢＥＮＤ
−　ＰＰＡＧＥ
−　ＰＲＩＮＴ
−　ＲＣＤ
−　ＳＰＡＣＥ
−　ＳＴＡＣＫ
−　ＴＩＴＬＥ
−　　ＵＮＳＴＡＣＫ
−
【０２９８】
ＭＦＳＤｅｖｉｃｅＴｙｐｅ
ＤＥＶステートメント
ＤＥＶステートメントでは、特定の装置の装置特性または特定の装置タイプのデータ・フォーマットを定義する。このＤＥＶステートメントに続くＤＦＬＤステートメントは、次のＤＥＶステートメントまたはＦＭＴＥＮＤステートメントに出会うまで、指定された特性を使用してマッピングされる。
サポートされない属性：
−　ＥＲＡＳＥ
−　ＦＴＡＢ
−　ＦＯＲＭＳ
−　ＨＴ
−　ＨＴＡＢ
−　ＬＤＥＬ
−　ＭＯＤＥ
−　ＳＬＤ
−　ＶＥＲＳＩＤ
−　ＶＴ
−　ＶＴＡＢ
ＭＦＳＳｔａｔｅｍｅｎｔから派生する
プライベート属性：
ｃａｒｄ ： Ｓｔｒｉｎｇ
ＣＡＲＤ属性
データが入力される時にオペレータＩＤカード・データを受け取る入力フィールド名を定義する。この名前は、ＭＦＬＤステートメントによって参照することができ、このＤＥＶ定義内のＤＦＬＤステートメントのラベルとして使用してはならない。このオペランドは、３２７０ディスプレイが指定される場合に限って有効である。３２７０ディスプレイについてＦＥＡＴ＝ＮＯＣＤが指定される場合には、ＦＥＡＴがＣＡＲＤに変更される。このカード・フィールド名を参照する入力ＭＦＬＤにデータが提示される前に、すべての制御文字が磁気カード入力から除去される。
３２７０ディスプレイについて、磁気カード・データおよび制御文字を含むのに十分に大きい無保護フィールドが、ＤＦＬＤステートメントを介して定義されなければならない。カーソルをこのフィールドに位置決めし、カードをリーダに挿入して、カード情報を入力する。カード・データは、ＤＦＬＤステートメントで使用される名前ではなく、ＣＡＲＤ＝フィールド名に論理的に関連付けられる。
ｄｓｃａ ： Ｓｔｒｉｎｇ
ＤＳＣＡ属性
この装置フォーマットを使用する出力メッセージのデフォルト・システム制御域（ＤＳＣＡ）を指定する。ＤＳＣＡは、メッセージ出力記述子で指定されたＳＣＡと衝突する場合に、そのようなＳＣＡを取り替える。通常、両方のＳＣＡで指定された機能が実行される。ＤＳＣＡ＝のオペランドが３２７０Ｐについて指定される場合には、「音響装置警告」のビット設定を除いて、そのオペランドが無視される。このビットがＤＳＣＡ／ＳＣＡオプションで指定される場合には、そのビットが装置に送られる。
ここで指定される値は、６５５３５またはＸ’ｆｆｆｆ’を超えない１０進数でなければならない。その数が指定される場合には、その数は、内部でＸ’ｆｆｆｆ’に変換される。
３２７５ディスプレイに関して、バイト１のビット５にＢ’１’（無保護画面オプション）がセットされ、入力および出力の両方が、同時に発生する場合（競合）には、装置が切断される。非３２７５装置では、ＳＣＡオプションが無視される。バイト１のビット５にＢ’０’がセットされる場合には、アプリケーション・プログラムが、ＳＣＡ値にＢ’１’をセットすることによって、自動ページングされた出力を要求することができる。この要求は、出力メッセージの最初のＬＰＡＧＥの最初のセグメントに存在する場合に限って順守される。
バイト０について、またはバイト１のビット６または７について、ゼロ以外の値が指定される場合に、ＭＦＳは、指定された値を０でオーバーライドする。
ｆｅａｔｕｒｅｓ ： ＭＦＳＦｅａｔｕｒｅＴｙｐｅ
ＦＥＡＴ属性
この装置またはプログラム・グループの機能を指定する。
ＩＧＮＯＲＥ
装置機能が、この装置について無視されることを指定する。
１２０｜１２６｜１３２
３２８４および３２８６装置タイプ（ＴＹＰＥ＝３２７０Ｐ）にいて行の長さを指定する。
ＣＡＲＤ
装置が３２７０オペレータＩＤカード・リーダを有することを指定する。ＮＯＣＤは、ＣＡＲＤ機能がないことを指定する。
ＤＥＫＹＢＤ
データ入力キーボード機能を指定する。この機能は、ＰＦＫ機能を暗示し、したがって、ＰＦＫは、ＤＥＫＹＢＤが指定される場合には無効である。ＮＯＰＦＫは、ＰＦＫ機能およびＤＥＫＹＢＤ機能の不在を暗示する。
ＰＦＫ
装置がプログラム・ファンクション・キーを有することを指定する。ＮＯＰＦＫは、ＰＦＫ機能およびＤＥＫＹＢＤ機能の不在を暗示する。
ＰＥＮ
選択ライト・ペン検出機能を指定する。ＮＯＰＥＮは、ＰＥＮ機能の不在を指定する。
１｜２｜３｜４｜５｜６｜７｜８｜９｜１０
３２７０Ｐ装置タイプの顧客定義機能を指定する。
３２７０Ｐ装置について、ＦＥＡＴ＝によって、特殊な装置特性を有する装置のグループ化が可能になる。たとえば、ＦＥＡＴ＝１によって、最大８０個の印刷位置を有しＶＦＣを有しない装置をグループ化することができ、ＦＥＡＴ＝２によって１３２個の印刷位置とＶＦＣ機能を備える装置をグループ化することができる。ＦＥＡＴ＝ＩＧＮＯＲＥは、装置機能の最小限の組を有する装置を一緒にグループ化するために指定されなければならない。ＷＩＤＴＨ＝が指定される時には、ＦＥＡＴ＝（１…１０）も指定されなければならない。ＦＥＡＴ＝（１…１０）が指定され、ＷＩＤＴＨ＝が指定されない場合に、ＷＩＤＴＨ＝のデフォルトは１２０になる。
ＩＧＮＯＲＥが指定される時には、他の値をＦＥＡＴ＝オペランドにコピーしてはならない。システム定義中にＴＥＲＭＩＮＡＬマクロでＦＥＡＴ＝ＩＧＮＯＲＥが指定されない時には、ＭＳＧステートメントで、装置フォーマットのＳＯＲ＝オペランドでＩＧＮＯＲＥ指定を用いてＩＧＮＯＲＥを指定しなければならない。ＦＥＡＴ＝ＩＧＮＯＲＥが使用されない限り、ＦＥＡＴ＝では、ＩＭＳシステム定義中にＴＥＲＭＩＮＡＬマクロで指定されたものを正確に指定しなければならない。そうでない場合には、ＤＦＳ０５７エラー・メッセージが発行される。３２７０装置についてＦＥＡＴ＝ＩＧＮＯＲＥまたは１から１０が指定される時には、まだオペランドＰＥＮ＝、ＣＡＲＤ＝、およびＰＦＫ＝を指定することができる。ＴＹＰＥ＝３２７０ＰかつＦＥＡＴ＝ＩＧＮＯＲＥの時には、ＭＦＳが、１２０文字の行幅を可能にする。
ＣＡＲＤ、ＰＦＫ、ＤＥＫＹＢＤ、およびＰＥＮの機能値は、３２７０ディスプレイだけについて有効である。ＦＥＡＴ＝オペランドが省略される場合には、デフォルト機能は、３２７０ディスプレイについてはＣＡＲＤ、ＰＦＫ、およびＰＥＮになり、デフォルトの行幅は、ＴＹＰＥ＝３２７０Ｐについて１２０である。
１、２、３、４、５、６、７、８、９、および１０は、３２７０、３２７０Ｐ、および３２７０−Ａｎに限って有効な値である。３２７０ディスプレイに関して、１から５までのＦＥＡＴ＝指定を使用して、特定の機能またはハードウェア・データ・ストリーム依存性を有する装置をグループ化することができる。
制約：このキーワードは、任意選択であり、３２７０ディスプレイの他の特徴指定と共に使用することはできない。
機能オペランド値は、任意の順序で、指定される必要が所望される値だけを、指定することができる。各垂直リストで１つの値だけを指定することができる。
ｐａｇｅ ： ＭＦＳＰａｇｅＴｙｐｅ
ＰＡＧＥ属性
下記のように出力パラメータを指定する：
ｎｕｍｂｅｒ
プリンタ装置について、Ｎｕｍｂｅｒによって、印刷されるページ上の印刷行数が定義され、カード装置について、Ｎｕｍｂｅｒによって、ＤＰＡＧＥまたは物理ページ（ＤＦＬＤステートメントでｐｐパラメータが使用される場合）ごとに穿孔されるカードの数が定義される。この値は、有効性検査に使用される。指定される数は、１以上２５６未満でなければならない。デフォルトは５５である。
ＤＥＦＮ
ＤＦＬＤステートメントによる定義で行／カードが印刷／穿孔されることを指定する（行／カードは、除去されず、出力ページに追加されない）。
ＳＰＡＣＥ
各出力ページに、Ｎｕｍｂｅｒパラメータで指定された正確な数の行／カードが含まれることを指定する。
ＦＬＯＡＴ
フォーマットが削除された後のデータがない行／カード（すべてブランクまたはＮＵＬＬ）を指定する。
３２７０Ｐ装置の場合に、データを有しない（すなわち、すべてブランクまたはヌル）いくつかの行を、下記の情況で削除してはならない。
行に、１つまたは複数の行密度設定（ＳＬＤｘ＝）指定が含まれる。
拡張属性を有すると指定されたフィールドが、複数の行にまたがる。
ｐｅｎ ： Ｓｔｒｉｎｇ
ＰＥＮ属性
スペースまたはヌル指定文字を有するフィールドの即時ライト・ペン検出が行われる時に、リテラル・データが格納される入力フィールド名を定義する。リテラル・データは、ＰＥＮ＝オペランドのＤＦＬＤステートメントで定義される（ＤＦＬＤステートメントについてはＰＥＮ＝オペランドを参照されたい）。この名前は、ＭＦＬＤステートメントによって参照される可能性があり、このＤＥＶ定義内のＤＦＬＤステートメントのラベルとして使用してはならない。ＰＥＮ＝オペランドは、３２７０ディスプレイのみについて有効である。ＦＥＡＴ＝ＮＯＰＥＮが指定された場合に、ＦＥＡＴがＰＥＮに変更される。
スペースまたはヌル指定文字を用いて定義されたフィールドに対して即時検出が行われ、もう１つのフィールドが、選択されるか修正されるかＭＯＤ属性を有するか、ＰＥＮ＝オペランドが、ＤＦＬＤに関して定義されていない場合に、疑問符（？）がＰＥＮ＝フィールド名に挿入される。
即時検出が行われないか、アンパサンド（＆）指定文字を用いて定義されたフィールドに対して即時検出が行われる場合には、ＰＥＮ＝オペランドが、ＭＦＬＤステートメントで指定された充てんによって埋め込まれる。
ｐｆｋ ： ＭＦＳＦｕｎｃｔｉｏｎＫｅｙＴｙｐｅ
ＰＦＫ属性
プログラム・ファンクション・キー・リテラルまたは制御機能データを含む入力フィールド名（第１サブパラメータ）と、位置フォーマットまたはキーワード・フォーマットで、指定されたフィールドに配置されるリテラル・データ、または対応するファンクション・キーが押された時に実行される制御機能のいずれか（残りのサブパラメータ）を定義する。
第１サブパラメータの名前（プログラム・ファンクション・キー・リテラルまたは制御機能データを含む入力フィールド名）は、ＭＦＬＤステートメントによって参照される可能性があり、このＤＥＶ定義内のＤＦＬＤステートメントのラベルとして使用してはならない。残りのサブパラメータは、位置フォーマットまたはキーワード・フォーマットで指定することができる。サブパラメータが、キーワード・フォーマットの場合に、指定される整数は、両端を含めて１から３６までであり、重複してはならない。１つのＰＦＫ＝オペランド・フォーマット（位置またはキーワード）だけを、１つのＤＥＶステートメントで指定することができる。このオペランドは、３２７０ディスプレイのみについて有効である。実際のフォーマット・ブロックが作成される時に、各リテラルは、リスト内の最長のリテラルの長さまで、右側にブランクを埋め込まれる。最大リテラル長は、２５６バイトである。
装置が、ＩＭＳコピー機能をサポートする場合に、ＰＦＫ１２が、コピー機能を呼び出し、ＤＥＶステートメントのＰＦＫ１２の定義は無視され、そうでない場合には、ＰＦＫ１２の定義に従う。
ＦＥＡＴ＝ＮＯＰＦＫが指定される場合には、ＦＥＡＴがＰＦＫに変更される。ユーザ定義ＰＦＫの最大個数は、３６である。
指定することができる制御機能は、次の通りである：
ＮＥＸＴＰＰ−−ＰＡＧＥ ＡＤＶＡＮＣＥ
現在の出力メッセージの次の物理ページの要求を指定する。進行中の出力メッセージがない場合には、明示的な応答は行われない。
ＮＥＸＴＭＳＧ−−ＭＥＳＳＡＧＥ ＡＤＶＡＮＣＥ
進行中の出力メッセージ（ある場合に）を待機解除し、次の出力メッセージ（ある場合に）をキューに送る要求を指定する。
ＮＥＸＴＭＳＧＰ−−ＭＥＳＳＡＧＥ ＡＤＶＡＮＣＥ ＰＲＯＴＥＣＴ
進行中の出力メッセージ（ある場合に）を待機解除し、次の出力メッセージを送るか、次のメッセージが存在しないことを示す情報メッセージを返す要求を指定する。
ＮＥＸＴＬＰ−−ＮＥＸＴ ＬＯＧＩＣＡＬ ＰＡＧＥ
現在のメッセージの次の論理ページの要求を指定する。
ＥＮＤＭＰＰＩ−−ＥＮＤ ＭＵＬＴＩＰＬＥ ＰＡＧＥ ＩＮＰＵＴ
複数の物理ページ入力メッセージの終りを指定する。
ｓｕｂｓｔｉｔｕｔｉｏｎ ： Ｓｔｒｉｎｇ
ＳＵＢ属性
入力データ・ストリーム内のすべてのＸ’３Ｆ’文字を置換するのにＭＦＳが使用する文字を指定する。このパラメータが、Ｘ’３Ｆ’として指定されるか、パラメータが指定されないか、受け取られる入力がＭＦＳ編集を迂回する場合には、変換は行われない。指定されたＳＵＢ文字は、データ・ストリームのどこにも現れてはならず、したがって、非グラフィックでなければならない。
Ｘ’ｆｆ’
その１６進数表現が’ｆｆ’である文字によって、入力データ・ストリームのすべてのＸ’３Ｆ’が置換される。
Ｃ’ｃ’
文字’ｃ’によって、入力データ・ストリームのすべてのＸ’３Ｆ’が置換される。
ｔｙｐｅ ： Ｓｔｒｉｎｇ
ＴＹＰＥ属性
このフォーマット記述を使用する装置タイプおよび装置のモデル番号を指定する。３２７５に接続された３２８４−３プリンタは、ＴＹＰＥ＝３２７０Ｐとしてのみサポートされる。３２８４−３のフォーマットを定義する時に指定されるモデル番号は、関連する３２７５のモデル番号である。
ＴＹＰＥ＝３２７０−Ａｎは、ＩＭＳシステム定義中に定義される画面サイズと機能番号ｎ＝１−１５を有する３２７０およびＳＬＵ　２ディスプレイの記号名を指定する。この指定によって、ＭＦＳ言語ユーティリティが、ＭＦＳ装置特性テーブル（ＤＦＳＵＤＴ０ｘ）を読み取り、画面サイズを抽出する。
ｗｉｄｔｈ ： ｉｎｔ
ＷＩＤＴＨ属性
このＤＥＶタイプの最大行幅を、下記の１つとして指定する：
−　入力データまたは出力データの行ごとの印刷位置の数
−　入力データまたは出力データのカードごとの穿孔位置の数
−　カード・リーダ入力データのカード幅
デフォルトは、３２７０Ｐ出力の１２０である。行幅は、ＨＴＡＢ＝キーワードで左マージン値が指定されるかどうかに無関係に、桁１に対して相対的に指定される。指定される幅は、１以上でなければならない。
３２７０Ｐ装置について、ＷＩＤＴＨが指定される場合に、ＦＥＡＴ＝（１…１０）も指定されなければならない。ＦＥＡＴ＝（１…１０）が指定され、ＷＩＤＴＨ＝が指定されない場合に、ＷＩＤＴＨ＝のデフォルトは１２０になる。
【０２９９】
ＭＦＳＭｅｓｓａｇｅＤｅｓｃｒｉｐｔｏｒ
ＭＳＧステートメント
ＭＳＧステートメントは、メッセージ入力定義またはメッセージ出力定義を開始し、命名する。
サポートされない属性：
−　すべての属性がサポートされる
ＭＦＳＳｔａｔｅｍｅｎｔから派生する
プライベート属性：
ｆｉｌｌ ： Ｓｔｒｉｎｇ
ＦＩＬＬ属性
出力装置フィールドの充てん文字を指定する。このオペランドは、ＴＹＰＥ＝ＯＵＴＰＵＴの場合に限って有効である。デフォルトは、Ｃ’　’である。充てん指定は、ＦＭＴ定義のＤＰＡＧＥステートメントでＦＩＬＬ＝ＮＯＮＥが指定されない限り無視される。ＥＧＣＳフィールドが存在する時の３２７０出力に関して、ＦＩＬＬ＝ＰＴまたはＦＩＬＬ＝ＮＵＬＬだけを指定しなければならない。ＦＩＬＬ＝ＰＴでは、データがフィールドに送られる時に限って出力フィールド（１バイト・フィールドまたは２バイト・フィールドのいずれか）を消去し、したがって、アプリケーション・プログラム・メッセージがＭＦＬＤを省略する場合に、ＤＦＬＤを消去しない。
Ｃ’ｃ’
文字’ｃ’が、装置フィールドを充てんするのに使用される。３２７０表示装置について、Ｘ’３Ｆ’未満の値を伴う指定のすべてが、制御文字は’００’、他の非グラフィック文字はＸ’４０’に変更される。すべての他の装置について、Ｘ’３Ｆ’未満の値を伴うＦＩＬＬ＝Ｃ’ｃ’指定のすべてが、無視され、デフォルトのＸ’３Ｆ’にされる（ＦＩＬＬ＝ＮＵＬＬの指定と同等である）。
ＮＵＬＬ
フィールドが充てんされないことを指定する。
ＰＴ
３２７０ディスプレイを除いてＮＵＬＬと同等である。３２７０ディスプレイについて、ＰＴは、装置フィールド（ＤＦＬＤ）を充てんしない出力フィールドに、前にフィールド内にあったデータを消去するために、プログラム・タブ文字が続くことを指定する。
ｉｇｎｏｒｅＳｏｕｒｃｅ ： ｂｏｏｌｅａｎ
ＳＯＲ属性
ＤＥＶステートメントと共に、このメッセージ記述子によって処理される端末またはリモート・プログラムのデータ・フィールドを定義する、ＦＭＴステートメントのソース名を指定する。ＴＹＰＥ＝ＯＵＴＰＵＴについてＩＧＮＯＲＥを指定すると、ＭＦＳが、装置フォーマット定義でそのＦＥＡＴ＝オペランドによってＩＧＮＯＲＥが指定される装置に関して指定されるデータ・フィールドが使用されるようになる。ＴＹＰＥ＝ＩＮＰＵＴの場合、ＩＧＮＯＲＥは、対応するメッセージ出力記述子でＩＧＮＯＲＥが指定される場合に限って指定しなければならない。ＳＯＲ＝ＩＧＮＯＲＥを使用する場合には、メッセージ入力記述子とメッセージ出力記述子の両方でＩＧＮＯＲＥを指定しなければならない。
ｏｐｔｉｏｎ ： ｉｎｔ
ＯＰＴ属性
メッセージを編集するためにＭＦＳによって使用されるメッセージ・フォーマット・オプションを指定する。デフォルトは、１である。
ｐａｇｉｎｇ ： ｂｏｏｌｅａｎ
ＰＡＧＥ属性
オペレータ論理ページング（順方向および逆方向のページング）が、この制御ブロックを使用して編集されるメッセージについて提供されるか（ＹＥＳ）否か（ＮＯ）を指定する。このオペランドは、ＴＹＰＥ＝ＯＵＴＰＵＴの場合に限って有効である。デフォルトはＮＯであり、これは、物理ページの順方向ページングだけが提供されることを意味する。
ｔｙｐｅ ： ＭＦＳＤｅｓｃｒｉｐｔｏｒＴｙｐｅ
ＴＹＰＥ属性
この定義をメッセージＩＮＰＵＴ制御ブロックまたはメッセージＯＵＴＰＵＴ制御ブロックとして定義する。デフォルトはＩＮＰＵＴである。
【０３００】
ＭＦＳＬｏｇｉｃａｌＰａｇｅ
ＬＰＡＧＥステートメント
任意選択のＬＰＡＧＥステートメントでは、論理ページを含むセグメントのグループが定義される。存在しない場合には、暗黙指定される。
サポートされない属性：
−　すべての属性がサポートされる
ＭＦＳＳｔａｔｅｍｅｎｔから派生する
プライベート属性：
ｃｏｎｄｉｔｉｏｎ ： ＭＦＳＣｏｎｄｉｔｉｏｎＴｙｐｅ
ＣＯＮＤ属性
成功の場合に、このＬＰＡＧＥに従うセグメント定義およびフィールド定義が、この論理ページの出力編集に使用されることを指定する条件テストを記述する。このＬＰＡＧＥを編集に使用するかどうかを判定するために、論理ページの最初のセグメントの指定された部分が、指定されたリテラル値より大きい（＞）、より小さい（＜）、以上（＜＝）、以下（＞＝）、等しい（＝）、等しくない（ｎｅ）かどうかを判定するために検査される。ＣＯＮＤ＝は、ＭＳＧ定義の最後のＬＰＡＧＥステートメントには不要である。
検査される区域は、フィールド名（ｍｆｌｄｎａｍｅ）、フィールド内のオフセット（ｍｆｌｄｎａｍｅ（ｐｐ）、このｐｐは、名前を指定されたフィールド内のオフセットである）、またはセグメント内のオフセット（ｓｅｇｏｆｆｓｅｔ）によって定義することができる。ｍｆｌｄｎａｍｅ（ｐｐ）形式が使用される場合には、ｐｐは、１以上でなければならない。比較の長さは、指定されたリテラルの長さである。前のＭＳＧステートメントでＯＰＴ＝３が指定される場合には、検査される区域が、ＭＦＬＤステートメントで定義される１フィールド以内でなければならない。
ｓｅｇｏｆｆｓｅｔが使用される場合に、これは０に対する相対値であり、そのオフセットの指定は、セグメントのＬＬＺＺを考慮しなければならない（すなわち、最初のデータ・バイトがオフセット４にある）。
ｐｐが使用される場合に、オフセットは、名前を指定されたフィールドに関して１に対する相対値である（すなわち、フィールド内の最初のバイトが、０ではなくオフセット１にある）。指定されるｍｆｌｄｎａｍｅがＡＴＴＲ＝ＹＥＳを用いて定義されている場合には、ｐｐオフセットを使用しなければならない。指定される最小オフセットは、３でなければならない。すなわち、フィールド内のデータの最初のバイトが、２バイトの属性に続いて、オフセット３にある。
ＡＴＴＲ＝ｎｎが指定される場合には、最小オフセットは、１にｎｎの２倍を加えたものでなければならない。したがって、ＡＴＴＲ＝２が指定される場合には、ｐｐは少なくとも５でなければならず、ＡＴＴＲ＝（ＹＥＳ，２）が指定される場合には、ｐｐは少なくとも７でなければならない。
すべてのＬＰＡＧＥに関する条件テストが失敗した場合に、このＭＳＧ定義の最後のＬＰＡＧＥが、編集に使用される。
ＬＰＡＧＥ選択が、コマンド・データ・フィールドを使用して指定される、すなわち、／ＦＯＲＭＡＴｍｏｄｎａｍｅ…（データ）である場合には、ＬＰＡＧＥ ＣＯＮＤ＝ｍｆｌｄｎａｍｅパラメータで指定されるＭＦＬＤが、ＭＯＤの関連するＬＰＡＧＥの最初の８バイト以内でなければならない。
ｐｒｏｍｐｔＶａｌｕｅ ： Ｓｔｒｉｎｇ
【０３０１】
ＬＰＡＧＥ ＣＯＮＤ＝ｍｆｌｄｎａｍｅ
ＳＥＧステートメント
ＳＥＧステートメントは、メッセージ・セグメントの輪郭を描き、複数セグメント・メッセージ処理がアプリケーション・プログラムによって要求される場合に限って必要である。出力メッセージ・セグメントは、ユーザが指定したキュー・バッファ長を超えることができない。入力メッセージ宛先が単一のセグメント・コマンドまたはトランザクションとして定義される時に、ＴＹＰＥ＝ＩＮＰＵＴ ＭＳＧについて、１つのセグメントだけを定義しなければならない。複数のセグメントが定義され、その定義が、単一のセグメント・コマンドまたはトランザクションを入力するのに指定される場合には、ユーザ入力が、編集後に１つのセグメントだけを作るようにするために注意しなければならない。存在しない場合には暗黙指定される。
サポートされない属性：
−　すべての属性がサポートされる
ＭＦＳＳｔａｔｅｍｅｎｔから派生する
プライベート属性：
ｅｘｉｔ ： ＭＦＳＥｘｉｔＴｙｐｅ
ＥＸＩＴ属性
このメッセージ・セグメントのセグメント編集出口ルーチン・インターフェースを記述する。ｅｘｉｔＮｕｍは、出口ルーチン番号であり、ｅｘｉｔｖｅｃｔは、このセグメントのために出口ルーチンが呼び出される時に出口ルーチンに渡される値である。ｅｘｉｔＮｕｍは、０から１２７までの範囲とすることができる。ｅｘｉｔｖｅｃｔは、０から２５５までの範囲とすることができる。この入力セグメントについて処理が完了した時に、ＳＥＧ出口が呼び出される。
ｇｒａｐｈｉｃ ： ｂｏｏｌｅａｎ
ＧＲＡＰＨＩＣ属性
ＭＳＧ ＴＹＰＥ＝ＩＮＰＵＴについて、宛先定義が大文字変換を要求する場合に、ＩＭＳがこのセグメントに対して大文字変換を実行するか（ＹＥＳ）否か（ＮＯ）を指定する（ＴＲＡＮＳＡＣＴまたはＮＡＭＥマクロのＥＤＩＴ＝パラメータを参照されたい）。デフォルトはＹＥＳである。入力セグメント・データが、非グラフィック・フォーマット（パック１０進、ＥＧＣＳ、２進、など）の場合には、ＧＲＡＰＨＩＣ＝ＮＯを指定しなければならない。ＧＲＡＰＨＩＣ＝ＮＯが指定される時に、このセグメント内のＭＦＬＤについて、ＦＩＬＬ＝ＮＵＬＬは無効である。
下のリストに、ＧＲＡＰＨＩＣ＝ＹＥＳが指定され、入力メッセージ宛先が、大文字変換を要求するものとして定義される時に行われる変換を示す：
Figure 2004506264
ＧＲＡＰＨＩＣ＝ＹＥＳとして定義されたセグメント内のＭＦＬＤについてＦＩＬＬ＝ＮＵＬＬが指定される場合に、１６進文字Ｘ’３Ｆ’が、セグメントから圧縮される。ＳＥＧステートメントでＧＲＡＰＨＩＣ＝ＮＯおよびＦＩＬＬ＝ＮＵＬＬが指定される場合に、非グラフィック・データ・ストリームのすべてのＸ’３Ｆ’が、セグメントから圧縮され、望ましくない結果が作られる可能性がある。非グラフィック・データは、固定長出力フィールドとして出力に送られなければならず、この場合にはＦＩＬＬ＝ＮＵＬＬの使用は推奨されない。
ＭＳＧ ＴＹＰＥ＝ＯＵＴＰＵＴについて、ＧＲＡＰＨＩＣ＝キーワードは、ＤＰＭだけに適用される。これは、ＩＭＳアプリケーション・プログラムからのデータ内の非グラフィック制御文字（Ｘ’００’からＸ’３Ｆ’まで）が、ブランクに置換されるか（ＹＥＳ）否か（ＮＯ）を指定する。デフォルト値はＹＥＳである。ＮＯが指定される場合に、ＭＦＳは、ＩＭＳアプリケーション・プログラムから受け取るビット・ストリングのすべてが、ＭＦＳを介してリモート・プログラムに無変更で流れられるようにする。
制約：ＧＲＡＰＨＩＣ＝ＮＯが指定される時に、Ｏｐｔｉｏｎｓ １および２を使用するＩＭＳアプリケーション・プログラムは、ＬＰＡＧＥの途中でセグメントを省略するか、ヌル文字（Ｘ’３Ｆ’）を使用してセグメント内のフィールドを切り捨てるか省略することができない。
【０３０２】
ＭＦＳＭｅｓｓａｇｅＦｉｅｌｄ
ＭＦＬＤステートメント
ＭＦＬＤステートメントでは、メッセージ出力セグメントの一部としてアプリケーション・プログラムに提示されるメッセージ・フィールドを定義する。ＭＳＧ定義ごとに、少なくとも１つのＭＦＬＤステートメントを指定しなければならない。
サポートされない属性：
−　すべての属性がサポートされる
ＭＦＳＳｔａｔｅｍｅｎｔから派生する
プライベート属性：
ａｔｔｒｉｂｕｔｅｓ ： ｂｏｏｌｅａｎ
ＡＴＴＲ属性
アプリケーション・プログラムが３２７０属性および拡張属性（ｎｎ）を修正できるか（ＹＥＳ）否か（ＮＯ）を指定する。
ＹＥＳの場合には、２バイトを、出力にアプリケーション・プログラムが充てんし、入力時にブランクに初期化される３２７０属性データとして予約しなければならない。これらの２バイトは、ＬＴＨ＝指定に含まれなければならない。
ｎｎに指定される値は、動的に修正することができる拡張属性の数である。ｎｎの値は、１から６までの数とすることができる。無効な指定は、デフォルトの１になる。属性ごとに２つの追加バイトが、出力時にアプリケーション・プログラムによって充てんされ、入力時に空白に初期化される拡張属性データのために予約されなければならない。この属性バイトは、ＭＦＬＤ　ＬＴＨ＝指定に含まれなければならない。
例：下に示されているのは、ＡＴＴＲ＝の有効な指定と、異なる指定ごとに予約されなければならないバイト数である。
ＭＦＬＤ，ＡＴＴＲ＝（ＹＥＳ，ｎｎ）
２＋（２×ｎｎ）
ＭＦＬＤ，ＡＴＴＲ＝（ＮＯ，ｎｎ）
２×ｎｎ
ＭＦＬＤ，ＡＴＴＲ＝（ｎｎ）
２×ｎｎ
ＭＦＬＤ，ＡＴＴＲ＝ＹＥＳ
２
ＭＦＬＤ，ＡＴＴＲ＝ＮＯ
０
ＡＴＴＲ＝ＹＥＳおよびｎｎは、出力メッセージで位置パラメータを介してリテラル値が指定された場合には無効である。
別のＩＭＳ　ＩＳＣサブシステムに送られるフィールドの属性は、受け取るサブシステムのフォーマットでのＡＴＴＲ＝指定に無関係に、ＭＦＳによって入力データとして扱われる。たとえば、ＡＴＴＲ＝（ＹＥＳ，１）、ＬＴＨ＝５として定義されたメッセージ・フィールド（ＭＦＬＤ）に、下記が含まれる：
００Ａ０Ｃ２Ｆ１Ｃ８Ｃ５Ｄ３Ｄ３Ｄ６
受け取るサブシステムのＭＦＬＤが、ＡＴＴＲ＝なしでＬＴＨ＝９として定義される場合には、アプリケーション・プログラムが、下記を受け取る：
００Ａ０Ｃ２Ｆ１Ｃ８Ｃ５Ｄ３Ｄ３Ｄ６
受け取るサブシステムのＭＦＬＤが、ＬＴＨ＝１３およびＡＴＴＲ＝（ＹＥＳ，１）として定義される場合には、アプリケーション・プログラムが、下記を受け取る：
４０４０４０４０００Ａ０Ｃ２Ｆ１Ｃ８Ｃ５Ｄ３Ｄ３Ｄ６
受け取るサブシステムのＭＦＬＤが、ＬＴＨ＝５およびＡＴＴＲ＝（ＹＥＳ，１）として定義される場合には、アプリケーション・プログラムが、下記を受け取る：
４０４０４０４０００Ａ０Ｃ２Ｆ１Ｃ８
入力ＳＥＧステートメントは、属性データの大文字への変換を避けるために、ＧＲＡＰＨＩＣ＝ＮＯとして指定されなければならない。
ｅｘｉｔ ： ＭＦＳＥｘｉｔＴｙｐｅ
ＥＸＩＴ属性
このメッセージ・フィールドのフィールド編集出口ルーチン・インターフェースを記述する。出口ルーチン番号は、ｅｘｉｔＮｕｍで指定され、ｅｘｉｔｖｅｃｔは、出口ルーチンがこのフィールドについて呼び出される時に出口ルーチンに渡される値である。ｅｘｉｔＮｕｍの値は、０から１２７までの範囲とすることができる。ｅｘｉｔｖｅｃｔの値は、０から２５５までの範囲とすることができる。ＭＦＳ編集後（オプション１および２に関するＮＵＬＬ圧縮の前）に存在するフィールドのアドレスが、そのフィールドについて定義されたベクトルと共に、編集出口ルーチンに渡される（ＤＰＭ装置についてＮＯＦＬＤＥＸＩＴが指定される場合には、出口ルーチンは呼び出されない）。出口ルーチンは、０から２５５までの値を有するコードを返すことができる。ＭＦＳは、セグメント編集ルーチンによる使用のために、セグメントごとに、そのような返される最大のコードを維持する。同一のＭＦＬＤステートメントで’リテラル’が指定される場合には、ＥＸＩＴ＝は無効である。
ｅｘｔｅｎｄｅｄＡｔｔｒｉｂｕｔｅｓ ： ｉｎｔ
ＡＴＴＲ属性
アプリケーション・プログラムが３２７０属性および拡張属性（ｎｎ）を修正できるか（ＹＥＳ）否か（ＮＯ）を指定する。
ＹＥＳの場合には、２バイトを、出力にアプリケーション・プログラムが充てんし、入力時にブランクに初期化される３２７０属性データとして予約しなければならない。これらの２バイトは、ＬＴＨ＝指定に含まれなければならない。
ｎｎに指定される値は、動的に修正することができる拡張属性の数である。ｎｎの値は、１から６までの数とすることができる。無効な指定は、デフォルトの１になる。属性ごとに２つの追加バイトが、出力時にアプリケーション・プログラムによって充てんされ、入力時に空白に初期化される拡張属性データのために予約されなければならない。この属性バイトは、ＭＦＬＤ　ＬＴＨ＝指定に含まれなければならない。
例：下に示されているのは、ＡＴＴＲ＝の有効な指定と、異なる指定ごとに予約されなければならないバイト数である。
ＭＦＬＤ，ＡＴＴＲ＝（ＹＥＳ，ｎｎ）
２＋（２×ｎｎ）
ＭＦＬＤ，ＡＴＴＲ＝（ＮＯ，ｎｎ）
２×ｎｎ
ＭＦＬＤ，ＡＴＴＲ＝（ｎｎ）
２×ｎｎ
ＭＦＬＤ，ＡＴＴＲ＝ＹＥＳ
２
ＭＦＬＤ，ＡＴＴＲ＝ＮＯ
０
ＡＴＴＲ＝ＹＥＳおよびｎｎは、出力メッセージで位置パラメータを介してリテラル値が指定された場合には無効である。
別のＩＭＳ　ＩＳＣサブシステムに送られるフィールドの属性は、受け取るサブシステムのフォーマットでのＡＴＴＲ＝指定に無関係に、ＭＦＳによって入力データとして扱われる。たとえば、ＡＴＴＲ＝（ＹＥＳ，１）、ＬＴＨ＝５として定義されたメッセージ・フィールド（ＭＦＬＤ）に、下記が含まれる：
００Ａ０Ｃ２Ｆ１Ｃ８Ｃ５Ｄ３Ｄ３Ｄ６
受け取るサブシステムのＭＦＬＤが、ＡＴＴＲ＝なしでＬＴＨ＝９として定義される場合には、アプリケーション・プログラムが、下記を受け取る：
００Ａ０Ｃ２Ｆ１Ｃ８Ｃ５Ｄ３Ｄ３Ｄ６
受け取るサブシステムのＭＦＬＤが、ＬＴＨ＝１３およびＡＴＴＲ＝（ＹＥＳ，１）として定義される場合には、アプリケーション・プログラムが、下記を受け取る：
４０４０４０４０００Ａ０Ｃ２Ｆ１Ｃ８Ｃ５Ｄ３Ｄ３Ｄ６
受け取るサブシステムのＭＦＬＤが、ＬＴＨ＝５およびＡＴＴＲ＝（ＹＥＳ，１）として定義される場合には、アプリケーション・プログラムが、下記を受け取る：
４０４０４０４０００Ａ０Ｃ２Ｆ１Ｃ８
入力ＳＥＧステートメントは、属性データの大文字への変換を避けるために、ＧＲＡＰＨＩＣ＝ＮＯとして指定されなければならない。
ｆｉｌｌ ： Ｓｔｒｉｎｇ
ＦＩＬＬ属性
装置から受け取るデータの長さがこのフィールドの長さより短い時に、このフィールドに埋め込むのに使用される文字を指定する。この文字は、このフィールドについてデータが受け取られない時にも（ＭＳＧステートメントでオプション３が指定された時を除く）、埋込みに使用される。このオペランドは、ＴＹＰＥ＝ＩＮＰＵＴの場合に限って有効である。デフォルトは、Ｘ’４０’である。
Ｘ’ｈｈ’
その１６進数表現がｈｈである文字が、フィールドを充てんするのに使用される。ＦＩＬＬ＝Ｘ’３Ｆ’は、ＦＩＬＬ＝ＮＵＬＬと同一である。
Ｃ’ｃ’
文字’ｃ’によって、フィールドが充てんされる。
ＮＵＬＬ
フィールド内の欠けているデータの量だけ左へのメッセージ・セグメントの圧縮が行われる。
ｊｕｓｔｉｆｙ ： ＭＦＳＪｕｓｔｉｆｙＴｙｐｅ
ＪＵＳＴ属性
データ・フィールドが、左寄せ（Ｌ）または右寄せ（Ｒ）され、装置フォーマット制御ブロックによって期待されるか提示されるデータの量に依存して、必要なだけ右切捨または左切捨が行われるデータ・フィールドを指定する。デフォルトはＬである。
ｌｅｎｇｔｈ ： ＭＦＳＬｅｎｇｔｈＴｙｐｅ
ＬＴＨ属性
リテラルが位置オペランド（ＴＹＰＥ＝ＩＮＰＵＴ）で指定される場合に省略することができ、この場合には、リテラルについて指定された長さが使用される。ＬＴＨ＝がリテラル・フィールドについて指定される場合には、指定されるリテラルが、切り捨てられるか、指定された長さまでブランクを埋め込まれる。ＭＦＬＤステートメントがＤＯステートメントとＥＮＤＤＯステートメントの間にある場合には、ＬＴＨ＝がＭＦＬＤソース・ステートメントで指定されているかどうかに無関係に、長さの値が、生成されるＭＦＬＤステートメントに印刷される。
ｖａｌｕｅ ： Ｓｔｒｉｎｇ
ｖａｌｕｅ属性
これは、以下の説明の’ｌｉｔｅｒａｌ’フィールドに対応する。
装置フィールド名は、’ｄｅｖｉｃｅＦｉｅｌｄｓ’関係を介して指定される。
入力データがそこから抽出されるか、出力データがそこに配置される装置フィールド名（ＤＥＶステートメントまたはＤＦＬＤステートメントを介して定義される）を指定する。メッセージ出力制御ブロックを定義する時にこのパラメータが省略された場合には、アプリケーション・プログラムによって供給されるデータが、出力装置に表示されない。ＭＦＳの反復生成機能（ＤＯステートメントおよびＥＮＤＤＯステートメント）が使用される場合には、ｄｆｌｄｎａｍｅが、６文字の最大長に制限されなければならない。ステートメントの各反復が生成される時に、２文字のシーケンス番号（０１から９９まで）が、ｄｆｌｄｎａｍｅに付加される。ここで指定されるｄｆｌｄｎａｍｅが、６バイトを超え、反復生成が使用される場合に、ｄｆｌｄｎａｍｅが６文字目で切り捨てられ、２文字のシーケンス番号が付加されて、８文字の名前が形成される。これが行われる場合に、エラー・メッセージは提供されない。このパラメータは、下記のフォーマットの１つで指定することができる：
ｄｆｌｄｎａｍｅ
入力データがそこから抽出されるか、出力データがそこに配置される装置フィールド名を識別する。
’ｌｉｔｅｒａｌ’
リテラル値が入力メッセージに挿入される場合に指定することができる。
（ｄｆｌｄｎａｍｅ，’ｌｉｔｅｒａｌ’）
ＴＹＰＥ＝ＯＵＴＰＵＴの場合に、これによって、リテラル・データが名前付きＤＦＬＤに配置されることが記述される。この形が指定される時には、リテラルのスペースを、アプリケーション・プログラムによって供給される出力メッセージ・セグメント内で割り振ってはならない。
ＴＹＰＥ＝ＩＮＰＵＴの場合に、これによって、このフィールドのデータが装置から受け取られない時にメッセージ・フィールドにリテラル・データが配置されることが記述される。このｄｆｌｄｎａｍｅが、ＤＥＶステートメントのＰＦＫパラメータで使用される場合には、このリテラルが、必ずＰＦキー・リテラルまたは制御機能によって置換される。しかし、このｄｆｌｄｎａｍｅがＰＦＫパラメータで指定されるが、ＰＦキーが使用されない時には、ＭＦＬＤステートメントで指定されたリテラルが、メッセージ・フィールドに移動される。物理ページングが使用される時に、リテラルは、フィールドに挿入されるが、論理ページの最後の物理ページが表示された後までは処理されない。
両方の場合で、ＬＴＨ＝オペランドが指定される場合には、ＬＴＨ＝指定の長さの必要に応じて、リテラルの長さが切り捨てられるか埋め込まれる。指定されたリテラルの長さが、定義されたフィールド長より短い場合には、リテラルに、ＴＹＰＥ＝ＯＵＴＰＵＴならばブランク、ＴＹＰＥ＝ＩＮＰＵＴならば指定された充てん文字（ＦＩＬＬ＝）が埋め込まれる。充てん文字が入力について指定されない場合には、リテラルは、ブランクを充てんされる（デフォルト）。リテラル値の長さは、２５６バイトを超えることができない。
（ｄｆｌｄｎａｍｅ，ｓｙｓｔｅｍ−ｌｉｔｅｒａｌ）
システム・リテラルのリストから名前を指定する。システム・リテラルは、リテラル値が、装置への送信の前のフォーマット中に作成されることを除いて、通常のリテラルと同様に機能する。ＬＴＨ＝オペランド、ＡＴＴＲ＝オペランド、およびＪＵＳＴ＝オペランドを指定することはできない。この形が指定される時には、リテラルのスペースを、アプリケーション・プログラムによって供給される出力メッセージ・セグメント内で割り振ってはならない。
（，ＳＣＡ）
この出力フィールドを、出力装置に表示されないシステム制御域として定義する。１論理ページ（ＬＰＡＧＥ）内に１つだけそのようなフィールドを設けることができ、このフィールドは、そのページの最初のメッセージ・セグメント内になければならない。論理ページが定義されない場合には、１つのＳＣＡフィールドだけを定義することができ、そのＳＣＡフィールドは、出力メッセージの最初のセグメント内になければならない。この指定は、前のＭＳＧステートメントでＴＹＰＥ＝ＯＵＴＰＵＴが指定された場合に限って有効である。
【０３０３】
ＭＦＳＤｅｖｉｃｅＰａｇｅ
ＤＰＡＧＥステートメント
ＤＰＡＧＥステートメントでは、装置フォーマットの論理ページを定義する。このステートメントは、この装置フォーマット（ＦＭＴ）を参照するメッセージ記述子のどれにもＬＰＡＧＥステートメントが含まれず、特定の装置オプションが不要である場合に、省略することができる。存在しない場合には、暗黙指定される。
サポートされない属性：
−　ＡＣＴＶＰＩＤ
−　ＣＯＮＤ
−　ＯＦＴＡＢ
−　ＯＲＩＧＩＮ
−　ＰＤ
−　ＳＥＬＥＣＴ
ＭＦＳＳｔａｔｅｍｅｎｔから派生する
プライベート属性：
ｃｕｒｓｏｒ ： ＭＦＳＣｕｒｓｏｒＴｙｐｅ
ＣＵＲＳＯＲ属性
物理ページ上のカーソルの位置を指定する。論理ページまたはメッセージが複数の物理ページからなる場合に、複数のカーソル位置が必要になる可能性がある。値ｌｌｌが、行番号を指定し、ｃｃｃが、列を指定する；ｌｌｌおよびｃｃｃの両方が、１以上でなければならない。カーソル位置は、定義されたフィールド上またはデフォルトのどちらかでなければならない。３２７０ディスプレイのデフォルトｌｌｌ、ｃｃｃ値は、１、２である。財務ディスプレイ・コンポーネントについて、カーソル位置が指定されない場合に、ＭＦＳは、カーソルを位置決めしない−カーソルは、通常は、装置上の出力データの末尾に配置される。財務ディスプレイ・コンポーネントについて、ＯＲＩＧＩＮ＝パラメータが指定されたかどうかに無関係に、すべてのカーソル位置が絶対位置である。
ｄｆｌｄパラメータによって、入力時にアプリケーション・プログラムにカーソル情報を供給し、出力時にアプリケーション・プログラムがカーソル位置を指定できるようにする方法が提供される。
推奨：出力カーソル位置決めにはカーソル属性機能を使用する（ＭＦＬＤステートメントでＡＴＴＲ＝ＹＥＳを指定する）。
ｄｆｌｄパラメータによって、カーソル位置を含むフィールドの名前が指定される。この名前は、ＭＦＬＤステートメントによって参照される可能性があり、このＤＥＶ定義のＤＦＬＤステートメントのラベルとして使用してはならない。このフィールドのフォーマットは、それぞれ行と列の番号を含む２つの２進ハーフワードである。このフィールドが、メッセージ入力記述子によって参照される時に、このフィールドに、メッセージ入力時のカーソル位置が含まれる。メッセージ出力記述子によって参照される時に、アプリケーション・プログラムが、それぞれ行と列を含む２進ハーフワードとしてこのフィールドに所望のカーソル位置を置く。名前を指定されたフィールドに２進数０があると、指定されたｌｌｌ、ｃｃｃが、出力中にカーソル位置に使用されるようになる。入力中には、このフィールドの２進数０は、カーソル位置が定義されないことを示す。このｄｆｌｄを参照する入力ＭＦＬＤは、ＧＲＡＰＨＩＣ＝ＮＯを指定されたセグメント内で定義されるか、２進数を１０進数に変換するためにＥＸＩＴ＝（０，２）を使用しなければならない。
ｆｉｌｌ ： Ｓｔｒｉｎｇ
ＦＩＬＬ属性
出力装置フィールドの充てん文字を指定する。３２７０ディスプレイを除くすべての装置タイプのデフォルト値は、Ｘ’４０’であり、３２７０ディスプレイのデフォルトは、ＰＴである。ＥＧＣＳフィールドが存在する時の３２７０出力について、ＦＩＬＬ＝ＰＴまたはＦＩＬＬ＝ＮＵＬＬだけを指定しなければならない。ＦＩＬＬ＝ＰＴでは、データがフィールドに送られる時に限って、出力フィールド（１バイト・フィールドまたは２バイト・フィールドのいずれか）が消去され、したがって、アプリケーション・プログラム・メッセージでＭＦＬＤが省略される場合に、ＤＦＬＤは消去されない。
ＮＯＮＥ
メッセージ出力記述子からの充てん文字が、装置フィールドを充てんするのに使用される場合に指定されなければならない。
Ｘ’ｈｈ’
その１６進数表現がｈｈである文字が、装置フィールドを充てんするのに使用される。
Ｃ’ｃ’
文字’ｃ’が、装置フィールドを充てんするのに使用される。
ＮＵＬＬ
フィールドが充てんされないことを指定する。３２７０ディスプレイ以外の装置について、メッセージ・データが装置フィールドを満たさない時に、「短縮された行」が作られる。
ＰＴ
装置フィールド（ＤＦＬＤ）を満たさない出力フィールドに、そのフィールドに前に存在したデータを消去するプログラム・タブ文字が続くことを指定する；それ以外は、この動作はＦＩＬＬ＝ＮＵＬＬと同一である。
３２７０ディスプレイ装置について、Ｘ’３Ｆ’未満の値を有するすべての指定が、制御文字はＸ’００’、他の非グラフィック文字はＸ’４０’に変更される。
ｍｕｌｔｉｐｌｅＰａｇｅｓ ： ｂｏｏｌｅａｎ
ＭＵＬＴ属性
このＤＰＡＧＥについて複数の物理ページ入力メッセージが許容されることを指定する。
【０３０４】
ＭＦＳＤｅｖｉｃｅＦｉｅｌｄ
ＤＦＬＤステートメント
ＤＦＬＤステートメントでは、端末またはリモート・プログラムから読み取られるか書き込まれる、装置フォーマット内のフィールドを定義する。ＩＭＳまたはリモート・アプリケーション・プログラムに重要な区域だけを定義しなければならない。フォーマットのヌル・スペースは、定義する必要がない。
サポートされない属性：
−　ＳＬＤ
ＭＦＳＳｔａｔｅｍｅｎｔから派生する
プライベート属性：
ａｔｔｒｉｂｕｔｅｓ ： ＭＦＳＡｔｔｒｉｂｕｔｅＴｙｐｅ
ＡＴＴＲ属性
ｅｘｔｅｎｄｅｄＡｔｔｒｉｂｕｔｅｓ ： ＭＦＳＥｘｔｅｎｄｅｄＡｔｔｒｉｂｕｔｅＴｙｐｅ
ＥＡＴＴＲ属性
ｌｅｎｇｔｈ ： ｉｎｔ
ＬＴＨ属性
フィールドの長さを指定する。このオペランドは、位置パラメータで’ｌｉｔｅｒａｌ’が指定される場合には省略されなければならず、その場合には、リテラルの長さが、フィールド長として使用される。このオペランドが’ｌｉｔｅｒａｌ’と共に使用され、この２つの長さが異なる場合に、予測不能な出力フォーマットが行われる可能性がある。指定されるＬＴＨ＝は、装置の物理ページ・サイズを超えることができない。
３２７０、３６０４ディスプレイ、およびＲＣＤＣＴ＝ＮＯＳＰＡＮを伴うＤＰＭを除く最大の許容可能な長さは、８０００文字である。３２７０ディスプレイについて、最大長は、画面サイズより１つ少ない。たとえば、４８０文字ディスプレイについて、最大長は４７９文字である。０の長さを指定してはならない。ＳＣＡとＬＴＨ＝の両方が指定される場合には、ＬＴＨが２でなければならない。
ＰＯＳ＝およびＬＴＨ＝に、３２７０ディスプレイ装置またはＡＴＴＲ＝ＹＥＳを指定されたＤＦＬＤについて予約されている属性文字位置を含めてはならない。ディスプレイ／プリンタ・フォーマットの設計にこのバイトを含めることは、それがアプリケーション・プログラムによってアクセス可能でない場合であっても、それが、表示／印刷されるフィールドのそれぞれに先行する画面／印刷されるページ位置を占めるので、必要である。
３２７０プリンタのＤＦＬＤを定義する時には、ハードウェアＡＴＴＲＩＢＵＴＥ文字は使用されない。したがって、フィールドは、ＡＴＴＲ＝ＹＥＳが指定されない限り、属性文字を許容しない並置を用いて定義しなければならない。しかし、３２７０Ｐとして定義されるプリンタについて、印刷行の最後の桁（ＦＥＡＴ＝、ＷＩＤＴＨ＝、または装置のデフォルト幅に基づく）を使用することはできない。行の最後の桁は、ＩＭＳによって実行される紙送り制御動作用に予約されている。したがって、印刷行で１２０が指定され（ＦＥＡＴ＝１２０）、ＤＦＬＤでＰＯＳ＝（１，１）、ＬＴＨ＝１２０が指定される場合に、１１９文字が行１に印刷され、１文字が行２に印刷される。
検出可能フィールド（ＤＥＴまたはＩＤＥＴ）には、検出可能フィールドが表示行の最後のフィールドでない限り（この場合には、検出指定文字の１位置だけが必要）、１バイトの検出指定文字と３つの埋込み文字のための４つの位置が、ＰＯＳおよびＬＴＨに含まれなければならない。検出指定文字は、フィールド・データに先行しなければならず、埋込み文字（必要な場合）は、フィールド・データの後に続かなければならない。検出指定文字および必要な埋込み文字は、アプリケーション・プログラムまたはフィールド・データに伴うＭＦＬＤリテラルによって供給されなければならない。埋込み文字は、装置の先行するフィールドにも必要になる可能性がある。
ｐｅｎ ： Ｓｔｒｉｎｇ
ＰＥＮ属性
このフィールドが検出される時に選択されるリテラルまたは実行されるオペレータ制御機能を指定する。（１）’ｌｉｔｅｒａｌ’が指定され、（２）フィールドが即座に検出可能（ＡＴＴＲ＝オペランド）として定義され、（３）ヌル文字またはスペース指定文字が含まれる場合に、フィールドが検出される時（他の装置フィールドが修正されない場合）に、指定されたリテラルが、前のＤＥＶステートメントのＰＥＮオペランドによって参照されるフィールドに配置される。装置の別のフィールドが修正される場合には、リテラルの代わりに疑問符（？）が供給される。リテラルの長さは、２５６バイトを超えてはならない。
（１）制御機能が指定され、（２）フィールドが即座に検出可能（ＡＴＴＲ＝オペランド）として定義され、（３）ヌル文字またはスペース指定文字が含まれる場合に、フィールドが検出され、他の装置フィールドが修正されない時に、指定された制御機能が実行される。装置の別のフィールドが修正される場合には、疑問符（？）が提供され、機能は実行されない。指定することができる制御機能は次の通りである：
ＮＥＸＴＰＰ−−ＰＡＧＥ ＡＤＶＡＮＣＥ
現在の出力メッセージの次の物理ページの要求を指定する。進行中の出力メッセージがない場合には、明示的な応答は行われない。
ＮＥＸＴＭＳＧ−−ＭＥＳＳＡＧＥ ＡＤＶＡＮＣＥ
進行中の出力メッセージ（ある場合に）を待機解除し、キューの次の出力メッセージ（ある場合に）を送る要求を指定する。
ＮＥＸＴＭＳＧＰ−−ＭＥＳＳＡＧＥ ＡＤＶＡＮＣＥ ＰＲＯＴＥＣＴ
進行中の出力メッセージ（ある場合に）を待機解除し、次の出力メッセージを送るか、次のメッセージが存在しないことを示す情報メッセージを返す要求を指定する。
ＮＥＸＴＬＰ−−ＮＥＸＴ ＬＯＧＩＣＡＬ ＰＡＧＥ
現在のメッセージの次の論理ページの要求を指定する。
ＥＮＤＭＰＰＩ−−ＥＮＤ ＭＵＬＴＩＰＬＥ ＰＡＧＥ ＩＮＰＵＴ
複数の物理ページ入力メッセージの終りを指定する。
ＥＮＤＭＰＰＩは、データが受信された場合に限って有効であり、データ入力がない場合の複数ページ入力（ＭＰＰＩ）は終了されない。
ｐｏｓｉｔｉｏｎ ： ＭＦＳＰｏｓｉｔｉｏｎＴｙｐｅ
ＰＯＳ属性
表示フォーマットの行（ｌｌｌ）、桁（ｃｃｃ）、および物理ページ（ｐｐ）に関してこのフィールドの最初のデータ位置を定義する。ｐｐが省略された場合には、１が仮定される。
ＤＥＶ ＴＹＰＥ＝３２７０、３２７０−Ａｎ、または３２７０Ｐ用
ｌｌｌ，ｃｃｃ，ｐｐ
出力フィールドの行、桁、および、任意指定として物理ページ番号を指定する。ｌｌｌ、ｃｃｃ、およびｐｐは、１以上でなければならない。
３２７０ディスプレイについて、ＰＯＳ＝（１，１）を指定しなければならない。最下部から最上部にラップするフィールドを定義してはならない。
制約：３２７０のいくつかのモデルで、行１、桁２から始まるフィールドがアルファベット属性と保護属性の両方を有する時に、表示画面をコピーすることができない。
ｖａｌｕｅ ： Ｓｔｒｉｎｇ
【０３０５】
ＭＦＳＴａｂｌｅ
ＴＡＢＬＥステートメント
ＴＡＢＬＥステートメントでは、ＤＦＬＤステートメントのＯＰＣＴＬキーワードによって参照することができるオペレータ制御テーブルを開始し、名前を付ける。ＴＡＢＬＥステートメントおよびそれに続くＩＦおよびＴＡＢＬＥＥＮＤステートメントは、ＭＳＧ定義またはＦＭＴ定義の外になければならない。
サポートされない属性：
−　すべての属性がサポートされる
ＭＦＳＳｔａｔｅｍｅｎｔから派生する
【０３０６】
ＭＦＳＤｅｖｉｃｅＤｉｖｉｓｉｏｎ
ＤＩＶステートメント
ＤＩＶステートメントでは、ＤＩＦまたはＤＯＦ内の装置フォーマットを定義する。フォーマットは、入力、出力、または入力と出力の両方として識別され、複数の物理ページから構成することができる。ＤＥＶごとに１つのＤＩＶステートメントだけが許容される。
サポートされない属性：
−　ＲＣＤＣＴＬ
−　ＨＤＲＣＴＬ
−　ＯＰＴＩＯＮＳ
−　ＯＦＴＡＢ
−　ＤＰＮ
−　ＰＲＮ
−　ＲＤＰＮ
−　ＲＰＲＮ
ＭＦＳＳｔａｔｅｍｅｎｔから派生する
プライベート属性：
ｔｙｐｅ ： ＭＦＳＤｅｓｃｒｉｐｔｏｒＴｙｐｅ
ＴＹＰＥ属性
入力専用フォーマット（ＩＮＰＵＴ）、出力専用フォーマット（ＯＵＴＰＵＴ）、または両方（ＩＮＯＵＴ）を記述する。
ＤＩＶ ＴＹＰＥ＝ＯＵＴＰＵＴまたはＴＹＰＥ＝ＩＮＰＵＴが指定される場合に、ある種のＤＥＶステートメント・キーワードが適用可能である。
ｃｏｍｐｒｅｓｓｉｏｎ ： ＭＦＳＣｏｍｐｒｅｓｓｉｏｎＴｙｐｅ
ＣＯＭＰＲ属性
短いフィールド、固定長フィールド、またはアプリケーション・プログラムによって提示されるすべてのフィールドから末尾ブランクを除去するようにＭＦＳに要求する。
【０３０７】
ＭＦＳＩｆＣｏｎｄｉｔｉｏｎ
ＩＦステートメント
ＩＦステートメントでは、前のＴＡＢＬＥステートメントによって名前を付けられたテーブル内の項目を定義する。各ＩＦステートメントで、条件演算と、条件が真である場合に実行される関連する制御機能または分岐機能が定義される。
サポートされない属性：
−　すべての属性がサポートされる
ＭＦＳＳｔａｔｅｍｅｎｔから派生する
プライベート属性：
ｃｏｎｄｉｔｉｏｎ ： ＭＦＳＣｏｎｄｉｔｉｏｎＴｙｐｅ
条件属性
条件は、下記のフォーマットを有する：
Figure 2004506264
条件演算が、フィールドについて装置から受け取られたデータに対して実行されることを指定する。
ＬＥＮＧＴＨ
条件演算が、フィールドについて入力された文字の数をテストすることを指定する。このフィールドのサイズ限界は、ＤＦＬＤと同一である（トピック２．５．１．５．８の「ＤＦＬＤステートメント」を参照されたい）。
＝，＜，＞，≠，≧，≦
指定された制御機能を呼び出すために真にならなければならない条件関係を指定する。
’ｌｉｔｅｒａｌ’
入力データが比較されるリテラル・ストリングである。比較は、入力を大文字に変換する前に行われる。’ｌｉｔｅｒａｌ’が指定される場合には、ＤＡＴＡが第１オペランドで指定されなければならない。入力データ長が、リテラル・ストリング長と等しくない場合には、比較は、条件関係が≠でなく、データ長が０でない限り（この場合には制御機能が実行される）、短い方の長さを用いて実行される。入力が小文字の場合には、ＡＬＰＨＡステートメントを使用しなければならず、リテラルが小文字でコード化されなければならない。
ｄａｔａ−ｌｅｎｇｔｈ
比較されるフィールドの入力データがの文字の数の整数値を指定する。
ＮＯＦＵＮＣ
条件機能テストが終了することを指定する。
ＮＥＸＴＰＰ−−ＰＡＧＥ ＡＤＶＡＮＣＥ
現在の出力メッセージの次の物理ページの要求を指定する。進行中の出力メッセージがない場合には、明示的な応答は行われない。
ＮＥＸＴＭＳＧ−−ＭＥＳＳＡＧＥ ＡＤＶＡＮＣＥ
進行中の出力メッセージ（ある場合に）を待機解除し、キューの次の出力メッセージ（ある場合に）を送る要求を指定する。
ＮＥＸＴＭＳＧＰ−−ＭＥＳＳＡＧＥ ＡＤＶＡＮＣＥ ＰＲＯＴＥＣＴ
進行中の出力メッセージ（ある場合に）を待機解除し、次の出力メッセージを送るか、次のメッセージが存在しないことを示す情報メッセージを返す要求を指定する。
ＮＥＸＴＬＰ−−ＮＥＸＴ ＬＯＧＩＣＡＬ ＰＡＧＥ
現在のメッセージの次の論理ページの要求を指定する。
ＰＡＧＥＲＥＱ−−ＬＯＧＩＣＡＬ ＰＡＧＥ ＲＥＱＵＥＳＴ
入力データの２番目から最後までの文字を論理ページ要求とみなさなければならないことを指定する。
ＥＮＤＭＰＰＩ−−ＥＮＤ ＭＵＬＴＩＰＬＥ ＰＡＧＥ ＩＮＰＵＴ
複数物理ページ入力の終り（この入力が、作成されるメッセージの最後の入力である）を指定する。
ａｃｔｉｏｎ ： Ｓｔｒｉｎｇ
【０３０８】
ＭＦＳＰａｓｓｗｏｒｄ
ＰＡＳＳＷＯＲＤステートメント
ＰＡＳＳＷＯＲＤステートメントでは、ＩＭＳパスワードとして使用される１つまたは複数のフィールドを識別する。使用される時に、ＰＡＳＳＷＯＲＤステートメントおよびそれに関連するＭＦＬＤが、入力のＬＰＡＧＥまたはＭＳＧの定義の最初のＳＥＧステートメントに先行しなければならない。８つまでのＭＦＬＤステートメントを、ＰＡＳＳＷＯＲＤステートメントの後で指定することができるが、パスワードの全長が、８文字を超えてはならない。充てん文字は、Ｘ’４０’でなければならない。オプション１および２のメッセージについて、編集後のデータの最初の８文字が、ＩＭＳパスワードに使用される。オプション３のメッセージについて、編集後の第１フィールドのデータ内容が、ＩＭＳパスワードに使用される。
３２７０入力に関するパスワードは、ＤＦＬＤステートメントで定義することもできる。両方のパスワード方法が使用される場合には、ＭＳＧ定義で指定されたパスワードが使用される。
サポートされない属性：
−　すべての属性がサポートされる
ＭＦＳＳｔａｔｅｍｅｎｔから派生する
【０３０９】
ＭＦＳＤｅｖｉｃｅＤｅｓｃｒｉｐｔｏｒ
ＦＭＴステートメント
ＦＭＴステートメントでは、ＤＥＶステートメントで指定される装置タイプおよび特徴でのみ異なる１つまたは複数の装置フォーマットを含むフォーマット定義を開始し、名前を付ける。このフォーマット定義に含まれる各装置フォーマットによって、装置またはリモート・プログラムから送信または受信されるデータのレイアウトが指定される。
サポートされない属性：
−　すべての属性がサポートされる
ＭＦＳＳｔａｔｅｍｅｎｔから派生する
【０３１０】
ＭＦＳＦｕｎｃｔｉｏｎＫｅｙＴｙｐｅ
プライベート属性：
ｆｉｅｌｄＮａｍｅ ： Ｓｔｒｉｎｇ
【０３１１】
ＭＦＳＦｕｎｃｔｉｏｎＫｅｙＶａｌｕｅＴｙｐｅ
プライベート属性：
ｉｎｄｅｘ ： ｉｎｔ
ｆｕｎｃｔｉｏｎ ： Ｓｔｒｉｎｇ
【０３１２】
ＭＦＳＦｏｒｍａｔＬｉｂｒａｒｙ
このクラスは、ＦＯＲＭＡＴＬＩＢの効果を複製するために設計された。言い換えると、これは、ＭＦＳソース・ファイルがそれを中心にしてグループ化される中心点として働く。
このクラスは、他のソース・ファイル内のＭＳＧステートメントを参照するＭＳＧステートメントおよびＬＰＡＧＥステートメントの問題に対処するために導入された。所与のｆｏｒｍａｔｌｉｂ内のすべてのソース・ファイルを１回で解析することをユーザに強制するのではなく、ＭＳＧポインタのコンテナとして働くためにこのクラスが追加された。詳細については、ＭＦＳＭｅｓｓａｇｅＰｏｉｎｔｅｒの資料を参照されたい。
プライベート属性：
ｎａｍｅ ： Ｓｔｒｉｎｇ
【０３１３】
ＭＦＳＭｅｓｓａｇｅＰｏｉｎｔｅｒ
このクラスは、ＭＳＧステートメントのプレースホルダとして働くように設計された。ＮＸＴ属性（ｎｅｘｔＭｅｓｓａｇｅ関係）から実際のＭＳＧステートメントを指すのではなく、ＭＳＧステートメントおよびＬＰＡＧＥステートメントが、このクラスのインスタンスを指す。
このクラスの新しいインスタンスは、ＭＳＧステートメントまたはＬＰＡＧＥステートメントが、この特定のＦＯＲＭＡＴＬＩＢで表されないＭＳＧステートメントを指す時に作成される。新しいインスタンスは、ＭＳＧステートメントが解析され、そのステートメントがまだここで表されていない場合にも作成される。
プライベート属性：
ｎａｍｅ ： Ｓｔｒｉｎｇ
【０３１４】
総計：
１論理パッケージ
１６クラス
論理パッケージ構造
論理ビュー
ｍｆｓ
【０３１５】
７．共通アプリケーション・メタモデルおよびシステムの例示的アプリケーション
複数の個々のプラットフォームにまたがって発生するさまざまな複雑なトランザクションが、共通アプリケーション・メタモデルのシームレス性および透過性を必要とする。これらのトランザクションには、「リッチ」・トランザクション、高水準グループ・ウェア、および財務トランザクションが含まれる。
【０３１６】
図４７に、たとえば注文が端末で入力され、ウェブ・サーバに渡され、ウェブ・サーバを介して製造業者のアプリケーション・サーバに渡される、「リッチ」トランザクションに関する単純化されたネットワーク構成を示す。製造業者のアプリケーション・サーバは、それ自体のデータベース・サーバならびに、本明細書に記載のコネクタによって透過的に接続されたそのベンダの似ていない非互換のデータベース・サーバおよびデータベースを介して検索し、コンポーネントの状況、価格、および配送日付を照会し、注文を満足するのに必要なコンポーネントの注文を行う。
【０３１７】
制限ではなく厳密に例示のために、リッチ・トランザクションを、新しい自動車の構成および注文から、自動車の資金調達、新しい自動車の要素および構成要素の収集、自動車の組立、顧客への送達を介する、自動車の購入を用いて例示する。たとえば、自動車を構成する際に、たとえば技術的理由または性能的理由から、エンジンのあるサブセットを含めることを除外しながらエンジンの別のサブセットを含めることを必要とするトラクション・コントロール・モジュールを含めることを検討する。同様に、ある色の選択によって、たとえば在庫または使用可能性の理由から、ある車内装飾の組合せが排除される場合がある。もちろん、エンジンおよびトランスミッションを選択しない場合には、自動車は得られない。いくつかの選択を、行わなければならない。問題は、「’Ｘ’を選択する場合に、’Ｙ’および’Ｚ’も選択しなければならないが、’Ｙ’を選択する場合には、’Ａ’または’Ｂ’を得ることができず、既に‘Ａ’が選択されている」の１つである。すなわち、ある構成要素またはサブシステムの選択によって、前に選択された構成要素またはサブシステムがシステムから除去される場合がある。しばしば供給パイプラインの選択された要素の使用可能性に基づいて、自動車を構成した後に、注文が、製造スケジューリングを含めて実行のために製造業者のサーバに送信される。製造業者は、供給チェーンのベンダ、たとえばトランスミッション・ベンダに照会し、このベンダが、コントローラ・ベンダ、ギア・ベンダ、ハウジング・ベンダ、油圧導管ベンダなどに照会する。これらのベンダが、そのサブベンダに照会する。
【０３１８】
コネクタの方法およびシステムを使用して、ディーラおよび顧客が、端末３９０１で自動車を構成し、注文する。構成および注文の入力が、製造業者のサーバ３９１１に送信される。製造業者のサーバは、サーバ３９２１、３９３１、および３４４１（サーバ３９２１は、製造業者の自社構成要素事業およびその購入機能のサーバとすることができる）またはその直接ベンダに照会し、この直接ベンダが、第３のサブベンダのサーバ３９２３、３９３３、および３９４３に照会する。照会は、アクセス許可の対象になる「空白埋め」ＳＱＬ照会の形とすることができる。サブベンダのサーバ３９２３、３９３３、および３９４３は、クライアントとしてのベンダのサーバ３９２１、３９３１、および３４４１に特殊ビューを提示し、このベンダのサーバが、クライアントとしての製造業者のサーバ３９１１に特殊ビューを提示する。製造業者のサーバ３９１１に返されるデータは、最適化アプリケーションおよび生産スケジューリング・アプリケーションを用いて最適化して、ディーラのサーバ側の買い手に通し番号および送達日付を提示することができる。
【０３１９】
本発明のコネクタのもう１つの応用例が、グループウェアとの接続にあり、特に、「グループウェアの島」を一緒にリンクすることである。「グループウェア」は、グループの作業を容易にするように設計された技術に適用される広義の用語である。グループウェア技術は、通信、協力、調整、問題解決、競合、または折衝に使用することができる。アプリケーションのグループウェア・スイートは、人々が、互いに遠隔地に位置する場合であっても、一緒に協力して作業するのを助けるプログラムからなる。グループウェア・サービスには、カレンダの共用、集団執筆、電子メール処理、共用データベース・アクセス、電子会議、ビデオ会議、および他の活動を含めることができる。
【０３２０】
図４８に、複数の異なるプラットフォームで稼動し、本明細書に記載のコネクタによって接続される、複数のグループ・ウェア・アプリケーションにまたがって分散されたグループ・ウェア・セッションを示す。特に示されているのは、２つのグループウェア・システム４０１０および４０２０である。各システムには、電子メール、スケジュール／カレンダ、ワード・プロセッサ、スプレッド・シート、グラフィックス、およびＣＴＩ（コンピュータ・テレフォニー統合）などの電子メール対応アプリケーション４０１３および４０２３が含まれる。これらは、メッセージＡＰＩ４０１５および４０２５と、オペレーティング・システム４０１７および４０２７と、ローカル・グループウェア・サーバ４０１１および４０２１によってサポートされる。ローカル・グループウェア・サーバ４０１１および４０２１のそれぞれが、本発明のコネクタ、電子メール・サーバ、電子メール・データ・ベース、ディレクトリ・サーバ、および複製データベースを有する。２つのローカル・グループウェア・サーバ４０１１および４０２１は、インターネット、ＬＡＮ、ＷＡＮ、またはＰＳＴＮなどの遠隔通信媒体を介して通信する。
【０３２１】
電子メールは、断然一般的であり基本的なグループウェア・アプリケーションである。基本的な技術は、人の間で単純なメッセージを渡すように設計されているが、現在の比較的単純な電子メール・システムであっても、メッセージ転送、メッセージのファイリング、メーリング・グループの作成、およびメッセージへのファイルの添付の機能が含まれる。調査されてきた他の機能には、メッセージの内容ベースのソートおよび処理、メッセージの内容ベースのルーティング、および構造化された通信（ある情報を要求するメッセージ）が含まれる。
【０３２２】
ワークフロー・システムが、グループウェアのもう１つの要素である。ワーク・フロー・システムを用いると、比較的固定されたプロセスを介して、組織内で文書をルーティングできるようになる。ワークフロー・アプリケーションの単純な例が、組織の経費報告である：ある従業員が、経費報告を入力し、サブミットし、コピーが、アーカイブされ、その後、従業員の上司に許可のためにルーティングされ、上司が文書を受け取り、電子的に承認し、回送し、経費が、グループの口座に登録され、支払いのために会計部門に転送される。ワークフロー・システムは、ルーティング、フォームの開発、異なる役職および特権のサポートを提供することができる。
【０３２３】
ハイパーテキストは、テキスト文書を互いにリンクするシステムであり、ウェブが明白な例である。しかし、複数の人が文書を作成し、リンクする時には、必ず、そのシステムが、常に発展し、他人の作業に応答するグループ作業になる。ハイパーテキストのもう１つの一般的なマルチユーザ機能（ウェブではみられない）が、すべてのユーザがすべてのページからリンクを作成できるようにし、その結果、他のユーザが、元の作成者が知らない関連するリンクがある時に知ることができるようにすることである。
【０３２４】
グループ・カレンダリングが、グループウェアのもう１つの態様であり、これによって、多数の人の間のスケジューリング、プロジェクト管理、および調整が容易になり、スケジューリング機器のサポートも提供することができる。通常の特徴では、スケジュールが衝突する時が検出されるか、誰もが働く会議時間が発見される。グループ・カレンダは、人の居場所を知るのにも役立つ。
【０３２５】
協同執筆システムは、リアルタイム・サポートと非リアルタイム・サポートの両方を提供することができる。ワード・プロセッサは、原作者を示すことと、ユーザが変更を追跡し、文書に対する注釈を作成できるようにすることによって、非同期サポートを提供することができる。文書について協同作業する作成者に、文書の部分をロックする方法または別々に作成された文書をリンクする方法など、作成過程を計画し調整するのを助けるツールを与えることもできる。同期サポートを用いると、作成者が、変更を行う時に他者のそれぞれの変更を見ることができるようになり、通常は、作成者が作業する時に作成者に追加の通信チャネルを提供することが必要である。
【０３２６】
グループは、複数の人が、異なる位置からでも、共用される描画面を見、描くことができるようにする共用ホワイトボードなど、同期式またはリアル・タイムとすることができる。これは、たとえば、通話中に、各人がメモ（たとえば名前、電話番号、または地図など）を書き留めるか、視覚的問題について協同で作業するのに使用することができる。ほとんどの共用ホワイトボードは、形式ばらない会話のために設計されているが、協同グラフィック設計応用分野、出版応用分野、またはエンジニアリング応用分野など、構造化された通信またはより洗練された描画タスクをサービスすることもできる。共用ホワイトボードは、各人を識別するためにカラーコードされるかラベルを付けられるテレポインタによって、各人が描画している場所または指している場所を示すことができる。
【０３２７】
グループウェアのもう１つの態様が、ビデオ会議である。ビデオ会議システムは、生ビデオを伴う２方向または多方向の呼を可能にし、本質的には、調整用のタイム・スタンプを伴う追加の視覚的構成要素を有する電話システムである。
【０３２８】
意思決定支援が、グループウェアのもう１つの態様であり、グループの意思決定を促進するように設計される。これは、ブレインストーミング、アイデアの批評、事象および代替物に重みまたは確率を置くこと、および投票のツールを提供する。そのようなシステムは、おそらくは、より合理的で公平な決定を可能にする。これらは、主に会議を容易にするために設計されるが、たとえば、匿名性を提供するか交替を強制することによって、平等な参加を促進する。
【０３２９】
マルチプレイヤ・ゲームが、ゲームセンタで適度に一般的になったが、インターネットで非常に一般的になりつつある。初期の電子ゲームセンタ・ゲームの多数、たとえばＰｏｎｇ、Ｓｐａｃｅ Ｗａｒｓ、および自動車レース・ゲームが、マルチユーザであった。ゲームは、「非協同」マルチユーザ情況の原型的例であるが、競争的なゲームであっても、プレイヤがゲームのルールに従って協力することが必要である。ゲームは、チャット・システムまたはビデオ・システムなど、他の通信媒体によって機能強化することができる。
【０３３０】
グループウェアの製品の例には、Ｌｏｔｕｓ ＮｏｔｅｓおよびＭｉｃｒｏｓｏｆｔＥｘｃｈａｎｇｅが含まれ、この両方が、カレンダ共用、電子メール処理、分散システムを介するファイルの複製を容易にし、その結果、すべてのユーザが同一の情報を見られるようになる。
【０３３１】
本発明のコネクタを、グループウェア・アプリケーションにとって特に魅力的にしているのが、グループウェア提供と、グループ・サーバ・アーキテクチャ、実施形態、およびプラットフォームの多様性である。本発明のコネクタは、グループウェア・サーバへのフロント・エンドまたはゲートウェイとして働くことができる。
【０３３２】
図４９に、実際の商品が、売り手から買い手に出荷され、さまざまな形の電子支払いおよび保護された電子支払いが、売り手に支払うために買い手によって使用され、銀行および金融機関が、本明細書に記載のコネクタを介して接続される、商業トランザクションを示す。具体的に言うと、商人または製造業者の売り手４１０１が、「ヒストリ」を有しない顧客４１０３に製品を売る。製品が、出荷される４６０５。しかし、買い手である顧客４１０３は、商品を受け取り、検査し、承認し、「受け入れる」まで金を手放すことを望まず、売り手４１０１は、支払われるまで商品の制御を放棄することを望まない。この基本的な商取引の衝突が、さまざまなパラダイムにつながり、そのほとんどが、ハード・コピーの「擬似金銭」またはある形から別の形への法律文書を伴う。現在、財務トランザクションは、最も頻繁に電子資金転送と、メモ、法律文書、流通証券、荷為替手形、支払い指図書、信用状、倉庫証券、荷渡指図書、船荷証券（商品に対する請求権を含む、すなわち、商品の権利または物理的管理を運搬人または名前を指定された人に譲渡することを意味する権利証券）、および商品の担保権を伴うトランザクションである。通常、顧客４１０３は、売り手４１０１に払い渡す証書を実行し、買い手の銀行４１２１に、売り手の銀行４１２５を介して売り手４１０１に買い手の金を向ける。通常、これは、前に互いに取引した売り手と買い手の間の、前に互いに取引した、同一のまたは互換性があるソフトウェア・アプリケーションを使用している銀行または金融機関を介して扱われる、単純な電子トランザクションである。しかし、これらの事前条件が満足されない特別の場合には、本発明のコネクタによって、トランザクションの電子的な銀行間側を容易にする。
【０３３３】
単一のレベルのアプリケーション・プログラム・インターフェースまたはコンバータを有する応用例に関して本発明を説明し、図示してきたが、そのようなアプリケーション・プログラム・インターフェースまたはコンバータが、処理階層内のさまざまなレベルに、たとえばウェブ・クライアントとウェブ・サーバの間、ウェブ・サーバとアプリケーション・サーバの間、アプリケーション・サーバとデータベース・サーバの間、およびアプリケーション・サーバまたはデータベース・サーバまたはその両方とさまざまな特殊リポジトリの間に、存在することができることを理解されたい。
【０３３４】
本発明を、ある好ましい実施形態と、個々のクライアントおよび個々のサーバを有する例示を用いて説明し、図示してきたが、グループウェア・アプリケーションによって例証されるように、複数のクライアント、複数のサーバ、およびクライアントとサーバの両方として機能するアプリケーションが存在することができ、リッチ・トランザクションのシステム内で、アプリケーション・サーバ、データ・サーバ、およびデータベースの複数の並列の線または複数の階層レベルあるいはその両方が存在することができることも理解されたい。
【０３３５】
本発明を、ある好ましい実施形態および例示に関して説明してきたが、これによって本発明の範囲を制限することは意図されておらず、本発明の範囲は、請求項のみによって制限される。
【図面の簡単な説明】
【図１】
ＮｅｔｓｃａｐｅまたはＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒブラウザ、ＳｕｎＳｏｌａｒｉｓサーバ上のＮｅｔ．Ｃｏｍｍｅｒｃｅ、データベース・サーバ上のＯｒａｃｌｅおよびＤＢ２、ＡＩＸで稼動するＳＡＰ、ＣＩＣＳ　３９０サーバ、ＩＭＳ　３９０サーバ、Ｓ／３９０プラットフォーム上のＤＢ２およびＤＬ／Ｉ、Ｗｉｎｄｏｗｓ（Ｒ）２０００クライアント、およびＨＰＵｎｉｘ（Ｒ）サーバ上で稼動するＢａａｎを含む、複数のアプリケーション・コンポーネントを有するシステムを示す図である。
【図２】
実行時のエンタープライズ・アプリケーション統合を促進するために共通アプリケーション・メタモデルのメタデータ・リポジトリへの入力としてのメッセージ・セット、ＳＱＬストアド・プロシージャ、レガシ・アプリケーション、およびプログラミング言語の役割を示す図である。
【図３】
３種類のメタモデルすなわち、呼出しメタモデル、アプリケーションドメイン・インターフェース・メタモデル、および言語メタモデルからなる本発明の共通アプリケーション・メタモデルを示す図である。所与のアプリケーションドメイン・メタモデルについて、１つまたは複数の言語メタモデルを使用することができ、０個以上の呼出しメタモデルを設けることができる。
【図４】
ＯＴＭＡ呼出しメタモデル、ＩＭＳトランザクション・メッセージ・メタモデル・アプリケーション・インターフェースを伴い、ＣＯＢＯＬメタモデル、Ｃメタモデル、または他の言語メタモデルを使用することができる、ＩＭＳ　ＯＴＭＡメタモデルを示す図である。
【図５】
アプリケーション・プログラミング・インターフェースを記述したＸＭＬ文書を生成するのにツールをどのように使用することができるかを示す図である。まず、オブジェクト・モデルすなわちＣＡＭメタモデルを作成して、アプリケーション・サーバに関するインターフェース定義を取り込む。その後、ツールが、アプリケーション・プログラムのソース定義を読み取り、解析し、オブジェクト・モデルの情報をリポジトリから検索することによってＸＭＬ文書を生成する。
【図６】
共通アプリケーション・メタモデルＲｏｓｅファイル、たとえばＣＯＢＯＬメタモデル、ＰＬ／Ｉメタモデル、ＭＦＳメタモデル、ＢＭＳメタモデル、および類似物をツールキットに読み取って、Ｒｏｓｅモデル用のＤＴＤ、ＸＭＬスキーマ、およびＪａｖａ（Ｒ）コードを生成する、開発フェーズのシナリオを示す図である。ＣＯＢＯＬソース・ファイル、ＰＬ／Ｉソース・ファイル、ＭＦＳソース・ファイル、ＢＭＳソース・ファイル、および類似物としてのアプリケーションのソース・ファイルが、インポータに読み込まれる。インポータは、ソース・コードを解析し、アプリケーション・ソース・ファイルのＲｏｓｅモデルのＪａｖａ（Ｒ）コードを読み込むことによって、出力としてＸＭＩインスタンス・ファイルすなわちＸＭＬ文書を生成する。
【図７】
アプリケーション・コンポーネントの、フロー・モデルを含むイベント・ベース・メッセージング・モデルへの統合を可能にする、アプリケーション・インターフェースのメタモデルを示す図である。フローおよびメッセージング・ミドルウェアが、アプリケーション・インターフェースを介してアプリケーションを呼び出す。これらのインターフェースは、それを介してすべての入出力がミドルウェアに接続されるアプリケーションへのアクセス点である。インターフェースは、アプリケーション・インターフェース・メタモデルに関して記述される。メタモデルによる変換処理は、ソース／クライアント・アプリケーション、ターゲット・アプリケーション、またはゲートウェイで行うことができる。
【図８】
実行時中の共通アプリケーション・メタモデルの適用を示す図である。図からわかるように、ＣＡＭモデルが、バックエンドＩＭＳアプリケーションとウェブ・ファイル（たとえばＳＯＡＰ準拠ＸＭＬ文書）の間の接続性を促進する。これは、モデルに取り込まれた情報を使用して、図示の混合言語環境で、あるプラットフォームから別のプラットフォームへのデータ変換を行うことによって達成される。
【図９】
ＴｙｐｅＤｅｓｃｒｉｐｔｏｒメタモデルが、全体的なデータ構造体名およびフィールド名の言語固有メタモデルを用い、言語モデルに存在する集約関連を複製せずに、実行時データ変換の処方またはテンプレートして使用される、ＴＤＬａｎｇ基本クラスを示す図である。
【図１０】
ＴｙｐｅＤｅｓｃｒｉｐｔｏｒメタモデルのＭ２レベルのＭＯＦクラス・インスタンスを示す図である。
【図１１】
ＴｙｐｅＤｅｓｃｒｉｐｔｏｒメタモデルのＭ２レベルのＭＯＦクラス・インスタンスを示す図である。
【図１２】
ＴｙｐｅＤｅｓｃｒｉｐｔｏｒメタモデルのＭ２レベルのＭＯＦクラス・インスタンスを示す図である。
【図１３】
ＴＤＬａｎｇメタモデルのＴＤＬａｎｇＥｌｅｍｅｎｔとＴｙｐｅＤｅｓｃｒｉｐｔｏｒメタモデルのＰｌａｔｆｏｒｍＣｏｍｐｉｌｅｒＴｙｐｅとの間の関連を示す図である。
【図１４】
ＴｙｐｅＤｅｓｃｒｉｐｔｏｒメタモデルのさまざまな列挙型、たとえば、ｓｉｇｎＣｏｄｉｎｇ、ｌｅｎｇｔｈＥｎｃｏｄｉｎｇ、ｆｌｏａｔＴｙｐｅ、ａｃｃｅｓｓｏｒ、ｐａｃｋｅｄＤｅｃｉｍａｌＳｉｇｎ、およびｂｉｔＭｏｄｅｌＰａｄを示す図である。
【図１５】
コネクタ・インターフェースを表すデータ構造体セマンティクスを定義するためのＣＯＢＯＬメタモデルを示す図である。このメタモデルは、Ｍ２レベルのＭＯＦクラス・インスタンスでもある。
【図１６】
コネクタ・インターフェースを表すデータ構造体セマンティクスを定義するためのＣＯＢＯＬメタモデルを示す図である。このメタモデルは、Ｍ２レベルのＭＯＦクラス・インスタンスでもある。
【図１７】
ＴＤＬａｎｇＣｌａｓｓｉｆｉｅｒ、ＴＤＬａｎｇｕａｇｅＣｏｍｐｏｓｅｄＴｙｐｅ、およびＴＤＬａｎｇＥｌｅｍｅｎｔである、ＣＯＢＯＬメタモデルとＴＤＬａｎｇ基本クラスの間の関連を示す図である。
【図１８】
ＣＯＢＯＬメタモデルのＣＯＢＯＬＵｓａｇｅＶａｌｕｅｓの列挙を示す図である。
【図１９】
コネクタ・インターフェースを表すデータ構造体を定義するためにアプリケーション・プログラムによって使用可能なＰＬ／Ｉ言語メタモデルを示す図である。このメタモデルは、Ｍ２レベルのＭＯＦクラス・インスタンスである。
【図２０】
コネクタ・インターフェースを表すデータ構造体を定義するためにアプリケーション・プログラムによって使用可能なＰＬ／Ｉ言語メタモデルを示す図である。このメタモデルは、Ｍ２レベルのＭＯＦクラス・インスタンスである。
【図２１】
コネクタ・インターフェースを表すデータ構造体を定義するためにアプリケーション・プログラムによって使用可能なＰＬ／Ｉ言語メタモデルを示す図である。このメタモデルは、Ｍ２レベルのＭＯＦクラス・インスタンスである。
【図２２】
ＰＬ／ＩメタモデルについてはＴＤＬａｎｇＣｌａｓｓｉｆｉｅｒ、ＴＤＬａｎｇｕａｇｅＣｏｍｐｏｓｅｄＴｙｐｅ、およびＴＤＬａｎｇｕａｇｅＥｌｅｍｅｎｔである、ＰＬ／ＩメタモデルとＴＤＬａｎｇ基本クラスの関連を示す図である。
【図２３】
ＰＬ／ＩメタモデルのＭｏｄｅＶａｌｕｅｓ、ＢａｓｅＶａｌｕｅｓ、ＬｅｎｇｔｈＴｙｐｅｓ、およびＳｔｒｉｎｇＴｙｐｅＶａｌｕｅｓの列挙を示す図である。
【図２４】
Ｃ Ｍａｉｎ言語メタモデルを示す図である。
【図２５】
ＴＤＬａｎｇＣｌａｓｓｉｆｉｅｒ、ＴＤＬａｎｇＣｏｍｐｏｓｅｄＴｙｐｅ、およびＴＤＬａｎｇＥｌｅｍｅｎｔである、ＣメタモデルとＴＤＬａｎｇ基本クラスの間の関連を示す図である。
【図２６】
Ｃ言語メタモデルのＴｙｐｅｄＥｌｅｍｅｎｔ態様を示す図である。
【図２７】
Ｃ言語メタモデルでのユーザ定義データ型を含む、Ｃメタモデルのユーザ定義データ型を示す図である。
【図２８】
Ｃ言語メタモデルでのＤａｔａｔｙｐｅ−ＳｔｒｉｎｇおよびＤａｔａｔｙｐｅ−Ｉｎｔｅｇｅｒ、ならびにＤｉｒｅｃｔｉｏｎＫｉｎｄの引数および戻り値の列挙およびＢｏｏｌｅａｎデータ型のｔｒｕｅおよびｆａｌｓｅの列挙を示す図である。
【図２９】
Ｃ Ｍａｉｎメタモデルから継承するＣ＋＋ Ｍａｉｎメタモデルを示す図である。このモデルには、Ｃ＋＋メタモデルのＤｅｒｉｖｅｄ、Ｓｔｒｕｃｔｕｒｅｄ、ＢｅｈａｖｉｏｒａｌＦｅａｔｕｒｅｓ、Ｆｉｅｌｄ、およびＤｅｒｉｖａｂｌｅＴｙｐｅｓが含まれる。
【図３０】
Ｃ＋＋メタモデルの可視性型の列挙を示す図である。Ｃ＋＋が、オブジェクト指向言語であり、オブジェクト指向プログラミングに有用であり、ｐｕｂｌｉｃ、ｐｒｉｖａｔｅ、およびｐｒｏｔｅｃｔｅｄの可視性をサポートすることに留意されたい。
【図３１】
３種類のトランザクション・メッセージすなわち、プレフィックス付きのＩＭＳ−ＯＴＭＡメッセージ、デフォルトＯＴＭＡプレフィックスをＩＭＳが構築することができるプレフィックスなしのＩＭＳメッセージ、およびアプリケーション・プログラムに直接に送ることができるＩＭＳ基本メッセージを含む、ＩＭＳトランザクション・メッセージのメタモデルを示す図である。
【図３２】
ＯＴＭＡプレフィックス・メタデータ・モデルを示す図である。
【図３３】
制御データ定義データ型のＯＴＭＡプレフィックスを示す図である。
【図３４】
状態定義データ型のＯＴＭＡプレフィックスを示す図である。
【図３５】
セキュリティ定義型のＯＴＭＡプレフィックスを示す図である。
【図３６】
ＩＭＳメタモデルのＩＭＳメッセージ・プリミティブを示す図である。
【図３７】
コネクタ・インターフェースを表すデータ構造体セマンティクスを定義するＨｉｇｈＬｅｖｅｌ Ａｓｓｅｍｂｌｙ Ｌａｎｇｕａｇｅ（ＨＬＡＳＭ）メタモデルを示す図である。このメタモデルは、Ｍ２レベルのＭＯＦクラス・インスタンスでもある。
【図３８】
ＴＤＬａｎｇＣｌａｓｓｉｆｉｅｒ、ＴＤＬａｎｇｕａｇｅＣｏｍｐｏｓｅｄＴｙｐｅ、およびＴＤＬａｎｇＥｌｅｍｅｎｔである、ＨＬＡＳＭメタモデルとＴＤＬａｎｇ基本クラスの間の関連を示す図である。
【図３９】
ＨＬＡＳＭメタモデルでのＨＬＡＳＭ使用値の列挙を示す図である。
【図４０】
コネクタ・インターフェースを表すデータ構造体を定義するためにアプリケーション・プログラムによって使用可能なＣＩＣＳ　ＢＭＳ言語メタモデルを示す図である。
【図４１】
ＢＭＳＭｅｔａＭｏｄｅｌの属性、フィールド、属性値、およびマップを示す図である。
【図４２】
ＢＭＳＭｅｔａＭｏｄｅｌの属性、フィールド、属性値、およびマップを示す図である。
【図４３】
コネクタ・インターフェースを表すデータ構造体を定義するためにアプリケーション・プログラムによって使用可能なＭＦＳ言語メタモデルを示す図である。
【図４４】
ＭＦＳメタモデルのクラスの間の関連を示す図である。
【図４５】
ＭＦＳメタモデルのＭｏｄｅＶａｌｕｅｓ、ＢａｓｅＶａｌｕｅｓ、ＬｅｎｇｔｈＴｙｐｅｓ、およびＳｔｒｉｎｇＴｙｐｅＶａｌｕｅｓの列挙を示す図である。
【図４６】
ＭＦＳメタモデルのＭｏｄｅＶａｌｕｅｓ、ＢａｓｅＶａｌｕｅｓ、ＬｅｎｇｔｈＴｙｐｅｓ、およびＳｔｒｉｎｇＴｙｐｅＶａｌｕｅｓの列挙を示す図である。
【図４７】
たとえば注文が端末で入力され、ウェブ・サーバに渡され、ウェブ・サーバを介して製造業者のアプリケーション・サーバに渡される、「リッチ」トランザクションに関する単純化されたネットワーク構成を示す図である。製造業者のアプリケーション・サーバは、それ自体のデータベース・サーバならびに、本明細書に記載のコネクタによって透過的に接続されたそのベンダの似ていない非互換のデータベース・サーバおよびデータベースを介して検索し、構成要素の状況、価格、および配送日付を照会し、注文を満足するのに必要な構成要素の注文を行う。
【図４８】
複数の異なるプラットフォームで稼動し、本明細書に記載の共通アプリケーション・メタモデルを使用して接続される、複数のグループ・ウェア・アプリケーションにまたがって分散されたグループ・ウェア・セッションを示す図である。
【図４９】
実際の商品が売り手から買い手に出荷され、さまざまな形の電子支払いおよび保護された電子支払いが、売り手に支払うために買い手によって使用され、銀行および金融機関が、本明細書に記載の共通アプリケーション・メタモデルを使用して接続される、商取引を示す図である。

Claims (67)

  1. エンド・ユーザ・アプリケーションおよびアプリケーション・サーバでアプリケーション要求を処理する方法であって、
    ａ）第１アプリケーション・プログラムを用いて第１言語で前記エンド・ユーザ・アプリケーション上で前記アプリケーション要求を開始するステップと、
    ｂ）前記アプリケーション要求を前記サーバに送信し、前記アプリケーション要求を前記第１エンド・ユーザ・アプリケーションの前記第１言語から前記アプリケーション・サーバ上で稼動する言語に変換するステップと、
    ｃ）前記アプリケーション・サーバ上で前記アプリケーション要求を処理するステップと、
    ｄ）前記アプリケーション要求に対する応答を、前記アプリケーション・サーバから前記エンド・ユーザ・アプリケーションに送信し、前記アプリケーション要求に対する前記応答を、前記アプリケーション・サーバ上で稼動する前記言語から前記第１エンド・ユーザ・アプリケーションの前記第１言語に変換するステップと
    を含み、
    ｅ）前記エンド・ユーザ・アプリケーションおよび前記アプリケーション・サーバが、その間の少なくとも１つのコネクタを有し、（ｉ）前記アプリケーション要求を、ソース言語としての前記第１エンド・ユーザ・アプリケーションの前記第１言語からターゲット言語としての前記アプリケーション・サーバ上で稼動する前記言語に変換するステップと、（ｉｉ）前記アプリケーション要求に対する応答を、ソース言語としての前記アプリケーション・サーバ上で稼動する前記言語からターゲット言語としての前記第１エンド・ユーザ・アプリケーションの前記第１言語に変換するステップとのそれぞれが、
    １）各々のソース言語およびターゲット言語のコネクタ・メタモデルを呼び出すステップと、
    ２）前記各々のソース言語およびターゲット言語のそれぞれのメタモデル・データを前記コネクタ・メタモデルに移植するステップと、
    ３）前記ソース言語を前記ターゲット言語に変換するステップと
    を含む、方法。
  2. 前記エンド・ユーザ・アプリケーションが、ウェブ・ブラウザである、請求項１に記載の方法。
  3. 前記エンド・ユーザ・アプリケーションが、ウェブ・サーバを介して前記アプリケーション・サーバに接続され、前記ウェブ・サーバが、コネクタを含む、請求項２に記載の方法。
  4. 前記メタモデル・メタデータが、呼出しメタモデル・メタデータ、アプリケーション・ドメイン・インターフェース・メタモデル・メタデータ、および型記述子メタモデル・メタデータを含む、請求項１に記載の方法。
  5. 前記呼出しメタモデル・メタデータが、メッセージ制御情報と、セキュリティ・データと、トランザクショナル・セマンティクスと、トレースおよびデバッグ情報と、事前条件リソースと、事後条件リソースと、ユーザ・データとからなる群から選択される、請求項４に記載の方法。
  6. 前記アプリケーション・ドメイン・インターフェース・メタモデル・メタデータが、入力パラメータ・シグニチャ、出力パラメータ・シグニチャ、および戻りの型を含む、請求項４に記載の方法。
  7. 前記アプリケーション・ドメイン・インターフェース・メタモデル・メタデータが、さらに、言語メタモデル・メタデータを含む、請求項４に記載の方法。
  8. 前記言語メタモデル・メタデータが、ソース言語とターゲット言語との間のマッピングを含む、請求項７に記載の方法。
  9. 前記ソース言語または前記ターゲット言語の１つが、オブジェクト指向であり、前記ターゲット言語または前記ソース言語の他方が、オブジェクト指向でなく、前記言語メタモデル・メタデータが、カプセル化されたオブジェクトをコードおよびデータにマッピングする、請求項８に記載の方法。
  10. 前記言語メタモデル・メタデータが、オブジェクト継承を参照およびポインタにマッピングする、請求項９に記載の方法。
  11. 前記ソース言語および前記ターゲット言語が、異なるオブジェクト指向言語であり、前記言語メタモデル・メタデータが、カプセル化されたコードおよびデータを、前記ソース言語と前記ターゲット言語との間でマッピングする、請求項８に記載の方法。
  12. 前記型記述子メタモデル・メタデータが、物理的実現、ストレージ・マッピング、データ型、データ構造体、および実現制約を定義する、請求項４に記載の方法。
  13. トランザクションが、複数の個々のトランザクションを含むリッチ・トランザクションであり、さらに、１つのエンド・ユーザ・アプリケーションおよび複数のアプリケーション・サーバで前記複数の個々のトランザクションを処理するステップを含む、請求項１に記載の方法。
  14. 個々のアプリケーション・サーバの間で個々のトランザクションを渡すステップを含む、請求項１３に記載の方法。
  15. 前記ソース言語または前記ターゲット言語の１つが、ＣおよびＣ＋＋からなる群から選択される、請求項１に記載の方法。
  16. クライアント、サーバ、およびそれらの間の少なくとも１つのコネクタを含むトランザクション処理システムであって、
    ａ）前記クライアントが、エンド・ユーザ・アプリケーションを有し、第１アプリケーション・プログラムを用いて第１言語で前記サーバとのアプリケーション要求を開始し、前記アプリケーション要求を前記サーバに送信するように制御され、構成され、
    ｂ）前記コネクタが、前記クライアントから前記アプリケーション要求を受信し、前記アプリケーション要求を前記クライアント上で稼動する前記第１エンド・ユーザ・アプリケーションの前記第１言語から前記サーバ上で稼動する言語に変換するように構成され、制御され、
    ｃ）前記サーバが、前記変換されたアプリケーション要求を前記コネクタから受信し、前記サーバに常駐する第２アプリケーション・プログラムを用いて第２言語で前記アプリケーション要求を処理し、その後、前記アプリケーション要求に対する応答を、前記コネクタを介して前記クライアント上の前記第１アプリケーション・プログラムに送信するように構成され、制御され、
    ｄ）前記コネクタが、前記サーバから前記アプリケーション要求に対する応答を受信し、前記アプリケーション要求に対する応答を前記アプリケーション・サーバ上で稼動する前記言語から前記クライアント上で稼動する前記第１アプリケーション・プログラムの前記第１言語に変換するように構成され、制御され、
    ｅ）前記クライアントと前記サーバの間のコネクタが、
    １）メタモデル・メタデータ・リポジトリから各々のソース言語およびターゲット言語のコネクタ・メタモデルを検索するステップと、
    ２）前記各々のソース言語およびターゲット言語のそれぞれの前記メタモデル・メタデータ・リポジトリからのメタモデル・データを前記コネクタ・メタモデルに移植するステップと、
    ３）前記検索され移植されたコネクタ・メタモデルを呼び出し、前記ソース言語を前記ターゲット言語に変換するステップと
    を含む方法によって、（ｉ）前記アプリケーション要求を、ソース言語としての前記クライアント上の前記クライアント・アプリケーションの前記第１言語からターゲット言語としての前記アプリケーション・サーバ上で稼動する前記言語に変換し、（ｉｉ）前記アプリケーション要求に対する前記応答を、ソース言語としての前記アプリケーション・サーバ上で稼動する前記言語からターゲット言語としての前記クライアント上で稼動する前記クライアント・アプリケーションの前記第１言語に変換するように構成され、制御される
    トランザクション処理システム。
  17. 前記エンド・ユーザ・アプリケーションが、ウェブ・ブラウザである、請求項１６に記載のシステム。
  18. 前記エンド・ユーザ・アプリケーションが、ウェブ・サーバを介して前記アプリケーション・サーバに接続され、前記ウェブ・サーバが、コネクタを含む、請求項１７に記載のシステム。
  19. 前記メタモデル・メタデータが、呼出しメタモデル・メタデータ、アプリケーション・ドメイン・インターフェース・メタモデル・メタデータ、および型記述子メタモデル・メタデータを含む、請求項１６に記載のシステム。
  20. 前記呼出しメタモデル・メタデータが、メッセージ制御情報と、セキュリティ・データと、トランザクショナル・セマンティクスと、トレースおよびデバッグ情報と、事前条件リソースと、事後条件リソースと、ユーザ・データとからなる群から選択される、請求項１９に記載のシステム。
  21. 前記アプリケーション・ドメイン・インターフェース・メタモデル・メタデータが、入力パラメータ・シグニチャ、出力パラメータ・シグニチャ、および戻りの型を含む、請求項１９に記載のシステム。
  22. 前記アプリケーション・ドメイン・インターフェース・メタモデル・メタデータが、さらに、言語メタモデル・メタデータを含む、請求項１９に記載のシステム。
  23. 前記言語メタモデル・メタデータが、ソース言語とターゲット言語との間のマッピングを含む、請求項２２に記載のシステム。
  24. 前記ソース言語または前記ターゲット言語の１つが、オブジェクト指向であり、前記ターゲット言語または前記ソース言語の他方が、オブジェクト指向でなく、前記言語メタモデル・メタデータが、カプセル化されたオブジェクトをコードおよびデータにマッピングする、請求項２３に記載のシステム。
  25. 前記言語メタモデル・メタデータが、オブジェクト継承を参照およびポインタにマッピングする、請求項２４に記載のシステム。
  26. 前記ソース言語および前記ターゲット言語が、異なるオブジェクト指向言語であり、前記言語メタモデル・メタデータが、カプセル化されたコードおよびデータを、前記ソース言語と前記ターゲット言語との間でマッピングする、請求項２４に記載のシステム。
  27. 前記型記述子メタモデル・メタデータが、物理的実現、ストレージ・マッピング、データ型、データ構造体、および実現制約を定義する、請求項２０に記載のシステム。
  28. 前記システムが、複数のアプリケーション・サーバを有し、リッチ・トランザクションを処理するように構成され、制御される、請求項１６に記載のシステム。
  29. 前記ソース言語または前記ターゲット言語の１つが、ＣおよびＣ＋＋からなる群から選択される、請求項１６に記載のシステム。
  30. クライアント・アプリケーションと対話するように構成され、制御され、サーバと、前記サーバと前記クライアント・アプリケーションとの間の少なくとも１つのコネクタとを含むトランザクション処理システムであって、前記クライアントが、エンド・ユーザ・アプリケーションを有し、前記第１アプリケーション・プログラムを用いて第１言語で前記サーバに関するアプリケーション要求を開始し、前記アプリケーション要求を前記サーバに送信するように構成され、制御され、
    ａ）前記コネクタが、前記クライアントからアプリケーション要求を受信し、前記アプリケーション要求を前記クライアント上で稼動する前記第１エンド・ユーザ・アプリケーションの前記第１言語から前記サーバ上で稼動する言語に変換するように構成され、制御され、
    ｂ）前記サーバが、前記変換されたアプリケーション要求を前記コネクタから受信し、前記アプリケーション要求を前記サーバ上に常駐する第２アプリケーション・プログラムを用いて第２言語で処理し、その後、前記アプリケーション要求に対する応答を、前記コネクタを介して前記クライアント上の前記第１アプリケーション・プログラムに送信するように構成され、制御され、
    ｃ）前記コネクタが、前記アプリケーション要求に対する応答を前記サーバから受信し、前記アプリケーション要求に対する応答を前記アプリケーション・サーバ上で稼動する前記言語から前記クライアント上で稼動する前記第１アプリケーション・プログラムの前記第１言語に変換するように構成され、制御され、
    ｄ）前記クライアントと前記サーバとの間のコネクタが、
    １）メタモデル・メタデータ・リポジトリから各々のソース言語およびターゲット言語のコネクタ・メタモデル・メタデータを検索するステップと、
    ２）前記メタデータ・メタモデル・リポジトリからの前記各々のソース言語およびターゲット言語のそれぞれのメタモデル・データを前記コネクタ・メタモデルに移植し、前記検索され移植されたコネクタ・メタモデルを呼び出すステップと、
    ３）前記ソース言語を前記ターゲット言語に変換するステップと
    を含む方法によって、（ｉ）前記アプリケーション要求を、ソース言語としての前記クライアント上の前記クライアント・アプリケーションの前記第１言語からターゲット言語としての前記アプリケーション・サーバ上で稼動する前記言語に変換し、（ｉｉ）前記アプリケーション要求に対する前記応答を、ソース言語としての前記アプリケーション・サーバ上で稼動する前記言語からターゲット言語としての前記クライアント上で稼動する前記クライアント・アプリケーションの前記第１言語に変換するように構成され、制御される
    トランザクション処理システム。
  31. 前記エンド・ユーザ・アプリケーションが、ウェブ・ブラウザである、請求項３０に記載のシステム。
  32. 前記エンド・ユーザ・アプリケーションが、ウェブ・サーバを介して前記アプリケーション・サーバに接続され、前記ウェブ・サーバが、コネクタを含む、請求項３１に記載のシステム。
  33. 前記メタモデル・メタデータが、呼出しメタモデル・メタデータ、アプリケーション・ドメイン・インターフェース・メタモデル・メタデータ、および型記述子メタモデル・メタデータを含む、請求項３０に記載のシステム。
  34. 前記呼出しメタモデル・メタデータが、メッセージ制御情報と、セキュリティ・データと、トランザクショナル・セマンティクスと、トレースおよびデバッグ情報と、事前条件リソースと、事後条件リソースと、ユーザ・データとからなる群から選択される、請求項３３に記載のシステム。
  35. 前記アプリケーション・ドメイン・インターフェース・メタモデル・メタデータが、入力パラメータ・シグニチャ、出力パラメータ・シグニチャ、および戻りの型を含む、請求項３３に記載のシステム。
  36. 前記アプリケーション・ドメイン・インターフェース・メタモデル・メタデータが、さらに、言語メタモデル・メタデータを含む、請求項３３に記載のシステム。
  37. 前記言語メタモデル・メタデータが、ソース言語とターゲット言語との間のマッピングを含む、請求項３６に記載のシステム。
  38. 前記ソース言語または前記ターゲット言語の１つが、オブジェクト指向であり、前記ターゲット言語または前記ソース言語の他方が、オブジェクト指向でなく、前記言語メタモデル・メタデータが、カプセル化されたオブジェクトをコードおよびデータにマッピングする、請求項３７に記載のシステム。
  39. 前記ソース言語および前記ターゲット言語が、異なるオブジェクト指向言語であり、前記言語メタモデル・メタデータが、カプセル化されたコードおよびデータを、前記ソース言語と前記ターゲット言語との間でマッピングする、請求項３７に記載のシステム。
  40. 前記言語メタモデル・メタデータが、オブジェクト継承を参照およびポインタにマッピングする、請求項３９に記載のシステム。
  41. 前記型記述子メタモデル・メタデータが、物理的実現、ストレージ・マッピング、データ型、データ構造体、および実現制約を定義する、請求項３３に記載のシステム。
  42. 前記システムが、複数のアプリケーション・サーバを有し、リッチ・トランザクションを処理するように構成され、制御される、請求項３０に記載のシステム。
  43. 前記ソース言語または前記ターゲット言語の１つが、ＣおよびＣ＋＋からなる群から選択される、請求項３０に記載のシステム。
  44. 複数のエンド・ユーザ・アプリケーションを有するグループウェア・システムであって、前記エンド・ユーザ・アプリケーションのそれぞれが、電子メール・クライアント、コンテンツ・データベース・クライアント、およびコンテンツ複製クライアントを含み、前記システムが、さらに、電子メール・サーバ、コンテンツ・データベース・サーバ、およびコンテンツ複製サーバを含み、前記グループウェア・システムが、異なるエンド・ユーザ・アプリケーションの間で通信するように構成され、制御され、前記グループウェア・システムが、サーバとエンド・ユーザ・アプリケーションとの間の少なくとも１つのコネクタを含み、前記エンド・ユーザ・アプリケーションが、第１アプリケーション・プログラムを用いて第１言語でサーバに関係するように制御され、構成され、前記サーバが、第２言語で前記クライアントに関係するように構成され、制御され、
    ａ）前記コネクタが、前記エンド・ユーザ・アプリケーションからアプリケーション要求を受信し、前記アプリケーション要求を、前記第１エンド・ユーザ・アプリケーションの前記第１言語から前記サーバ上で稼動する第２言語に変換するように構成され、制御され、
    ｂ）前記サーバが、前記変換されたアプリケーション要求を前記コネクタから受信し、サーバ上で稼動する第２アプリケーション・プログラムを用いて第２言語で前記アプリケーション要求を処理し、その後、前記アプリケーション要求に対する応答を前記コネクタを介して前記エンド・ユーザ・アプリケーションに送信するように構成され、制御され、
    ｃ）前記コネクタが、前記サーバから前記アプリケーション要求に対する前記応答を受信し、前記アプリケーション要求に対する応答を、前記アプリケーション・サーバ上で稼動する前記言語から前記エンド・ユーザ・アプリケーションの前記第１言語に変換するように構成され、制御され、
    ｄ）前記エンド・ユーザ・アプリケーション・プログラムと前記サーバとの間のコネクタが、
    １）各々のソース言語およびターゲット言語のコネクタ・メタモデル・メタデータをメタモデル・メタデータ・リポジトリから検索するステップと、
    ２）前記メタモデル・メタデータ・リポジトリから前記各々のソース言語およびターゲット言語のそれぞれのメタモデル・データを前記コネクタ・メタモデルに移植し、前記検索され移植されたコネクタ・メタモデルを呼び出すステップと、
    ３）前記ソース言語を前記ターゲット言語に変換するステップと
    を含む方法によって、（ｉ）前記アプリケーション要求を、ソース言語としての前記エンド・ユーザ・アプリケーションの前記第１言語からターゲット言語としての前記アプリケーション・サーバ上で稼動する前記言語に変換し、（ｉｉ）前記アプリケーション要求に対する前記応答を、ソース言語としての前記アプリケーション・サーバ上で稼動する前記言語からターゲット言語としての前記エンド・ユーザ・アプリケーションの前記言語に変換するように構成され、制御される
    グループウェア・システム。
  45. 前記メタモデル・メタデータが、呼出しメタモデル・メタデータ、アプリケーション・ドメイン・インターフェース・メタモデル・メタデータ、および型記述子メタモデル・メタデータを含む、請求項４３に記載のグループウェア・システム。
  46. 前記呼出しメタモデル・メタデータが、メッセージ制御情報と、セキュリティ・データと、トランザクショナル・セマンティクスと、トレースおよびデバッグ情報と、事前条件リソースと、事後条件リソースと、ユーザ・データとからなる群から選択される、請求項４３に記載のグループウェア・システム。
  47. 前記アプリケーション・ドメイン・インターフェース・メタモデル・メタデータが、入力パラメータ・シグニチャ、出力パラメータ・シグニチャ、および戻りの型を含む、請求項４５に記載のグループウェア・システム。
  48. 前記アプリケーション・ドメイン・インターフェース・メタモデル・メタデータが、さらに、言語メタモデル・メタデータを含む、請求項４５に記載のグループウェア・システム。
  49. 前記言語メタモデル・メタデータが、ソース言語とターゲット言語との間のマッピングを含む、請求項４８に記載のグループウェア・システム。
  50. 前記ソース言語または前記ターゲット言語の１つが、オブジェクト指向であり、前記ターゲット言語または前記ソース言語の他方が、オブジェクト指向でなく、前記言語メタモデル・メタデータが、カプセル化されたオブジェクトをコードおよびデータにマッピングする、請求項４９に記載のグループウェア・システム。
  51. 前記ソース言語および前記ターゲット言語が、異なるオブジェクト指向言語であり、前記言語メタモデル・メタデータが、カプセル化されたコードおよびデータを、前記ソース言語と前記ターゲット言語との間でマッピングする、請求項４９に記載のグループウェア・システム。
  52. 前記言語メタモデル・メタデータが、オブジェクト継承を参照およびポインタにマッピングする、請求項４９に記載のグループウェア・システム。
  53. 前記型記述子メタモデル・メタデータが、物理的実現、ストレージ・マッピング、データ型、データ構造体、および実現制約を定義する、請求項４４に記載のグループウェア・システム。
  54. 前記ソース言語または前記ターゲット言語の１つが、ＣおよびＣ＋＋からなる群から選択される、請求項４４に記載のグループウェア・システム。
  55. 呼出しメタモデル・メタデータ、アプリケーション・ドメイン・インターフェース・メタモデル・メタデータ、および言語メタモデル・メタデータと、ソース言語メタモデル・メタデータおよびターゲット言語メタモデル・メタデータのメタモデル・メタデータ・リポジトリを構築するコンピュータ命令とを有する記憶媒体を含むプログラム製品。
  56. さらに、前記メタモデル・メタデータからコネクタ・スタブを構築するコンピュータ命令を含む、請求項５５に記載のプログラム製品。
  57. １）前記メタモデル・メタデータ・リポジトリから各々のソース言語およびターゲット言語のコネクタ・メタモデル・メタデータを検索するステップと、
    ２）前記メタデータ・メタモデル・リポジトリからの前記各々のソース言語およびターゲット言語のそれぞれのメタモデル・データを前記コネクタ・メタモデルに移植し、前記検索され移植されたコネクタ・メタモデルを呼び出すステップと、
    ３）前記ソース言語を前記ターゲット言語に変換するステップと
    を実行するコネクタを構築するコンピュータ命令をさらに含む、請求項５５に記載のプログラム製品。
  58. 前記リポジトリ内の前記メタモデル・メタデータが、呼出しメタモデル・メタデータ、アプリケーション・ドメイン・インターフェース・メタモデル・メタデータ、および型記述子メタモデル・メタデータを含む、請求項５７に記載のプログラム製品。
  59. 前記呼出しメタモデル・メタデータが、メッセージ制御情報と、セキュリティ・データと、トランザクショナル・セマンティクスと、トレースおよびデバッグ情報と、事前条件リソースと、事後条件リソースと、ユーザ・データとからなる群から選択される、請求項５８に記載のプログラム製品。
  60. 前記アプリケーション・ドメイン・インターフェース・メタモデル・メタデータが、入力パラメータ・シグニチャ、出力パラメータ・シグニチャ、および戻りの型を含む、請求項５８に記載のプログラム製品。
  61. 前記アプリケーション・ドメイン・インターフェース・メタモデル・メタデータが、さらに、言語メタモデル・メタデータを含む、請求項５８に記載のプログラム製品。
  62. 前記言語メタモデル・メタデータが、ソース言語とターゲット言語との間のマッピングを含む、請求項６１に記載のプログラム製品。
  63. 前記ソース言語または前記ターゲット言語の１つが、オブジェクト指向であり、前記ターゲット言語または前記ソース言語の他方が、オブジェクト指向でなく、前記言語メタモデル・メタデータが、カプセル化されたオブジェクトをコードおよびデータにマッピングする、請求項６２に記載のプログラム製品。
  64. 前記ソース言語および前記ターゲット言語が、異なるオブジェクト指向言語であり、前記言語メタモデル・メタデータが、カプセル化されたコードおよびデータを、前記ソース言語と前記ターゲット言語との間でマッピングする、請求項６２に記載のプログラム製品。
  65. 前記言語メタモデル・メタデータが、オブジェクト継承を参照およびポインタにマッピングする、請求項６４に記載のプログラム製品。
  66. 前記型記述子メタモデル・メタデータが、物理的実現、ストレージ・マッピング、データ型、データ構造体、および実現制約を定義する、請求項５８に記載のプログラム製品。
  67. 前記ソース言語または前記ターゲット言語の１つが、ＣおよびＣ＋＋からなる群から選択される、請求項５８に記載のプログラム製品。
JP2002517625A 2000-08-08 2001-08-02 Ｃ／ｃ＋＋メタモデルを含む共通アプリケーション・メタモデル Expired - Fee Related JP3842213B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US22367100P 2000-08-08 2000-08-08
US09/849,107 US7275079B2 (en) 2000-08-08 2001-05-04 Common application metamodel including C/C++ metamodel
PCT/US2001/024280 WO2002013007A1 (en) 2000-08-08 2001-08-02 Common application metamodel including c/c++ metamodel

Publications (2)

Publication Number Publication Date
JP2004506264A true JP2004506264A (ja) 2004-02-26
JP3842213B2 JP3842213B2 (ja) 2006-11-08

Family

ID=26918009

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2002517625A Expired - Fee Related JP3842213B2 (ja) 2000-08-08 2001-08-02 Ｃ／ｃ＋＋メタモデルを含む共通アプリケーション・メタモデル

Country Status (7)

Country Link
US (1) US7275079B2 (ja)
EP (1) EP1323034A4 (ja)
JP (1) JP3842213B2 (ja)
CN (1) CN1267820C (ja)
AU (1) AU2001278142A1 (ja)
CA (1) CA2412312A1 (ja)
WO (1) WO2002013007A1 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009165011A (ja) * 2008-01-09 2009-07-23 Nippon Telegr & Teleph Corp <Ntt> 機能分散型パケット転送システム及びこれを用いた制御方法
JP2010026815A (ja) * 2008-07-18 2010-02-04 Kddi Corp 情報処理装置
JP2012190102A (ja) * 2011-03-09 2012-10-04 Nec Corp リモートプロシージャコール処理方法
KR101189773B1 (ko) 2010-12-31 2012-10-10 전자부품연구원 사용자 시청상황 정보를 적용한 스케일러블 애플리케이션 서비스 시스템 및 방법

Families Citing this family (156)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7203491B2 (en) 2001-04-18 2007-04-10 Space Data Corporation Unmanned lighter-than-air safe termination and recovery methods
US7356390B2 (en) 1999-06-29 2008-04-08 Space Data Corporation Systems and applications of lighter-than-air (LTA) platforms
US6760844B1 (en) * 1999-07-30 2004-07-06 Unisys Corporation Secure transactions sessions
US7899690B1 (en) 2000-08-18 2011-03-01 The Crawford Group, Inc. Extended web enabled business to business computer system for rental vehicle services
US7275038B1 (en) * 2000-08-18 2007-09-25 The Crawford Group, Inc. Web enabled business to business operating system for rental car services
US8600783B2 (en) 2000-08-18 2013-12-03 The Crawford Group, Inc. Business to business computer system for communicating and processing rental car reservations using web services
US7562147B1 (en) * 2000-10-02 2009-07-14 Microsoft Corporation Bi-directional HTTP-based reliable messaging protocol and system utilizing same
US7079990B2 (en) * 2001-02-08 2006-07-18 Solidworks Corporation Automated connections of computer-aided design components
US9643706B2 (en) 2001-04-18 2017-05-09 Space Data Corporation Systems and applications of lighter-than-air (LTA) platforms
US9908608B2 (en) 2001-04-18 2018-03-06 Space Data Corporation Systems and applications of lighter-than-air (LTA) platforms
US9632503B2 (en) 2001-04-18 2017-04-25 Space Data Corporation Systems and applications of lighter-than-air (LTA) platforms
US6788317B2 (en) * 2001-05-18 2004-09-07 Sun Microsystems, Inc. Generation of delegating implementation for IDL interfaces which use inheritance
US8086643B1 (en) * 2001-06-28 2011-12-27 Jda Software Group, Inc. Translation between product classification schemas
US20030140220A1 (en) * 2001-06-29 2003-07-24 Bull Hn Information Systems Inc. Method and data processing system providing remote program initiation and control across multiple heterogeneous computer systems
US7055143B2 (en) 2001-07-10 2006-05-30 Microsoft Corporation System and methods for providing a declarative syntax for specifying SOAP-based web services
EP1298525A1 (en) * 2001-09-26 2003-04-02 Sap Ag Interaction between computers with different object-oriented run-time environments
US10019683B1 (en) * 2001-10-04 2018-07-10 Jda Software Group, Inc. Facilitating the negotiation of standards for inter-enterprise collaboration between trading partners
US7552203B2 (en) * 2001-10-17 2009-06-23 The Boeing Company Manufacturing method and software product for optimizing information flow
US7552135B2 (en) * 2001-11-15 2009-06-23 Siebel Systems, Inc. SQL adapter business service
US7921023B2 (en) * 2001-12-28 2011-04-05 Sap Aktiengesellschaft Portal for implementation of multiple software components
US20030177259A1 (en) * 2002-02-04 2003-09-18 Wookey Michael J. Remote services systems data delivery mechanism
US20030149740A1 (en) * 2002-02-04 2003-08-07 Wookey Michael J. Remote services delivery architecture
US20030163544A1 (en) * 2002-02-04 2003-08-28 Wookey Michael J. Remote service systems management interface
US7167448B2 (en) * 2002-02-04 2007-01-23 Sun Microsystems, Inc. Prioritization of remote services messages within a low bandwidth environment
US20030149771A1 (en) * 2002-02-04 2003-08-07 Wookey Michael J. Remote services system back-channel multicasting
US7769825B2 (en) * 2002-02-22 2010-08-03 Bea Systems, Inc. System and method for web services Java API-based invocation
US20040015578A1 (en) * 2002-02-22 2004-01-22 Todd Karakashian Web services runtime architecture
US7624062B1 (en) * 2002-03-18 2009-11-24 Chicago Mercantile Exchange Inc. Method and system for generating and trading composite contracts
US8041836B1 (en) * 2002-04-26 2011-10-18 Unisys Corporation Automatic COBOL working storage to open/OLTP view conversion
US20030212738A1 (en) * 2002-05-10 2003-11-13 Wookey Michael J. Remote services system message system to support redundancy of data flow
US20040039612A1 (en) * 2002-06-14 2004-02-26 Neil Fitzgerald Method and apparatus for customer direct on-line reservation of rental vehicles
US8108231B2 (en) * 2002-06-14 2012-01-31 The Crawford Group, Inc. Method and apparatus for improved customer direct on-line reservation of rental vehicles
US7181455B2 (en) * 2002-06-27 2007-02-20 Sun Microsystems, Inc. Bandwidth management for remote services system
US7240109B2 (en) * 2002-06-27 2007-07-03 Sun Microsystems, Inc. Remote services system service module interface
US8266239B2 (en) * 2002-06-27 2012-09-11 Oracle International Corporation Remote services system relocatable mid level manager
US7260623B2 (en) * 2002-06-27 2007-08-21 Sun Microsystems, Inc. Remote services system communication module
US7424702B1 (en) * 2002-08-19 2008-09-09 Sprint Communications Company L.P. Data integration techniques for use in enterprise architecture modeling
US7673053B1 (en) * 2002-08-30 2010-03-02 At&T Intellectual Property I, L.P. System and method for providing a communications service in distributed computing environment
US7421701B2 (en) * 2002-09-16 2008-09-02 International Business Machines Corporation System for facilitating transactions between thin-clients and message format service (MFS)-based information management system (IMS) applications
US20040054969A1 (en) * 2002-09-16 2004-03-18 International Business Machines Corporation System and method for generating web services definitions for MFS-based IMS applications
US7130893B2 (en) * 2003-05-19 2006-10-31 International Business Machines Corporation System and method for representing MFS control blocks in XML for MFS-based IMS applications
US20040103370A1 (en) * 2002-11-27 2004-05-27 International Business Machines Corporation System and method for rendering MFS XML documents for display
US6985910B2 (en) 2003-02-06 2006-01-10 International Business Machines Corporation Tilting tree spinning cones method and system for mapping XML to n-dimensional data structure using a single dimensional mapping array
US7827480B2 (en) * 2003-02-28 2010-11-02 Hewlett-Packard Development Company, L.P. System and method of using a transactional unit comprised of transactional subunits
US7526753B2 (en) * 2003-06-18 2009-04-28 Microsoft Corporation System and method for creating, managing and using code segments
RU2006107971A (ru) * 2003-08-15 2006-08-10 Те Ско Груп, Инк. (Us) Платформа для разблокирования и использования web-служб
US7370280B2 (en) * 2003-09-23 2008-05-06 International Business Machines Corporation Apparatus, system, and method for defining a web services interface for MFS-based IMS applications
US7418508B2 (en) 2004-01-26 2008-08-26 International Machines Corporation System and method to facilitate XML enabled IMS transactions between a remote client and an IMS application program
US7617459B2 (en) 2004-01-28 2009-11-10 International Business Machines Corporation Apparatus, system, and method for automatically generating a web interface for an MFS-based IMS application
US7698383B2 (en) * 2004-02-27 2010-04-13 Research In Motion Limited System and method for building component applications using metadata defined mapping between message and data domains
CN100337203C (zh) * 2004-04-05 2007-09-12 中国科学院计算技术研究所 一种遗产代码向现代语言变换过程中的控制流变换方法
WO2005109284A2 (en) * 2004-05-03 2005-11-17 Trintuition Llc Apparatus and method for creating and using documents in a distributed computing network
US7849085B2 (en) * 2004-05-18 2010-12-07 Oracle International Corporation System and method for implementing MBSTRING in weblogic tuxedo connector
US7802260B1 (en) * 2004-06-07 2010-09-21 Oracle America, Inc. Receiver-processor-dispatcher mechanism for inbound connectors
US20050289539A1 (en) * 2004-06-29 2005-12-29 Sudhir Krishna S Central installation, deployment, and configuration of remote systems
US7415021B1 (en) * 2004-09-22 2008-08-19 Sun Microsystems, Inc. Method and apparatus for preserving null semantics during use of a forwarding method
US7882170B1 (en) * 2004-10-06 2011-02-01 Microsoft Corporation Interfacing a first type of software application to information configured for use by a second type of software application
US7711676B2 (en) * 2004-11-12 2010-05-04 Sap Aktiengesellschaft Tracking usage of data elements in electronic business communications
US7818342B2 (en) * 2004-11-12 2010-10-19 Sap Ag Tracking usage of data elements in electronic business communications
US7865519B2 (en) 2004-11-17 2011-01-04 Sap Aktiengesellschaft Using a controlled vocabulary library to generate business data component names
US9146773B2 (en) * 2004-12-06 2015-09-29 Sap Se System and method for implicit transaction control
US20060135259A1 (en) * 2004-12-17 2006-06-22 Nokia Corporation System, game server, terminal, and method for game event notification in a multiplayer game
US20080208991A1 (en) * 2004-12-30 2008-08-28 Koninklijke Philips Electronics N.V. Data Processing Arrangement
US7712078B1 (en) * 2005-02-02 2010-05-04 Teradata Us, Inc. Techniques for data store population
US7793255B1 (en) * 2005-03-01 2010-09-07 Oracle America, Inc. System and method for maintaining alternate object views
US9363481B2 (en) * 2005-04-22 2016-06-07 Microsoft Technology Licensing, Llc Protected media pipeline
US20060271634A1 (en) * 2005-05-25 2006-11-30 England Laurence E Method, system, and program for processing a message with dispatchers
US20070022108A1 (en) * 2005-07-22 2007-01-25 Nec Corporation Predicate-logic retrieval system
US7870090B2 (en) * 2005-08-22 2011-01-11 Trane International Inc. Building automation system date management
US8055386B2 (en) * 2005-08-22 2011-11-08 Trane International Inc. Building automation system data management
US8050801B2 (en) * 2005-08-22 2011-11-01 Trane International Inc. Dynamically extensible and automatically configurable building automation system and architecture
US7917232B2 (en) * 2005-08-22 2011-03-29 Trane International Inc. Building automation system data management
US7904186B2 (en) * 2005-08-22 2011-03-08 Trane International, Inc. Building automation system facilitating user customization
US8024054B2 (en) * 2005-08-22 2011-09-20 Trane International, Inc. Building automation system facilitating user customization
US8055387B2 (en) * 2005-08-22 2011-11-08 Trane International Inc. Building automation system data management
US8099178B2 (en) * 2005-08-22 2012-01-17 Trane International Inc. Building automation system facilitating user customization
US7788651B2 (en) * 2005-09-02 2010-08-31 Microsoft Corporation Anonymous types
US7739696B2 (en) * 2005-09-08 2010-06-15 Honeywell International Inc. Message translation systems and methods
US7624113B2 (en) * 2005-11-23 2009-11-24 Sap Ag Data element naming system and method
US7783613B2 (en) * 2006-02-03 2010-08-24 Infosys Technologies Ltd. Context-aware middleware platform for client devices
CA2641941C (en) * 2006-02-10 2014-09-09 Make Technologies, Inc. Legacy software modernization system
US8271309B2 (en) 2006-03-16 2012-09-18 The Crawford Group, Inc. Method and system for providing and administering online rental vehicle reservation booking services
US7730192B2 (en) * 2006-03-20 2010-06-01 Microsoft Corporation Managing parallel requests in a communications environment supporting serial and parallel request handlers
US20070294116A1 (en) * 2006-06-14 2007-12-20 Scott Paul Stephens Method and system for an online rental vehicle reservation-booking website including a travel agent path
US8656374B2 (en) 2006-06-16 2014-02-18 Business Objects Software Ltd. Processing cobol data record schemas having disparate formats
US20080016023A1 (en) * 2006-07-17 2008-01-17 The Mathworks, Inc. Storing and loading data in an array-based computing environment
US20080033968A1 (en) * 2006-08-07 2008-02-07 Quan Dennis A Methods and apparatus for input specialization
US20080040488A1 (en) * 2006-08-09 2008-02-14 Infosys Technologies Ltd. Context-aware mobile portal
CN101127655B (zh) * 2006-08-18 2012-06-06 国际商业机器公司 集成现有基于万维网的系统的方法和系统
US8127279B2 (en) * 2006-09-01 2012-02-28 Ricoh Production Print Solutions LLC Systems and methods for graphical indexer operation on documents with SOSI characters
US7538625B2 (en) * 2007-02-27 2009-05-26 International Business Machines Corporation Method and enhanced phase locked loop circuits for implementing effective testing
JP4879785B2 (ja) 2007-03-19 2012-02-22 株式会社リコー 情報処理装置、情報処理方法及び情報処理システム
US7904480B2 (en) * 2007-07-17 2011-03-08 Oracle International Corporation System and method for synchronizing service metadata
US8918437B2 (en) * 2007-07-17 2014-12-23 International Business Machines Corporation Fragment reconstitution in a content management system
WO2009017158A1 (ja) * 2007-08-01 2009-02-05 Nec Corporation 変換プログラム探索システムおよび変換プログラム探索方法
US8510707B1 (en) * 2007-10-12 2013-08-13 The Pnc Financial Services Group, Inc. Mainframe-based web service development accelerator
US20090119415A1 (en) * 2007-11-02 2009-05-07 Chiang Chenhuei J System and method for representing mfs control blocks in xml for mfs-based ims applications
US9176714B2 (en) * 2007-11-12 2015-11-03 International Business Machines Corporation Re-using legacy libraries in software
US7493334B1 (en) * 2008-01-17 2009-02-17 International Business Machines Corporation System and method for handling invalid condition of a data element
US8374986B2 (en) 2008-05-15 2013-02-12 Exegy Incorporated Method and system for accelerated stream processing
US9141628B1 (en) 2008-11-07 2015-09-22 Cloudlock, Inc. Relationship model for modeling relationships between equivalent objects accessible over a network
US8180824B2 (en) 2009-02-23 2012-05-15 Trane International, Inc. Log collection data harvester for use in a building automation system
US20100262949A1 (en) * 2009-04-08 2010-10-14 Microsoft Corporation Visualized Modeling Language Connector Selection
US8135757B2 (en) 2009-06-10 2012-03-13 International Business Machines Corporation Generating references to reusable code in a schema
US8082313B2 (en) * 2009-10-26 2011-12-20 International Business Machines Corporation Efficient utilization of read-ahead buffer by partitioning read-ahead buffer in correspondence with selectors
US9245064B2 (en) * 2009-11-24 2016-01-26 Ice Edge Business Solutions Securely sharing design renderings over a network
US9258201B2 (en) 2010-02-23 2016-02-09 Trane International Inc. Active device management for use in a building automation system
US8793022B2 (en) 2010-02-26 2014-07-29 Trane International, Inc. Automated air source and VAV box association
US8219660B2 (en) 2010-02-26 2012-07-10 Trane International Inc. Simultaneous connectivity and management across multiple building automation system networks
US9182962B2 (en) * 2010-12-09 2015-11-10 Todd Bradley KNEISEL Method for translating a cobol source program into readable and maintainable program code in an object oriented second programming language
US20120233584A1 (en) * 2011-03-09 2012-09-13 Nec Laboratories America, Inc. Analysis of Interactions of C and C++ Strings
US8707277B2 (en) * 2011-05-02 2014-04-22 Raytheon Company Systems, methods, and language for SCA CORBA descriptor files
CN102891837B (zh) * 2011-07-22 2016-03-02 华为软件技术有限公司 消息转换处理方法、桥接设备和通信系统
US8806453B1 (en) * 2011-09-15 2014-08-12 Lockheed Martin Corporation Integrating disparate programming languages to form a new programming language
CN102508652A (zh) * 2011-09-30 2012-06-20 南威软件股份有限公司 应用系统与引擎跨语言实现交互的方法
US8813092B2 (en) 2011-10-12 2014-08-19 Raytheon Company CORBA embedded inter-orb protocol (EIOP)
US8768921B2 (en) * 2011-10-20 2014-07-01 International Business Machines Corporation Computer-implemented information reuse
US8719813B2 (en) * 2011-11-29 2014-05-06 Raytheon Company Optimized SCA CORBA descriptor for SCA CORBA descriptor files
US9298770B2 (en) * 2011-12-16 2016-03-29 Sap Se Generating remotely accessible repositories from language meta-models
US8782620B2 (en) 2012-06-12 2014-07-15 International Business Machines Corporation Processing reified generics in object-based programming environments
US9887872B2 (en) * 2012-07-13 2018-02-06 Microsoft Technology Licensing, Llc Hybrid application environments including hosted applications and application servers for interacting with data in enterprise environments
CN103577180B (zh) * 2012-08-03 2017-11-03 大唐网络有限公司 数据处理方法及装置
CA2887022C (en) 2012-10-23 2021-05-04 Ip Reservoir, Llc Method and apparatus for accelerated format translation of data in a delimited data format
US9594545B2 (en) 2013-06-05 2017-03-14 Splunk Inc. System for displaying notification dependencies between component instances
US8756593B2 (en) * 2013-06-05 2014-06-17 Splunk Inc. Map generator for representing interrelationships between app features forged by dynamic pointers
US8756614B2 (en) 2013-06-05 2014-06-17 Splunk Inc. Central registry for binding features using dynamic pointers
US10061626B2 (en) 2013-06-05 2018-08-28 Splunk Inc. Application framework providing a registry for mapping names to component instances
WO2015164639A1 (en) 2014-04-23 2015-10-29 Ip Reservoir, Llc Method and apparatus for accelerated data translation
US9734273B2 (en) * 2014-05-27 2017-08-15 Mentor Graphics Corporation System design management
US10403160B2 (en) 2014-12-24 2019-09-03 Space Data Corporation Techniques for intelligent balloon/airship launch and recovery window location
WO2016105522A1 (en) 2014-12-24 2016-06-30 Space Data Corporation Breaking apart a platform upon pending collision
US10059421B2 (en) 2014-12-30 2018-08-28 Space Data Corporation Multifunctional balloon membrane
CN104503942B (zh) * 2014-12-30 2017-10-31 合肥金星机电科技发展有限公司 串口指令解码方法
US9922037B2 (en) 2015-01-30 2018-03-20 Splunk Inc. Index time, delimiter based extractions and previewing for use in indexing
US10942943B2 (en) * 2015-10-29 2021-03-09 Ip Reservoir, Llc Dynamic field data translation to support high performance stream data processing
US9667676B1 (en) * 2016-01-29 2017-05-30 Dropbox, Inc. Real time collaboration and document editing by multiple participants in a content management system
US10042622B2 (en) * 2016-02-19 2018-08-07 International Business Machines Corporation Methods and systems of generating ease of use interfaces for legacy system management facilities
CN107239264B (zh) 2016-03-28 2020-06-23 阿里巴巴集团控股有限公司 代码提示信息的生成方法及装置
US9529922B1 (en) * 2016-05-06 2016-12-27 Ashok Wahi Computer implemented systems and methods for dynamic and heuristically-generated search returns of particular relevance
US10579238B2 (en) 2016-05-13 2020-03-03 Sap Se Flexible screen layout across multiple platforms
US10353534B2 (en) 2016-05-13 2019-07-16 Sap Se Overview page in multi application user interface
CN106686752B (zh) * 2016-07-11 2019-02-15 上海掌门科技有限公司 一种通过用户设备上第一应用建立无线连接的方法与设备
US10269235B2 (en) 2016-08-26 2019-04-23 Trane International Inc. System and method to assist building automation system end user based on alarm parameters
US10223085B2 (en) * 2017-04-28 2019-03-05 International Business Machines Corporation Discovering high-level language data structures from assembler code
WO2018220836A1 (ja) * 2017-06-02 2018-12-06 三菱電機株式会社 プログラムコード生成装置およびプログラムコード生成プログラム
US10496383B2 (en) * 2017-12-20 2019-12-03 Intel Corporation Methods and apparatus to convert a non-series-parallel control flow graph to data flow
US10713145B2 (en) * 2018-01-05 2020-07-14 International Business Machines Corporation Automated debugging with combined static and dynamic analysis
CN110110292B (zh) * 2018-01-29 2023-11-14 北京搜狗科技发展有限公司 一种数据处理方法、装置和用于数据处理的装置
CN108683930B (zh) * 2018-04-27 2020-09-25 青岛海信传媒网络技术有限公司 数字电视、其接口的初始化方法、装置及可读性存储介质
CN110442406B (zh) * 2018-05-02 2022-08-12 北京京东乾石科技有限公司 分页控件处理数据的方法及分页控件、电子设备
US10956392B1 (en) * 2018-07-23 2021-03-23 Allscripts Software, Llc Methods, apparatuses, and computer program products for identifying fields in a data tree
CN110045982A (zh) * 2019-03-28 2019-07-23 宋子杰 一种基于源代码聚合的嵌入式系统配置方法
CN111857678A (zh) * 2019-04-25 2020-10-30 阿里巴巴集团控股有限公司 代码生成方法、装置、电子设备及计算机存储介质
CN110134393B (zh) * 2019-05-16 2024-01-09 北京三快在线科技有限公司 一种处理操作信号的方法和装置
CN113342332B (zh) * 2021-05-31 2023-11-03 成都谐盈科技有限公司 一种基于模型驱动的组件可定制多接口的实现方法
US11868098B2 (en) * 2021-11-12 2024-01-09 Phaidra, Inc. Chiller and pump control using customizable artificial intelligence system

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU639802B2 (en) 1990-08-14 1993-08-05 Oracle International Corporation Methods and apparatus for providing dynamic invocation of applications in a distributed heterogeneous environment
JPH09160847A (ja) 1995-12-08 1997-06-20 Hitachi Ltd クライアント・サーバ型分散処理システム
US6094688A (en) * 1997-01-08 2000-07-25 Crossworlds Software, Inc. Modular application collaboration including filtering at the source and proxy execution of compensating transactions to conserve server resources
US6105064A (en) 1997-05-30 2000-08-15 Novell, Inc. System for placing packets on network for transmission from sending endnode to receiving endnode at times which are determined by window size and metering interval
US6574661B1 (en) * 1997-09-26 2003-06-03 Mci Communications Corporation Integrated proxy interface for web based telecommunication toll-free network management using a network manager for downloading a call routing tree to client
US6415329B1 (en) 1998-03-06 2002-07-02 Massachusetts Institute Of Technology Method and apparatus for improving efficiency of TCP/IP protocol over high delay-bandwidth network
JPH11288403A (ja) 1998-04-03 1999-10-19 Toshiba Corp 分散ネットワークコンピューティングシステム、同システムに用いられる情報交換装置、情報交換方法、及び記憶媒体
JPH11296390A (ja) 1998-04-07 1999-10-29 Hitachi Ltd 遠隔プログラムでの複数通信手段の切替方式
US6134559A (en) * 1998-04-27 2000-10-17 Oracle Corporation Uniform object model having methods and additional features for integrating objects defined by different foreign object type systems into a single type system
US6738975B1 (en) * 1998-11-18 2004-05-18 Software Ag, Inc. Extensible distributed enterprise application integration system
US6480860B1 (en) * 1999-02-11 2002-11-12 International Business Machines Corporation Tagged markup language interface with document type definition to access data in object oriented database
CA2327222A1 (en) * 1999-12-03 2001-06-03 Research In Motion Limited Virtual machine web browser
US6711734B1 (en) * 2000-06-27 2004-03-23 Unisys Corporation Method for translating MOF metamodels to UML models

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009165011A (ja) * 2008-01-09 2009-07-23 Nippon Telegr & Teleph Corp <Ntt> 機能分散型パケット転送システム及びこれを用いた制御方法
JP4635058B2 (ja) * 2008-01-09 2011-02-16 日本電信電話株式会社 機能分散型パケット転送システム及びこれを用いた制御方法
JP2010026815A (ja) * 2008-07-18 2010-02-04 Kddi Corp 情報処理装置
KR101189773B1 (ko) 2010-12-31 2012-10-10 전자부품연구원 사용자 시청상황 정보를 적용한 스케일러블 애플리케이션 서비스 시스템 및 방법
JP2012190102A (ja) * 2011-03-09 2012-10-04 Nec Corp リモートプロシージャコール処理方法

Also Published As

Publication number Publication date
EP1323034A4 (en) 2006-11-22
WO2002013007A1 (en) 2002-02-14
CN1267820C (zh) 2006-08-02
EP1323034A1 (en) 2003-07-02
US20020046294A1 (en) 2002-04-18
CA2412312A1 (en) 2002-02-14
AU2001278142A1 (en) 2002-02-18
US7275079B2 (en) 2007-09-25
CN1468398A (zh) 2004-01-14
JP3842213B2 (ja) 2006-11-08

Similar Documents

Publication Publication Date Title
JP3842213B2 (ja) Ｃ／ｃ＋＋メタモデルを含む共通アプリケーション・メタモデル
US6904598B2 (en) COBOL metamodel
US6964053B2 (en) Type descriptor language (TDLanguage) metamodel
US6775680B2 (en) High level assembler metamodel
US6912719B2 (en) Type descriptor metamodel
US6915523B2 (en) PL/I metamodel
US7559066B2 (en) CICS BMS (basic message service) meta model
US6948174B2 (en) IMS MFS (message format service) metamodel
US6910216B2 (en) IMS transaction messages metamodel
Brose et al. Java programming with CORBA: advanced techniques for building distributed applications
US6920461B2 (en) Application program interface for network software platform
US6931623B2 (en) Method of accessing data and logic on existing systems through dynamic construction of software components
US6289501B1 (en) Method for generating simple document type definitions
KR100684680B1 (ko) 확장가능한 분산된 기업용 애플리케이션 통합 시스템
US6381743B1 (en) Method and system for generating a hierarchial document type definition for data interchange among software tools
US20050262130A1 (en) Input data specification method and system in business-to-business integration
KR20040077573A (ko) 스키마 기반의 계층적 데이터 구조를 단층적 데이터구조로 변환하기 위한 방법 및 시스템
Serain Middleware and enterprise application integration: the architecture of e-business solutions
US8140347B2 (en) System and method for speeding XML construction for a business transaction using prebuilt XML with static and dynamic sections
EP0924614A2 (en) Method and apparatus for efficient representation of variable lenght identifiers in a distributed object system
Yusuf Enterprise messaging using JMS and IBM websphere
Templeman et al. Visual Studio. NET: The. NET Framework Black Book
Akbay et al. Design and implementation of an enterprise information system utilizing a component based three-tier client/server database system
Griffin et al. Linux Network Programming, Part 3
AU2002239926A1 (en) Method of accessing data and logic on existing systems through dynamic construction of software components

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20060110

RD12 Notification of acceptance of power of sub attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7432

Effective date: 20060201

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20060201

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20060406

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20060413

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20060707

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20060801

RD14 Notification of resignation of power of sub attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7434

Effective date: 20060801

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20060809

R150 Certificate of patent or registration of utility model

Ref document number: 3842213

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20090818

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20100818

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20100818

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110818

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120818

Year of fee payment: 6

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130818

Year of fee payment: 7

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: R3D02

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees