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

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

Info

Publication number
JP3842213B2
JP3842213B2 JP2002517625A JP2002517625A JP3842213B2 JP 3842213 B2 JP3842213 B2 JP 3842213B2 JP 2002517625 A JP2002517625 A JP 2002517625A JP 2002517625 A JP2002517625 A JP 2002517625A JP 3842213 B2 JP3842213 B2 JP 3842213B2
Authority
JP
Japan
Prior art keywords
application
metamodel
language
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.)
Expired - Fee Related
Application number
JP2002517625A
Other languages
English (en)
Other versions
JP2004506264A (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)

Description

【０００１】
【発明の属する技術分野】
本発明は、データの転送、交換または処理が作動可能であることを知らせるための、またはアプリケーション間でのデータ転送に関する少なくとも１つまたは複数のパラメータを確立するためのアプリケーション間の命令またはデータあるいはその両方の交換と、データの転送および通信を容易にするためのパラメータの制御に関する。本発明は、さらに、たとえば複数のコンピュータ、複数のオペレーティング・システム、複数のアプリケーション・コンポーネント、複数の開発環境、複数の展開環境、または複数のテストおよび処理など、一方があるプラットフォームで実行され他方が別のプラットフォームで実行される異なるアプリケーションの統合と、全体的な目標を達成するためにデータまたはその一部に対するタスクの実行を容易にするためにアプリケーション間でデータまたは命令あるいはその両方を転送するための接続性を確立するためのお互いとのダイアログ（たとえばネゴシエーション）の確立とに関する。パラメータには、１つまたは複数のフォーマット、データ型、データ構造体、またはコマンドを含めることができる。
【０００２】
【従来の技術】
関連出願の相互参照
本願は、米国特許法セクション111(b)および119(e)の下で、米国仮特許出願第60/223671号および米国特許出願第09/849107号の利益を主張する。
【０００３】
本願は、本願と同一の日付に出願された下記の米国特許出願にも関する。
米国特許出願第09/849813号。
米国特許出願第09/849563号。
米国特許出願第09/849190号。
米国特許出願第09/849377号。
米国特許出願第09/849816号。
米国特許出願第09/849105号。
米国特許出願第09/849793号。
【０００４】
e-businessの成長によって、レガシ・アプリケーションを統合し、インターネットに持ち込む重大な必要が生じた。これは、新しいアプリケーションが、エンド・ユーザ・アプリケーションの構成およびスケーラビリティを単純にするウェブ標準規格を包含するという現在の傾向のゆえである。さらに、新しいアプリケーションが作成される際に、それらを既存のシステムにシームレスに統合しながら、新しいビジネス・プロセスおよびパラダイムの導入を容易にすることが非常に重要である。
【０００５】
既存のアプリケーションとの新しいアプリケーションの統合は、e-commerceに特に関連するデータを含む企業データの７０％以上がメインフレーム・コンピュータ上にあると産業アナリストが推定しているので、特にクリティカルである。さらに、多数のe-commerceトランザクションが、Windows(R)、Mac、およびLinuxのエンド・ユーザ・プラットフォームで、さまざまなウェブ・ブラウザを使用して開始され、Windows(R)NTサーバおよびUnix(R)サーバを介して進むが、これらのトランザクションは、最終的にはメインフレーム・アプリケーションが稼動するメインフレーム・コンピュータで完了し、メインフレーム・データベースに格納されたデータに影響する。
【０００６】
サーバ・レベル・アプリケーションを統合し、インターネットに持ち込むことに関するe-businessからの圧力がある。しかし、アプリケーションを統合またはe-business対応にする完全で簡単な機構はない。統合は、メッセージング、プロシージャ呼出し、またはデータベース照会のどれを介するものであっても、現在のビジネス問題の多数を解決するための鍵である。
【０００７】
レガシ・アプリケーションと新しいソフトウェアの統合は、２つの異なるアプリケーションを結び付ける接続のそれぞれをカスタマイズする必要に大いに起因して、困難かつ高価な作業である。あるアプリケーションが別のアプリケーションによってそれ自体を呼び出されることを可能にする方法を記述する単一の機構はない。
【０００８】
１つの結果が、複数の開発チームによって開発され、異なるプラットフォームで稼動する、異なるデータ型、データ構造体、コマンド、およびコマンド構文を有する複数のアプリケーションのe-commerce環境である。この環境は、アプリケーション・プログラム・インターフェースおよびコネクタを用いてつなぎ合わされる。コネクタは、e-commerceの総合的なアプリケーション・フレームワークの本質的な部分である。コネクタは、異なるアプリケーションのインターフェース要件を一致させ、異なるインターフェースの間でマッピングを行う。
【０００９】
この新旧のソフトウェア・システムおよびアプリケーションの相互接続の増加によって、特にマークアップ言語（ＨＴＭＬ、ＸＭＬ、Dynamic HTML、ＷＭＬ、および類似物など）の、SmallTalkおよびC++などのオブジェクト指向言語を介する、レガシ・アプリケーション・サーバ・アプリケーションの言語（COBOLなど）との相互接続および対話に関する、さまざまなミドル・ウェア・アプリケーションおよびコネクタ・アプリケーション、インターフェース仕様、インターフェース定義、およびコードがもたらされた。これらのインターフェース仕様、定義、およびコードは、言語、ツール、アプリケーション、オペレーティング・システム、およびネットワークにまたがって適用され、その結果、エンド・ユーザが自分の端末で単一のシームレスなアプリケーションのルック、フィール、および応答を経験するようにしなければならない。その代わりに、たとえばcommonobject Request Broker（CORBA）、Common Object Model（ＣＯＭ）、オブジェクトのリンクと埋込み（ＯＬＥ）、ＳＯＭ、ＯＲＢPlus、Object Broker、Orbixなどの標準規格、プロトコル、仕様、定義、およびコードの増殖が、その代わりに、e-commerceの「バベルの塔」を生み出した。
【００１０】
アプリケーション統合の例が、ユビキタスであり、これは、ＥＲＰシステムのインストールから、ＩＭＳトランザクションを伴うオペレーショナル・データ・ストア（ＯＤＳ）の更新またはMQSeriesからのＣＲＭシステムの呼出しまでにおよび、これらのそれぞれが、同一の基本ステップを必要とする。第１に、ユーザは、自分が通信したいエンティティを見つけなければならず、その後、ユーザは、そのエンティティを呼び出す方法を見つけなければならず、最後に、ユーザは、あるネイティブ表現から別のネイティブ表現への変換を提供しなければならない。現在、これらのステップは、通常、手動調査およびハンド・コーディングを必要とし、開発者が、アプリケーションの間の維持しにくい接続の混乱状態に煩わされる。
【００１１】
この情況を救済する試みには、アプリケーション・プログラム・インターフェースおよびコネクタが含まれ、これらは、しばしば、インターフェース定義言語に基づいて構築される。インターフェース定義言語は、宣言的であり、インターフェース定義言語によって、アプリケーション・プログラム・インターフェースが定義され、いくつかの場合に、エラー処理などの問題が生じる。ほとんどのインターフェース定義言語は、C++のサブセットであり、コンポーネントの属性、継承する元の親クラス、それが発生する例外、それが発行する型付きイベント、そのインターフェースがサポートするメソッド、入出力パラメータ、およびデータ型を指定する。コネクタ内のインターフェース定義言語の目標は、ハード・コーディングされたアプリケーション・プログラム・インターフェースなしで、異なるアプリケーションの間のコラボレーションを可能にすることである。
【００１２】
理想的には、インターフェース定義言語およびそれを含むコネクタは、下記などの特徴を介して完全な実行時ソフトウェア・アプリケーション・コラボレーションを促進しなければならない。
・強い型検査を伴うメソッド呼出し、
・より高い柔軟性と実行時バインディングを伴う実行時メソッド呼出し、
・実装から分離されたインターフェースを伴う高水準言語バインディング、
・サーバの関数およびパラメータのリアル・タイム情報を含むインターフェース・リポジトリ。
【００１３】
さらに、コネクタおよびそのインターフェース定義言語は、高速であり、効率的であり、スケーラブルであり、ポータブルであり、メタクラスをサポートし、構文レベルの拡張をサポートし、セマンティック・レベルの拡張をサポートしなければならない。
【００１４】
【発明が解決しようとする課題】
新しいアプリケーション、たとえばe-commerceアプリケーションの、レガシ・アプリケーションとの統合に関連する問題が、本明細書に記載の共通アプリケーション・メタモデルのツール、方法、およびシステムによって除去される。本発明の共通アプリケーション・メタモデルの方法、ツール、およびシステムは、似ていない異なるアプリケーションの間のツーリング・ソリューション、データ変換、通信およびコラボレーションならびにアプリケーション・サーバ・インターフェース・ドメインとのインターフェースを介する完全な実行時ソフトウェア・アプリケーション・コラボレーションを容易にする。これは、メタデータ交換情報、強い型検査を伴うメソッド呼出し、実行時メソッド呼出し、実行時バインディング、および高水準言語バインディングを介して、実装から分離されたインターフェースと、クライアントおよびサーバのインターフェース・パラメータのリアル・タイム情報を格納するインターフェース・リポジトリとを用いて、達成される。
【００１５】
さらに、本発明のツール、方法、およびシステムは、すべてのツールまたはミドルウェアから独立の、高速であり、効率的であり、スケーラブルである相互接続性を提供し、再利用可能であり、ポータブルであり、メタクラス、構文レベルの拡張、およびセマンティック・レベルの拡張をサポートし、特定のツールまたはミドルウェアから独立である。
【００１６】
共通アプリケーション・メタモデルのツール、方法、およびシステムは、クライアント・アプリケーションとサーバ・アプリケーションの間で両方向であり、たとえばJava(R)、ＨＴＭＬ、ＸＭＬ、Ｃ、またはC++アプリケーションと、COBOL、ＰＬ／Ｉ、またはHigh LevelAssemblerアプリケーションとの間、ＨＴＭＬまたはＸＭＬアプリケーションとJava(R)、Ｃ、またはC++アプリケーションとの間、またはJava(R)アプリケーションとＣまたはC++アプリケーションとの間で両方向にコマンドおよびデータを送る、データ・トランスフォーマを提供するのに特に有用である。
【００１７】
【課題を解決するための手段】
本発明の一実施形態は、エンド・ユーザ・アプリケーションおよび１つまたは複数のアプリケーション・サーバで、またはこれらの間でアプリケーション要求を処理する方法である。この方法には、エンド・ユーザ・アプリケーションに対するアプリケーション要求を第１言語で第１アプリケーション・プログラムを用いて開始するステップと、アプリケーション要求をサーバに送信し、アプリケーション要求を第１エンド・ユーザ・アプリケーションの第１言語からアプリケーション・サーバ上で稼動する言語に変換するステップが含まれる。通常、上で説明したように、クライアントは、シン・クライアントまたはウェブ・ブラウザであり、クライアント上で稼動するアプリケーションは、ウェブ・ブラウザ・アプリケーションまたはシン・クライアント接続性アプリケーションであり、クライアント・アプリケーションの言語は、Java(R)、Ｃ、C++、あるいは、ＨＴＭＬまたは、ＸＭＬまたはDynamic HTMLまたはＷＭＬなどのＨＴＭＬの派生物のマークアップ言語であり、サーバ上で稼動する言語は、COBOL、ＰＬ／Ｉ、HLASM（HighLevel Assembler）または類似物である。本発明は、アプリケーション要求をエンド・ユーザ・アプリケーションの第１言語からアプリケーション・サーバ上で稼動する言語に変換するトランスフォーマを促進する。変換の後に、変換されたアプリケーション要求が、アプリケーション・サーバ上で処理される。
【００１８】
アプリケーションは、要求を処理し、その後、アプリケーション・サーバからエンド・ユーザ・アプリケーションに応答を送り返す。通常、上で説明したように、アプリケーション・サーバは、COBOLベースのアプリケーションを実行しており、クライアントは、Java(R)またはＣまたはC++で記述されたシン・クライアント、もしくは、ＨＴＭＬあるいはＸＭＬまたはDynamicHTMLまたは類似物などのＨＴＭＬの派生物などのマークアップ言語の、ウェブ・ブラウザ・アプリケーションまたはシン・クライアント接続性アプリケーションを実行するウェブ・ブラウザである。本発明は、１つまたは複数のアプリケーション・サーバ上で稼動する１つまたは複数の言語から第１エンド・ユーザ・アプリケーションの第１言語に応答を変換するデータ・トランスフォーマを提供する。
【００１９】
エンド・ユーザ・アプリケーションおよびアプリケーション・サーバは、その間に少なくとも１つのデータ・トランスフォーマを有する。この形で、（ｉ）ソース言語としての第１エンド・ユーザ・アプリケーションの第１言語からターゲット言語としてのアプリケーション・サーバ上で稼動する言語に要求を変換するステップと、（ｉｉ）後続のソース言語としてのアプリケーション・サーバ上で稼動する言語から後続のターゲット言語としての第１エンド・ユーザ・アプリケーションの第１言語に応答を変換するステップとのそれぞれに、各々のソース言語およびターゲット言語の型記述子および言語メタモデルを呼び出すステップと、各々のソース言語およびターゲット言語のデータ項目および型のそれぞれを用いてメタモデルを移植するステップと、ソース言語をターゲット言語に変換するステップとが含まれる。
【００２０】
エンド・ユーザ・アプリケーションは、ウェブ・ブラウザまたはシン・クライアントであることがしばしばである。エンド・ユーザ・アプリケーションが、ウェブ・ブラウザである時には、エンド・ユーザは、ウェブ・サーバを介してアプリケーション・サーバに接続される。本発明のもう１つの実施形態によれば、ウェブ・サーバに、コネクタまたはデータ・トランスフォーマを含めることができる。ウェブ・サーバに統合されたデータ・トランスフォーマは、要求、アプリケーション要求、またはメッセージを、ブラウザ指向の形からアプリケーション・サーバ言語または、ＸＭＬなどの中間のビジネス指向またはコマース指向のマークアップ言語に直接に変換することができる。
【００２１】
コンバータを構成するのに使用されるＣＡＭメタモデルには、呼出しメタモデル、アプリケーション・ドメイン・インターフェース・メタモデル、言語メタモデル、および型記述子メタモデルが含まれる。例示的な呼出しメタモデルには、メッセージ制御情報と、セキュリティ・データと、トランザクショナル・セマンティクスと、トレースおよびデバッグ情報と、事前条件リソースと、事後条件リソースと、ユーザ・データなどからなる群から選択された情報が含まれる。例示的なアプリケーション・ドメイン・インターフェース・メタモデルには、入力パラメータ・シグニチャ、出力パラメータ・シグニチャ、および戻りの型から選択される情報が含まれる。アプリケーション・ドメイン・インターフェース・メタモデルでは、COBOLまたはＰＬ／Ｉメタモデルなどの１つまたは複数の言語メタモデルが使用される。
【００２２】
型記述子メタモデルでは、物理的実現、ストレージ・マッピング、データ型、データ構造体、および実現制約が定義される。
【００２３】
本発明の方法は、ソース言語またはターゲット言語の一方がオブジェクト指向であり、ターゲット言語またはソース言語の他方がオブジェクト指向でない情況に適用可能である。この情況では、言語メタモデルおよび型記述子メタモデルが、一緒に、オブジェクト指向言語のカプセル化されたオブジェクトを、オブジェクト指向でない言語のコードおよびデータにマッピングする。さらに、言語メタモデルおよび型記述子メタモデルは、オブジェクト指向言語のオブジェクト継承を、オブジェクト指向でない言語の参照およびポインタにマッピングする。本発明の方法は、異なるオブジェクト指向言語が異なるプラットフォーム上で稼動しており、ソース言語のカプセル化されたオブジェクト（コードおよびデータ）が、ターゲット言語のカプセル化されたオブジェクトにマッピングされる情況にも適用可能である。本発明の方法は、異なる手続き型言語が異なるプラットフォームまたはアプリケーションで稼動しており、ソース手続き型言語のコマンドおよびデータが、ターゲット手続き型言語にマッピングされる場合にも適用可能である。
【００２４】
本発明の方法によれば、垂直（シーケンシャル、条件、または依存）処理用、水平（時間的に並列）処理用、または垂直処理と水平処理の両方の、複数のアプリケーションが存在することができる。これは、処理の複数の階層レベルおよび複数の並列シーケンスへおよびそれらを介するリッチ・トランザクションをサポートするためである。これは、財務、製造、スケジューリング、供給、出荷のデータベースおよびサーバを利用し、さまざまな市販セキュリティ器具を使用する、企業対企業のトランザクションにおいてそうである可能性がある。
【００２５】
本発明のもう１つの態様は、クライアント、サーバ、クライアントと１つまたは複数のサーバの間の少なくとも１つのトランスフォーマを有する、クライアント−サーバ処理システムである。
【００２６】
本発明のもう１つの態様は、クライアント・アプリケーションと相互作用するように構成され、制御される処理システムである。本発明のこの態様では、システムに、サーバと、サーバとクライアント・アプリケーションとの間の少なくとも１つのトランスフォーマが含まれ、クライアントが、エンド・ユーザ・アプリケーションを有し、第１アプリケーション・プログラムを用いて第１言語でサーバに関する要求を開始し、その要求をトランスフォーマを介して１つまたは複数のサーバに送信するように制御され、構成される。サーバは、要求を、第２言語を使用する第２ソフトウェア・アプリケーションで処理し、トランスフォーマを介してクライアントに応答を返す。
【００２７】
本発明のもう１つの態様は、電子メール、ワード・プロセッシング、スプレッドシート、単純なデータベース管理（Lotus ApproachまたはMicrosoft Accessなど）、グラフィックスおよびグラフィックス編集、オーディオおよびオーディオ編集、およびコンピュータ・テレフォニ統合（「ＣＴＩ」）などの、複数の電子メール対応エンド・ユーザ・アプリケーションを、クライアント・レベル・コンテンツ・データベース・クライアント・サービスおよびコンテンツ複製クライアント・サービスと共に有するグループウェア・システムである。グループウェアによって、これらの電子メール対応アプリケーションを、１つまたは複数のトランスフォーマと、トランスポート・サービス、ディレクトリ・サービス、およびコンテンツ・サーバと複製サーバとを含むストレージ・サービスとのアプリケーション・プログラム・インターフェースとを介して統合できるようになる。グループウェア・システムは、異なるエンド・ユーザ・アプリケーションの間、異なるサーバの間、および異なるサーバとエンド・ユーザ・アプリケーションの間で通信するように構成され、制御される。グループウェア・システムには、サーバとエンド・ユーザ・アプリケーションの間の少なくとも１つのトランスフォーマが含まれる。エンド・ユーザ・アプリケーションは、第１アプリケーション・プログラムの第１言語でサーバに関係するように制御され、構成され、サーバは、第２プログラムの第２言語でクライアントに関係するように構成され、制御される。
【００２８】
トランスフォーマは、エンド・ユーザ・アプリケーションから要求を受信し、その要求を第１エンド・ユーザ・アプリケーションの第１言語からサーバで稼動する言語に変換するように構成され、制御される。サーバは、変換された要求をトランスフォーマから受信し、サーバに常駐する第２アプリケーション・プログラムを用いて第２言語で要求を処理し、その後、トランスフォーマを介してエンド・ユーザ・アプリケーションに応答を送り返すように構成され、制御される。
【００２９】
本発明のもう１つの実施形態は、リッチ・トランザクション処理の提供である。リッチ・トランザクションは、複数のサーバへ、複数のサーバを介して、または複数のサーバにまたがって、およびあるいはこれらの組合せにスパンする、入れ子になったトランザクションである。入れ子になったサーバにまたがるスパンは、水平すなわち、並列の従属トランザクション、または垂直すなわち直列の従属トランザクションとすることができる。リッチ・トランザクションは、長寿命の進行中のトランザクション、または、複雑な企業対企業のトランザクション、特に複数の依存性または偶発性、大量および即座の支払いディスカウント、配送遅れおよび支払いの遅れのペナルティ、および、電子信用状、電子船荷証券、電子支払い保証、電子支払い、エスクロウ、商品の担保権、および類似物などの財務処理を伴うトランザクションとすることができる。リッチ・トランザクション環境では、いくつかのトランザクション・サーバを、リッチ・トランザクションを構成するあるサブ・トランザクションについて他のトランザクションに関するクライアントとして位置付けることができる。
【００３０】
本発明のもう１つの実施形態は、プログラム製品が、呼出しメタモデル、アプリケーション・ドメイン・インターフェース・メタモデル、および言語メタモデルと、ソース言語メタモデルおよびターゲット言語メタモデルのメタモデル・リポジトリを構築するコンピュータ命令を有するストレージ・メディア（複数のコンピュータの１つの、テープ、フロッピ・ディスク、ＣＤ−ＲＯＭ、または１つまたは複数のハード・ドライブなど）であることを特徴とする、ツールすなわち、ソフトウェア開発者キットである。プログラム製品には、メタモデルからコネクタ・スタブを構築するコンピュータ命令も含まれる。プログラム製品は、さらに、トランスフォーマを構築するコンピュータ命令を担持する。
【００３１】
本発明を、単一のレベルのコネクタを有するものとして要約の形で説明したが、そのようなコネクタが、もちろんたとえばウェブ・クライアントとウェブ・サーバの間、ウェブ・サーバとアプリケーション・サーバの間、アプリケーション・サーバとデータベース・サーバの間、およびアプリケーション・サーバまたはデータベース・サーバもしくはその両方とさまざまな特殊リポジトリの間など、処理階層内のさまざまなレベルに存在することができることを理解されたい。
【００３２】
本発明を個々のクライアントおよび個々のサーバに関して要約したが、グループウェア・アプリケーションによって例示されるように、複数のクライアント、複数のサーバ、およびクライアントとサーバの両方として機能するアプリケーションが存在することができ、リッチ・トランザクションのシステムのように、アプリケーション・サーバ、データ・サーバ、およびデータベースの、複数の並列のラインまたは複数の階層レベルもしくはその両方が存在することができることも理解されたい。
【００３３】
【発明の実施の形態】
定義。本明細書で使用される時に、以下の用語は、示された意味を有する。「ハンドシェーク」は、各接続に先立つ、２つのアプリケーションの間の情報の交換と、その結果の、どの言語、機能、およびプロトコルを使用するかに関する合意である。
【００３４】
「アプリケーション・プログラム・インターフェース」（ＡＰＩ）は、コンピュータ・オペレーティング・システムまたは別のアプリケーション・プログラムによって規定される受動的な特定のメソッドであり、これによって、アプリケーション・プログラムを記述するプログラマが、オペレーティング・システムまたは別のアプリケーションに要求を行うことができる。例が、ＳＡＸ（Simple API for XML）、すなわち、プログラマが、Extensible Markup Languageを使用するウェブ・ファイルすなわち、データの集合を記述するウェブ・ファイルを解釈できるようにするコネクタである。ＳＡＸは、「イベント駆動」インターフェースである。プログラマは、発生する可能性があるイベントを指定し、そのイベントが実際に発生した場合に、ＳＡＸが、制御を得、その状況を処理する。ＳＡＸは、直接にＸＭＬパーサと共に作動する。
【００３５】
本明細書で使用される「コネクタ」は、ターゲット・プラットフォームまたはプログラムの関数およびパラメータが格納されたプラットフォームの間の動的な実行時インターフェースであり、ターゲット・プラットフォーム・プログラムをリアル・タイムでバインドする。
【００３６】
「スタブ」は、サーバへの静的インターフェースを提供する小さいプログラム・ルーチンである。事前にコンパイルされたスタブによって、クライアントがサーバ上の対応するサービスを呼び出す方法が定義される。スタブは、サーバ上のより長いプログラムに代わり、サーバ・オブジェクトに関するローカル呼出しまたはローカル・プロキシとして働く。スタブは、要求を受け入れ、その後、その要求をリモート・プロシージャに転送する（別のプログラムを介して）。そのプロシージャは、そのサービスを完了した時に、結果または他の状況をスタブに返し、スタブは、要求を行ったプログラムにそれを渡す。サーバ・サービスは、スタブ内で、インターフェース定義言語（「ＩＤＬ」）を使用して定義される。クライアントは、それがアクセスするサーバ・インターフェースごとに１つのＩＤＬスタブを有し、このＩＤＬスタブに、マーシャルを実行するコードが含まれる。サーバ・スタブは、サーバによってエクスポートされる各サービスへの静的インターフェースを提供する。
【００３７】
「ＣＩＣＳ」（顧客情報管理システム）は、COBOL（Common BusinessOriented Language）プログラミング言語と共に、大企業メインフレーム・コンピューティングの世界で顧客トランザクション・アプリケーションを構築するツールの組である、IBM社のオンライン・トランザクション処理プログラムである。ＣＩＣＳによって供給されるプログラミング・インターフェースを使用して、ＣＩＣＳ内で顧客レコードおよび他のレコード（注文、在庫額、顧客データなど）を記述することによって、プログラマが、IBM社のアクセス・メソッドを直接に使用するのではなく、ＣＩＣＳ機能を使用して、オンライン・ユーザと通信し、データベース（通常は「データ・セット」と称する）から読み取るプログラムを記述することができる。ＣＩＣＳは、トランザクションが完了されることを保証し、そうでない場合には、部分的に完了したトランザクションを元に戻し、その結果、データ・レコードの保全性が維持されるようにすることができる。ＣＩＣＳ製品は、ＯＳ／３９０オペレーティング・システム、UNIX(R)オペレーティング・システム、およびIntelPCオペレーティング・システム用に供給される。ＣＩＣＳを用いると、エンド・ユーザが、IBM社のTransaction Serverを使用して、インターネット・ユーザからのe-businessトランザクションを処理し、これらを、既存のＣＩＣＳ注文および在庫データベースにアクセスするメインフレーム・サーバに転送できるようになる。
【００３８】
「ＩＭＳ」（情報管理システム）は、IBM社のエンタープライズ・システム体系（ＩＭＳ／ＥＳＡ）と共に、トランザクション・マネージャおよび階層データベース・サーバを提供する、IBM社のシステムである。
【００３９】
「ＭＱ」は、そのコンポーネントが他のソフトウェア・アプリケーションを一緒に結び付けるのに使用され、その結果、それらが一緒に動作できるようにする、MQSeries IBMソフトウェア・ファミリである。このタイプのアプリケーションを、しばしば、ビジネス・インテグレーション・ソフトウェアまたはミドルウェアと称する。機能的には、MQSeriesは、異なるプラットフォーム上のアプリケーションの間の通信機構、ビジネス・オペレーション・ルールを集中化し、適用するインテグレータ、および、ビジネス・プロセスの取込、視覚化、および自動化を可能にするワークフロー・マネージャを提供する。MQSeriesは、異なった地理的位置にある、似ていないＩＴインフラストラクチャを使用する、異なるコンピュータ・システムを接続し、その結果、シームレスな動作を実行できるようにする。IBM社のMQSeriesは、アプリケーション間および異なるシステム上のユーザおよびアプリケーションの組の間の通信を供給する。さらに、MQSeriesのメッセージング方式は、メッセージを受信するアプリケーションが受信を確認することを必要とする。確認が具体化されない場合には、メッセージが、MQSeriesによって再送信される。
【００４０】
「Rose」は、エンタープライズレベル・ソフトウェア・アプリケーションのビジュアル・モデリングおよびコンポーネント構成に充てられるオブジェクト指向統一モデリング言語（ＵＭＬ）ソフトウェア設計ツールである。Roseは、ソフトウェア設計者が、記号のドラッグアンドドロップを使用して、シーケンス図でアクタ（スティック人形）、ユース・ケース要素（楕円）、オブジェクト（長方形）、およびメッセージ／関係（矢印）を用いてクラスの輪郭を描くことによって、アプリケーションのフレームワークを視覚的に作成（モデル化）できるようにする。Roseでは、図が、構成されつつある間に文書化され、その後、C++、VisualBasic、Java(R)、Oracle８、Corba、またはデータ定義言語のうちの設計者が選択したもののコードが生成される。
【００４１】
共通アプリケーション・メタモデルの概要。共通アプリケーション・メタモデル（ＣＡＭ）は、図１に示された環境に相互接続性をもたらす。図１には、NetscapeまたはInternet Explorerブラウザ１０３、Sun Solarisサーバ１０７上のNet.Commerce１０５、データベース・サーバ１１３上のOracle１０９およびＤＢ２ １１１、AIX117で稼動するSAP115、CICS390サーバ119、ＩＭＳ ３９０サーバ１２１、Ｓ／３９０プラットフォーム１２７上のＤＢ２ １２３およびＤＬ／Ｉ １２５、Windows(R)2000クライアント１２９、およびＨＰ Unix(R)サーバ１３３上で稼動するＢａａｎ１３１を含む、複数のアプリケーション・コンポーネントを有する通常のシステム１０１を示す図である。共通アプリケーション・メタモデル（ＣＡＭ）は、図１内などのエンタープライズ・アプリケーションにソース言語でアクセスし、それらをターゲット言語に変換するのに必要な情報のマーシャルおよび適用のためのメタデータ交換の方法、ツール、およびシステムである。ＣＡＭは、図２に示されているように、言語メタモデルおよびアプリケーション・ドメイン・インターフェース・メタモデルからなり、図２には、エンタープライズ・アプリケーション統合２２１を促進するために共通アプリケーション・メタモデルのメタデータ・リポジトリ２１１への入力としてのメッセージ・セット２０３、ＳＱＬストアド・プロシージャ２０５、レガシ・アプリケーション２０７、およびプログラミング言語２０９の役割が示されている。
【００４２】
例示的なメタモデルには、図３に示されているように、Ｃ、C++、Java(R)、COBOL、ＰＬ／Ｉ、HLAssembler、ＩＭＳトランザクション・メッセージ、ＩＭＳ ＭＦＳ、ＣＩＣＳ ＢＭＳ、およびMQSeriesメッセージ・モデルが含まれ、図３には、呼出しメタモデル３０１、アプリケーションドメイン・インターフェース・メタモデル３０３、および言語メタモデル３０５と共に、本発明の共通アプリケーション・メタモデルが示されている。
【００４３】
図４に、ＯＴＭＡ呼出しメタモデル４２１、ＩＭＳトランザクション・メッセージ・メタモデル４２３、COBOLメタモデル４２５、およびＣメタモデル４２７と共に、ＩＭＳ ＯＴＭＡアプリケーション・インターフェース・メタモデル４１１を示す。
【００４４】
図５に、既存のアプリケーション５０１からインターフェース５０３を介してアプリケーション・インターフェース・メタデータを含むオブジェクト・モデルへの情報の流れを示す。このアプリケーション・インターフェース・メタモデルは、メタデータ・リポジトリ５０５に格納され、適当な時にメタデータ・リポジトリ５０５から検索され、生成ツール５０９でソース・プログラム５０７と組み合わされ、ＸＭＬファイルとしてのターゲット・ファイル５１１すなわちＸＭＩインスタンス・ファイルの生成に使用される。ＣＡＭは、大いに再利用可能であり、特定のツールまたはミドルウェアから独立である。
【００４５】
開発ステージ。ＣＡＭがあれば、ツーリングによって、エンタープライズ・アプリケーション、たとえばＩＭＳアプリケーションへのアクセスに対する解決策を簡単に提供することができる。各ソース・ファイルを解析し、ＣＡＭモデル、COBOLコピーブック、ＰＬ／Ｉコピーブック、ＭＦＳソース、ＢＭＳソースなどに基づいてＸＭＬ文書を生成することによって、ツールが、ＩＭＳ、ＣＩＣＳなどに対するコネクタ解決策を提供することができる。
【００４６】
これに関して、図６に、たとえばCOBOLメタモデル、ＰＬ／Ｉメタモデル、ＭＦＳメタモデル、ＢＭＳモデル、または類似物などの共通アプリケーション・メタモデルRoseファイル６０１が、ツールキット６０３に読み込まれて、RoseモデルのＤＴＤおよびスキーマとRoseモデル６０５のJava(R)コードが生成される開発フェーズのシナリオを示す。COBOLソース・ファイル、ＰＬ／Ｉソース・ファイル、ＭＦＳソース・ファイル、ＢＭＳソース・ファイル、または類似物として、およびRoseモデル６０９のJava(R)コードとして、アプリケーションのソース・ファイル６０７が、インポータ６１１に読み込まれる。インポータは、ソース・コードを解析し、出力としてＸＭＩインスタンス・ファイル６１３すなわちアプリケーション・ソース・ファイルのＸＭＬ文書を提供する。
【００４７】
図７に、アプリケーション・インターフェースのＣＡＭメタモデルを示す。この図には、アプリケーション・インターフェース・メタモデル７０７に従って、既存のアプリケーション・プログラムのインターフェース定義を含むインターフェース７０５を介して既存のアプリケーション・プログラム７０３とインターフェースする、呼出し機能および変換機能を有する実行時コネクタ７０１が示されている。アプリケーション・インターフェース・メタデータは、メタデータ・リポジトリ７０９に格納される。
【００４８】
フローおよびメッセージング・ミドルウェア７１３が、アプリケーション・インターフェース７０５を介してアプリケーション７０３を呼び出す。これらのインターフェース７０５は、それを介してすべての入出力がミドルウェア７１３に接続されるアプリケーション７０３へのアクセス点である。インターフェース７０５は、アプリケーション・インターフェース・メタモデルに関して記述される。メタモデルによる変換処理は、ソース／クライアント・アプリケーション、ターゲット・アプリケーション、またはゲートウェイで行うことができる。
【００４９】
ＣＡＭは、データ型およびストレージ・マッピングの物理的表現を提供して、エンタープライズ・アプリケーション統合環境でのデータ変換をもサポートするので、エンタープライズ・アプリケーション用のウェブ・サービスを使用可能にする。開発時に、ＣＡＭは、下記を容易にする情報を取り込む。
ａ）．コネクタまたはコネクタビルダ・ツールあるいはその両方、
ｂ）．アプリケーション生産性および品質保証に関するデータ駆動影響分析、および
ｃ）．開発者によるプログラミング言語データ宣言の考察。
【００５０】
ＣＡＭメタモデル・ファイルは、ＣＡＭモデルを表すＤＴＤファイル、ＸＭＬスキーマ、およびJava(R)クラスの生成に使用されるツールキットへの入力である。インポータは、各ソース・ファイル（たとえばCOBOLまたはＰＬ／Ｉコピーブック、ＭＦＳソース、およびＢＭＳなど）を解析し、その後、ＸＭＩ／ＭＯＦ２ツールキットによって生成されたJava(R)クラスに基づいてＸＭＬ文書（すなわちＸＭＬインスタンス・ファイル）を生成する。
【００５１】
実行時。実行時に、ＣＡＭは、それが混合言語間のデータ型マッピングを提供するエンタープライズ・アプリケーション統合環境での変換を容易にする情報を提供し、ある言語およびプラットフォーム・ドメインから別の言語およびプラットフォーム・ドメインへのデータ変換を容易にする。
【００５２】
図８に、実行時中の共通アプリケーション・メタモデルの適用を示す。図からわかるように、ＳＯＡＰ準拠ＸＭＬ文書８０３が、たとえばIBM WebSphereミドルウェア８０５内で受け取られ、このIBM WebSphereミドルウェア８０５は、Java(R)用のＩＭＳＣｏｎｎｅｃｔｏｒ８０７を含み、ＸＭＬリポジトリ８０９と接触し、ＸＭＬリポジトリ８０９には、ＣＡＭモデルのＸＭＩインスタンス・ファイルが含まれる。IBMWebSphereミドルウェアは、変換されたファイルをＩＭＳシステム８１１に送り、ＩＭＳシステム８１１には、ＩＭＳ接続８１３とＩＭＳトランザクショナル・アプリケーション・プログラム８１５のインスタンスが含まれる。ＣＡＭは、バックエンドのＩＭＳアプリケーション８１５とウェブ・ファイル（たとえばＳＯＡＰ準拠ＸＭＬ文書）８０３の間の接続性を促進する。ＣＡＭは、ＣＡＭモデル情報（リポジトリ８０９からの）を使用して、図示の混合言語環境で、あるプラットフォームから別のプラットフォームへのデータ変換を実行することによって、これを達成する。
【００５３】
TypeDescriptorメタモデル。ＣＡＭによって提供される１つの重要な特徴が、TypeDescriptorメタモデルである。TypeDescriptorメタモデルによって、物理的実現、ストレージ・マッピング、および実現に対する制約（位置調整など）が定義される。このメタモデルによって、所与のデータ構造体の個々のフィールドの物理的表現が提供される。エンタープライズ・アプリケーション統合環境でデータ変換をサポートする時に、このモデルによって、混合言語の間でのデータ型マッピングが提供される。このモデルによって、ある言語およびプラットフォーム・ドメインから別の言語およびプラットフォーム・ドメインへのデータ変換も容易になる。メタモデルは、全体的なデータ構造体名およびフィールド名の言語固有メタモデルを用いる実行時データ変換（またはマーシャル）に使用される。
【００５４】
１．アプリケーション・インターフェースに関する共通アプリケーション・メタモデル
図１に示されたように、異なるオペレーティング・システム、物理プラットフォーム、および物理的実現を有する、異なるソフトウェア・プラットフォームで稼動する異なる似ていないアプリケーションは、相互接続メタデータを組み込んだコネクタを介して達成される。コネクタは、e-businessに関するアプリケーション・フレームワークの中心部分である。エンド・ユーザの要求は、興味を持たれるすべてのものにできる限りすばやくできる限り簡単に接続することである。
【００５５】
アダプタとレガシ・アプリケーションのインターフェース要件を一致させるために、コネクタが必要である。２つのインターフェースの間でのマッピングも必要である。本明細書で提示されるアプリケーション・インターフェースの標準化されたメタモデルを用いると、複数のコネクタ・ツールでの情報の再利用が可能になる。これらの標準化されたメタモデルによって、コネクタを作成する作業が減るだけではなく、コネクタ・ビルダ・ツールを開発するのに必要な作業も減る。
【００５６】
本発明の共通アプリケーション・メタモデルを使用して構築されるコネクタは、既存のアプリケーションとのインターオペラビリティを提供する。コネクタは、既存のアプリケーション・システム内で保持されるデータおよびビジネス・ロジックの活用および再利用をサポートする。コネクタの仕事は、あるアプリケーション・システム・サーバ・「インターフェース」から別のアプリケーション・システム・サーバ・インターフェースに接続することである。したがって、アプリケーションドメイン・インターフェース・メタモデルによって、所与のアプリケーション・システム・ドメイン（たとえばＩＭＳ、MQSeries）の入出力パラメータのシグニチャおよび戻りの型が記述されるが、これは、特定のＩＭＳアプリケーション・プログラムまたはMQSeriesアプリケーション・プログラムに関するものではない。メタモデルには、構文インターフェース・メタデータおよびセマンティック・インターフェース・メタデータの両方が含まれる。
【００５７】
１．ａ．共通アプリケーション・メタモデルを使用するエンドツーエンド・コネクタ使用
共通アプリケーション・メタモデル（ＣＡＭ）は、特定のツールまたはミドルウェアから独立の、メッセージ・シグニチャのメタ定義からなる。異なるコネクタ・ビルダ・ツールが、この情報を使用して、これらのアプリケーション・プログラム間での、異なるツール、言語、およびミドルウェアにまたがる「ハンドシェーク」を保証することができる。たとえば、MQSeriesアプリケーションを呼び出す必要がある場合には、ＧＵＩツールからのデータを使用してＭＱメッセージを構築し、ＭＱ ＡＰＩを使用してそのメッセージを送達する必要がある。同様に、MQSeriesアプリケーションからメッセージを受け取った時には、MQSeriesからバッファを入手し、それを解析し、それをＧＵＩツール・データ構造体に入れる必要がある。これらの機能は、アプリケーション・インターフェースの標準化メタモデルとしてＣＡＭを使用するコネクタ・ビルダ・ツールによって、効率的に設計し、実装することができる。
【００５８】
ＣＡＭを、コピー・ブックを含む多数のソースから移植して、入力を収集し出力を返すＨＴＭＬフォームおよびJava(R) Server Page（ＪＳＰ）を生成することができる。前の図に示されたコネクタの例は、フローおよびメッセージ・ミドルウェアが、コネクタを呼び出すことによってエンタープライズ・アプリケーションへの関数呼出しを行い、このコネクタがエンタープライズ・アプリケーションＡＰＩを呼び出すということである。コネクタは、言語およびデータ型のマッピングを行って、たとえば、ＸＭＬ文書とCOBOL入力の間で変換し、ＣＡＭに基づくデータ構造体を出力する。コネクタおよびＣＡＭは、ミドルウェアとエンタープライズ・アプリケーションの間のエンドツーエンド統合を提供する。
【００５９】
例としてＩＭＳを使用する。自分のデスクトップ機からＩＭＳトランザクション・アプリケーション・プログラムにアカウント番号を渡して、５０．００ドルを引き出さなければならないと仮定する。ＣＡＭおよびコネクタ・ビルダ・ツールがあれば、まず、入力ＨＴＭＬフォームおよび出力ＪＳＰを生成し、要求をサポートするのに必要なミドルウェア・コードを開発することになる。デスクトップ・アプリケーションが、要求データ構造体（すなわち、入力ＨＴＭＬフォーム）に値を書き込み、ミドルウェアを呼び出す。ミドルウェア・サービス・コードは、ＧＵＩツールからデータを受け取り、IMS ConnectのＸＭＬフォーマットのメッセージを構築し、そのメッセージを、ＴＣＰ／ＩＰを介してＩＭＳゲートウェイ（すなわちIMSConnect）に送達する。IMS Connectは、ＣＡＭに取り込まれたメタデータ定義を使用して、ＸＭＬ文書とCOBOLのＩＭＳメッセージ・データ構造体の間で変換する。その後、IMSConnectは、ＩＭＳメッセージ・データ構造体を、Open Transaction Manager Access（ＯＴＭＡ）を介してＩＭＳに送る。ＩＭＳ COBOLアプリケーション・プログラムが、稼動し、IMSConnectを介して出力メッセージをミドルウェア・サービス・コードに返す。ミドルウェア・サービス・コードは、メッセージを入手し、応答データを出力ＪＳＰページ（すなわち、前に生成されたＧＵＩツール応答データ構造体）に移植する。その後、トランザクション出力データが、ユーザに提示される。
【００６０】
２．共通アプリケーション・メタモデル
ＣＡＭは、共通のプログラミング・モデルで開発されたアプリケーションを、他のシステムと簡単に統合するのに必要な情報を記述するのに使用される。ＣＡＭメタモデルは、同期式呼出しと非同期式呼出しの両方に使用することができる。
【００６１】
２．ａ．共通アプリケーション・メタモデル
以下で述べる共通アプリケーション・メタモデルは、呼出しメタモデルと、言語メタモデルを使用するアプリケーションドメイン・インターフェース・メタモデルからなる。所与のアプリケーションドメイン・インターフェース・メタモデルについて、そのメタモデルは、１つまたは複数の言語メタモデルを使用することができるが、０個以上の呼出しメタモデルを設けることができる。
【００６２】
共通コネクタ・メタモデルを、図３に示す。これは、呼出しメタモデル３０１、アプリケーションドメイン・インターフェース・メタモデル３０３、および言語メタモデル３０５を有する。
【００６３】
２．ａ．ｉ．呼出しメタモデル
呼出しメタモデル３０１は、１つまたは複数の下記の可能なメタデータ要素からなる。しかし、特定の呼出しに関して、呼出しメタモデルに、１つまたは複数の下記のメタデータ要素だけを含めることができる。
【００６４】
メッセージ制御情報。これには、メッセージ接続名、メッセージ・タイプ、シーケンス番号（ある場合）、および、応答、コミット確認、および処理オプション（これによって、クライアントまたはサーバが、メッセージ処理を同期式または非同期式になるように制御することができる）に関するさまざまなフラグおよびインジケータなどのメッセージ制御情報が含まれる。
【００６５】
接続名は、すべての入出力を特定のクライアントに関連付けるために、アプリケーション・システム・サーバが使用することができる。メッセージ・タイプによって、メッセージが応答メッセージであること、またはコミットが完了したことが指定される。メッセージ・タイプによって、クライアントへのサーバ出力データまたはサーバへのクライアント入力データを示すこともできる。
【００６６】
セキュリティ・データ −− これには、認証機構と、たとえばディジタル証明書、識別、ユーザ名およびパスワードなどのセキュリティ・データが含まれる。これには、ロール・ベースの認証またはＡＣＬ（アクセス制御リスト）ベースの認証を介してデータを許可することができるかどうかを示す認証情報も含めることができる。
【００６７】
トランザクション・セマンティクス −− これは、たとえばローカル・トランザクション対グローバル・トランザクション、２フェーズ・コミット対１フェーズ・コミット、およびトランザクション・コンテキストなどのトランザクション情報を搬送する。
【００６８】
トレースおよびデバッグ −− トレースおよびデバッグ情報は、メタモデルの一部として指定される。
【００６９】
事前条件リソースおよび事後条件リソース −− これによって、アプリケーション状態の事前条件および事後条件の関係が記述される。
【００７０】
ユーザ・データ −− これには、クライアントによって要求される特殊な情報のすべてが含まれる。これには、どのようなデータでも含めることができる。
【００７１】
２．ａ．ｉｉ．アプリケーションドメイン・インターフェース・メタモデル
前に述べたアプリケーションドメイン・インターフェース・メタモデル３０３によって、アプリケーション・システム・ドメインに関する、入出力パラメータのシグニチャおよび戻りの型が記述される。
【００７２】
２．ａ．ｉｉｉ．言語メタモデル
たとえばCOBOLメタモデルなどの言語メタモデル３０５は、コネクタ・インターフェースを表すデータ構造体（セマンティクス）を定義するために、エンタープライズ・アプリケーション・システムによって使用される。コネクタ開発者に、ソース言語、ターゲット言語、およびこの２つの間のマッピングを見せることが、コネクタ・ツールにとって重要である。ＣＡＭ言語メタモデルには、編集可能でないモデル（すなわち、読取専用モデル）内の宣言テキストも含まれる。コネクタ／アダプタ開発者は、おそらく、コメントおよび宣言の各フィールドによって演じられるビジネス・ロールを理解するのに役立つ他のドキュメンテーションを含めて、COBOLデータ宣言全体を見ることを好む。
【００７３】
言語メタモデルは、アプリケーションの生産性および品質保証のためのデータ駆動影響分析もサポートする（しかし、コピーブックの複写をサポートすることは、ＣＡＭの意図ではない）。
【００７４】
コネクタ・データを記述する言語メタモデルを、下にリストする。
＊ Ｃ
＊ C++
＊ COBOL
＊ ＰＬ／Ｉ
【００７５】
２．ａ．ｉｖ．TypeDescriptorメタモデル
TypeDescriptorメタモデルは、言語中立であり、このメタモデルによって、物理的実現、ストレージ・マッピング、および位置調整などの実現に対する制約が定義される。このメタモデルによって、所与のデータ構造体の個々のフィールドの物理的表現が提供される。この型記述子メタモデルは、エンタープライズ・アプリケーション統合環境でデータ変換をサポートして、混合言語の間でのデータ型マッピングを提供するためのものである。このメタモデルによって、ある言語およびプラットフォーム・ドメインから別の言語およびプラットフォーム・ドメインへのデータ変換も容易になる。このメタモデルは、全体的なデータ構造体名およびフィールド名の言語固有メタモデルを用いる実行時データ変換（またはマーシャル）の処方として使用される。
【００７６】
３．共通コネクタ・メタモデルの例
ＩＭＳ ＯＴＭＡ（Open Transaction Manager Access）は、ＯＳ／３９０シスプレックス環境内のトランザクションベースのコネクションレス・クライアント／サーバ・プロトコルである。ＩＭＳ ＯＴＭＡトランザクション・メッセージは、ＯＴＭＡプレフィックスと、入力要求および出力要求に関するメッセージ・セグメントからなる。入力メッセージ・セグメントと出力メッセージ・セグメントの両方に、ｌｌｚｚ（すなわち、セグメントの長さと予約済みフィールド）と、アプリケーション・データが含まれる。最初の入力メッセージ・セグメントだけに、アプリケーション・データの前にトランザクション・コードが含まれる。ＩＭＳトランザクション・アプリケーション・プログラムは、COBOL、ＰＬ／Ｉ、Ｃ、およびJava(R)などのさまざまな言語で記述することができる。したがって、アプリケーション・データに、これらの言語のどれでも使用することができる。
【００７７】
図４に示されているように、ＩＭＳ ＯＴＭＡアプリケーション・インターフェース・メタモデル４１１は、ＯＴＭＡ呼出しメタモデル４２１およびＩＭＳトランザクション・メッセージ・メタモデル４２３ならびにCOBOLメタモデル４２５およびＣメタモデル４２７からなる。図４に示されているように、ＯＴＭＡ呼出しメタモデル４２１は、ＯＴＭＡプレフィックスであり、ＩＭＳトランザクション・メッセージ・メタモデル４２３は、言語メタモデルを使用するＩＭＳアプリケーション・システムのアプリケーションドメイン・インターフェース・メタモデルである。COBOLメタモデル４２５およびＣメタモデル４２７が示されている。
【００７８】
４．TypeDescriptorメタモデル
型記述子メタモデルは、配列および構造型を含む実装型を記述する言語独立かつプラットフォーム独立の形を提示する。この情報は、ある言語およびプラットフォーム・ドメインから別の言語およびプラットフォーム・ドメインにデータを変換しなければならない、マーシャルおよびコネクタに必要である。異なる言語の型モデルの検査によって、言語型の一致可能性を判定することができる。たとえば、Java(R)のlong型は、しばしば、COBOLのbinary型（computational-5）と同一であり、その場合には、これらの型を、副作用なしで相互変換することができる。その一方で、COBOLのalphanumeric型は、サイズが固定されるが、Java(R)の型にマッピングされる場合に、この特性が失われる。Java(R)からCOBOLに再変換される時に、COBOLの切詰規則が適用されず、計算の例外がもたらされる可能性がある。さらに、サーバ環境で言語を混合するツール（たとえばＣＩＣＳおよびＩＭＳのJava(R)およびCOBOL）は、ある言語がどれほど忠実に別の言語の型を表現できるかを判定する方法としてこれが有用であることを見出すに違いない。したがって、型記述子メタモデルのインスタンスでは、特定のプラットフォームおよびコンパイラに関する特定のデータ型の物理的表現を記述する。
【００７９】
４．ａ．TDLangメタモデル
TDLangメタモデルは、TypeDescriptorメタモデルとすべてのＣＡＭ言語メタモデルとの間の抽象のレイヤを提供することによって、ＣＡＭ言語メタモデルに対する基本クラスとして働く。TDLangクラスのすべてが、抽象クラスであり、すべてのＣＡＭ言語メタモデルに共通である。TDLangクラス間のすべての関連が、その関連が言語メタモデルから派生したことを反映するために、”volatile”、”transient”、または”derived”としてマークされる。TDLangモデルは、独力では何の機能も提供しないが、TypeDescriptorメタモデルから言語メタモデルへの関連の型ターゲットである。
【００８０】
図９に、TDLangClassifier９０１、TDLangComposedType９０３、およびTDLangElement９０５と共にTDLangメタモデルの構造を示す。
【００８１】
TDLang基本クラスと共に、TypeDescriptorメタモデルを、全体的なデータ構造体名およびフィールド名の言語固有メタモデルを用い、言語モデルに存在する集約関連を複製せずに、実行時データ変換（またはマーシャル）の処方として使用することができる。
【００８２】
４．ｂ．TypeDescriptorメタモデル
このメタモデルは、Ｍ２レベルのＭＯＦクラスのインスタンスである。図１０、図１１、および図１２に、PlatformCompilerType、InstanceTDBase、ArrayTD、AggregateInstanceTD、SimpleInstanceTD、およびInstanceTypeを含む、型記述子メタモデル内の関係を示す。InstanceTypeには、StringTD、AddressTD、NumberTD、およびFloatTDの定義が含まれる。図１３に、TDLanguageElement１１００とPlatformCompilerType１１０１の高水準ビューを示す。図１４に、signCoding１２０１、lengthEncoding１２０３、floatType１２０５、accessor１２０７、packedDecimalSign１２０９、およびbitModePad１２１１の列挙を示す。
【００８３】
４．ｃ．TypeDescriptorおよび言語モデル
TypeDescriptorモデルは、TDLangElementとInstanceTDBaseの間のナビゲート可能な関連によってＣＡＭ言語モデルに接続される。TDLangElementは、宣言されたデータ項目すなわち型のインスタンスを表すのに使用される基本言語モデル型である。InstanceTDBaseは、この同一の宣言されたデータ項目の実装固有インスタンスを表すのに使用される基本TypeDescriptorモデル型である。InstanceTDBaseは、抽象クラスであり、そのサブタイプの１つだけをインスタンス化することができる。
【００８４】
プログラミング言語で宣言されたデータ項目が、異なる実装を有することができる可能性がある。これらの相違は、ハードウェア・プラットフォーム、システム・プラットフォーム、およびコンパイラの相違によって誘発される。この可能性は、PlatformCompilerTypeモデル型によってモデル化される。TDLangElementとPlatformCompilerTypeの間の関連は、多対１であり、PlatformCompilerTypeとInstanceTDBaseの間の関連は、１対１である。言語モデルからナビゲートするために、どのPlatformCompilerTypeが前提になっているかを知る必要がある。実装において、モデル・インスタンスをインポートする際に、重要でないPlatformCompilerTypeインスタンスをモデルから除去することが望まれる可能性がある。TDLangElementとInstanceTDBaseの間の関連を、この形でモデル化して、ハードウェア・プラットフォーム、システム・プラットフォーム、およびコンパイラをより完全に記述する新しい型とPlatformCompilerTypeの間の関連を含むようにモデルを拡張できるようにする。
【００８５】
データ要素インスタンスを、繰り返されるグループまたは配列として定義することができる。これは、InstanceTDBaseとArrayTDモデル型の間の１対多関連としてモデル化することができる。データ要素の次元、添字、または独立のインデックスのそれぞれについて、この関連に１つのArrayTDインスタンスがある。これらのインスタンスは、限界およびアクセス計算に関する情報を保持する。
【００８６】
関連は、言語モデル内の対応する関連と同一の順序で順序付けられ、プログラミング言語によって定義されるインデックスの構文的な順序付けを反映する。この選択の根本的な理由は、その結果の、言語モデルとTypeDescriptorモデルの間のナビゲーションおよび処理アルゴリズムの同等性である。おそらくマーシャル・エンジンにより有利なもう１つの選択は、インデックスの順序付けを、最小のストライドから最大のストライドにすることである。これによって、配列が普通の連続的な形で配置されると仮定して、マーシャル・エンジンが、配列を自然なストレージ順序で処理できるようになる。マーシャル・エンジンは、望まれる場合に、ストライド式に従って関連ターゲットをソートし直すことによって、この順序を計算することができる。
【００８７】
配列情報は、データ要素またはその型の複雑な特性になる可能性があり、さまざまな言語およびプログラミングの実践が、このどちらかに含まれると思われる。ＣおよびC++のtypedef機能を用いると、typedefからのいくつかの配列型の定義が可能であるが、これは、配列定義が、typedef集約の最上位要素に適用される場合に限られる。たとえば、次のtypedefを検討されたい。
typedef struct {
int A;
struct {
int C;
char D;
struct {
intF;
int G;
} E;
} B;
} X;
このtypedefを使用して、固定サイズの配列の新しいtypedef、たとえば
typedef X Q[10];
を作成することができる。しかし、Ｘのサブコンポーネントのどれか、たとえばＤまたはＥを配列にする新しいtypedefを、Ｘから作成することは不可能である。この例および多数の他の例によって、型付き言語での配列定義の不明瞭な状況が示される。
【００８８】
InstanceTDBase型は、２つの具象サブタイプ、SimpleInstanceTDおよびAggregateInstanceTDを有する。SimpleInstanceTDは、サブコンポーネントなしのデータ要素をモデル化し、AggregateInstanceTDは、サブコンポーネントを有するデータ要素をモデル化する。AggregateInstanceTDのサブコンポーネントを見つけるためには、ＣＡＭ言語モデルの対応するデータ要素宣言まで逆にナビゲートしなければならない。そこで、集約型とそのサブコンポーネントの間の関連をナビゲートすることができ、これがサブコンポーネント・データ要素の組につながり、そのそれぞれが、TypeDescriptorモデルの１つまたは複数のインスタンスを有する。これによって、ある程度のモデル・ナビゲーションの複雑さが導入されるが、言語モデルとTypeDescriptorモデルの両方での集約階層の重複が回避される。トラバーサルの追加の処理の複雑さは、大きくはなく、モデルを修正して集約にサブコンポーネントを追加、削除、または再配置するアルゴリズムで、かなりの単純化が得られる。
【００８９】
SimpleInstanceTDモデル型も、BaseTDモデル型に１対１で関連する。BaseTDモデル型は、同一の言語型のすべてのデータ要素に共通する実装情報を保持するように特殊化される。したがって、特定のハードウェア／ソフトウェア・プラットフォームでの３２ビット符号付き２進整数を記述する情報は、この型を用いてどれほど多数のデータ要素が宣言されるかに無関係に、所与のモデル・インスタンス化において１回だけインスタンス化される。
【００９０】
TDLangElementとInstanceTDBaseの間の関連に一致する、TDLangClassifierとBaseTDの間の関連を企図することができる。しかし、これには、言語が単純型（たとえばストリング）とみなす構造が、単純なハードウェア／ソフトウェア型に直接にマッピングされない可能性があるという点で問題がある。ストリング実装を記述するためにTypeDescriptorモデルにより多くの機構を導入するのではなく、共通のストリング実装を記述するBaseTDの特殊化を使用する。TypeDescriptorモデルのさまざまな属性に、ストリング”formula”の接尾辞が付けられている。これらの属性には、いくつかの場合に実行時にのみ作成されるデータにアクセスしなければ計算が不可能である可能性がある情報が含まれる。１つの例が、可変サイズ配列の現在の上限、またはサイズが実行時にのみ既知になる別の要素に続く要素へのオフセットである。そのような情報は、モデル・インスタンスに値として含めることができるが、これは、実行時インスタンスごとに１つのモデル・インスタンスを必要とし、モデルを実行時にのみ構成できることを意味し、モデル定義で、実行時にモデル・インスタンスを作成するためにファクトリおよび他の装置を含めることが必要になることを意味する。プラットフォームおよびコンパイラの知識から構成できるモデルは、はるかに有用であり、数式によって、実行時情報が使用可能である時に具象的な値を定義する方法が提供される。これらの数式は、マーシャル・エンジンによって解釈することができ、あるいは、数式を使用して、マーシャル・エンジンによってオンデマンドでロードされ実行されるマーシャル・コードを生成することができる。
【００９１】
４．ｄ．数式
数式に関して使用される時に、「フィールド」は、TypeDescriptorモデルによって記述される言語データ構造体の構成要素を指し、「属性」は、モデルの部分を指し、フィールドの「特性」を表す値を有する。したがって、フィールドの値は、言語データ構造体の特定のインスタンスの実行時値を意味し、属性の値は、言語データ構造体のフィールドの記述の一部であり、そのデータ構造体のすべてのインスタンスに適用され、データ構造対がモデル化される時に決定される。TypeDescriptorモデルのインスタンスのほとんどの属性について、属性の値は、インスタンスが構築される時に既知である。というのは、データ構造体内のサイズおよびオフセットなど、記述されるフィールドの特性が、不変であるからである。しかし、データ構造体のフィールドが、COBOLのOCCURSDEPENDING ON構造またはＰＬ／ＩのRefer構造を使用して定義される場合には、フィールドのいくつかの特性（およびそのフィールドの値に依存する他のフィールドの特性）を、モデル・インスタンスが構築される時に判定できない。
【００９２】
これらの言語構造を使用して定義できる特性が、ストリング長および配列の限界である。これらの言語構造に間接的に依存する可能性がある特性が、フィールドが可変サイズのフィールドに続く場合の、構造体内のフィールドのオフセットである。
【００９３】
これらの言語構造を処理するために、これらの構造（したがって、対応する属性の値）に依存する可能性があるフィールドの特性を、モデルが使用される時に評価できる数式を指定するストリングを用いて定義する。
【００９４】
しかし、あるフィールドの特性が、モデル・インスタンスが構築される時に既知である場合には、属性数式によって、単純に整数値が指定される。たとえば、ストリングが長さ１７を有する場合には、その長さの数式が”１７”になる。
【００９５】
上で述べた数式は、下記に制限される。
＊符号なし整数
＊下記の算術整数関数
neg(x) := -x ／／ プレフィックス否定
add(x、y) := x+y ／／ インフィックス加算
sub(x、y) := x-y ／／ インフィックス減算
mpy(x、y) := x*y ／／ インフィックス乗算
div(x、y) := x/y ／／ インフィックス除算
max(x、y) := max(x、y)
min(x、y) := min(x、y)
mod(x、y) := x mod y
ｍｏｄ関数は、ｍｏｄ（ｘ、ｙ） ＝ ｒとして定義され、ここで、ｒは、ｘ−ｒがｙによって割り切れるようになる最小の非負の整数である。したがって、ｍｏｄ（７、４）は３であるが、ｍｏｄ（−７、４）は１である。ｙが２のべきである場合には、ｍｏｄ（ｘ、ｙ）は、ｘとｙ−１のビット単位の論理ＡＮＤに等しい。
＊ ｖａｌ関数
ｖａｌ関数は、モデルによって記述されるフィールドの値を返す。ｖａｌ関数は、１つまたは複数の引数をとり、第１引数は、フィールドを含むレベル−１データ構造体を参照し、
＊言語モデル内のレベル−１データ構造体の名前、または
＊可変サイズ・フィールドのレベル−１親を示す整数１
のいずれかでなければならない。後者の場合に、可変サイズ・フィールドと、そのサイズを指定するフィールドが、同一のデータ構造体内にあり、したがって、共通のレベル−１親を有する。
後続の引数は、参照解除されなければならない（サブ）フィールドのサブ構造体内での序数を指定する整数である。
【００９６】
デフォルトで、構造体内のCOBOLデータ・フィールドは、ストレージ内で型固有の境界に位置合せされない。たとえば、４バイト整数の「自然な」位置合せは、フルワード・ストレージ境界である。そのような位置合せは、宣言でSYNCHRONIZED文節を使用することによって指定することができる。そうでない場合には、データ・フィールドは、構造体内の先行するフィールドの末尾の直後から始まる。COBOLは、ビット・データを有しないので、フィールドは、必ずバイト全体の境界から始まる。
【００９７】
ＰＬ／Ｉの場合に、状況はより複雑になる。位置合せは、Aligned宣言属性およびＵｎAligned宣言属性によって制御される。COBOLとは違って、データのほとんどの型、特に２進数および浮動小数点数が、デフォルトで自然な境界に位置合せされる。
【００９８】
４．ｄ．ｉ）数式の例
４．ｄ．ｉ）ａ）COBOL
この例では、ドラフト規格からの提案されたインライン・コメント・インジケータ”＊＞”を使用する。これは、まだ正当なCOBOLの使用法ではない。
【００９９】
１．下記のデータ記述を検討されたい。
*> フィールドオフセット
01 Used-Car.*> "0"
02 Summary.*> "0"
03 Make picx(36).*> "0"
03 Model picx(44).*> "36"
03 VIN picx(13).*> "80"
03 Color picx(10).*> "93"
88 Redvalue 'Red'.
88White value 'White'.
88Blue value 'Blue'.
02 History.*> "103"
03 Mileagepic 9(6).*> "103"
03 NumClaimsbinary pic 9.*> "109"
03 InsCodepic x.*> "111"
03Claims.*> "112"
04Claim occurs 1 to 9 times
depending on NumClaims. *> stride(1) ="157"
05 ClaimNo pic x(12).
05 ClaimAmt binary pic 9(5).
05 Insurer pic x(38).
05 Details pic x(100).
02 Price comp pic9(5)v99.*> "add(112,mpy(val(1,2,2),157))"
Modelのオフセットは、単純であり、数式”３６”によって与えられる。Claimsのオフセットもそうであり、”１１２”である。
【０１００】
しかし、配列Claimは、変化する回数だけ現れる可能性があるので、構造体Historyは、可変サイズ・フィールドである。したがって、Claimsの直後のPriceのオフセットは、配列ストライド（特定の次元に沿って連続する要素の間の距離）を含む、より複雑な数式を必要とする。Claimについて、１つの次元だけがあり、そのストライドの数式は”１５４”である。したがって、Priceのオフセットの数式は、次のようになる。
"add(112,mpy(val(1,2,2),154))"
【０１０１】
ｖａｌ関数の第１引数は１であり、これは、実行時に値を含むフィールドNumClaimsが、数式によってオフセットが指定されるフィールドPriceと同一のレベル−１構造体Used-Car内にあることを意味する。他の２つの引数は、２と２である。第１の２は、Used-Carの第２の即値サブコンポーネントHistoryを指す。第２の２は、参照解除されるフィールドが、Historyの第２コンポーネントすなわち、NumClaimsであることを意味する。
【０１０２】
OCCURS DEPENDING ONオブジェクトが、別の構造体、たとえばレベル−１構造体Car-Dataの第３サブコンポーネント内にある場合には、ｖａｌ関数が、”ｖａｌ（Car-Data、３）”になる。
【０１０３】
COBOLの構造体マッピングは、トップダウンであるが、この方向は、SYNCHRONIZED文節がデータ宣言で指定されない限り、影響を生じない。SYNCHRONIZEDを指定することによって、個々のフィールドがその自然な境界に位置合せされ、したがって、構造体マッピングに「ギャップ」が導入される。下のデータ構造体を参照されたい。これは、SYNCHRONIZED文節を除いて、上の例と同一である。
*> フィールドオフセット
01 Used-CarSYNCHRONIZED *> "0"
02 Summary.*> "0"
03 Make picx(36). *>"0"
03 Model picx(44).*> "36"
03 VIN picx(13).*> "80"
03 Color picx(10).*> "93"
88 Redvalue 'Red'.
88White value 'White'.
88Blue value 'Blue'.
02 History.*> "103"
03 Mileagepic 9(6).*> "103"
03 NumClaimsbinary pic 9.*> "110"
03 InsCodepic x.*> "112"
03Claims.*> "113"
04Claim occurs 1 to 9 times
depending on NumClaims. *> stride(1) = "160"
05 ClaimNo pic x(14).
05 ClaimAmt binary pic 9(5).
05 Insurer pic x(39).
05 Details pic x(100).
02 Price comp pic9(5)v99.*> "add(add(113,mpy(val(1,2,2),160)),3)"
【０１０４】
２進フィールドを適当なハーフワード・ストレージ境界またはフルワード・ストレージ境界に位置決めするために、COBOLでは、「遊びバイト」と称する埋込みを構造体に導入する。トップダウンで作業して、この埋込みが、位置合わせを必要とするフィールドの直前に導入される。したがって、MileageとNumClaimsの間に１バイトの埋込みがある。
【０１０５】
Claimなどの配列について、COBOLは、要素内の埋込みを調整するだけではなく、配列の各要素の位置合わせも調整する。この例では、Claimの最初の出現が、フルワード境界の１バイト後に開始される。フィールドClaimNoは、正確にフルワードの長さなので、フルワード境界の１バイト後で終り、したがって、COBOLでは、２進数フルワード整数ClaimAmtの直前に３バイトの埋込みが挿入される。また、後続の出現を位置合わせし、その結果、それらも最初の出現のようにフルワード境界の１バイト後から始まり、したがって、同一の構成を有することができるようにするために、COBOLでは、各出現の末尾に３バイトの埋込みを追加する。
【０１０６】
最後に、埋込みの後に、Claimの各出現が、フルワード境界の１バイト後で（始まり、）終わるので、COBOLでは、２進フィールドPriceの後に３バイトの埋込みが置かれる。これらの余分なバイトのすべての結果として、Priceのオフセットの数式は、位置合わせされない例からかなり変更され、次のようになる。
"add(add(113,mpy(val(1,2,2),160)),3)"
【０１０７】
OCCURS DEPENDING ON構成とＰＬ／ＩのReferオプションの間に、複数の相違がある。COBOL構造体のストレージは、必ず最大サイズで割り振られるが、ＰＬ／Ｉ構造体は、Referオプションによって指定される実際のサイズで割り振られる。可変サイズCOBOL配列の特定のインスタンスでの出現の数を変更することが、正しく、普通であり、これは、その配列に続くすべてのフィールドの位置およびオフセットが変化するという影響を有する。ＰＬ／Ｉについて、構造体の特定のインスタンスのReferオブジェクトの値は、実行中に固定されることを意図される。したがって、可変サイズ・フィールドに続く位置合わせされるオブジェクトは、必ず、構造体の各インスタンスについて正しく位置合わせされる。というのは、埋込みの量が、Referオプションによって決定されるように、インスタンスごとに一意に計算されるからである。対照的に、可変サイズCOBOL配列に続くすべての位置合わせされるフィールドの埋込みの量は、最大配列サイズを仮定して計算され、コンパイル時に固定される。配列が、その最大サイズより小さい場合には、位置合わせが、通常は不正になる。たとえば、COBOLでは、次の例で、
1 a sync.
2 b binary pic 9.
2 c pic x occurs 1 to 5times depending on b.
2 d binary pic 9(9).
ｃとｄの間に１バイトが挿入される。したがって、ｄの位置合わせは、ｂの２つの値すなわち、最大値５と２だけについて正しい。
【０１０８】
上で注記したように、数式は、構造体内のフィールドのオフセットだけではなく、境界およびストライドなど、配列の特性も記述する。COBOLでは、要素参照に、複数の添字が使用されるが、真の多次元配列がない。その代わりに、COBOLには、次の簡単な例のように、配列の配列がある。
1 a.*< offset = "0"
2 d1 occurs 5times. *< offset ="0"
*< lbound(1) = "1"
*< hbound(1) = "5"
*< stride(1) = "168"
3 d2 occurs 6times. *< offset ="0"
*< lbound(2) = "1"
*< hbound(2) = "6"
*< stride(2) = "28"
4 el binary pic 9(9)occurs 7 times. *<offset = "0"
*< lbound(3) = "1"
*< hbound(3) = "7"
*< stride(3) = "4"
【０１０９】
プログラムは、たとえばｄ１（２）またはｄ２（３、４）など、上位コンテナ・フィールドを添字にすることによって配列のスライスを参照することができるが、普通の種類の参照は、たとえばｅｌ（４、５、６）など、添字のフル・シーケンスを使用して、下位レベルに対して行われる。このストライド数式を使用して要素ｅｌ（ｍ、ｎ、ｏ）を突き止めるためには、ａのアドレスをとり、それを(m-1)×168+(n-1)×28+(o-1)×4に加算する。COBOLの場合に、配列添字の下限は、必ず１である。すなわち最初の要素は必ずElement（１）であり、逆も同様である。
【０１１０】
言うまでもなく、配列のすべての次元が、OCCURS DEPENDING ON文節を有することができ、配列に他のフィールドを続けることができ、これによって数式が非常に複雑になる。次の例を検討されたい。
1 a.
2 x1 binary pic 9. *< offset ="0"
2 x2 binary pic 9. *< offset ="2"
2 x3 binary pic 9. *< offset ="4"
2 d1 occurs 1 to 5times *< offset ="6"
depending onx1. *<lbound(1) = "1"
*< hbound(1) = "val(1,1)"
*< stride(1) = "mpy(val(1,2),mpy(val(1,3),4))"
3 d2 occurs 1 to 6times *< offset ="6"
depending onx2. *<lbound(2) = "1"
*< hbound(2) = "val(1,2)"
*< stride(2) = "mpy(val(1,3),4)"
4 el binary pic 9(9) *< offset = "6"
occurs 1 to7 times *< lbound(3) ="1"
depending onx3. *<hbound(3) = "val(1,3)"
*< stride(3) = "4"
2 b binary pic9(5). *< offset ="see below!"
1
【０１１１】
特定の要素のアドレスの計算に、まだストライド数式が含まれるが、もはや単純な整数はない。上の例の要素ｅｌ（ｍ、ｎ、ｏ）のアドレスは、ａのアドレスをとり、次式に加算することによって与えられる。
(m-1)*stride(1) +(n-1)*stride(2) + (o-1)*stride(3), すなわち、
(m-1)*4*val(1,3)*val(1,2) + (n-1)*4*val(1,3) + (o-1)*4.
【０１１２】
同様に、これらのストライド数式は、ｂのオフセットに関する下記の数式に使用される。
"add(6,mpy(val(1,1),mpy(val(1,2),mpy(4,val(1,3)))))"
【０１１３】
４．ｄ．ｉ）．ｂ）．ＰＬ／Ｉ
１．下記の構造体を与える
dcl/* オフセット */
1 c unaligned /*"0"*/
,2 c1/* "0" */
,3 c2 fixedbin(31) /* "0"*/
,3 c3fixed bin(31) /*"4" */
,2 c4/* "8" */
,3 c5fixed bin(31) /*"0" */
,3 c6fixed bin(31) /*"4" */
,3 c7 fixedbin(31) /* "8" */
,2 c8 fixedbin(31) /*"20" */
,2 c9char(*refer(c7)) /*"24"*/
,2 c10char(6) /*"add(24,val(1,2,3))" */
,2 c11char(4) /* "add(add(24,val(1,2,3)),6)" */
;
ｃ３のオフセットは、単純な数式”４”によって与えられるが、ｃ１０のオフセットは、下の数式によって与えられる。
"add(24,val(1,2,3))"
【０１１４】
上のｖａｌ関数の第１引数は１であり、これは、現在の構造体ｃを示す。後続の引数は２と３であり、第２のレベル−２フィールドｃ４の第３引数ｃ７が、参照解除されるフィールドであることを示す。
【０１１５】
ｃ１１のオフセットは、ｃ１０のオフセットにｃ１０の長さを加えたものに等しく、次の数式によって与えられる。
"add(add(24,val(1,2,3)), 6)"
【０１１６】
ＰＬ／Ｉ構造体マッピングは、トップダウンではなく、これは、次の構造体のマッピングを調べることによって示すことができる。
dcl/* オフセット */
1 a based,/* "0"*/
2 b, /*"0"*/
3 b1fixed bin(15),/* "0"*/
3 b2fixed bin(15),/* "2"*/
3 b3fixed bin(31),/* "4"*/
2 c,/* "add(8,mod(neg(val(1,1,1)),4))" */
3 c1char(n refer(b1)), /*"0"*/
3 c2fixed bin(31);/* "val(1,1,1)"*/
【０１１７】
ｂ１の値は、ｖａｌ（１、１、１）によって与えられ、ｃ２を４バイト境界に置くために、ＰＬ／Ｉでは、ｃの前（ｃ１とｃ２の間ではなく）に、必要な埋込みのすべてを置き、したがって、ｃのオフセットが、次の数式によって与えられる。
"add(8,mod(neg(val(1,1,1)),4))"
【０１１８】
したがって、ｂ１に値３が含まれる場合に、この数式は、add(8、mod(neg(3)、4))になり、これは９と評価される。すなわち、構造体ｂと構造体ｃの間に１バイトの埋込みがある。
【０１１９】
このモデルでは、配列の境界およびストライドの指定にもこれらの数式が使用され、ここで、ストライドは、配列内の２つの連続する要素の間の距離として定義される。
【０１２０】
たとえば、下の構造体では、ａ．ｅの第２次元が、数式”４”によって指定されるストライドを有し、第１次元が、数式”２０”によって指定されるストライドを有する。
dcl
1 a,/* offset = "0" */
2 b(4) fixedbin(31), /* offset = "0" */
/* lbound(1) = "1" */
/* hbound(1) = "4" */
/* stride(1) = "4" */
2 c(4) fixedbin(31), /* offset = "16" */
/* lbound(1) = "1" */
/* hbound(1) = "4" */
/* stride(1) = "4" */
2 d(4)char(7) varying, /* offset ="32" */
/* lbound(1) = "1" */
/* hbound(1) = "4" */
/* stride(1) = "9" */
2 e(4,5)fixed bin(31); /* offset ="68" */
/*lbound(1) = "1" */
/* hbound(1) = "4" */
/* stride(1) = "20" */
/* lbound(2) = "1" */
/* hbound(2) = "5" */
/* stride(1) = "4" */
【０１２１】
これは、要素ａ．ｅ（ｍ、ｎ）を突き止めるために、ａ．ｅのアドレスをとり、
(m-1)*20 + (n-1)*4
に加算することを意味する。
【０１２２】
上の例がわずかに変更されて、
dcl
1 a(4),/* offset = "0"*/
/* lbound(1) = "1"*/
/* hbound(1) = "4"*/
/* stride(1) = "40" */
2 b fixedbin(31), /* offset ="0" */
2 c fixedbin(31), /* offset = "4" */
2 d char(7)varying, /* offset ="8" */
2 e(5) fixedbin(31); /* offset = "20" */
/* lbound(1) = "1"*/
/* hbound(1) = "5"*/
/*stride(1) = "4" */
になる場合に、ｄとｅの間に埋込みがあるが、型記述子のユーザは、全く気付かず、単にストライドとオフセットの数式を使用して、所与の配列要素を突き止めることができる。ａのストライドは”４０”であり、ｅのストライドは”４”であり、ｅのオフセットは”２０”である。これは、要素ａ（ｍ）．ｅ（ｎ）を突き止めるために、ａのアドレスをとり、(m-1)×40+20+(n-1)×4に加算することを意味する。
【０１２３】
最後に、上の例がまた変更されて、
dcl
1 a(4), /*offset = "0"*/
/* lbound(1)= "1" */
/* hbound(1) = "4"*/
/* stride(1) = "40" */
2 b fixedbin(31), /* offset ="0" */
2 c(8)bit(4), /* offset ="4" */
/* lbound(1) = "1"*/
/* hbound(1) = "8"*/
/* stride(1) = "4"*/
2 d char(7)varying, /* offset = "8" */
2 e(5) fixed bin(31); /* offset ="20" */
/* lbound(1) = "1"*/
/* hbound(1) = "5"*/
/* stride(1) = "4"*/
になる場合に、ａ．ｅの計算は、上と同一であるが、ａ．ｃの計算が、興味深いものになる。
【０１２４】
ａのストライドは、まだ”４０”であり、ｃのストライドは、”４”であり（この”４”は、ビットのカウントであってバイトではない）、ｃのオフセットは”４”である。要素ａ（ｍ）．ｃ（ｎ）を突き止めるためには、バイト・アドレスとビット・オフセットの両方が必要である。バイト・アドレスについては、ａのアドレスをとり、(m-1)×40+4+((n-1)×4)/8に加算する。ａ（ｍ）．ｃ（ｎ）のビット・アドレスは、mod((n-1)×4、8)によって与えられる。
【０１２５】
４．ｅ．TypeDescriptorの仕様
４．ｅ．ｉ．TDLangメタモデル仕様
TDLangクラス − 全般的な概要。TDLangクラスは、すべてのＣＡＭ言語モデルとTypeDescriptorモデルの間の抽象の１レイヤとして働く。
【０１２６】
どのＣＡＭ言語モデルでも、TDLangモデルにプラグ・インすることができるので、TypeDescriptorモデルは、ＣＡＭ言語モデルにアクセスするために、TDLangとインターフェースする方法を理解するだけでよい。
【０１２７】
TDLangモデルは、独力では全く機能を提供せず、したがって、言語モデルに接続される時に限って意味を持つ。TDLangは、すべてのＣＡＭ言語モデルに共通し、TypeDescriptorモデルから言語モデルへの関連の型ターゲットである。
【０１２８】
すべてのTDLangクラスが、抽象クラスであり、言語メタモデルの基本クラスとして働くことに留意されたい。
【０１２９】
TDLangClassifier。TDLangClassifierは、すべての言語固有ClassifierクラスおよびTDLangComposedTypeの親クラスである。TDLangSharedType関連は、ElementクラスからClassiferクラスへの言語の”＋SharedType”関連から派生する。関連は、その関連が言語モデルから派生したことを反映するために、”volatile”、”transient”、または”derived”としてマークされなければならない。TDLangClassifierは、TDLangModelElementから派生する。
【０１３０】
TDLangElement。TDLangElementは、すべての言語固有Elementクラスの親クラスである。tdLangTypedElement関連は、ClassifierクラスからElementクラスへの言語の”＋TypedElement”関連から派生する。関連は、その関連が言語モデルから派生したことを反映するために、”volatile”、”transient”、または”derived”としてマークされなければならない。
【０１３１】
tdLangElement関連は、ClassifierクラスからElementクラスへの言語の”＋Element”関連から派生する。関連は、その関連が言語モデルから派生したことを反映するために、”volatile”、”transient”、または”derived”としてマークされなければならない。
【０１３２】
TDLangComposedType。TDLangComposedTypeは、すべての言語固有ComposedTypesの親クラスである。TDLangGroup関連は、ElementクラスからComposedTypeクラスへの言語の”＋group”関連から派生する。関連は、その関連が言語モデルから派生したことを反映するために、”volatile”、”transient”、または”derived”としてマークされなければならない。TDLangComposedTypeは、TDLangClassifierから派生する。
【０１３３】
４．ｅ．ｉｉ．TypeDescriptorメタモデル仕様
TypeDescriptorパッケージでは、データ項目型の物理的実装を記述するモデルが定義される。このモデルは、言語中立であり、多数の言語の型を記述するのに使用することができる。異なる言語の型モデルの検査によって、言語型の一致可能性を判定することができる。たとえば、Java(R)のlong型は、しばしば、COBOLのbinary型と同一であり、その場合には、これらの型を、副作用なしで相互変換することができる。その一方で、COBOLのalphanumeric型は、サイズが固定されるが、Java(R)の型にマッピングされる場合に、この特性が失われる。Java(R)からCOBOLに再変換される時に、COBOLの切詰規則が適用されず、計算の例外がもたらされる可能性がある。
【０１３４】
AggregateInstanceTD。集約のインスタンスごとに、このクラスのインスタンスがある。この集約の子を探すためにには、関連を言語Classifierまで逆にナビゲートし、言語ComposedTypeにダウンキャストし、その子への関連に従わなければならない。
InstanceTDBaseから派生
パブリック属性：
union : boolean = false
集約が包含的（たとえば構造体）または排他的（たとえば共用体）のどちらであるかを区別する。
union = trueの場合には、ストレージがオーバーレイされ、その結果として内容の解釈が不確実になる可能性がある。
【０１３５】
ArrayTD。ArrayTDは、配列型の情報を保持する。
パブリック属性：
arraryAlign : int
配列内の各要素のアドレス可能単位での位置合わせ要件。
strideFormula : string
インデックスを与えられて、配列内の要素の変位アドレスを計算するのに使用することができる数式。
strideInBit : boolean
真は、strideFormula値がビット単位であることを示す。
偽は、strideFormula値がバイト単位であることを示す。
upperBoundFormula : String
この値が変数によって参照される時に、インスタンスのStringとして宣言される。この属性は、可変サイズ配列の上限値を供給する。
上限は、構造体全体を逆にトラバースする時に必要になる。
lowerBoundFormula : String
この値が変数によって参照される時に、インスタンスのStringとして宣言される。この属性は、可変サイズ配列の下限値を供給する。
【０１３６】
InstanceTDBase。InstanceTDBaseは、宣言された変数および構造体要素ごとにインスタンスを有する。
インスタンスの親（インスタンスが親を有する場合に）を見つけるためには、関連をTDLangElementまで逆にナビゲートし、TDLangClassifierへの関連に従って親を突き止め、その後、TypeDescriptorモデルへ逆に関連に従わなければならない。
パブリック属性：
offsetFormula : string
このインスタンスの先頭へのオフセットを計算する数式。
この属性は、このフィールドが必ず整数値であるとは限らないので、Stringである。たとえば、(value(n)+4)が、可能な値になる可能性がある。
注：オフセット値は、最上位の親から計算される（たとえば、２進木Ａ→Ｂ、Ａ→Ｃ、Ｂ→Ｄ、Ｂ→Ｅについて、Ｄへのオフセットは、ＢからＤではなく、ＡからＤへ計算される）。
contentSizeFormula : string
内容の現在のサイズを計算する数式。
allocSizeFormula : string
インスタンスの割り振られたサイズを計算する数式。
formulaInBit : boolean
真は、offsetFormula、contentSizeFormula、およびallocSizeFormulaの値がビット単位であることを示す。
偽は、offsetFormula、contentSizeFormula、およびallocSizeFormulaの値がバイト単位であることを示す。
defaultEncoding : String
物理的エンコーディング − コード・ポイントのエンコードに何ビットが使用され、コード・ポイントがビット・パターンにどのようにマッピングされるか
ストリング内容がどのようにエンコードされるかに関する情報：ＥＢＣＤＩＣ、ＡＳＣＩＩ、ＵＮＩＣＯＤＥ、ＵＴＦ−８、ＵＴＦ−１６、コードページ番号などが格納される。
accessor : enumeration
この要素のアクセス権を指定する。
defaultBigEndian : boolean
この要素がビッグ・エンディアン・フォーマットである場合に真。
floatType : enumeration
この要素の浮動型を指定する。
【０１３７】
PlatformCompilerType。特定のプラットフォームおよびコンパイラに関する特定のデータ型。
注：プラットフォームおよびコンパイラを識別する何らかの方法が必要である。
このクラスは、特殊化されるか属性を有することができ、あるいは、属性をInstanceTDBaseに置くことによって単純化することができる。
パブリック属性：
platformCompilerType : String
この属性は、言語モデル内のデータを作成するのに使用されたコンパイラの型を指定する。このストリングの使用法は、次の通りである。
”ベンダ名、言語、ＯＳ、ハードウェア・プラットフォーム”（たとえば、"IBM,COBOL, OS390, 390"または"IBM, PLI, WinNT, Intel"）。
【０１３８】
SimpleInstanceTD。言語モデルのSimple型のインスタンス。
InstanceTDBaseから派生する。
【０１３９】
NumberTD
すべての数の表現。
現在は、IntegerとPacked Decimalが含まれる。
Numberのこれらの型に必要なフィールドに留意されたい：
*Integer*
Base=2
MSBU=０または １
Signed/Unsigned
サイズ（バイト単位）＝１、２、４、８（１６）
*Packed Decimal*
Base=10
MSBU=0
Signed
幅=1-63
*Float*
Base=2(IEEE)、16(Hex)
MSBU＝０または１
Signed
サイズ（バイト単位）＝４、８、１６
エンコーディングの詳細
BaseTDから派生する
パブリック属性：
base : int
この数の基数表現。２＝２進、１０＝１０進、１６＝１６進、など
baseWidth : int
基数を表すのに使用されるビット数
たとえば、２進数＝１、１０進数＝８、パック＝４
baseInAddr : int
アドレス可能記憶単位内のbaseWidth単位の数。たとえば、アドレス可能単位がバイトの場合に、１０進＝１、パック＝２、２進＝８。アドレス可能単位が３２ビット・ワードである場合には、１０進が４、パックが８、２進が３２になる。
baseUnits : int
数のbase単位の数。これとbasewidthの積は、widthとaddrUnitの積以下でなければならない。
たとえば、右に位置合わせされる３２ビット・ワードの２４ビット・アドレスは、base＝１、basewidth＝２４、baseInAddr＝８、width＝４を有する。
signCoding : enumeration
列挙の組すなわち、２進数の場合に２の補数、１の補数、および符号絶対値、１０進数の場合に０符号、パック１０進数、符号なし２進数、および符合なし１０進数の場合にパック符号。
checkValidity : boolean
ピクチャ・ストリング・サポートのために言語モデルが必要な場合に真。
packedDecimalSign : enumeration
COBOL１０進数の符号のコード・ポイントを決定するのに使用される。符号は、先頭の数字または末尾の数字と組み合わされる。
【０１４０】
FloatTD
浮動小数点
BaseTDから派生する
パブリック属性：
floatType : enumeration
この要素の浮動型を指定する。
【０１４１】
StringTD
英数字型
BaseTDから派生する
パブリック属性：
encoding : String
物理的エンコーディング − コード・ポイントのエンコードに何ビットが使用され、コード・ポイントがビット・パターンにどのようにマッピングされるか ストリング内容がどのようにエンコードされるかに関する情報：ＥＢＣＤＩＣ、ＡＳＣＩＩ、ＵＮＩＣＯＤＥ、ＵＴＦ−８、ＵＴＦ−１６、コードページ番号などが格納される。
lengthEncoding : enumeration
lengthEncodingの可能な値：
−固定長（全長が宣言されたストリング長と等しい）
−長さプレフィックス付き（全長が、ストリングの長さとヘッダ・バイトの長さの和に等しい。ヘッダ・バイトは、通常は１バイト、２バイト、または４バイトである）。
−ヌル終端（ＰＬ／ＩではvaryingZストリングと称する）（ヌル記号がストリングの末尾に追加される。したがって、最大長さは、宣言されたストリング長と、ヌル記号を表す１バイトの合計までになる）
maxLengthFormula : String
このストリングの最大長さを指定する数式。
checkValidity : boolean
ピクチャ・ストリング・サポートのために言語モデルが必要な場合に真。
textType : String = Implicit
値は、’Implicit’または’Visual’である
orientation : StringTD = LTR
値は、’ＬＴＲ’、’ＲＴＬ’、’Contextual LTR’、または’ContextualRTL’であり、ここで、LTR=Left to Right（左から右へ）であり、RTL=Right to Left（右から左へ）である。
Symmetric : boolean = true
対称スワッピングが許可される場合に真
numeralShapes : String = Nominal
値は、’Nominal’、’National’、または’Contextual’
textShape : String = Nominal
値は、’Nominal’、’Shaped’、’Initial’、’Middle’、’Final’、または’Isolated’である
【０１４２】
AddressTD
ポインタ／アドレスを表す型
このクラスの理論的根拠：
アドレスは、NumberTDクラスとは別に考慮されなければならない。というのは、ある計算機（たとえばIBM４００）上のいくつかの言語が、アクセス権タイプ（NumberTDクラスでは表現されない）などの追加情報を伴うアドレスを表すからである。
BaseTDから派生する
パブリック属性：
permission : String
このアドレスのアクセス権を表す。主にＡＳ／４００システムで使用される。
bitModePad : enumeration
このアドレスのビット数を指定する。埋込みの計算に使用される。
【０１４３】
BaseTD
TypeDescriptorの基本クラス。
BaseTDモデル型は、同一の言語型のすべてのデータ要素に共通する実装情報を保持するように特殊化される。したがって、特定のハードウェア／ソフトウェア・プラットフォームの３２ビット符号付き２進整数を記述する情報は、この型を用いていくつのデータ要素が宣言されるかに無関係に、所与のモデル・インスタンス化で１回だけインスタンス化される。
パブリック属性：
addrUnit : enumeration
ストレージ・アドレス可能単位(bit/byte/word/dword)でのビット数
width : int
記述される型でのアドレス可能ストレージ単位の数。１ビット、８ビット、１６ビット、３２ビットにすることができる。
alignment : int
アドレス空間で型に必要な位置合わせ − たとえば、ワード位置合わせされる３２ビット整数は、４のalignmentを有する。
nickname : int
基本要素の名前。これは、属性の組合せに基づく論理ではなく名前に基づく論理を可能にするために、単純型のインスタンスを一意に識別しなければならない。たとえば、３２ビットＳ／２９０非拡大縮小２進整数は”S390Binary31_0”である。
bigEndian : boolean
この要素がビッグ・エンディアン・フォーマットである場合に真。
【０１４４】
ステレオタイプ
ｂｉｔModeＰａｄ
パブリック属性：
16bit :
24bit :
31bit :
32bit :
64bit :
128bit :
signCoding
このモデルに、下記のCOBOL使用が含まれないことに留意されたい：
1 POINTER
PROCEDURE-POINTER
OBJECT REFERENCE
パブリック属性：
twosComplement :
onesComplement :
signMagnitude :
zoneSigns :
packedSigns :
unsignedBinary :
unsignedDecimal :
lengthEncoding
パブリック属性：
fixedLength :
lengthPrefixed :
nullTerminated :
floatType
パブリック属性：
Unspecified :
IEEEextendedIntel :
Intelプラットフォームで稼動するＩＥＥＥ拡張浮動小数点
IEEEextendedAIX :
ＡＩＸプラットフォームで稼動するＩＥＥＥ拡張浮動小数点
IEEEextendedOS390 :
ＯＳ／３９０プラットフォームで稼動するＩＥＥＥ拡張浮動小数点
IEEEextendedAS400 :
ＡＳ４００プラットフォームで稼動するＩＥＥＥ拡張浮動小数点
IEEEnonextended :
ＩＥＥＥ非拡張浮動小数点
IBM390Hex :
IBM ＯＳ／３９０で稼動する１６進浮動小数点
IBM400Hex :
IBM ＡＳ４００で稼動する１６進浮動小数点
accessor
パブリック属性：
ReadOnly :
WriteOnly :
ReadWrite :
NoAccess :
packedDecimalSign
パブリック属性：
MVS :
MVSCustom :
NT/OS2/AIX :
【０１４５】
５．言語メタモデル
５．ａ．COBOLメタモデル
COBOLメタモデルは、コネクタ・インターフェースを表すデータ構造体（セマンティクス）を定義するために、エンタープライズ・アプリケーション・プログラムによって使用される。
【０１４６】
図１５、および図１６に、コネクタ・インターフェースを表すデータ構造体セマンティクスを定義するためのCOBOLメタモデルを示す。このメタモデルは、Ｍ２レベルのＭＯＦクラス・インスタンスでもある。図１７に、TDLangClassifier、TDLanguageComposedType、およびTDLangElementである、COBOLメタモデルとTDLang基本クラスの間の関連を示す。図１８に、COBOLメタモデルのCOBOL使用値の列挙を示す。
【０１４７】
このCOBOLモデルの目標は、Data Divisionで見つかるはずの情報を取り込むことである。このモデルは、COBOLのdatadivisionをそのＸＭＬ同等物に変換するために、読取専用としてのみ使用されることを予定されている。このモデルは、ＸＭＬコードからCOBOLのdatadivisionの同等物へのコンバータとして使用されることを予定されていない。その結果、要素のinitialValueは、このモデルには取り込まれない。
【０１４８】
COBOLSimpleType
COBOLSimpleTypeは、COBOL言語のすべての単純型によって共用される属性を含む抽象クラスである。
COBOLClassifierから派生する
パブリック属性：
usage : COBOLUsageValues
usageには、COBOLUsageValuesで定義されるデータ型が含まれる。
usageでは、メモリ内のデータのフォーマットが定義される。COBOLソースで何も指定されていない場合には、デフォルトは”display”である。よく使われるＣＯＭＰ−３が、パック１０進数の同等物であることに留意されたい。
pictureString : String
これは、ソースで指定されるピクチャ・ストリングの正規形式である。これは、必ずしもプログラムで与えられるピクチャ・ストリングと同一「ではない」！
ピクチャ・ストリングの正規形式に達する手順は次の通りである：
１．括弧で囲まれた文字のすべてを展開する
２．４文字より長い同一の文字のすべてのシーケンスについて、括弧で囲まれた表現を構成する。
たとえば：
ＸＸＸ９９９（３）から開始する
ステップ１の後に、ＸＸＸ９９９９９が得られる
ステップ２の後に、ＸＸＸ９（５）が得られる
この正規形式は、最短の同等なピクチャ・ストリングをもたらす。正規形式は、同等性検査に有益である。
Synchronized : Boolean = false
このブール属性は、要素について任意選択として指定することができるSYNCHRONIZED文節またはＳＹＮＣ文節に対応する。
COBOL言語で、SYNCHRONIZED文節に続けることができる追加の文節RIGHT/LEFTが定義されていることに留意されたい。しかし、COBOLのIBMの実装では、この追加の文節が、文書化のみとしてサポートされ、SYNCHRONIZEDとして定義されたすべての要素が、自動的に左に同期化される。
パブリック動作：
getCanonicalPictureString (pictureString :String) : String
このストリングの圧縮された値を返す。たとえば、pictureString属性に、９９９９ｖ９９のピクチャ・ストリングを含めることができるが、getCanonicalPictureString()は、値として９（４）ｖ９（２）を返す。
【０１４９】
COBOLElement
COBOLElementは、COBOLプログラム内のすべてのデータ定義を表す。
たとえば：
01 EMPLOYEE
03 SERIAL-NUMBER PIC 9(5).
03 DEPARTMENT PIC (5).
EMPLOYEE、SERIAL-NUMBER、およびDEPARTMENTのすべてが、COBOLElementsである。
TDLangElementから派生する
パブリック属性：
level : String
levelは、この要素が宣言されたデータ番号を指す。
redefined : Boolean = false
【０１５０】
COBOLVariableLengthArray
COBOLVariableLengthArrayは、COBOLElementのソースが下記の構文を有する時に、必ずインスタンス化されなければならない。
LEVEL ELEMENTNAME1 OCCURS X1 TO X2 TIMESDEPENDING ON ELEMENTNAME2.
ここで、Ｘ１およびＸ２は、０以上のすべての整数とすることができ、Ｘ２＞Ｘ１である。ELEMENTNAME2は、ELEMENTNAME1の前に定義されていなければならない。
COBOLVariableLengthArrayは、この配列がどの要素に依存するかを指定する、単一の必要な関連を有する。
COBOLFixedLengthArrayから派生する
パブリック属性：
minUpper : Integer
maxUpper（最大上限）がVariableArrayに属する場合に、maxUpperは、メモリ内で割り振ることができる配列の絶対上限を示す。実際の最大値は、それが参照する要素の値によって示され、これは、”dependingOn”関連を呼び出すことによって入手される。
minUpper（最小上限）は、OCCURS 4 to 7 TIMESDEPENDING ON X1の形のCOBOL構文を取り込むのに使用される。この場合に、minUpperは４に等しく、maxUpperは７に等しく、実際の上限は、Ｘ１の値に依存する。
lower（下限）は、COBOLの場合には必ず１であるが、他の言語との一貫性および明瞭さのために含まれる。
【０１５１】
COBOLRedefiningElement
REDEFINES文節を用いると、同一のコンピュータ・ストレージ域を記述する異なるデータ記述項目を使用できるようになる。
この文節の使用の例は次の通りである：
1 TEST
2 Y PIC X(4)
2 YRREDEFINES Y BINARY PIC 9(5)
Typedef＝再定義／共用体の場合に偽
COBOLElementから派生する
【０１５２】
COBOLComposedType
COBOLComposedTypeクラスは、追加要素を含む入れ子になった宣言を表す。COBOLComposedTypeは、COBOLElementsの集約である。
COBOLComposedTypeは、COBOLRedefineの親クラスでもある。
たとえば：
01 STUDENT.
05 CLASSES OCCURS 5.
10 CLASSNAME PIC X(20).
10 CLASSNUM PIC 9(4).
STUDENTは、COBOLComposedElementによって定義される。その集約は、COBOLElementであるCLASSES項目だけを指す。CLASSES自体は、COBOLComposedElementによって定義される。
COBOLClassifier、TDLangComposedTypeから派生する
【０１５３】
COBOL８８Element
COBOL８８Elementは、COBOL ８８データ・レベルを表す。
たとえば：
1 TESTX PIC.
88 TRUEXVALUE 'T' 't'. *(TRUEXは２つの値を有する)
88 FALSEXVALUE 'F' 'f'. *(FALSEXは２つの値を有する)
ここで、TRUEXおよびFALSEXは、それぞれ、値が（’Ｔ’または’ｔ’）または（’Ｆ’または’ｆ’）と等しい場合のTESTX変数の条件名である。
したがって、TESTX＝’Ｔ’または’ｔ’の場合には、TRUEX＝TRUEかつFALSEX＝FALSEであり、
TESTX＝’Ｆ’または’ｆ’の場合には、FALSEX＝TRUEかつTRUEX＝FALSEである
パブリック属性：
name : String
COBOL８８Elementの名前またはハンドルを指定する。
【０１５４】
COBOL８８ElementValue
このクラスの使用の例は次の通りである：
1 TESTX PIC X.
88 TRUEXVALUE 'T' 't'. *(TRUEXは２つの値を有する)
88 FALSEXVALUE 'F' 'f'. *(FALSEXは２つの値を有する)
88 UA VALUE'A' THRU 'I' 'J' THRU 'R' 'S' THRU 'Z' '&' '-'.
*UAは５つの値を有し、最初の３つは範囲である
このクラスの理論的根拠：
・このクラスが存在するのは、各COBOL８８Elementに複数の値を含めることができるからである。たとえば、TRUEXには、２つの値、’Ｔ’および’ｔ’が含まれる。したがって、このクラスは、COBOL８８Element（したがって、１…＊基数）ごとに複数（だが少なくとも１回）インスタンス化することができる。
・ＵＡの’Ａ’ THRU ’Ｉ’などの範囲値について、lowerLimit＝’Ａ’、upperLimit＝’Ｉ’であり、range＝trueである。また、THRUキーワードを使用する時に、lowerLimitがupperLimit未満でなければならないことに留意されたい。
・’Ｔ’および’ｔ’などの非範囲値について、lowerLimitフィールドを使用して値を表すと決定した。
パブリック属性：
lowerLimit : String
lowerLimitは、THROUGH範囲の下限を指す
upperLimit : String
upperLimitは、THROUGH範囲の上限を指す
range : Boolean
rangeに真がセットされる場合には、関連付けられたデータ項目がウィンドウ化日付フィールドでない限り、リテラル−１がリテラル−２未満でなければならない。
【０１５５】
COBOLAlphanumericType
PICTURE文字列は、下記のいずれかからなることが必要である：
・記号
・記号Ａ、Ｘ、および９の組合せ（すべてＡまたはすべて９を含む文字列は、英数字項目を定義しない。）
他の文節：USAGE DISPLAYが指定されるか、暗黙指定されなければならない。
すべての関連するVALUE文節で、非数字リテラルまたは表意定数を指定しなければならない。
COBOLSimpleTypeから派生する
パブリック属性：
JustifyRight : Boolean = false
このブール値は、JUSTIFIED（またはJUST）文節に対応する。JUSTとJUST RIGHTが同一の意味を持つことに留意されたい。
【０１５６】
COBOLNumericEditedType
PICTURE文字列には、下記の記号を含めることができる：
B P V Z 9 0 / , . + - CR DB * cs
他の文節：USAGE DISPLAYが指定されるか、暗黙指定されなければならない。
すべての関連するVALUE文節で、非数字リテラルまたは表意定数を指定しなければならない。リテラルは、正確に指定されたままで扱われ、編集は行われない。
編集される型（Edited Types）は、数字が、編集される型の場合にメモリに保管され、編集されない型では保管されないという点で、編集されない型と異なる。
COBOLSimpleTypeから派生する
パブリック属性：
BlankWhenZero : Boolean
このブール値は、BLANK WHEN ZERO文節に対応する。
BLANK WHEN ZEROの場合に真。
currencySign : String
このストリングは、たとえば＄、£、ＤＭなど、世界で使用される異なる通貨記号を表す。
Decimal : Boolean
Decimalブール値は、ピクチャ・ストリングおよび数値のピリオドおよびコンマの機能を入れ替える。
真の場合には、１０進数が使用される（たとえば1,234.56）
偽の場合には、コンマが使用される（たとえば、1.234,56）
【０１５７】
COBOLNumericType
数値項目の型は、次の通りである：
・２進数
・パック１０進数（内部１０進数）
・ゾーン１０進数（外部１０進数）
PICTURE文字列には、記号９、Ｐ、Ｓ、およびＶだけを含めることができる。数値データ・フィールドの場合に、PICTURE文字列に、記号９およびＳだけを含めることができる。
有効な範囲の例
PICTURE 有効な値の範囲
9999 0から9999まで
S99 -99から+99まで
S999V9 -999.9から+999.9まで
PPP999 ０から．000999まで
S999PPP -1000から-999000までおよび+1000から+999000までまたは0
他の文節：項目のUSAGEは、DISPLAY、BINARY、COMPUTATIONAL、PACKED-DECIMAL、COMPUTATIONAL-3、COMPUTATIONAL-4、またはCOMPUTATIONAL-5とすることができる。
このクラスの可能な使用値は、’binary’、’packedDecimal’、および’display’であり、これらは、それぞれｃｏｍｐ−１宣言およびｃｏｍｐ−２宣言によって表される。
COBOLSimpleTypeから派生する
パブリック属性：
Signed : Boolean
このブール値は、SIGN文節に対応する。
数が符号付きである場合に真。
SignLeading : Boolean
この属性は、LEADING（TRAILINGに対する）文節に対応する。
LEADINGの場合に真。
SignSeparate : Boolean
このブール値は、SEPARATE文節に対応する。
SEPARATEの場合に真。
currencySymbol : char
この文字は、COBOLでcurrencySignを表すのに使用される記号（たとえば、＄＝＄、Ｌ＝£、Ｄ＝ＤＭなど）を表す。
trunc : String
Truncオプションによって、２進データ項目について１０進数ピクチャ制約を順守しなければならないかどうかが決定される。
Truncの値は次の通りである：
ＳＴＤ、ＯＰＴ、およびＢＩＮ
TRUNC（ＳＴＤ）は、COBOL ８５標準規格に準拠するが、TRUNC（ＯＰＴ）およびTRUNC（ＢＩＮ）は、IBM拡張である。
Trunc属性に関するさらなる情報については、「COBOL/VSEProgramming Guide」を参照されたい。
numproc : String
Numproc（ＰＤＦ）は、１０進符号値に関するより厳格な標準規格を負わせる。
Numprocの値は次の通りである：
ＮＯＰＤＦ、ＰＤＦ、およびＭＩＧ。
コンパイラに無効な符号の処理を実行させたい場合には、NUMPROC（ＮＯＰＦＤ）を使用する。このオプションは、NUMPROC（ＰＦＤ）ほど効率的ではない。オブジェクト・コード・サイズが増え、すべての符号付きデータを検証するために実行時オーバーヘッドが増える可能性がある。
NUMPROC（ＮＯＰＦＤ）およびNUMPROC（ＭＩＧ）は、COBOL ８５標準規格に準拠する。
Decimal : Boolean
Decimalブール値は、ピクチャ・ストリングおよび数値のピリオドおよびコンマの機能を入れ替える。
真の場合には、１０進数が使用される（たとえば１，２３４．５６）
偽の場合には、コンマが使用される（たとえば、１．２３４，５６）
【０１５８】
COBOL６６Element
COBOL６６Elementは、COBOL ６６データ・レベルを表す。
たとえば：
01 DATA-GROUP PIC 9.
03 DATA1VALUE 1.
03 DATA2VALUE 2.
03 DATA3VALUE 3.
66 SUB-DATA RENAMESDATA1 THROUGH DATA2.
66 AKA-DATA3 RENAMESDATA3.
この例で、SUB-DATAは、DATA1およびDATA2の内容を参照する。
パブリック属性：
name : String
COBOL６６Elementの名前またはハンドルを指定する。
【０１５９】
COBOLFixedLengthArray
COBOLFixedLengthArrayは、COBOLElementのソースが下記の構文を有する時に、必ずインスタンス化されなければならない：
LEVEL ELEMENTNAME OCCURS X TIMES.
ここで、Ｘは、１以上の任意の整数とすることができる。
maxUpper（最大上限）がFixedArrayに属する場合に、maxUpperは、メモリ内で割り振られる配列の上限を示す。
lower（下限）は、COBOLの場合には必ず１であるが、他の言語との一貫性および明瞭さのために含まれる。
【０１６０】
COBOLＤＢＣＳType
PICTURE文字列に、記号Ｇ、ＧおよびＢ、またはＮを含めることができる。Ｇ、Ｂ、またはＮのそれぞれが、単一のＤＢＣＳ文字位置を表す。ＤＢＣＳリテラルの文字の範囲全体を使用することができる。
他の文節：PICTURE文節記号Ｇが使用される時には、USAGE DISPLAY−１を指定しなければならない。
PICTURE文節記号Ｎが使用される時には、USAGE DISPLAY−１が、仮定され、指定する必要ない。
すべての関連するVALUE文節で、ＤＢＣＳリテラルまたは表意定数SPACE/SPACESを指定しなければならない。
ＤＢＣＳTypeは、１文字ごとに２バイトを占有する。
COBOLSimpleTypeから派生する
【０１６１】
COBOLAlphanumericEditedType
PICTURE文字列に、下記の記号を含めることができる：
A X 9 B 0 /
ストリングには、少なくとも１つのＡまたはＸが含まれ、少なくとも１つのＢまたは０（ゼロ）または／が含まれなければならない。
標準データ・フォーマットの項目の内容は、コンピュータの文字セットからの２つ以上の文字でなければならない。
他の文節：USAGE DISPLAYが指定されるか、暗黙指定されなければならない。
すべての関連するVALUE文節で、非数字リテラルまたは表意定数を指定しなければならない。リテラルは、正確に指定されたままで扱われ、編集は行われない。
編集される型は、数字が、編集される型の場合にメモリに保管され、編集されない型では保管されないという点で、編集されない型と異なる。
COBOLSimpleTypeから派生する
【０１６２】
COBOLClassifier
COBOLClassifierクラスは、COBOLComposedTypeおよびCOBOLSimpleTypeの親クラスであり、’typedef’属性を含む。
COBOLでのTYPEDEFの影響を考える最も良い方法は、単純なＣマクロに似た字句置換である。TYPE文節を、TYPEDEFキーワードに続くすべてのものに置換する。その後、レベル番号を適当に調整した後に、結果が、正しいCOBOLにならなければならない（調整されるレベル番号自体（４９を超えることができる）を除く）。実際のルールは、予想されるであろうように非常に複雑であり、したがって、説明するのではなく、例を示す：
財務データに関するショップ・スタンダードを実施する単純な方法：
定義：
1 uniform-amount typedefusage comp pic s9(6)v99 synchronized.
参照：
1 account-record.
...
5 prior-balancetype uniform-amount.
5 current-balancetype to uniform-amount.
...
TDLangClassifierから派生する
パブリック属性：
Typedef : boolean
ユーザ定義型は、TYPEDEF属性を使用することによって導入され、TYPE文節によって参照される。型がユーザ定義である場合に、’typedef’＝真である。
Typedef＝再定義／共用体の場合にFalse
name : String
COBOLClassifierの名前またはハンドルを指定する。
【０１６３】
COBOLAlphabeticType
PICTURE文字列に、記号Ａだけを含めることができる。
標準データ・フォーマットの項目の内容は、英語アルファベットの文字およびスペース文字のいずれかからなる必要がある。
他の文節：USAGE DISPLAYが指定されるか、暗黙指定されなければならない。
すべての関連するVALUE文節で、アルファベット文字、スペース、または表意定数の値としての記号文字だけを含む非数値リテラルを指定しなければならない。
COBOLSimpleTypeから派生する
パブリック属性：
JustifyRight : Boolean = false
このブール値は、JUSTIFIED（またはJUST）文節に対応する。JUSTとJUST RIGHTが同一の意味を持つことに留意されたい。
【０１６４】
COBOLObjectReferenceType
このオブジェクト参照型は、COBOLでUSAGE IS INDEX OBJECTREFERENCE METACLASS OF class-name-1（class-name-1は任意選択である）として宣言されたオブジェクトをポイントする。
COBOLSimpleTypeから派生する
パブリック属性：
className : String
このインスタンスが参照するオブジェクトの名前を参照する。
【０１６５】
COBOLSourceText
このクラスには、ソース・コード全体（コメントを含む）およびそれに関連する行番号が含まれる。
パブリック属性：
source : String
fileName : String
【０１６６】
COBOLUnicodeType
このユニコード型は、ユニコード・フォーマットで保管されたデータを表す。
COBOLSimpleTypeから派生する
【０１６７】
COBOLInternalFloatType
COBOLInternalFloat型は、浮動小数点がメモリ内で表される形を取り込む。たとえば、値１２３．４５は、内部的に１２３４５と表され、暗黙の小数部が、３と４の間でマークされる。
このクラスの可能な使用値は、’float’および’double’であり、これは、それぞれｃｏｍｐ−１宣言およびｃｏｍｐ−２宣言によって表される。
COBOLSimpleTypeから派生する
【０１６８】
COBOLExternalFloatType
COBOLExternalFloat型は、浮動小数点がユーザに表示される形を取り込む。COBOLExternalFloatTypesは、ＰＩＣが、仮数および指数の前に＋／−符号を有する点を除いて、COBOLNumericEditedTypesと同一である。たとえば、値１２３．４５は、ExternalFloatTypeでは+12345E -2として表される。
このクラスの可能な使用値は、’binary’、’packedDecimal’、および’display’である。
COBOLSimpleTypeから派生する
【０１６９】
COBOLAddressingType
COBOLAddressingTypeは、インデックス値、ポインタ値、およびprocedurePointer値に使用される。
このクラスの可能な使用値は、’index’、’pointer’ 、および’procedurePointer’である。
COBOLSimpleTypeから派生する
【０１７０】
COBOLElementInitialValue
TDLangElementから派生する
パブリック属性：
initVal : String
valueKind : COBOLInitialValueKind =string_value
【０１７１】
総計：
１論理パッケージ
２３クラス
論理パッケージ構造
論理ビュー
cobol
TDLang
【０１７２】
５．ｂ．ＰＬ／Ｉメタモデル
ＰＬ／Ｉ言語メタモデルは、コネクタ・インターフェースを表すデータ構造体（セマンティクス）を定義するために、エンタープライズ・アプリケーション・プログラムによって使用される。このメタモデルは、Ｍ２レベルのＭＯＦクラス・インスタンスである。図１９、図２０、および図２１に、コネクタ・インターフェースを表すデータ構造体を定義するためにアプリケーション・プログラムによって使用可能なＰＬ／Ｉ言語メタモデルを示す。このメタモデルは、Ｍ２レベルのＭＯＦクラス・インスタンスである。図２２に、ＰＬ／ＩメタモデルのTDLangClassifier、TDLanguageComposedType、およびTDLanguageElementを示す。図２３に、ＰＬ／ＩメタモデルのModeValues、BaseValues、LengthTypes、およびStringTypeValuesの列挙を示す。
【０１７３】
５．ｂ．ｉ．ＰＬ／Ｉメタモデル仕様
ＰＬ／Ｉ
ＰＬ／Ｉ言語メタモデルは、コネクタ・インターフェースを表すデータ構造体（セマンティクス）を定義するために、エンタープライズ・アプリケーション・プログラムによって使用される。
このＰＬ／Ｉの言語モデルは、PARAMETER、STATIC、またはBASEDのいずれかのストレージ・クラスを有するＰＬ／Ｉ宣言を記述することを試みる。CONTROLLED、AUTOMATIC、およびDEFINEDはサポートされない。
ＰＬ／Ｉ言語では、エクステント（すなわち、ストリング長、区域サイズ、および配列の限界）が、一般に、定数として、実行時に評価される式として、アスタリスクとして、またはREFERオプションを介して定義されるものとして、宣言されるが、これらの選択肢のどれもが、すべてのストレージ・クラスに対して有効ではない。
エクステントが定数でなく、REFERオプションを介して定義されるのでない基底付き変数は、エクステントがアスタリスクを介して指定されるパラメータと同様に、このモデルから除外される。
INITIAL属性（どの場合にもパラメータについては無効である）は、このモデルでは無視される。
【０１７４】
PLISimpleType
PLISimpleTypeは、ＰＬ／Ｉ言語のすべての単純型によって共用される属性を含む抽象クラスである。
PLIClassifierから派生する
【０１７５】
PLIElement
＊PLIDeclarationは、ＰＬ／Ｉプログラムのすべてのデータ定義を表す。
＊たとえば：
DCL 1 Employee,
2 Name,
3 Last char(29),
3 First char(29),
2 Deparment char(5);
ここで、Eemployee、Name、Last、First、およびDepartmentのすべてがPLIElementsである。
TDLangElementから派生する
パブリック属性：
level : String
【０１７６】
PLIComposedType
PLIComposedTypeは、構造体、共用体、または基本的な変数および配列とすることができる、メンバ要素の集合である。PLIComposedTypeは、この構成の一部であるすべての要素を含む単一の集約を有する。
構造体は、その要素が同一の属性を有する必要がないデータ集約である。配列と同様に、構造体全体に、データの集約全体を参照するのに使用することができる名前が与えられる。しかし、配列と異なって、構造体の各要素も名前を有する。
構造体は、異なるレベルを有する。第１レベルでは、構造体名が、主構造と呼ばれる。より深いレベルでは、構造体の名前を、小構造と呼ぶ。最も深いレベルでは、要素の名前を要素名と呼ぶ。構造体の要素名は、配列を表すことができ、この場合に、その要素は、要素変数ではなく配列変数である。
構造体の編成は、関連する名前に先立つレベル番号の使用を介して、DECLAREステートメントで指定され、レベル番号は、整数でなければならない。主構造名は、レベル番号１を用いて宣言される。
小構造および要素名は、１より大きいレベル番号を用いて宣言される。
主構造名の記述は、下記の１つによって終了する：
レベル番号１を有するもう１つの項目の宣言
レベル番号がないもう１つの項目の宣言
DECLAREステートメントを終了するセミコロン
区切り文字（通常はブランク）によって、レベル番号とそれに関連する名前を区切らなければならない。たとえば、従業員名簿（payroll）の項目を、次のように宣言することができる：
DECLARE 1 PAYROLL,
2 NAME,
3 LAST CHAR(20),
3 FIRST CHAR(15),
2 HOURS,
3 REGULAR FIXED DEC(5,2),
3 OVERTIME FIXED DEC(5,2),
2RATE,
3 REGULAR FIXED DEC(3,2),
3 OVERTIME FIXED DEC(3,2);
字下げは、読みやすくするためのものでしかない。ステートメントは、DECLARE １ PAYROLL、 ２ NAME、 ３ LASTCHAR（２０）、などとして、連続するストリングで記述することができる。
PAYROLLは、小構造NAME、HOURS、およびRATEを含む主構造として宣言される。各小構造に、２つの要素名が含まれる。この構造体全体を、名前PAYROLLによって参照することができ、また、この構造体の部分を、小構造体名によって参照することができる。要素は、要素名を引用することによって参照することができる。
連続するより深いレベルについて選択されるレベル番号は、連続的である必要がない。レベルｎの小構造に、その小構造名とｎ以下のレベル番号を有する次の名前との間にある、ｎを超えるレベル番号を有するすべての名前が含まれる。PAYROLLを、下記のように宣言することができる。
DECLARE 1 PAYROLL,
4 NAME,
5 LAST CHAR(20),
5 FIRST CHAR(15),
2 HOURS,
6 REGULAR FIXED DEC(5,2),
5 OVERTIME FIXED DEC(5,2),
2 RATE,
3REGULAR FIXED DEC(3,2),
3 OVERTIME FIXED DEC(3,2);
この宣言は、前の宣言と正確に同一の構造化をもたらす。
PLIClassifier、TDLangComposedTypeから派生する
パブリック属性：
Union : Boolean
【０１７７】
PLIElementInitialValue
INITIAL属性によって、ストレージが割り振られる時に変数に割り当てられる１つまたは複数の初期値が指定される。要素変数については、１つの初期値だけを指定することができる。配列変数については、複数を指定することができる。構造体変数または共用体変数は、要素変数であれ配列変数であれ、要素名の別々の初期化によってのみ初期化することができる。INITIAL属性は、定数、定義されるデータ、非制御パラメータでないパラメータ、および非LIMITED静的項目変数に与えることができない。
INITIAL属性は、３つの形を有する。
１．第１の形、INITIALでは、初期定数、式、または関数参照が指定され、これらについて、変数にストレージが割り振られる時に、変数に値が割り当てられる。
２．第２の形、INITIAL CALLでは、プロシージャが初期化を実行するために呼び出されることが（CALLオプションを用いて）指定される。変数は、呼び出されるルーチンの実行中の割当によって初期化される（このルーチンは、呼び出し点に値を返す関数としては呼び出されない）。
３．第３の形、INITIAL TOでは、ポインタ（またはポインタの配列）が、INITIALLISTで指定された文字列のアドレスを用いて初期化されることが指定される。このストリングは、TOキーワードによって示される属性も有する。
TDLangElementから派生する
パブリック属性：
initialValue : String
ValueType : PLIInitalValueType
【０１７８】
PLIClassifier
PLI型
TDLangClassifierから派生する
【０１７９】
PLISourceText
このクラスには、ソース・コード全体（コメントを含む）およびそれに関連する行番号が含まれる。
パブリック属性：
source : String
fileName : String
【０１８０】
PLIComputationalType
計算型は、所望の結果を作るために計算に使用される値を表す。算術データおよびストリング・データが、計算データを構成する。
PLISimpleTypeから派生する
【０１８１】
PLIArithmeticType
算術データは有理数である
PLIComputationalTypeから派生する
パブリック属性：
mode : ModeValues
【０１８２】
PLIStringType
ストリングは、連続する文字、ビット、widechar、およびgraphicの、単一のデータ項目として扱われるシーケンスである。
PLIComputationalTypeから派生する
【０１８３】
PLIIntegerType
Fixed Binとして宣言される。精度とスケール・ファクタを有する。精度は、総桁数であり、スケールは、２進小数点の右側の桁数である。
例
DCL bindata BINARY FIXED (7,3)
は、７データ・ビットであり、そのうちの３ビットが２進小数点の右にある数、1011.111Bを表すのに使用することができる。
PLIArithmeticTypeから派生する
パブリック属性：
precision : Integer
scale : Integer
Signed : Boolean
BigEndian : Boolean = true
【０１８４】
PLIFloatType
は、＝Ａを有する。１０進浮動小数点定数は、仮数とそれに続く指数である。仮数は、１０進固定小数点定数である。指数は、文字Ｅと、それに続く任意選択として符号付きの整数であり、これは１０のべきを指定する。１０進浮動小数点定数は、精度（ｐ）を有し、このｐは、仮数の桁数である。
例は次の通りである：
15E-23 は精度＝２を有する
15E23 は精度＝２を有する
4E-3 は精度＝１を有する
1.96E+07 は精度＝３を有する
438E0 は精度＝３を有する
3141593E-6 は精度＝７を有する
.003141593E3 は精度＝９を有する
最後の２つの例は、同一の値を表す（精度は異なる）。
１０進浮動小数点変数の宣言に関するデータ属性は、DECIMALおよびFLOATである。たとえば：
DECLARELIGHT_YEARS DECIMAL FLOAT(5);
LIGHT_YEARSは、少なくとも５つの１０進数字を有する１０進浮動小数点データ項目を表す。
２進浮動小数点定数は、仮数とそれに続く指数および文字Ｂである。仮数は、２進数固定小数点定数である。指数は、文字Ｅと、それに続く任意選択として符号付きの１０進整数であり、これは２のべきを指定する。２進浮動小数点定数は、精度（ｐ）を有し、このｐは、仮数の２進数字の数である。例は次の通りである：
101101E5B は精度＝６を有する
101.101E2B は精度＝６を有する
11101E-28B は精度＝５を有する
11.01E+42B は精度＝４を有する
２進浮動小数点変数の宣言に関するデータ属性は、BINARYおよびFLOATである。たとえば：
DECLARE S BINARY FLOAT (16);
Ｓは、１６個の２進数の精度を有する２進浮動小数点データ項目を表す。
デフォルトの精度は（２１）である。指数は、１０進数３個を超えることができない。２進浮動小数点データは、正規化された１６進浮動小数点として保管される。宣言された精度が（２１）以下である場合には、short浮動小数点形が使用される。宣言された精度が（２１）を超え、（５３）以下である場合には、long浮動小数点形が使用される。宣言された精度が（５３）を超える場合には、extended浮動小数点形が使用される。
PLIArithmeticTypeから派生する
パブリック属性：
base : BaseValues
precision : Integer
IEEE : Boolean = false
BigEndian : Boolean = true
【０１８５】
PLIPackedType
１０進固定小数点変数の宣言に関するデータ属性は、DECIMALおよびFIXEDである。たとえば：
declare A fixed decimal (5,4);
では、Ａが５桁の１０進固定小数点データを表し、５桁のうちの４桁が、小数点の右にあることが指定される。
次の２つの例：
declare B fixed (7,0) decimal;
declare Bfixed decimal(7);
の両方で、Ｂが７桁の整数を表すことが指定される。
次の例
declare C fixed (7,-2) decimal;
では、Ｃが−２の位取り係数を有することが指定される。これは、Ｃが、１００の増分で範囲−9999999×100から9999999×100までの７桁を保持することを意味する。
次の例
declare D decimal fixed real(3,2);
では、Ｄが、３桁の固定小数点データを表し、３桁のうちの２桁が小数であることが指定される。
PLIArithmeticTypeから派生する
パブリック属性：
precision : Integer
scale : Integer
【０１８６】
PLIPictureType
数字ピクチャ・データは、文字形式で保持される数値データである
PLIArithmeticTypeから派生する
パブリック属性：
pictureString : String
【０１８７】
PLICodedStringType
PLIStringTypeから派生する
パブリック属性：
type : StringTypeValues
varying : LengthType
【０１８８】
PLIPictureStringType
文字ピクチャ指定では、固定小数点文字データ項目が記述され、データ項目内の任意の位置に、使用可能な文字の完全な組のあるサブセットからの文字だけが含まれることを指定する追加機能がある。
文字ピクチャ指定は、ＡまたはＸのピクチャ指定文字の出現によって認識される。文字ピクチャ指定で有効な文字は、Ｘ、Ａ、および９だけである。これらのそれぞれによって、文字値内の１つの文字位置の存在が指定され、これには、下記を含めることができる：
Ｘ ８ビット・バイトによって表される２５６個の可能なビット組合せのすべての文字。
Ａ 英数字文字、＃、＠、＄、またはブランク。
９ 任意の数字またはブランク（数値文字指定での９ピクチャ指定文字は、対応する文字が数字だけである点で異なることに留意されたい）。
文字値がピクチャ形式文字データ項目に割り当てられるか転送される時に、各位置の特定の文字が、対応するピクチャ指定文字による指定に従って有効性を検査され、無効な文字についてCONVERSION状態が発生する（しかし、レコード指向伝送を介するか別名を使用することのいずれかによって値が変更される場合には、検査はない）。
たとえば：
DECLARE PART# PICTURE 'AAA99X';
PUT EDIT (PART#) (P'AAA99X');
次の値は、ＰＡＲＴ＃について有効である：
'ABC12M'
'bbb09/'
'XYZb13'
次の値は、ＰＡＲＴ＃について有効でない（無効な文字に下線を付ける）：
'AB123_M'
'ABC1/_2'
'Mb#A5;_'
PLIStringTypeから派生する
パブリック属性：
pictureString : String
【０１８９】
PLINonComputationalType
プログラムの実行を制御するのに使用される値を表す。次のデータ型からなる。area、entry、label、file、format、pointer、およびoffset。
PLISimpleTypeから派生する
【０１９０】
PLILabelType
ラベルは、ラベル定数またはラベル変数の値である。
ラベル定数は、ステートメントのラベル・プレフィックス（PROCEDURE、ENTRY、PACKAGE、またはFORMAT以外）として記述され、その結果、実行中に、それへの参照を介してプログラム制御をそのステートメントに転送することができる名前である。次のコードの行では、たとえば、Ａｂｃｄｅがラベル定数である。
Abcde: Miles = Speed*Hours;
ラベル付きステートメントは、命令の通常のシーケンシャル実行、またはプログラム内の他の点からそのステートメントに制御を転送するためのGO TOステートメントの使用のいずれかによって実行することができる。
ラベル変数に、もう１つのラベル変数またはラベル定数を割り当てることができる。そのような割当が行われる時に、ソース・ラベルの環境が、ターゲットに割り当てられる。ラベルの静的配列が初期値を有するように宣言された場合には、その配列は、非割当可能として扱われる。
GO TOステートメントに使用されるラベル変数は、その値として、GO TOが実行される時にアクティブであるブロック内で使用されるラベル定数を有しなければならない。次の例を検討されたい：
declare Lbl_x label;
Lbl_a: statement;
.
.
.
Lbl_b: statement;
.
.
.
Lbl_x = Lbl_a;
.
.
.
go to Lbl_x;
Ｌｂｌ＿ａおよびＬｂｌ＿ｂは、ラベル定数であり、Ｌｂｌ＿ｘは、ラベル変数である。Ｌｂｌ＿ａをＬｂｌ＿ｘに割り当てることによって、ステートメントGO TO Ｌｂｌ＿ｘによって制御がＬｂｌ＿ａステートメントに転送される。このプログラムの他の場所に、Ｌｂｌ＿ｂをＬｂｌ＿ｘに割り当てるステートメントを含めることができる。その場合に、Ｌｂｌ＿ｘへの参照は、どれもがＬｂｌ＿ｂへの参照と同一になる。Ｌｂｌ＿ｘの値は、別の値が割り当てられるまで保持される。ラベル変数が無効な値を有する場合に、そのようなエラーの検出は保証されない。次の例では、転送が、Ｉの値に基づいて配列Ｚの特定の要素に対して行われる。
go to Z(1);
.
.
.
Z(1): if X=Y then return;
.
.
.
Z(2):A=A+B+C*D;
.
.
.
Z(3): A=A+10;
Ｚ（２）が省略される場合に、Ｉ＝２の時のGO TO Ｚ（Ｉ）は、ERROR状態を発生させる。Ｉ＜ＬＢＯＵＮＤ（Ｚ）またはＩ＞ＨＢＯＵＮＤ（Ｚ）の時のGOTO Ｚ（Ｉ）は、SUBSCRIPTRANGE条件がディスエーブルされている場合に、予測不能な結果を引き起こす。
PLINonComputationalTypeから派生する
【０１９１】
PLIFormatType
リモート（またはＲ）フォーマット項目は、FORMATステートメント内のフォーマット・リストを使用しなければならないことを指定する。
Ｒフォーマット項目および指定されたFORMATステートメントは、同一のブロックの中にある必要があり、そのブロックの同一の呼出しの中になければならない。
リモートFORMATステートメントに、ラベル参照としてそれ自体を参照するＲフォーマット項目を含めることはできず、元のFORMATステートメントを参照することになる別のリモートFORMATステートメントを参照することもできない。
GETステートメントまたはPUTステートメントについてイネーブルされる条件は、参照されるリモートFORMATステートメントについてもイネーブルされなければならない。GETステートメントまたはPUTが、ONユニットの単一のステートメントである場合には、そのステートメントはブロックであり、リモート・フォーマット項目を含めることができない。
たとえば：
DECLARE SWITCH LABEL;
GET FILE(IN) LIST(CODE);
IF CODE =1
THEN SWITCH = L1;
ELSE SWITCH = L2;
GET FILE(IN) EDIT (W,X,Y,Z)
(R(SWITCH));
L1: FORMAT (4 F(8,3));
L2: FORMAT(4 E(12,6));
SWITCHは、ラベル変数として宣言されており、第２のGETステートメントは、２つのFORMATステートメントの一方と共に動作するようにすることができる。
データ・フォーマット項目によって、単一のデータ項目の文字またはグラフィック表現が記述される。それらは：
A - 文字
B - ビット
C - 複合
E - 浮動小数点
F - 固定小数点
G - グラフィック
P - ピクチャ
リモート・フォーマット項目では、その値がほかの位置にあるFORMATステートメントのラベル定数であるラベル参照が指定される。FORMATステートメントには、リモートに配置されたフォーマット項目が含まれる。ラベル参照項目は、Ｒである。
最初のデータ・フォーマット項目は、最初のデータ・リスト項目に関連し、２番目のデータ・フォーマット・項目は、２番目のデータ・リスト項目に関連し、以下同様である。フォーマット・リストに、関連するデータ・リストの項目より少ない数のデータ・フォーマット項目が含まれる場合には、フォーマット・リストが再利用される。フォーマット項目が多すぎる場合には、無視される。
フォーマット・リストに、５つのデータ・フォーマット項目が含まれ、それに関連するデータ・リストで、送信される１０個の項目が指定されると仮定する。データ・リストの６番目の項目は、最初のデータ・フォーマット項目に関連し、以下同様である。フォーマット・リストに１０個のデータ・フォーマット項目があり、それに関連するデータ・リストで、５つの項目だけが指定されると仮定する。６番目から１０番目までのフォーマット項目が、無視される。
例：
GET EDIT (NAME, DATA, SALARY)(A(N), X(2), A(6), F(6,2));
この例では、ストリーム内の最初のＮ文字が、文字列として扱われ、NAMEに割り当てられることが指定される。次の２文字は、スキップされる。次の６文字は、文字フォーマットでDATAに割り当てられる。次の６文字は、任意選択として符号付きの１０進固定小数点定数とみなされ、SALARYに割り当てられる。
PLINonComputationalTypeから派生する
【０１９２】
PLIEntryType
入り口データは、入り口定数または入り口変数の値とすることができる。
入り口定数は、PROCEDUREステートメントまたはENTRYステートメントに対するラベル・プレフィックスとして記述された名前、またはVARIABLE属性ではなくENTRY属性を用いて宣言された名前、または数学組込み関数の名前である。
入り口定数を、入り口変数に割り当てることができる。たとえば：
P: PROCEDURE;
DECLARE EV ENTRYVARIABLE,
(E1,E2) ENTRY;
EV=E1;
CALL EV;
EV = E2;
CALL EV;
Ｐ、Ｅ１、およびＥ２が、入り口定数である。ＥＶは、入り口変数である。最初のCALLステートメントは、入口点Ｅ１を呼び出す。２番目のCALLは、入口点Ｅ２を呼び出す。
次の例には、添字付きの入り口参照が含まれる：
DECLARE (A,B,C,D,E) ENTRY,
DECLARE F(5) ENTRY VARIABLE
INITIAL (A,B,C,D,E);
DO I=1 TO 5;
CALL F(I)(X,Y,Z);
END;
５つの入り口Ａ、Ｂ、Ｃ、Ｄ、およびＥは、それぞれ、パラメータＸ、Ｙ、およびＺを用いて呼び出される。
内部プロシージャの入口点である入り口定数が、入り口変数に割り当てられる時に、割り当てられる値は、入り口定数が内部にあったブロックがアクティブである（および、再帰プロシージャの場合にカレントである）限り、有効なままになる。
ENTRYADDR組込み関数および擬似変数を用いると、入り口変数のPROCEDUREまたはENTRYの入口点のアドレスを入手するか設定することができるようになる。入口点のアドレスは、入り口が呼び出された場合に実行される最初の命令のアドレスである。たとえば：
PTR1 =ENTRYADDR(ENTRY_VBL);
では、入り口点のアドレスが得られ、
ENTRYADDR(ENTRY_VBL) = PTR2;
である。
PLINonComputationalTypeから派生する
パブリック属性：
Limited : Boolean
【０１９３】
PLIAreaType
区域変数では、基底付き変数の割振りのために予約されるストレージの区域が記述される。この予約されるストレージは、ALLOCATEステートメントによって基底付き変数に割り振り、FREEステートメントによって基底付き変数から解放することができる。区域変数は、任意のストレージ・クラスを有することができ、位置合わせされなければならない。
基底付き変数が割り振られ、区域が指定されない時に、ストレージは、使用可能であればどこからでも獲得される。その結果、割り振られる基底付き変数が、主記憶域全体に広く分散する可能性がある。これは、項目がポインタを使用して簡単にアクセスされるので、内部動作にとっては重要でない。しかし、これらの割振りが、データ・セットに送られる場合には、項目を一緒に収集しなければならない。区域変数を用いて割り振られる項目は、既に収集されており、別々の識別を保ちながら１単位として送るか割り振ることができる。
区域変数内の、区域変数の先頭に対する相対的な基底付き変数の位置を識別したい場合がある。オフセット変数が、この目的のために設けられている。区域を、それに含まれる割当を完備して割当または送信することができ、したがって、基底付き割振りの組を、各割当の個々の識別を保持しながら、割当および入出力に関する１単位として扱うことができる。
区域のサイズは、ストリング長または配列の限界と同じ形で調整可能であり、したがって、式またはアスタリスク（被制御区域または被制御パラメータの場合）またはREFERオプション（基底付き区域の場合）によって指定することができる。
ストレージ・クラスAUTOMATICまたはCONTROLLEDを有する区域の区域サイズは、その整数値によって予約されるバイト数が指定される式によって与えることができる。区域がBASED属性を有する場合に、その区域が基底付き構造体のメンバであり、REFERオプションが使用される場合を除いて、区域サイズは整数でなければならない。
静的ストレージ・クラスの区域のサイズは、整数として指定しなければならない。AREA宣言の例は次の通りである：
DECLARE AREA1 AREA(2000),
AREA2 AREA;
宣言されたサイズのほかに、余分な１６バイトの制御情報が、区域の予約されたサイズの前に置かれる。この１６バイトに、使用中のストレージの量などの詳細が含まれる。
実際に使用されている予約済みストレージの量を、区域のエクステントと称する。区域変数は、割り振られる時に、空である、すなわち、区域エクステントが０である。最大エクステントは、区域サイズによって表される。基底付き変数は、実行中にいつでも区域内で割り振り、解放することができ、したがって、区域のエクステントが変化する。
基底付き変数が解放される時に、それが占有したストレージが、他の割振りに使用可能になる。ある区域内の使用可能なストレージのチェーンが、維持され、このチェーンの先頭は、１６バイトの制御情報内に保持される。不可避的に、異なるストレージ要件を有する基底付き変数が、割り振られ、解放されるので、割振りが使用可能なスペースと一致しない時に、区域内にギャップが生じる。これらのギャップは、区域のエクステントに含まれる。
比較を含めてどの演算子も、区域変数に適用することはできない。
PLINonComputationalTypeから派生する
【０１９４】
PLIPointerType
ポインタ変数は、基底付き変数の宣言内に、ロケータ修飾子として、BASED属性内に、あるいは、ALLOCATEステートメント、LOCATEステートメント、またはREADステートメントのSETオプション内に現れる場合に、コンテキスト的に宣言される。ポインタ変数を明示的に宣言することもできる。
PLINonComputationalTypeから派生する
【０１９５】
PLIFileType
FILE属性によって、関連する名前がファイル定数またはファイル変数であることが指定される。
FILE属性は、ファイル記述属性のいずれかによってファイル定数について暗黙指定することができる。名前を、入力ステートメントまたは出力ステートメントのFILEオプション内、または入力／出力条件に関するONステートメント内の出現を介して、ファイル定数としてコンテキスト的に宣言することができる。
PLINonComputationalTypeから派生する
【０１９６】
PLIOffsetType
区域変数内の、区域変数の先頭に対する相対的な基底付き変数の位置を識別したい場合がある。オフセット変数は、この目的のために設けられる。
PLINonComputationalTypeから派生する
パブリック属性：
BigEndian : Boolean = true
【０１９７】
PLIAlias
別名は、明示的なデータ型が許容される場所であればどこでも使用することができる型名である。DEFINE ALIASステートメントを使用して、データ属性の集合の別名を定義することができる。この形で、意味のある名前をデータ型に割り当て、プログラムの理解される能力を改善することができる。別名を定義することによって、データ属性の組のより短い表記を供給することもでき、これによってタイプの誤りを減らすことができる。
例
define alias Name char(31) varying;
define alias Salary fixed dec(7); /* デフォルトでreal */
define alias Zip char(5) /* デフォルトでnonvarying */
PLINamedTypeから派生する
【０１９８】
Attribute
指定することができる属性は、関数が返すことができる変数の属性のいずれかである（たとえば、RETURNSオプションおよび属性で有効な属性）。すなわち、配列または構造化された属性リストの別名を指定することはできない。しかし、DEFINEORDINALステートメントまたはDEFINE STRUCTUREステートメントあるいは別のDEFINE ALIASステートメントで定義された型の別名を指定することができる。また、RETURNSオプションおよび属性と同様に、ストリング長または区域サイズは、制限付き式でなければならない。
欠けているデータ属性は、ＰＬ／Ｉデフォルトを使用して供給される。
パブリック属性：
attribute : String
【０１９９】
PLIOrdinal
序数は、順序付きの値の名前付きの組である。DEFINE ORDINALステートメントを使用して、序数を定義し、その組を参照するのに使用される意味のある名前を割り当てることができる。たとえば、「color」と呼ばれる序数を定義することができる。「color」序数に、メンバ「red」、「yellow」、「blue」などを含めることができる。「color」組のメンバを、関連する固定された２進値によるのではなく、これらの名前によって参照することができ、コードがはるかに自己文書化的になる。さらに、序数型を用いて宣言された変数は、同一の型の序数またはその序数型のメンバだけを割り当てることができ、比較することができる。この自動的な検査によって、よりよいプログラムの信頼性がもたらされる。
下の例では、Redが値０を有し、Orangeが値１を有するなどである。しかしLowは値２を有し、Mediumは値３を有する。
例
define ordinal Color ( Red, /* VALUEが省略されているので0 */
Orange,
Yellow,
Green,
Blue,
Indigo,
Violet);
define ordinal Intensity ( Low value(2),
Medium,
High value(5));
PLINamedTypeから派生する
パブリック属性：
precision : int
isSigned : boolean
【０２００】
OrdinalValue
OrdinalValueでは、組内の特定のメンバの値を指定する。最初のメンバについてVALUE属性が省略された場合には、０の値が使用される。他のメンバについてVALUE属性が省略された場合には、次に大きい整数値が使用される。
所与の（または仮定される）VALUE属性の値は、整数でなければならず、符号付きとすることができ、厳密に増分しなければならない。所与の（または仮定される）VALUE属性の値は、ＸＮ定数として指定することもできる。
例
define ordinal Intesity (low value(2), middle, high value (5));
は、lowに２の値、middleに３の値、highに５の値を与える。
パブリック属性：
name : String
value : int
【０２０１】
PLIStructure
構造体は、構造体、共用体、または基本的な変数および配列とすることができるメンバ要素の集合である。共用体は、互いに重なり合い、同一のストレージを占めるメンバ要素の集合である。共用体は、通常は共通部分、セレクタ部分、および可変部分を含む可変レコードを宣言するのに使用することができる。
DEFINE STRUCTUREステートメントが、名前付きの構造体または共用体を指定するのに使用される。構造体は、強く型付けされる。すなわち、構造体として宣言された変数だけを、構造体として宣言された変数またはパラメータに割り当てることができる。
PLINamedType、PLIComposedTypeから派生する
【０２０２】
PLIHandleType
変数を構造体型へのポインタとして宣言するには、HANDLEを使用する。ハンドルは、強く型付けされる、すなわち、同一の構造体型のハンドルに割り当てるかそれと比較することができる。
PLINonComputationalTypeから派生する
パブリック属性：
structure : tPLIStructure
【０２０３】
PLINamedType
ＰＬ／Ｉでは、組込みデータ型を使用して、ユーザ自身が命名した型を定義することができる。これには、ユーザ定義型（別名、序数、構造体、および共用体）、これらの型を有する変数の宣言、ハンドル、および型関数が含まれる。
PLIClassifierから派生する
【０２０４】
PLIArray
配列は、同一の属性を有する要素のｎ次元集合である。
例
dcl List fixed decimal(3) dimension(8)
は、８つの固定小数点１０進要素の１次元配列である。
dcl table (4,2) fixed dec (3)
は、３つの固定小数点１０進要素の２次元配列であり、tableの２次元は、１つの次元に関して１の下界と４の上界を有し、他方の次元に関して１の下界と２の上界を有する。
REFERオプションは、構造体の割振り時に、式の値が、構造体内の変数に割り当てられ、構造体内の別の変数の長さ、限界、またはサイズを表すことを指定するために、基底付き構造体の宣言で使用される。REFERオプションを用いる長さ、限界、またはサイズの構文は、次の通りである：
expression REFER ( variable )
variableは、REFERオプションのオブジェクトと称するが、宣言される構造体のメンバでなければならない。REFERオブジェクトは、下記の規則に従わなければならない。
REAL FIXED BINARY（ｐ，０）でなければならない。
REFERオプションを有するか、REFERオプションを有する要素を含む、最初のレベル２要素の前に置かなければならない。
ロケータ修飾または添字付きであってはならない。
配列の一部であってはならない。
たとえば：
DECLARE 1 STR BASED(P),
2 X FIXED BINARY,
2 Y (L REFER (X)),
L FIXED BINARY INIT(1000);
この宣言では、基底付き構造体ＳＴＲが、配列Ｙおよび要素Ｘからなることが指定される。ＳＴＲが割り振られる時に、上界にＬの現在の値がセットされ、これがＸに割り当てられる。ＰをセットするREADステートメントなど、Ｙへの他の参照について、限界の値は、Ｘからとられる。
同一のメンバについて、REFERオプションとINITIAL属性の両方が使用される場合には、REFERのオブジェクトが値を割り当てられた後に、初期化が行われる。
下記の制約の少なくとも１つが満足されるならば、任意の数のREFERオプションを、構造体の宣言に使用することができる：
REFERオプションのすべてのオブジェクトが、論理レベル２で宣言される、すなわち、小構造内で宣言されない。たとえば：
DECLARE 1 STR BASED,
2 (M,N),
2 ARR(I REFER(M),
J REFER(N)),
2 X;
この構造体が割り振られる時に、ＩおよびＪに割り振られる値によって、２次元配列ＡＲＲの限界がセットされる。
構造体のメンバの間で埋込みが発生しないように構造体が宣言される。たとえば：
DECLARE 1 STR UNAL BASED (P),
2 BFIXED BINARY,
2 C,
3 D FLOAT DECIMAL,
3 E (I REFER (D))
CHAR(J REFER (B)),
2 G FIXED DECIMAL;
この構造体は、ＵＮALIGNED属性を有するので、すべての項目が、バイト位置合わせだけを必要とする。したがって、ＢおよびＤ（REFERオブジェクト）の値に無関係に、埋込みは行われない。Ｄが、小構造内で宣言されていることに留意されたい。
REFERオプションが、構造体宣言で１回だけ使用される場合に、下記が成り立つならば前の２つの制約を無視することができる：
ストリング長または区域サイズに関して、オプションが、構造体の最後の要素に適用される。
配列の限界に関して、オプションが、構造体の最後の要素または最後の要素を含む小構造のいずれかに適用される。配列の限界は、先行する次元の上界でなければならない。たとえば：
DCL 1 STR BASED (P),
2 X FIXED BINARY,
2 Y,
3 Z FLOAT DECIMAL,
3 M FIXED DECIMAL,
2 D (L REFER (M)),
3 E (50),
3 F (20);
配列の先行する次元は、上位レベルから継承することができる。上の例でＳＴＲ（４）を宣言した場合に、先行する次元は、ＳＴＲ（４）から継承され、したがって、ＤでREFERオプションを使用することが不可能になる。
この宣言は、前の２つの制約を満足しない。REFERオブジェクトＭは、小構造内で宣言され、埋込みが行われる。しかし、REFERオプションが、最後の要素を含む小構造に適用されるので、この制約は満足される。
次の例も有効である：
DCL 1 STR BASED(P),
2 X FIXED BINARY(31),
2 Y,
3 Z FLOAT DECIMAL,
3 M FIXED BINARY(31),
3 N FIXED BINARY(31),
2 D,
3E(50),
3 F(L REFER (M))
CHAR(K REFER (N));
REFERオプションのオブジェクトの値が、プログラム中で変更される場合には：
オブジェクトが、割り振られた時に有した値に復元されるまで、構造体を解放してはならない。
オブジェクトが、割り振られた時より大きい値を有する間は、構造体を書き出してはならない。
オブジェクトが、割り振られた時以下の値を有する時には、構造体を書き出すことができる。実際に書き込まれる要素の数、ストリング長、または区域サイズは、オブジェクトの現在の値によって示される値である。たとえば：
DCL 1 REC BASED (P),
2 N,
2 A (M REFER(N)),
M INITIAL (100);
ALLOCATE REC;
N=86;
WRITE FILE (X) FROM (REC);
では、８６要素のＲＥＣが書き込まれる。この時点でＲＥＣを解放する試みは、エラーになる。というのは、Ｎが、割り振られた時に有した値（すなわち１００）に復元されなければならないからである。Ｎに１００を超える値が割り当てられる場合には、ＷＲＩＴＥステートメントに出会った時にエラーが発生する。
REFERオブジェクトの値が変更される時に、構造体への次の参照が、再マッピングを引き起こす。たとえば：
DCL 1 A BASED(P),
2 B,
2 C (I REFER(B)),
2D,
1 INIT(10);
ALLOCATE A;
B=5;
Ｂの割当の後のＡへの次の参照によって、構造体が再マッピングされて、Ｃの上界が１０から５に減り、ＤのストレージがＣの新しい最後の要素に直接に続くように割り振られる。構造体は再マッピングされるが、データの再割当は行われず、ストレージのうちで構造体Ａによって元々占有されていた部分の内容は、変更されない。再マッピングを考慮しない場合には、エラーが発生する可能性がある。次の例を検討されたい。この例では、１つの構造体に２つのREFERオプションがある：
DCL 1 A BASED (P),
2 B FIXED BINARY (15,0),
2 C CHAR (I1 REFER (B)),
2 D FIXED BINARY (15,0),
2 E CHAR (I2 REFER(D)),
(I1,I2)INIT(10);
ALLOCATE A;
B=5;
Ｂ＝１０およびＢ＝５のＡのマッピングは、次のようになる：
| B | C | D | E |
|___|__________|___|________|
| B | C | D | E|
|___|_____|___|_ _ _ _ _ _
Ｄは、現在、元々は文字列変数Ｃに割り当てられていた部分のデータを参照する。このデータは、Ｄの属性すなわち固定小数点２進数に従って解釈され、得られる値がＥの長さになる。したがって、Ｅの長さは予測不能である。
【０２０５】
PLIFixedLengthString
PLICodedStringTypeから派生する
パブリック属性：
length : Integer
【０２０６】
PLIVariableLengthString
PLICodedStringTypeから派生する
パブリック属性：
lengthToAllocate : String
【０２０７】
PLIFixedLengthArea
PLIAreaTypeから派生する
プライベート属性：
length : Integer
【０２０８】
PLIVariableLengthArea
区域のサイズは、ストリング長または配列の限界と同一の形で調整可能であり、したがって、式またはアスタリスク（被制御区域または被制御パラメータの場合）またはREFERオプション（基底付き区域の場合）によって指定することができる。
PLIAreaTypeから派生する
プライベート属性：
lengthToAllocate : String
【０２０９】
PLIFixedBoundArray
PLIArrayから派生する
パブリック属性：
lbound : Integer
ubound : Integer
【０２１０】
PLIFixedLboundArray
PLIArrayから派生する
パブリック属性：
lbound : Integer
HboundtoAllocate : String
【０２１１】
PLIHboundArray
PLIArrayから派生する
パブリック属性：
LboundtoAllocate : String
ubound : Integer
【０２１２】
PLIVariableBoundArray
PLIArrayから派生する
パブリック属性：
LboundToAllocate : String
HboundToAllocate : String
【０２１３】
総計：
１論理パッケージ
３９クラス
論理パッケージ構造
論理ビュー
PLI
TDLang
【０２１４】
５．ｃ．Ｃメタモデル
Ｃ MainおよびUser Types（すなわちユーザ定義型）を含むＣメタモデルは、Ｍ２レベルのＭＯＦクラス・インスタンスである。図２４にＣ言語メタモデルを示す。図２５に、Ｃ言語メタモデルのTDLangClassifier、TDLangComposedType、およびTDLangElementを示す。図２６に、Ｃ言語メタモデルのTypedElement態様を示す。図２７に、Ｃ言語メタモデルでのユーザ定義データ型を含むデータ型を示す。図２８に、Ｃ言語メタモデルでのDatatype-StringおよびDatatype-Integer、ならびにDirectionKindの引数および戻り値の列挙およびBooleanデータ型のtrueおよびfalseの列挙を示す。
【０２１５】
５．ｃ．ｉ．Ｃメタモデル仕様
Ｃメタモデル仕様は、コネクタ・インターフェースを表すデータ構造体を定義するために、エンタープライズ・アプリケーション・プログラムによって使用される。
【０２１６】
Classifier
型指定子は、宣言されつつあるオブジェクトまたは関数の型を示す。
基本データ型は次の通りである：
文字
浮動小数点数
整数
列挙
Void
これらの型から、ユーザは下記を導出することができる：
ポインタ
配列
構造体
共用体
関数
整数型は、char、ｗchar_t（C++のみ）、およびすべてのサイズのintである。浮動小数点数は、型float、double、またはlong doubleを有することができる。整数型と浮動小数点型を、集合的に算術型と呼ぶことができる。C++のみにおいて、下記も導出することができる：
参照
クラス
メンバへのポインタ
C++では、列挙が、整数型ではないが、整数拡張の対象になり得る。これは、ＣMainで型を定義する基本クラスである。
列挙は、それに含まれるFeaturesの組を介するインスタンスの分類を提供する。
分類子は、主にFeaturesの構成によって定義される。
TDLangClassifierから派生する
パブリック属性：
name : String
【０２１７】
Structured
これは、構造型の抽象クラスである。
Classifier、TDLangComposedType、DerivableType、StructureContentsから派生する
【０２１８】
Struct
構造体には、データ・オブジェクトの順序付きグループが含まれる。配列の要素とは違って、構造体内のデータ・オブジェクトは、さまざまなデータ型を有することができる。構造体内の各データ・オブジェクトは、メンバまたはフィールドである。
構造体を使用して、論理的に関係するオブジェクトをグループ化する。たとえば、１つの住所の構成要素のストレージを割り振るために、次の変数を定義する：
int street_no;
char *street_name;
char *city;
char *prov;
char *postal_code;
複数の住所のストレージを割り振るためには、構造体データ型と、その構造体データ型を有するのに必要なだけの変数を定義することによって、各住所の構成要素をグループ化する。
次の例では、行１から７で、構造体タグaddressを宣言している：
1 struct address {
2 intstreet_no;
3 char*street_name;
4 char *city;
5 char *prov;
6 char*postal_code;
7 };
8 struct address perm_address;
9 struct address temp_address;
10 struct address*p_perm_address = &perm_address;
変数perm_addressおよびtemp_addressは、構造体データ型addressのインスタンスである。この両方に、addressの宣言で記述されたメンバが含まれる。ポインタp_perm_addressは、addressの構造体を指し、perm_addressを指すように初期化される。
ドット演算子（．）を伴う構造体変数名または矢印演算子（−＞）を伴うポインタとメンバ名を指定することによって、構造体のメンバを参照する。たとえば、下記の両方で、ストリング”Ontario”へのポインタを、構造体perm_addressに含まれるポインタprovに割り当てている：
perm_address.prov ="Ontario";
p_perm_address ->prov = "Ontario";
構造体への参照のすべてを、完全に修飾しなければならない。この例では、４番目のフィールドをprovだけで参照することができない。このフィールドは、perm_address．provによって参照しなければならない。
同一のメンバを有するが異なる名前の構造体は、互換ではなく、互いに割り当てることができない。構造体は、ストレージを節約することを意図されていない。バイト・マッピングの直接制御が必要な場合には、ポインタを使用する。
Structuredから派生する
【０２１９】
Union
共用体は、名前付きメンバの組のどの１つでも保持することができるオブジェクトである。名前付きの組のメンバは、任意のデータ型とすることができる。Ｃ／C++は、ストレージ内でメンバをオーバーレイする。
共用体に割り振られるストレージは、共用体の最大のメンバに必要なストレージ（と、共用体がその最も厳密なメンバの自然な境界で終わるようにするのに必要な埋込み）である。
C++の注記：
１．C++では、共用体が、コンストラクタおよびデストラクタを含むメンバ関数を有することができるが、仮想メンバ関数を有することはできない。共用体を基本クラスとして使用することも、基本クラスから共用体を派生させることもできない。
２．C++の共用体メンバは、コンストラクタ、デストラクタ、またはオーバーロードされるコピー代入演算子を有するクラス・オブジェクトとすることができない。C++では、キーワードstaticを用いて共用体のメンバを宣言することができない。
Structuredから派生する
【０２２０】
BehavioralFeature
これによって、これを含むModelElementの動的特性が定義される。BehavioralFeatureは、FeatureとNamespaceの両方である。
パブリック属性：
name : String
【０２２１】
TypedElement
これは、定義に型指定を必要とする属性、パラメータおよび定数の基本クラスである。TypeElement型は、定義の一部として型を必要とする、ModelElementsの抽象である。TypeElementは、それ自体で型を定義するのではなく、Classifierに関連する。
TDLangElementから派生する
【０２２２】
StructuralFeature
それを含むModelElementの静的特性を定義する。
TypedElement、StructureContentsから派生する
パブリック属性：
name : String
【０２２３】
Parameter
Parameterは、動作および他のBehavioralFeaturesとの通信の手段を提供する。パラメータによって、その定義された型の値が渡されるか通信される。
関数宣言子に、関数に命名する識別子と、関数パラメータのリストが含まれる。必ずプロトタイプ関数宣言子を使用すべきである。というのは、これによって関数パラメータを検査できるからである。C++関数は、プロトタイプ関数宣言子を有しなければならない。
プロトタイプ関数宣言子：関数宣言子内で各パラメータを宣言すべきである。関数への呼出しでは、宣言にあるパラメータと同数の引数を渡さなければならない。
非プロトタイプ関数宣言子：宣言子に続くパラメータ宣言リストで各パラメータを宣言すべきである。パラメータを宣言しない場合には、そのパラメータは型intを有する。
コンパイラは、charパラメータおよびshortパラメータをintに拡幅し、floatパラメータをdoubleに拡幅する。コンパイラは、プロトタイプ宣言されていない関数の引数の型とパラメータの型の間の型検査を実行しない。また、コンパイラは、引数の数がパラメータの数と一致することを保証するための検査を行わない。
宣言に続くプロトタイプ宣言されない関数定義のパラメータ宣言リストで、関数が受け取る値のそれぞれの値を宣言すべきである。
パラメータ宣言によって、ストレージ・クラス指定子と値のデータ型が決定される。
Ｃ／C++が許容する唯一のストレージ・クラス指定子が、registerストレージ・クラス指定子である。これは、パラメータのすべての型指定子を受け入れる。registerストレージ・クラス指定子を指定しない場合には、パラメータは、autoストレージ・クラス指定子を有する。Ｃのみにおいて、型指定子を省略し、関数の定義にプロトタイプ形式を使用していない場合には、パラメータは、次のように型intを有する：
int func(i,j)
{
/* iおよびjは型intを有する */
}
Ｃのみにおいて、あるパラメータが宣言子にリストされていない場合に、パラメータ宣言リストでそのパラメータを宣言することはできない。
TypedElementから派生する
パブリック属性：
direction : Directionkind
プライベート属性：
name : String
【０２２４】
Datatype
これは、データ型および内部型を表す。
Classifierから派生する
【０２２５】
Derived
DerivableType、Classifierから派生する
【０２２６】
Field
Fieldは属性である。
StructuralFeatureから派生する
【０２２７】
Function
BehavioralFeature、DerivableTypeから派生する
パブリック属性：
isVarArg : Boolean
【０２２８】
StructureContents
Structured
これは、structured型の抽象クラスである。
Classifier、TDLangComposedType、DerivableType、StructureContentsから派生する
【０２２９】
TypedElement
これは、定義に型指定を必要とする属性、パラメータ、および定数の基本クラスである。TypeElement型は、定義の一部として型を必要とするModelElementsの抽象である。TypeElementは、それ自体で型を定義するのではなく、Classifierに関連する。
TDLangElementから派生する
【０２３０】
Typedef
Derivedから派生する
【０２３１】
Derived
DerivableType、Classifierから派生する
【０２３２】
Array
配列は、データ・オブジェクトの順序付きグループである。各オブジェクトを要素と呼ぶ。配列内のすべての要素が、同一のデータ型を有する。
配列の定義または宣言では、任意の型指定子を使用する。配列要素は、関数またはC++の参照以外のどのデータ型にもすることができる。しかし、関数へのポインタの配列を宣言することはできる。
Derivedから派生する
パブリック属性：
dimension : Integer
【０２３３】
Pointer
ポインタ型変数は、データ・オブジェクトまたは関数のアドレスを保持する。ポインタは、ビット・フィールドおよび参照を除くすべてのデータ型のオブジェクトを参照することができる。さらに、Ｃでは、ポインタが、register記憶クラスのオブジェクトを指すことができない。
ポインタの一般的な用途の一部を下に示す：
リンク・リスト、ツリー、キューなどの動的データ構造体にアクセスするため。
配列の要素、構造体のメンバ、またはC++クラスのメンバにアクセスするため。
ストリングとして文字の配列にアクセスするため。
変数のアドレスを関数に渡すため（C++では、参照を使用してこれを行うこともできる）。アドレスを介して変数を参照することによって、関数がその変数の内容を変更することができる。
Derivedから派生する
【０２３４】
Function
BehavioralFeature、DerivableTypeから派生する
パブリック属性：
isVarArg : Boolean
【０２３５】
DerivableType
【０２３６】
５．ｄ．C++メタモデル
書籍「ANNOTATED C++ REFERENCE MANUAL」（MargaretA.Ellis,Bjarne Stoustrup著、1990年、「注解C++リファレンスマニュアル」足立高徳／小山裕司訳）に基づくC++メタモデルは、Ｍ２レベルのＭＯＦクラス・インスタンスである。C++メタモデルは、C++Mainと、下に記載のモデル型からなる。
【０２３７】
５．ｄ．ｉ．C++ Mainメタモデル：
このメタモデルは、Ｃ Mainメタモデルから継承する。図２９に、C++メタモデルのDerived、Structured、BehavioralFeatures、Field、およびDerivableTypesを含むC++Mainメタモデルを示す。図３０に、C++メタモデルの可視性型の列挙を示す。C++が、オブジェクト指向言語であり、オブジェクト指向プログラミングに有用であり、public、private、およびprotectedの可視性をサポートすることに留意されたい。
Model Typesメタモデル:
【０２３８】
５．ｄ．ｉｉ．C++メタモデル仕様
C++
C++メタモデルは、コネクタ・インターフェースを表すデータ構造体を定義するために、エンタープライズ・アプリケーション・プログラムによって使用される。
【０２３９】
Ｃｌａｓｓ
C++クラスは、Ｃ言語構造体の拡張である。構造体とクラスの唯一の相違は、構造体メンバがデフォルトでpublicアクセスを有するが、クラス・メンバがデフォルトでprivateアクセスを有することである。その結果、キーワードclassまたはstructを使用して、同等のクラスを定義することができる。
// この例では、クラスＸが構造体Ｙと同等である
class X
{
int a; // デフォルトでprivate
public:
int f() { return a = 5; }; // publicメンバ関数
};
struct Y
{
int f() { return a = 5; }; // デフォルトでpublic
private:
int a; // privateデータ・メンバ
};
構造体を定義し、その後、キーワードclassを使用してその構造体のオブジェクトを宣言する場合に、オブジェクトのメンバは、まだデフォルトでpublicである。次の例では、Ｘがキーワードclassを使用してして宣言されているが、main（）がＸのメンバにアクセスできる。
Structuredから派生する
パブリック属性：
isAbstract : Boolean
isVolatile : Boolean
プライベート属性：
visibility : VisibilityKind
【０２４０】
Member
データ・メンバには、基本型ならびに、ポインタ、参照、配列型、およびユーザ定義型を含む他の型のどれかを用いて宣言されるメンバが含まれる。データ・メンバは、変数と同一の形で宣言することができる。しかし、クラス定義の中に明示的な初期化指定子を配置することはできない。
配列をstaticでないクラス・メンバとして宣言する場合には、すべての配列次元を指定しなければならない。
Field、DerivableTypeから派生する
パブリック属性：
isStatic : Boolean
プライベート属性：
isVolatile : Boolean
isRegister : Boolean
visibility : VisibilityKind
【０２４１】
Reference
Derivedから派生する
【０２４２】
Operator
BehavioralFeature、StructureContentsから派生する
プライベート属性：
isInline : Boolean
visibility : VisibilityKind
【０２４３】
Operation
Function、StructureContentsから派生する
パブリック属性：
isStatic : Boolean
isExtern : Boolean
isInline : Boolean
isVirtual : Boolean
isPure : Boolean
visibility : VisibilityKind
isCtor : Boolean
プライベート属性：
isDtor : Boolean
【０２４４】
Extern
Externは、Derived型の一種である。Ｃとの関連付けに使用される。
Derivedから派生する
プライベート属性：
linkage : String
【０２４５】
Generalization
プライベート属性：
visibility : VisibilityKind
isVirtual : Boolean
【０２４６】
Const
Derivedから派生する
【０２４７】
Template
テンプレート宣言内の宣言では、下記の１つを定義または宣言しなければならない：
クラス
関数
テンプレート・クラスのstaticメンバ
型の識別子は、テンプレート宣言のスコープ内でtype_nameになる。テンプレート宣言は、グローバル宣言としてのみ行うことができる。
テンプレート引数（区切り文字＜と＞の中）によって、テンプレートをインスタンス化する時に指定しなければならないテンプレート内の型および定数を指定する。
下のテンプレートを与えられたものとして：
template<class L> class Key
{
L k;
L* kptr;
int length;
public:
Key(L);
// ..;
// ...
};
この宣言によって、次のオブジェクトが作成される：
型Key<int>のｉ
型Key<char*>のｃ
型Key<mytype>のｍ
この３つのクラスが、異なる名前を有することに留意されたい。かぎ括弧（＜＞）に含まれる型は、クラス名に対する引数ではなく、クラス名自体の一部である。Key<int>およびKey<char*>はクラス名である。この例のコンテキスト内で、Keyと呼ばれるクラス（テンプレート引数リストなし）は、未定義である。
C++では、下記の条件の下でテンプレート引数のデフォルト初期化指定子が許容される：
nontypeテンプレート引数だけに適用される。
関数のように、後端の引数だけに適用される。
後続のテンプレート宣言では、デフォルト初期化指定子を追加することができるが、既存のデフォルト初期化指定子を再定義することはできない。
関数テンプレート宣言ではなく、クラス・テンプレート宣言だけに適用される。
注：C++は、クラス・テンプレートのメンバ関数を定義するテンプレートを、関数テンプレートとみなす。そのようなテンプレートは、デフォルト初期化指定子を有することができない。
Derivedから派生する
【０２４８】
５．ｅ．HLASM（High Level Assembler）
これは、ＯＳ３９０用のHLASMである。図３７に、コネクタ・インターフェースを表すデータ構造体セマンティクスを定義するHighLevel Assembly Language（ＨＬＡＳＭ）メタモデルを示す。図３８に、TDLangClassifier、TDLanguageComposedType、およびTDLangElementである、HLASMメタモデルとTDLang基本クラスの間の関連を示す。図３９に、HLASMメタモデルでのHLASM使用値の列挙を示す。
【０２４９】
hlasm
HLASMDecimal
HLASMDecimal型は、１０進数命令によって使用される。
コードは、１０進数型（計算機フォーマット：パック１０進数フォーマット）の場合に’Ｐ’である。
コードは、１０進数型（計算機フォーマット：ゾーン１０進数フォーマット）の場合に’Ｚ’である。
例：
AP AREA,PCON
PCON DC P'100'
AREA DS P
HLASMSimpleTypeから派生する
プライベート属性：
exponent : int
exponent修飾子は、１０進定数の公称値が、内部２進数表現に変換される前に乗算される１０のべきを指定する。
packed : boolean
このブール値は、１０進数型の計算機フォーマットに対応する。
真はパック（コードはＰ）である
偽はゾーン（コードはＺ）である
scale : int
scale修飾子は、１０進定数についてユーザが望む内部スケーリングの量を指定する。
【０２５０】
HLASMAddress
HLASMAddressは、主に固定小数点命令および他の命令の使用に関するアドレス情報を保持する。
コードは、アドレス型（計算機フォーマット：アドレスの値；通常はフルワード）の場合に、’Ａ’である。
コードは、アドレス型（計算機フォーマット：アドレスの値；通常はダブルワード）の場合に、’ＡＤ’である。
コードは、アドレス型（計算機フォーマット：アドレスの値；通常はハーフワード）の場合に、’Ｙ’である。
コードは、アドレス型（計算機フォーマット：基底レジスタおよび変位値；ハーフワード）の場合に、’Ｓ’である。
コードは、アドレス型（計算機フォーマット：外部シンボルアドレス用に予約された空間；通常はフルワード）の場合に、’Ｖ’である。
コードは、アドレス型（計算機フォーマット：クラスの長さまたはＤＸＤ用に予約された空間；通常はフルワード）の場合に、’Ｊ’である。
コードは、アドレス型（計算機フォーマット：外部ダミー・セクション・オフセット用に予約された空間）の場合に、’Ｑ’である。
コードは、アドレス型（計算機フォーマット：ＰＳＥＣＴアドレス用に予約された空間；通常はフルワード）の場合に、’Ｒ’である。
例：
L 5,ADCON
ADCON DC A(SOMWHERE)
HLASMSimpleTypeから派生する
プライベート属性：
type : HLASMAddressType
この要素のアドレス型を指定する。
【０２５１】
HLASMBinary
HLASMBinaryでは、ビット・パターンが定義される。
コードは、バイナリ形式（計算機フォーマット：２進フォーマット）の場合に、’Ｂ’である。
例：
FLAG DC B'00010000'
HLASMSimpleTypeから派生する
プライベート属性：
exponent : int
exponent修飾子は、２進定数の公称値が、内部２進数表現に変換される前に乗算される１０のべきを指定する。
scale : int
scale修飾子は、２進定数についてユーザが望む内部スケーリングの量を指定する。
【０２５２】
HLASMCharacter
HLASMCharacterでは、文字列またはメッセージを定義する。
コードは、文字型（計算機フォーマット：文字ごとに８ビット）の場合に、’Ｃ’である。
コードは、ユニコード文字型（計算機フォーマット：文字ごとに１６ビット・コード）の場合に、’ＣＵ’である。
コードは、グラフィック型（計算機フォーマット：文字ごとに１６ビット・コード）の場合に、’Ｇ’である。
例：
CHAR DC C'string ofcharacters'
HLASMSimpleTypeから派生する
プライベート属性：
graphic : boolean
要素がグラフィックであるか否かを指定する。
グラフィックの場合に真（コードは’Ｇ’）。
通常の文字型の場合に偽。
type : HLASMCharacterType
この要素の文字型を指定する。
【０２５３】
HLASMFixedPoint
HLASMFixedPoint型は、固定小数点命令および他の命令によって使用される。
コードは、固定小数点型（計算機フォーマット：符号付き固定小数点２進フォーマット；通常はフルワード）の場合に、’Ｆ’である。
コードは、固定小数点型（計算機フォーマット：符号付き固定小数点２進フォーマット；通常はダブルワード）の場合に、’ＦＤ’である。
コードは、固定小数点型（計算機フォーマット：符号付き固定小数点２進フォーマット；通常はハーフワード）の場合に、’Ｈ’である。
例：
L 3,FCON
FCON DC F'100'
HLASMSimpleTypeから派生する
プライベート属性：
exponent : int
exponent修飾子は、固定小数点定数（Ｈ、Ｆ）の公称値が、内部２進数表現に変換される前に乗算される１０のべきを指定する。
exponent修飾子は、Ｅｎとして記述され、このｎは、１０進自己定義項目または括弧で囲まれた絶対式のいずれかである。この１０進自己定義項目または式の前に、符号を置くことができ、符号がない場合には、プラスの符号が仮定される。exponent修飾子の範囲は、−８５から＋７５まである。浮動小数点定数を定義するために型拡張を使用する場合には、exponent修飾子を、−２３１から２３１−１までの範囲内とすることができる。公称値を正確に表現することができない場合には、警告メッセージが発行される。
scale : int
scale修飾子は、固定小数点定数（Ｈ、Ｆ）の２進数についてユーザが望む内部スケーリングの量すなわち、固定小数点定数の公称値が２進表現に変換される前で、最終的なスケーリングされた形に組み立てられる前に、固定小数点定数に乗算しなければならない２のべきを指定する。スケーリングによって、２進小数点が、右端のビット位置の右にある仮定される固定された位置から移動される。
定数のそれぞれの型の範囲は：
固定小数点定数Ｈ
−１８７から１５まで
固定小数点定数Ｆ
−１８７から３０まで
scale修飾子は、Ｓｎとして記述され、このｎは、１０進自己定義項目または括弧で囲まれた絶対式のいずれかである。
この修飾子の値ｎの両方の形の前に符号を置くことができ、符号が存在しない場合には、プラスの符号が仮定される。
注：
１．scale修飾子は、正の値を有する時に、２進数の小数部分が占める２進位置の数を示す。
２．scale修飾子は、負の値を有する時に、２進数の整数部分から削除される２進位置の数を示す。
３．スケーリングのゆえに（またはスケーリングが行われないので）下位の桁が失われる時に、失われる位置の左端のビットで丸めが行われる。丸めは、保存される右端の位置に反映される。
【０２５４】
HLASMFloatingPoint
HLASMFloatingPoint型は、浮動小数点命令によって使用される。
コードは、浮動小数点型（計算機フォーマット：short浮動小数点フォーマット：通常はフルワード）の場合に、’Ｅ’である。
コードは、浮動小数点型（計算機フォーマット：long浮動小数点フォーマット：通常はダブルワード）の場合に、’Ｄ’である。
コードは、浮動小数点型（計算機フォーマット：extended浮動小数点フォーマット：通常は複数のダブルワード）の場合に、’Ｌ’である。
例：
LE 2,ECON
ECONDC E'100.50'
HLASMSimpleTypeから派生する
プライベート属性：
exponent : int
exponent修飾子は、浮動小数点定数（Ｅ、Ｄ、およびＬ）の公称値が、内部２進数表現に変換される前に乗算される１０のべきを指定する。
exponent修飾子は、Ｅｎとして記述され、このｎは、１０進自己定義項目または括弧で囲まれた絶対式のいずれかである。
この１０進自己定義項目または式の前に、符号を置くことができ、符号がない場合には、プラスの符号が仮定される。exponent修飾子の範囲は、−８５から＋７５まである。浮動小数点定数を定義するために型拡張を使用する場合には、exponent修飾子を、−２３１から２３１−１までの範囲内とすることができる。公称値を正確に表現することができない場合には、警告メッセージが発行される。
round : HLASMFloatingPointRoundType
この要素の浮動小数点丸めタイプを指定する。
scale : int
scale修飾子は、浮動小数点定数（Ｅ、Ｄ、およびＬ）の１６進数についてユーザが望む内部スケーリングの量すなわち、浮動小数点定数の公称値が２進表現に変換される前で、最終的なスケーリングされた形に組み立てられる前に、浮動小数点定数に乗算しなければならない２のべきを指定する。スケーリングによって、２進小数点が、右端のビット位置の右にある仮定される固定された位置から移動される。
定数のそれぞれ型の範囲は：
浮動小数点定数Ｅ
０から５まで
浮動小数点定数Ｄ
０から１３まで
浮動小数点定数Ｌ
０から２７まで
scale修飾子は、Ｓｎとして記述され、このｎは、１０進自己定義項目または括弧で囲まれた絶対式のいずれかである。
この修飾子の値ｎの両方の形の前に符号を置くことができ、符号が存在しない場合には、プラスの符号が仮定される。
１６進浮動小数点定数のscale修飾子：１６進浮動小数点定数のscale修飾子は、正の値を有しなければならない。このscale修飾子は、浮動小数点定数の２進表現の小数部分を右にシフトする、１６進位置の数を指定する。１６進小数点は、小数フィールド内の左端の位置の左に固定されるものと仮定される。スケーリングを指定する時には、正規化されない１６進小数が組み立てられることになる（正規化されないとは、小数の左端の位置に１６進数の０が含まれることを意味する）。定数の指数部の指数が、それ相応に上に調整されるので、定数の大きさが保存される。非０の１６進数位置が失われる時に、失われる部分の左端の１６進数位置で丸めが行われる。丸めは、保存される右端の位置に反映される。
type : HLASMFloatingPointType
この要素の浮動小数点型を指定する。
【０２５５】
HLASMＨexadecimal
HLASMＨexadecimalでは、大きいビット・パターンを定義する。
コードは、１６進数型（計算機フォーマット：１６進数ごとに４ビット・コード）の場合に、’Ｘ’である。
例：
PATTERN DC X'FF00FF00'
HLASMSimpleTypeから派生する
【０２５６】
HLASMClassifier
HLASMClassifierは、HLASMComposedTypeおよびHLASMSimpleTypeの抽象親クラスである。
TDLangClassifierから派生する
【０２５７】
HLASMElement
HLASMElementは、HLASMプログラムのすべてのＤＣ命令を表す。
たとえば：
CHAR DCC'string of characters'
PCON DCP'100'
PATTERN DC X'FF00FF00'
CHAR、PCON、およびＰＡＴＴＥＲＮのすべてが、ＤＣ命令である
TDLangElementから派生する
【０２５８】
HLASMSimpleType
HLASMSimpleTypeは、HLASM言語のすべての単純型によって共用される属性を含む抽象クラスである。
HLASMClassifierから派生する
プライベート属性：
length : int
length修飾子は、定数がその中に組み立てられるストレージのバイト数を示す。これは、Ｌｎとして記述され、このｎは、１０進自己定義項目または括弧で囲まれた絶対式のいずれかである。これは、正の値を有しなければならない。
length修飾子が指定される時には：
その値によって、定数に割り振られるストレージのバイト数が決定される。したがって、length修飾子によって、割り振られる空間におさまるように、定数の公称値を埋め込むか切り捨てる必要があるかどうかが決定される。
定数の型に従う境界位置合わせは、行われない。
その値は、定義される定数のさまざまな型について許容される最大長さを超えてはならない。
length修飾子が、Ｃ型定数でダブルバイト・データを切り捨ててはならない。
length修飾子は、Ｇ型またはＣＵ型の定数では２の倍数でなければならない。
文字定数（Ｃ）、グラフィック定数（Ｇ）、１６進定数（Ｘ）、２進定数（Ｂ）、および１０進定数（ＰおよびＺ）について長さが指定されない時に、定数全体が、その暗黙の長さに組み立てられる。
size : HLASMSizeType
この要素の境界位置合わせを指定する。
【０２５９】
HLASMComposedType
HLASMComposedTypeクラスは、追加の要素を含む入れ子になった宣言を表す。HLASMComposedTypeは、HLASMElementの集約である。HLASMComposedTypeは、HLASMUnionの親である。
HLASMClassifier、TDLangComposedTypeから派生する
プライベート属性：
union : boolean
要素が共用体であるか否かを指定する。
共用体の場合に真。
そうでない場合に偽。
【０２６０】
HLASMArray
HLASMArrayは、配列命令に関する情報を保持する。
プライベート属性：
size : int
ｓｉｚｅは、メモリ内で割り振られる配列の１次元サイズを表す。
【０２６１】
HLASMElementInitialValue
このクラスには、HLASMElementの初期値が含まれる。
TDLangElementから派生する
プライベート属性：
initVal : String
要素の初期値を指定する。例：’MIN’、’MAX’など
【０２６２】
HLASMSourceText
このクラスには、ソース・コード全体（コメントを含む）およびそれに関連する行番号が含まれる。
パブリック属性：
source : String
ソース・ファイル・ストリングを指定する。
fileName : String
ソース・ファイルのパスを指定する。
【０２６３】
総計：
１論理パッケージ
１４クラス
論理パッケージ構造
論理ビュー
TDLang
hlasm
【０２６４】
６．アプリケーションドメイン・インターフェース・メタモデル
６．ａ．ＩＭＳトランザクション・メッセージ・メタモデル
ＩＭＳトランザクション・メッセージ・メタモデルは、図３１に示されているように（図３１に、３種類のトランザクション・メッセージすなわち、プレフィックス付きのＩＭＳ−ＯＴＭＡメッセージ、デフォルトＯＴＭＡプレフィックスをＩＭＳが構築することができるプレフィックスなしのＩＭＳメッセージ、およびアプリケーション・プログラムに直接に送ることができるＩＭＳ基本メッセージを含む、ＩＭＳトランザクション・メッセージのメタモデルを示す）３種類のＩＭＳトランザクション・メッセージすなわち：
＊プレフィックス付きのＩＭＳ−ＯＴＭＡメッセージ
＊デフォルトＯＴＭＡプレフィックスをＩＭＳが構築することができるプレフィックスなしのＩＭＳメッセージ
＊アプリケーション・プログラムに直接に送ることができるＩＭＳ基本メッセージ
を含む。
【０２６５】
６．ａ．ｉ．ＩＭＳ ＯＴＭＡプレフィックス
ＩＭＳ ＯＴＭＡメッセージ・プレフィックスは、下記のコンポーネントから構成される。図３２に、ＯＴＭＡプレフィックス・メタデータ・モデルを示す。図３３に、制御データ定義データ型のＯＴＭＡプレフィックスを示す。図３４に、状態定義データ型のＯＴＭＡプレフィックスを示す。図３５に、セキュリティ定義型のＯＴＭＡプレフィックスを示す。図３６に、ＩＭＳメタモデルのＩＭＳメッセージ・プリミティブを示す。
＊制御データ：このセクションには、トランザクションパイプ名、メッセージ・タイプ、シーケンス番号、フラグ、およびインジケータが含まれる。
＊状態データ：このセクションには、宛先オーバーライド、マップ名、同期レベル、コミット・モード、トークン、およびサーバ状態が含まれる。
＊セキュリティ・データ：このセクションには、ユーザＩＤ、ユーザ・トークン、およびセキュリティ・フラグが含まれる。
＊ユーザ・データ：このセクションには、クライアントが必要とする特殊な情報のすべてが含まれる。
【０２６６】
ＯＴＭＡプレフィックス・メタモデルは、下記の特徴を有する。
１）OTMA Prefix − 制御データ定義型
２）OTMA Prefix − 状態データ定義型
３）OTMA Prefix − セキュリティ・データ定義型
【０２６７】
６．ａ．ｉｉ．ＩＭＳメッセージ・プリミティブ型
６．ａ．ｉ．ａ）．IMSTransactionMessageメタモデル仕様
IMSTransactionMessageメタモデルには、下記のＩＭＳメッセージ・シナリオが含まれる：
・プレフィックス付きのＩＭＳ ＯＴＭＡメッセージ
・プレフィックスなしのＩＭＳ ＯＴＭＡメッセージ
・アプリケーション・プログラムに直接に送られるＩＭＳ基本メッセージ。
プライベート属性：
OTMAPrefixFormat : OTMAPrefixFormats = one
StandardFieldsFlag : boolean
【０２６８】
OTMAPrefixFormatｓ
プライベート属性：
one :
two :
【０２６９】
StandardFieldｓ
StandardFieldｓ（ＬＬ、ＺＺ、およびトランザクション・コードを含む）は、下記のシナリオには含まれない。
・ＩＭＳトランザクション・アプリケーション・プログラムへのＸＭＬ文書の直接送信
・ＩＭＳアプリケーションへのＡＣＫメッセージまたはＮＡＫメッセージ
プライベート属性：
Length : TwoByteField
ＬＬとも称する。
ReservedField : TwoByteField
ＺＺとも称する。
TransactionCode : VariableLengthField
TransactionCodeフィールドは、１バイトから８バイトまでの長さとすることができる。
TransactionCodeは、入力メッセーの最初のセグメントだけに現れる。
TransactionCodeは、LLZZの後に来る。
【０２７０】
OTMAPrefix
ＩＭＳ ＯＴＭＡプレフィックスは、すべてのメッセージ・セグメントの前、またはメッセージの最初のセグメントの前だけのいずれかに現れることができる。しかし、ＯＴＭＡプレフィックスは、任意選択である。これが指定されない場合には、ＩＭＳゲートウェイが、要求のデフォルトのプレフィックスを構築する。
【０２７１】
ControlData
制御データは、メッセージ制御情報である。これには、トランザクションパイプ名、メッセージ・タイプ、シーケンス番号、フラグ、およびインジケータが含まれる。
プライベート属性：
ArchitectureLevel : OneByteField
ＯＴＭＡアーキテクチャ・レベルを指定する。クライアントが、アーキテクチャ・レベルを指定し、サーバは、それが使用しているアーキテクチャ・レベルを応答メッセージで示す。クライアントとサーバによって使用されるアーキテクチャ・レベルは、一致しなければならない。
ＩＭＳバージョン６では、有効な値はＸ’０１’だけである。
すべてのメッセージについて必須。
MessageType : TMessageType
メッセージ・タイプを指定する。すべてのＯＴＭＡメッセージで、メッセージ・タイプの値が指定されなければならない。値は、相互排他的ではない。たとえば、サーバが、クライアントがサブミットしたトランザクションに対するＡＣＫメッセージを送信する時に、トランザクション・フラグと応答フラグの両方がセットされる。
ResponseFlag : OneByteField
メッセージが応答メッセージであること、または応答が必要であることのいずれかを指定する。
トランザクションに対する肯定応答には、トランザクションで拡張応答要求が指定された場合に限って、メッセージ・プレフィックスのアプリケーションデータ・セクションに属性（そのトランザクションの）が含まれる。
CommitConfirmationFlag :TCommitConfirmationFlag
コミット要求の成功を指定する。コミット確認メッセージ内で、サーバによってクライアントに送信される。これらのメッセージは、送信後コミット（send-then-commit）トランザクションに関してのみ適用可能であり、メッセージ・プレフィックスの状態データ・セクションの同期レベル・フラグによって影響されない。
CommandType : TCommandType
ＯＴＭＡプロトコル・コマンド・タイプを指定する。
ＩＭＳ ＭＴＯコマンドは、メッセージのアプリケーションデータ・セクションで指定される。
ProcessingFlag : TProcessingFlag
クライアントまたはサーバがそれによってメッセージ処理を制御できるオプションを指定する。
TpipeName : EightByteField
トランザクションパイプ名を指定する。ＩＭＳの場合、この名前が、入出力ＰＣＢ上のLTERM名をオーバーライドするのに使用される。このフィールドは、すべてのトランザクション・メッセージ・タイプ、データ・メッセージ・タイプ、およびコミット確認メッセージ・タイプに適用可能である。このフィールドは、いくつかの応答メッセージ・タイプおよびコマンド・メッセージタイプにも適用可能である。
ChainFlag : TChainFlag
メッセージに含まれるセグメント数を指定する。このフラグは、トランザクション・メッセージ・タイプおよびデータ・メッセージ・タイプに適用可能であり、複数セグメント・メッセージに必須である。
PrefixFlag : TPrefixFlag
ＯＴＭＡメッセージに付加されるメッセージ・プレフィックスのセクションを指定する。すべてのメッセージが、メッセージ制御情報セクションを有しなければならないが、他のセクションの任意の組合せを、ＯＴＭＡメッセージと共に送信することができる。
SendSequenceNumber : FourByteField
トランザクション・パイプのシーケンス番号を指定する。このシーケンス番号は、メッセージまたはトランザクションを送信する時に、クライアントおよびサーバによって更新される。
推奨：トランザクション・パイプごとに別々に番号を増分されたい。
この番号は、ＡＣＫメッセージまたはＮＡＫメッセージを、肯定応答される指定されたメッセージと一致させるのにも使用することができる。
SenseCode : TwoByteField
ＮＡＫメッセージに付随するセンス・コードを指定する。
ReasonCode : TwoByteField
ＮＡＫメッセージに付随する理由コードを指定する。このコードが、さらに、センス・コードを修飾することができる。
RecoverableSequenceNumber : FourByteField
トランザクション・パイプの回復可能シーケンス番号を指定する。
同期化されるトランザクション・パイプを使用する回復可能メッセージの送信ごとに増分される。クライアントとサーバの両方が、回復可能シーケンス番号を増分し、送信シーケンス番号とは別に維持する。
SegmentSequenceNumber : TwoByteField
複数セグメント・メッセージのセグメントのシーケンス番号を指定する。
この番号は、セグメントごとに更新されなければならない。というのは、メッセージが、必ずしもＸＣＦによってシーケンシャルに送達されるのではないからである。
この番号は、メッセージが１つだけセグメントを有する場合に、０（ゼロ）の値を有しなければならない。
Reserved : TwoByteField
【０２７２】
DefinedTypes
TMessageType
プライベート属性：
Data : String
データ（値Ｘ’８０’）
クライアントに送信されるサーバ出力を指定する。クライアントが、メッセージ・プレフィックスの状態データ・セクションで同期レベルConfirmを指定する場合に、サーバも、応答フラグの応答要求をセットする。クライアントが同期レベルを指定しない場合には、サーバは、デフォルトのConfirmを使用する。
Transaction : String
トランザクション（値Ｘ’４０’）
サーバへの入力データを指定する。
Response : String
応答（値Ｘ’２０’）
メッセージが応答メッセージであることを指定し、このメッセージがそれに対する応答であるメッセージで応答フラグの応答要求が指定される場合に限ってセットされる。
このフラグがセットされる場合には、応答フラグでＡＣＫまたはＮＡＫのいずれかを指定する。
送信シーケンス番号が、元のデータ・メッセージおよび応答メッセージに関して一致しなければならない。サーバへのチェーン・トランザクション入力メッセージでは、必ず、次のトランザクション（特定のトランザクション・パイプに関する）が送信される前に、応答を要求しなければならない。
Command : String
コマンド（値Ｘ’１０’） ＯＴＭＡプロトコル・コマンドを指定する。ＯＴＭＡコマンドでは、必ず、応答フラグの応答要求を指定しなければならない。
CommitConfirmation : String
ＣｏｍｍｉｔConfirmation（値Ｘ’０８’） コミットが完了することを指定する。これは、同期点が完了した時にサーバによって送信され、送信後コミット・トランザクションについてのみ適用可能である。コミット確認フラグもセットされる。
【０２７３】
TResponseFlag
プライベート属性：
ACK : String
ＡＣＫ（値Ｘ’８０’） 肯定の応答を指定する。
NAK : String
ＮＡＫ（値Ｘ’４０’） 否定の応答を指定する。
ＮＡＫの理由に関する情報については、センス・コード・フィールドを参照されたい。
ResponseRequested : String
応答要求（値Ｘ’２０’） このメッセージに関して応答が要求されることを示す。これは、データ、トランザクション、またはコマンドのメッセージ・タイプについてセットすることができる。
送信後コミットＩＭＳコマンド出力を送信する時に、ＩＭＳは、同期レベルに無関係に、ＡＣＫを要求しない。
ExtendedResponseRequested : String
拡張要求応答（値Ｘ’１０’） このメッセージに関して拡張応答が要求されることを指定する。クライアントによって、トランザクションについてのみ（またはトランザクション・コードではなくＩＭＳコマンドを指定するトランザクションについて）セットすることができる。このフラグが、トランザクションについてセットされる場合に、ＩＭＳは、ＡＣＫメッセージのアプリケーションデータ・セクションで、そのトランザクションの設計済み属性を返す。このフラグが、コマンドについてセットされる場合に、ＩＭＳは、ＡＣＫメッセージのアプリケーションデータ・セクションで設計済み属性を返す。このフラグは、ＩＭＳコマンド／DISPLAY TRANSACTIONおよび／DISPLAY TRANSACTION ALLについてセットすることができる。
【０２７４】
TCommitConfirmationFlag
プライベート属性：
Committed : String
コミット済み（値Ｘ’８０’） サーバが成功裡にコミットしたことを指定する。
Aborted : String
打切り（値Ｘ’４０’） サーバがコミットを打ち切ったことを指定する。
【０２７５】
TCommandType
プライベート属性：
ClientBid : String
クライアント送信権要求（値Ｘ’０４’） クライアントがＯＴＭＡサーバに送信する最初のメッセージを指定する。このコマンドによって、メッセージ・プレフィックスのメッセージ制御情報セクションの応答要求フラグおよびセキュリティ・フラグもセットされる。適当な状態データ・フィールド（たとえばMember Name）もセットされなければならない。セキュリティデータ・プレフィックスでは、ＯＴＭＡサーバがＯＴＭＡクライアントとして働くためのクライアントの権限を検証できるように、Utokenフィールドを指定しなければならない。サーバは、クライアント送信権要求要求に応答することができるので、このメッセージは、クライアントがデータ・メッセージの受け入れを開始する準備ができるまで、送信してはならない。
ServerAvailable : String
サーバ使用可能（値Ｘ’０８’） サーバがクライアントに送信する最初のメッセージを指定する。これは、クライアントが接続される前に、サーバがＸＣＦグループに接続した時に送信される。クライアントは、サーバ使用可能メッセージに対して、クライアント送信権要求要求を用いて応答する。適当な状態データ・フィールド（たとえばMember Name）もセットされなければならない。クライアントは、初めて接続する場合に、サーバが接続した時にＸＣＦによって通知され、クライアント送信権要求要求を用いて処理を開始する。
CBresynch : String
CBresynch（値Ｘ’０Ｃ’） 再同期のためのクライアントによる要求を伴うクライアント送信権要求要求メッセージを指定する。このコマンドは、任意選択であり、サーバに、SRVresynchメッセージをクライアントに送信させる。CBresynchコマンドは、クライアントがＩＭＳとの再同期を試み、既存の同期化されたTpipesがそのクライアントのために存在する時に、クライアントがＯＴＭＡサーバに送信する最初のメッセージである。メッセージ・プレフィックス内のCBresynchメッセージ・インジケータ以外の、メッセージ・プレフィックスに必要な情報は、クライアント送信権要求要求コマンドと同一でなければならない。ＩＭＳが、クライアントに関するクライアント送信権要求要求を受信し、ＩＭＳが、既存の同期化されたTpipesを知っている場合に、ＩＭＳは、情報メッセージDFS2394IをＭＴＯに発行する。ＩＭＳは、すべての同期化されたTpipesについて、回復可能送信シーケンス番号または回復可能受信シーケンス番号を０（ゼロ）にリセットする。
SuspendProcessingForAllTpipes : String
すべてのTpipesに関する処理の延期（値Ｘ’１４’） サーバが、クライアントとのすべてのメッセージ・アクティビティを延期しようとしていることを指定する。すべての後続のデータ入力で、サーバからのＮＡＫメッセージが受信される。同様に、クライアントは、すべての後続のサーバ・メッセージに関してＮＡＫメッセージを送信しなければならない。クライアントは、特定のトランザクション・パイプに関して処理を延期することを望む場合には、ＯＴＭＡメッセージとして/STOPTPIPEコマンドをサブミットしなければならない。
ResumeProcessingForAllTpipes : String
すべてのTpipesに関する処理の再開（値Ｘ’１８’） サーバが、クライアントとのメッセージ・アクティビティを再開しようとしていることを指定する。クライアントは、停止された特定のトランザクション・パイプに関する処理を再開することを望む場合に、ＯＴＭＡメッセージとして/STARTTPIPEコマンドをサブミットしなければならない。
SuspendInputForTpipe : String
Tpipeの入力延期（値Ｘ’１Ｃ’） サーバが、過負荷であり、トランザクション・パイプに関する入力を一時的に延期しようとしていることを指定する。すべての後続のクライアント入力で、メッセージ・プレフィックスのメッセージ制御情報セクションで指定されたトランザクション・パイプに関するＮＡＫメッセージが受信される。このコマンドに関して、応答は不要である。この設計済みコマンドは、マスタ端末オペレータが/STOPTPIPEコマンドを入力した時にも、ＩＭＳによって送信される。
ResumeInputForTpipe : String
Tpipeの入力再開（値Ｘ’２０’） サーバが、前のTpipeの入力延期コマンドの後に、クライアント入力を再開する準備ができたことを指定する。このコマンドに関して、応答は不要である。このコマンドは、ＩＭＳマスタ端末オペレータが/STARTTPIPEコマンドを入力した時にも、ＩＭＳによって送信される。
SRVresynch : String
SRVresynch（値Ｘ’２Ｃ’） クライアントのCBresynchコマンドに対するサーバの応答を指定する。このコマンドでは、サーバ内の同期化されたトランザクション・パイプの状態（送信シーケンス番号および受信シーケンス番号）を指定する。このコマンドは、単一のメッセージ（単一または複数のセグメントを有する）として送信され、ＡＣＫが要求される。
REQresynch : String
REQresynch（値Ｘ’３０’） 特定のTpipeの送信シーケンス番号および受信シーケンス番号を指定する。REQresynchは、ＩＭＳからクライアントに送信される。
REPresynch : String
REPresynch（値Ｘ’３４’） Tpipeに関するクライアントの所望の状態情報を指定する。クライアントは、ＩＭＳから受信したREQresynchコマンドに応答して、ＩＭＳにREPresynchコマンドを送信する。
TBresynch : String
TBresynch（値Ｘ’３８’） クライアントが、ＩＭＳからREQresynchコマンドを受信する準備ができていることを指定する。
【０２７６】
TProcessingFlag
プライベート属性：
SynchronizedTpipe : String
同期化されたTpipe（値Ｘ’４０’） トランザクション・パイプが同期化されることを指定する。障害がある場合に、クライアントがトランザクション・パイプを再同期化できるようにする。コミット後送信トランザクションについてのみ有効。このフラグは、入力および出力のシーケンス番号がトランザクション・パイプに関して維持されるようにする。そのトランザクション・パイプを介して経路指定されるすべてのトランザクションが、矛盾がないように（オンまたはオフのいずれか）このフラグを指定しなければならない。
AsynchronousOutput: String
非同期出力（値Ｘ’２０’） サーバが、非送信請求待機出力をクライアントに送信しつつあることを指定する。これは、ＩＭＳが、代替ＰＣＢにメッセージを挿入する時に発生する可能性がある。いくつかのＩＭＳコマンドは、コミット後送信としてサブミットされる時に、ＩＭＳに、このフラグをセットされた出力をクライアントに送信させる場合がある。この場合に、ＯＴＭＡプレフィックスに、出力を元のコマンド・メッセージに相関させるのにクライアントが使用できる識別情報が含まれない。これらのコマンド出力データ・メッセージは、単に、トランザクションパイプ名を識別する。ＩＭＳは、トランザクションパイプ名だけを有する非送信請求エラー・メッセージを送信することもできる。
ErrorMessageFollows : String
エラー・メッセージが続く（値Ｘ’１０’） このメッセージにエラー・メッセージが続くことを指定する。このフラグは、サーバからのＮＡＫメッセージについてセットされる。その後、追加のエラー・メッセージが、クライアントに送信される。非同期出力フラグは、エラー・データ・メッセージではセットされない。というのは、この出力がＩＭＳアプリケーションによって生成されないからである。
【０２７７】
TChainFlag
プライベート属性：
FirstInChain : String
先頭チェーン（値Ｘ’８０’） 複数セグメント・メッセージを含むセグメントのチェーンの最初のセグメントを指定する。このメッセージの後続セグメントは、メッセージ・プレフィックスのメッセージ制御情報セクションだけを必要とする。他の適用可能なプレフィックス・セグメント（たとえば、トランザクション・メッセージ上でクライアントによって指定されるもの）は、最初のセグメントと共に送信されるだけである（先頭チェーン・フラグをセットされて）。ＯＴＭＡメッセージが、１つのセグメントだけを有する場合には、チェーン内での最後フラグもセットされなければならない。
MiddleInChain : String
中間チェーン（値Ｘ’４０’） 複数セグメント・メッセージを含むセグメントのチェーンの最初でも最後でもないセグメントを指定する。これらのセグメントは、メッセージ・プレフィックスのメッセージ制御情報セクションだけを必要とする。
制約：クライアント・トークンおよびサーバ・トークンが、メッセージ・プレフィックスの状態データ・セクションにあるので、これらを使用して、セグメント化されたメッセージを相関させ、組み合わせることはできない。トランザクションパイプ名および送信シーケンス番号を、この目的に使用することができる。これは、各セグメントのメッセージ・プレフィックスのメッセージ制御情報セクションにある。
LastInChain : String
チェーン内での最後（値Ｘ’２０’） 複数セグメント・メッセージの最後のセグメントを指定する。
DiscardChain : String
チェーン破棄（値Ｘ’１０’） 複数セグメント・メッセージのチェーン全体を破棄しなければならないことを指定する。チェーン内での最後フラグもセットしなければならない。
【０２７８】
TPrefixFlag
プライベート属性：
StateData : String
状態データ（値Ｘ’８０’） このメッセージに、メッセージ・プレフィックスの状態データ・セクションが含まれることを指定する。
SecurityData : String
セキュリティ（値Ｘ’４０’） このメッセージに、メッセージ・プレフィックスのセキュリティデータ・セクションが含まれることを指定する。
UserData : String
ユーザ・データ（値Ｘ’２０’） このメッセージに、メッセージ・プレフィックスのユーザデータ・セクションが含まれることを指定する。
ApplicationData : String
アプリケーション・データ（値Ｘ’１０’） このメッセージに、メッセージ・プレフィックスのアプリケーションデータ・セクションが含まれることを指定する。
【０２７９】
StateData
StateData
これには、宛先オーバーライド、マップ名、同期レベル、コミット・モード、トークン、およびサーバ状態が含まれる。これが、トランザクションに関する状態データであることに留意されたい。ＯＴＭＡは、サーバ使用可能コマンド、クライアント送信権要求コマンド、SRVresynchコマンド、REQresynchコマンド、REPresynchコマンドに関する状態データ・ヘッダもサポートする。しかし、これらのコマンドは、絶対にクライアント装置によって生成されず、したがって、コマンド・メッセージが、絶対にＩＭＳ接続インターフェースに入らず、したがって、これらをモデル化する必要はない。
プライベート属性：
Length : TwoByteField
ServerState : TServerState トランザクションが実行されているモードを指定する。
SynchronizationFlag : TSynchronizationFlag トランザクションのコミット・モードを指定する。このフラグによって、クライアントとサーバの間のデータの流れが制御され、同期化される。
SynchronizationLevel :TSynchronizationLevel トランザクション同期化レベルすなわち、クライアントとサーバのトランザクション・プログラム（たとえばＩＭＳアプリケーション・プログラム）がプログラム出力メッセージと対話する形を指定する。デフォルトはConfirmである。ＩＭＳは、コミット後送信出力をクライアントに送信する時に、必ず応答を要求する。
Reserved : OneByteField
MapName : EightByteField 出力データ・ストリーム（たとえば３２７０データ・ストリーム）をマッピングするのにサーバによって使用されるフォーマット設定マップを指定する。ＯＴＭＡは、ＭＦＳサポートを提供しないが、ユーザは、マップ名を指定して、出力データ・ストリームを定義することができる。名前は、入出力ＰＣＢ内に配置される８バイトＭＯＤ名である。ＩＭＳは、メッセージが挿入される時に、プレフィックス内のこのフィールドを、入出力ＰＣＢ内のマップ名に置換する。
マップ名は任意選択である。
ServerToken : SixteenByteField サーバ名を指定する。サーバ・トークンが、応答メッセージ（ＡＣＫまたはＮＡＫ）でクライアントによってサーバに返されなければならない。会話型トランザクションの場合には、サーバ・トークンが、後続の会話入力でもクライアントによって返されなければならない。
CorrelatorToken : SixteenByteField 入力を出力に相関させるクライアント・トークンを指定する。このトークンは、任意選択であり、サーバによって使用されることはない。
推奨：クライアントは、トランザクションの管理を助けるためにこのトークンを使用すべきである。
ContextID : SixteenByteField
SYNCLVL=02および保護会話と共に使用されるＲＲＳ／ＭＶＳトークンを指定する。
DestinationOverride : EightByteField ＩＭＳアプリケーション・プログラムの入出力ＰＣＢ内のLTERM名をオーバーライドするのに使用されるLTERM名を指定する。このオーバーライドは、クライアントが、入出力ＰＣＢ内のLTERM名をトランザクションパイプ名にオーバーライドしたくない場合に使用される。この任意選択のオーバーライドは、ブランクから開始される場合に、使用されない。
ServerUserDataLength : TwoByteField サーバ・ユーザ・データがある場合に、その長さを指定する。サーバ・ユーザ・データの最大長は、２５６バイトである。
ServerUserData : VariableLengthField サーバが必要とするデータを指定する。クライアントによってトランザクション・メッセージに含められる場合に、これは、出力データ・メッセージ内でサーバによって返される。
【０２８０】
DefinedTypes
TServerState
プライベート属性：
ConversationalState : String
会話状態（値Ｘ’８０’） 会話モード・トランザクションを指定する。サーバは、会話モード・トランザクションを処理する時に、この状態をセットする。この状態は、クライアントによって、後続ＩＭＳ会話データ・メッセージをＩＭＳに送信する時にもセットされる。
ResponseMode : String
応答モード（値Ｘ’４０’） 応答モード・トランザクションを指定する。応答モード・トランザクションを処理する時に、サーバによってセットされる。ＯＴＭＡはセッションまたは端末を使用しないので、この状態は、ＯＴＭＡサーバにとってほとんど意味がない。
【０２８１】
TSynchronizationFlag
プライベート属性：
CommitThenSend : String
コミット後送信（値Ｘ’４０’） コミット後送信トランザクションを指定する。サーバは、出力を送信する前にコミットする；たとえば、ＩＭＳが、ＩＭＳメッセージ・キューに出力を挿入する。
SendThenCommit : String
送信後コミット（値Ｘ’２０’） 送信後コミット・トランザクションを指定する。サーバは、出力をコミットする前にクライアントに送信する。
【０２８２】
TSynchronizationLevel
プライベート属性：
None : String
なし（値Ｘ’００’） 同期化が不要であることを指定する。サーバ・アプリケーション・プログラムは、クライアントに出力を送信する時に、ＡＣＫメッセージを要求しない。Noneは、送信後コミット・トランザクションに限って有効である。
Confirm : String
確認（値Ｘ’０１’） 同期化が必要であることを指定する。サーバは、メッセージ・プレフィックスのメッセージ制御情報セクションの応答フラグに応答要求をセットして出力を送信する。確認は、コミット後送信トランザクションまたは送信後コミット・トランザクションのいずれかに使用することができる。
SYNCPT : String
SYNCPT（値Ｘ’０２’） プログラムが、ＲＲＳ／ＭＶＳ回復プラットフォームの下での変換中に更新されるリソースに対する整合コミット処理に参加することを指定する。このレベルとの会話を、保護会話とも称する。
【０２８３】
SecurityData
SecurityData
これには、ユーザＩＤ、ユーザ・トークン、およびセキュリティ・フラグが含まれる。
セキュリティデータ・セクションは、すべてのトランザクションに必須であり、ＯＴＭＡコマンド・メッセージのために存在することができる。
プライベート属性：
Length : TwoByteField メッセージ・プレフィックスのセキュリティデータ・セクションの、長さフィールドを含む長さを指定する。
SecurityFlag : TSecurityFlag 実行されるセキュリティ検査のタイプを指定する。ユーザＩＤおよびパスワードが既に検証されていると仮定する。
LengthOfSecurityFields : OneByteField セキュリティ・データ・フィールドすなわちユーザＩＤ、プロファイル、およびUtokenの長さを指定する。この３つのフィールドは、任意の順序とすることができ、省略することができる。それぞれが、次の構造体を有する：Lengthフィールド、その後のFieldタイプ、およびその後のDataフィールド。ユーザＩＤまたはプロファイルの実際の長さは、各フィールドの長さについて指定された値未満になってはならない。長さは、０にすることができる。
tokenLength : OneByteField
ユーザ・トークンの長さを指定する。
長さには、長さフィールド自体は含まれない。
UtokenType : OneByteField このフィールドにユーザ・トークンが含まれることを指定する（値Ｘ’００’）。
Utoken : VariableLengthField ユーザ・トークンを指定する。ユーザＩＤおよびプロファイルが、ユーザ・トークンの作成に使用される。ユーザ・トークンは、ＩＭＳ依存領域に渡される。クライアントは、既にＲＡＣＦを呼び出している場合に、フィールド・タイプＸ’００’を有するUtokenを渡し、その結果、ＲＡＣＦがもう一度呼び出されないようにしなければならない。
１バイトから８０バイトまでの可変長。
UserIDLength : OneByteField ユーザＩＤの長さを指定する。長さには、長さフィールド自体は含まれない。
UserIDType : OneByteField このフィールドにユーザＩＤが含まれることを指定する（値Ｘ’０２’）。
UserID : VariableLengthField 実際のユーザＩＤを指定する。
１バイトから１０バイトまでの可変長。
ProfileLength : OneByteField プロファイルの長さを指定する。長さには、長さフィールド自体は含まれない。
ProfileType : OneByteField このフィールドにプロファイルが含まれることを指定する（値Ｘ’０３’）。
Profile : VariableLengthField システム許可機能（ＳＡＦ）プロファイルを指定する。ＲＡＣＦに関して、これはグループ名である。
１バイトから１０バイトまでの可変長。
【０２８４】
DefinedTypes
TSecurityFlag
プライベート属性：
NoSecurity : String
セキュリティなし（値Ｘ’Ｎ’） セキュリティ検査が行われないことを指定する。
Check : String
検査（値Ｘ’Ｃ’） トランザクションおよびコマンドのセキュリティ検査を実行しなければならないことを指定する。
Full : String
完全（値Ｘ’Ｆ’）
トランザクション、コマンド、およびＭＰＰ領域のセキュリティ検査を実行しなければならないことを指定する。
【０２８５】
UserData
UserData
これには、クライアントが必要とする特殊な情報のすべてが含まれる。
ユーザデータ・セクションは、可変長であり、メッセージ・プレフィックスのセキュリティデータ・セクションに続く。ユーザデータ・セクションには、どのようなデータでも含めることができる。
プライベート属性：
Length : TwoByteField
メッセージ・プレフィックスのユーザデータ・セクションの、長さフィールドを含む長さを指定する。ユーザ・データの最大長は、１０２４バイトである。
UserData : VariableLengthField
任意選択のユーザ・データを指定する。このデータは、クライアントによって管理され、ＤＦＳＹＤＲＵ０出口ルーチンを使用して作成し、更新することができる。サーバは、すべての出力メッセージの最初のセグメントとして、このセクションを無変更でクライアントに返す。
【０２８６】
Primitives
OneByteField
TwoByteField
FourByteField
EightByteField
SixteenByteField
SixByteField
VariableLengthField
【０２８７】
ApplicationData
ApplicationData
アプリケーション・データ・クラスには、ＬＬ、ＺＺ、およびトランザクション・コードを除くすべてのメッセージ・データが含まれる。
注：このモデルは、メッセージ・セグメントの概念を取り込まない。このモデルを使用する時には、使用しているシステムが、最大セグメント・サイズなどの制限を有するかどうかをユーザが憶えていなければならない。ＩＭＳコネクタ（ＯＴＭＡまたはＳＮＡを介する）は、「アプリケーション・データ」をＩＭＳメッセージ・セグメントに分解する機能をサポートしなければならない。たとえば、ユーザが、このＸＭＬメッセージをＩＭＳメッセージ・キューに直接に送信し、メッセージ・キューが３２ｋの制限を有する場合に、ユーザは、ＸＭＬメッセージをとり、３２ｋチャンクに分解しなければならない。ＩＭＳ上のアプリケーションは、３２ｋチャンクを１つずつ寄せ集めなければならない。ＸＭＬ文書を直接に受信するＩＭＳの新しいアプリケーションは、複数のセグメントでＸＭＬ文書を受信することができなければならない。ＡＣＫメッセージまたはＮＡＫメッセージに関して、メッセージに含まれるアプリケーション・データはない。
【０２８８】
Field
アプリケーション・データのコピーブック内で定義される各データ・フィールドは、データ型の型記述子に関連する。
【０２８９】
６．ｂ．ＣＩＣＳ ＢＭＳ（基本マッピング・サポート）メタモデル
図４０に、コネクタ・インターフェースを表すデータ構造体を定義するためにアプリケーション・プログラムによって使用可能なＢＭＳ言語メタモデルを示す。図４１、および図４２に、ＢＭＳメタモデルの属性、フィールド、属性値、およびマップを示す。
【０２９０】
BMSFieldAttributeｓ
プライベート属性：
justify : justifyValues
attrb : attrbValues
color : colorValue = "DEFAULT"
hiLight : hiLightValue = "OFF"
validn : validnValues
outline : outlineValues
sosi : yesno = "NO"
transp : yesno = "YES"
caSe : caseValue
ps : psValue = "BASE"
【０２９１】
BMSMap
ＤＦＨＭＤＩマクロによって実装される
MAPNAMEは、マップの名前であり、１つから７つまでの文字からなる。
COLUMNは、マップが配置される行内の桁を指定する、すなわち、左または右のマップ・マージンを確立する。
JUSTIFYは、マップおよびページのマージン選択および桁カウントが、ページの左側または右側のどちらから行われるかを制御する。指定されたマップ・マージンとページ・マージンの間の桁は、マップに含まれる行に関してそのページでの後続の使用に利用可能ではない。
NUMBERは、左または右のページ・マージンから、左または右のマップ・マージンが確立される桁である。
NEXTは、左または右のマップ・マージンが、現在の行の左または右からの次に使用可能な桁に配置されることを示す。
SAMEは、左または右のマップ・マージンが、COLUMN＝Numberを指定した最後に使用された非ヘッダ・マップまたは非トレーラ・マップと同一の桁で、このマクロと同一のJUSTIFYオペランドで確立されることを示す。入力動作に関して、マップは、JUSTIFY＝LEFTまたはJUSTIFY＝RIGHTのどちらが指定されたかに応じて、左端または右端に位置決めされる。
LINEは、マップのデータがフォーマットされるページの開始行を指定する。
NUMBERは、開始行番号を指定する、１から２４０までの範囲の値である。前のＢＭＳコマンドに応答してフォーマットされたデータを、行および列にマップする要求によって、現在のページが完了したかのように扱われる。新しいデータは、新しいページの要求された行および列でフォーマットされる。
NEXTは、データのフォーマットが、次に使用可能な完全に空の行で開始されることを指定する。LINE＝NEXTがＤＦＨＭＤＩマクロで指定される場合には、入力動作に関してそれが無視され、LINE＝１が仮定される。
SAMEは、データのフォーマットが、前のＢＭＳコマンドに使用されたものと同一の行で開始されることを指定する。COLUMN＝NEXTが指定された場合に、入力動作についてはこれが無視され、COLUMN＝１が仮定される。データが同一行におさまらない場合には、そのデータは、完全に空の次に使用可能な行に配置される。
SIZE（arg1，arg2）は、マップのサイズを指定する。arg2=lineは、１から２４０までの範囲の値であり、行数としてマップの奥行きを指定する。arg1＝columnは、１から２４０までの範囲の値であり、桁数としてマップの幅を指定する。
このオペランドは、次の場合に必要である：
ＰＯＳオペランドに関連するＤＦＨＭＤＦマクロが使用される。
マップが、ＡＣＣＵＭオプション付きのSEND MAPコマンドで参照される。
マップが、３２７０端末以外からの入力データをRECEIVE MAPコマンドで参照する時に使用される。
ＳＯＳＩから、フィールドにＥＢＣＤＩＣデータとＤＢＣＳデータの混合が含まれる可能性があることが示される。ＥＢＣＤＩＣフィールド内のＤＢＣＳサブフィールドは、ＳＯ（シフト・アウト）文字およびＳＩ（シフト・イン）文字によって区切られる。ＳＯとＳＩの両方が、単一の画面位置を占める（通常はブランクとして表示される）。これらは、正しく対にされる場合に、出力の非ＤＢＣＳフィールドに含めることができる。端末ユーザは、これらがフィールドに既に存在する場合に、これらをインバウンドに送信できるが、これらをＥＢＣＤＩＣフィールドに追加できるのは、そのフィールドがＳＯＳＩ属性を有する場合に限られる。
ＴＩＯＡＰＦＸは、ＢＭＳが、未使用のＴＩＯＡプレフィックスを可能にするために記号記述マップに充てん文字を含めなければならないことを指定する。このオペランドは、ＤＦＨＭＳＤマクロについて指定されたＴＩＯＡＰＦＸオペランドをオーバーライドする。
YESは、充てん文字が、記号記述マップに含まれなければならないことを指定する。TIOAPFX=YESが指定される場合には、マップセット内のすべてのマップが、充てん文字を有する。TIOAPFX=YESは、コマンドレベル・アプリケーション・プログラムに必ず使用されなければならない。
NOは、デフォルトであり、充てん文字が含まれないことを指定する。
BMSStatementから派生する
プライベート属性：
column : String
color : BMSColorType
control : BMSControlType
cursorLocation : boolean
data : BMSDataType
descriptionAttributes :BMSMapAttributesType
extendedAttributes :BMSExtendedAttributesType
fields : boolean
fieldSeparator : String
header : boolean
highlighting : BMSHighlightingType
justify : BMSJustifyType
line : String
mapAttributes : BMSMapAttributesType
outboardFormatting : boolean
outlining : BMSOutliningType
partition : String
programmedSymbol : String
shiftOutShiftIn : boolean
size : BMSSizeType
terminal : String
tioaPrefix : boolean
trailer : boolean
transparent : boolean
validation : BMSValidationType
【０２９２】
BMSMapset
ＤＦＨＭＳＤマクロによって実装される
このマクロのプログラミング属性
type=DSECT|MAP|FINAL。 必須、これは、ＢＭＳエンティティの２ビットを生成する。
mode=OUT|IN|INOUT。 OUTがデフォルトである。INOUTは、INおよびOUTの両方の処理を指す。INの場合に、Ｉがマップ名に付加され、OUTの場合に、Ｏがマップ名に付加される。
lang=ASM|COBOL|COBOL2|PLI|C。 ＡＳＭがデフォルトである。
fold=LOWER|UPPER。 LOWERがデフォルトである。Ｃだけに適用される。
dsect=ADS|ADSL。 ＡＤＳがデフォルトである。ＡＤＳＬはlang=Cを必要とする。
trigraph=YES lang=Cだけに適用される。
BASEは、同一のストレージ・ベースが、複数のマップセットからの記号記述マップに使用されることを指定する。同一の名前が、同一のストレージ・ベースを共用するマップセットごとに指定される。
同一のベースを有するすべてのマップセットが、同一のストレージを記述するので、前に使用されたマップセットに関連するデータは、新しいマップセットが使用される時に上書きされる可能性がある。同一のマップセット内の異なるマップも、互いにオーバーレイする。
このオペランドは、アセンブラ言語プログラムには有効でなく、STORAGE=AUTOが指定された時に使用することはできない。
term=type 各端末タイプが、１文字によって表される。３２７０は、デフォルトであり、ブランクである。MAPSET名に追加されるか、suffix＝Numcharであり、これが、やはりマップセット名に追加される。
ＣＵＲＳＬＯＣは、３２７０端末上でこのマップを使用するすべてのRECEIVEMAP動作について、ＢＭＳが、カーソルが位置するフィールドのアプリケーション・データ構造体要素内のフラグをセットすることを示す。
STORAGE
このオペランドの意味は、下記のように、アプリケーション・プログラムが記述された言語に依存する：
COBOLプログラムの場合に、STORAGE=AUTOは、マップセット内の記号記述マップが、ストレージの別々の（すなわち、再定義されない）区域を占めることを指定する。このオペランドは、記号記述マップが、作業記憶セクションにコピーされ、マップセット内の別々のマップのストレージが、並列に使用される時に使用される。
Ｃプログラムの場合に、STORAGE=AUTOは、記号記述マップが、自動ストレージ・クラスを有するものとして定義されることを指定する。STORAGE=AUTOが指定されない場合には、記号記述マップが、ポインタとして宣言される。同一のマップセットについてBASE＝nameとSTORAGE=AUTOの両方を指定することはできない。
STORAGE=AUTOが指定され、ＴＩＯＡＰＦＸが指定されない場合には、TIOAPFX=YESが仮定される。
ＰＬ／Ｉプログラムの場合に、STORAGE=AUTOは、記号記述マップが、AUTOMATICストレージ・クラスを有するものとして宣言されることを指定する。STORAGE=AUTOが指定されない場合には、記号記述マップが、BASEDとして宣言される。同一のマップセットについてBASE＝nameとSTORAGE=AUTOの両方を指定することはできない。STORAGE=AUTOが指定され、ＴＩＯＡＰＦＸが指定されない場合には、TIOAPFX=YESが仮定される。
アセンブラ言語プログラムの場合に、STORAGE=AUTOは、マップセット内の個々のマップが、互いにオーバーレイするのではなく、ストレージの別々の区域を占めることを指定する。
BMSStatementから派生する
プライベート属性：
base : String
color : BMSColorType
control : BMSControlType
cursorLocation : boolean
data : BMSDataType
descriptionAttributes :BMSMapAttributesType
extendedAttributes :BMSExtendedAttributesType
fieldSeparator : String
fold : BMSFoldType
highlighting : BMSHighlightingType
horizontalTabs : int
language : BMSLanguageType
logicalDeviceCode : int
mapAttributes : BMSMapAttributesType
mode : BMSModeType
outboardFormatting : boolean
outlining : BMSOutliningType
partition : String
programmedSymbol : String
shiftOutShiftIn : boolean
storage : boolean
suffix : String
terminal : String
tioaPrefix : boolean
transparent : boolean
trigraph : boolean
type : BMSMapsetType
validation : BMSValidationType
verticalTabs : int
【０２９３】
BMSField
ＤＦＨＭＤＦマクロによって実装される。
GRPNAMEは、記号ストレージ定義を生成し、１つのグループ名の下で特定のフィールドを組み合わせるのに使用される名前である。同一のグループ名が、グループに属するフィールドごとに指定されなければならない。名前の長さは、３０文字までであるが、コンパイラ・マニュアルを参照して、長さに対する他の制約がないことを確認されたい。
このオペランドが指定される場合には、OCCURSオペランドを指定することはできない。
グループ内のフィールドは、連続しなければならない。グループ内のフィールドの間に、ギャップを置くことはできるが、グループの外からの他のフィールドは置けない。フィールド名は、グループに属するすべてのフィールドについて指定されなければならず、フィールドが互いに続くことを保証するために、ＰＯＳオペランドも指定されなければならない。グループのフィールドを定義するＤＦＨＭＤＦマクロのすべてが、一緒に配置されなければならず、正しい順序（ＰＯＳ値の数字の昇順）でなければならない。
たとえば、マップの最初の６行の最初の２０桁を、最初の５行の残りの桁がフィールドして定義されない限り、６フィールドのグループとして定義することができる。
グループの最初のフィールドに対して指定されるＡＴＴＲＢオペランドは、グループ内のすべてのフィールドに適用される。
LENGTHは、フィールドまたはフィールドのグループの長さ（１から２５６バイト）を指定する。この長さは、フィールドに入力されるアプリケーション・プログラム・データに必要な最大長さでなければならず、後続処理での使用のためにＣＩＣＳによってフィールドに付加される１バイト属性インジケータを含んではならない。１グループ内の各個々のサブフィールドの長さが、２５６バイトを超えてはならない。PICINまたはPICOUTが指定される場合には、LENGTHを省略することができるが、それ以外の場合にはLENGTHが必要である。ＤＦＨＭＤＦマクロでラベル（フィールド名）を省略する場合に限って、０の長さを指定することができる。すなわち、フィールドは、アプリケーション・データ構造体の一部ではなく、アプリケーション・プログラムが、フィールドの属性を変更することはできない。０の長さのフィールドを使用して、マップの入力フィールドを区切ることができる。
マップを定義するＤＦＨＭＤＩマクロのSIZEオペランドで指定されるマップ寸法は、端末に関して定義される実際のページ・サイズまたは画面サイズより小さいものにすることができる。
ＤＦＨＭＤＦマクロのLENGTH指定によって、同一行のマップによって定義される境界を超える場合には、出力画面のフィールドは、ラップによって継続される。
OCCURSは、フィールドの示された数の項目が、マップ内で生成されることと、フィールドが行列または配列の項目としてアドレス可能な形でマップ定義が生成されることを指定する。これによって、フィールドごとに一意の名前を生成せずに、複数のデータ・フィールドを同一の名前（添字付き）によってアドレッシングできるようになる。
OCCURSとGRPNAMEは、相互に排他的である、すなわち、OCCURSは、フィールドがグループ名の下で定義された時には使用することができない。このオペランドが省略される場合には、OCCURS＝１の値が仮定される。
PICIN（COBOLおよびＰＬ／Ｉのみ）は、ＩＮマップまたはINOUTマップの入力フィールドに適用されるピクチャを指定する。このピクチャは、アプリケーション・プログラムに渡される編集指定として働き、したがって、ユーザがCOBOLまたはＰＬ／Ｉの編集機能を利用できるようになる。ＢＭＳは、指定された文字がマップの言語の有効なピクチャ指定であることを検査する。
しかし、入力データの有効性は、マップが使用される時には、ＢＭＳまたは高水準言語によって検査されず、したがって、所望の検査のすべてを、アプリケーション・プログラムが実行しなければならない。「値」に関連するデータの長さは、LENGTHが指定される場合に、LENGTHオペランドで指定されるものと同一でなければならない。PICINとPICOUTの両方が使用される場合には、その計算された長さが一致しない場合に、エラー・メッセージが作られ、２つの長さの短い方が使用される。フィールド定義についてPICINまたはPICOUTがコード化されない場合には、ATTRB=NUMなど、コード化される他のオペランドに無関係に、フィールドの文字定義が自動的に生成される。
注：COBOL入力マップの有効なピクチャ値は次の通りである：
A P S V X 9 / および (
ＰＬ／Ｉ入力マップの有効なピクチャ値は次の通りである：
A B E F G H I K M P R S T V X Y および Z
1 2 3 6 7 8 9 / + - , . * $ および (
ＰＬ／Ｉの場合に、通貨記号をピクチャ文字として使用することができる。この記号は、たとえば＜ＤＭ＞など、＜と＞に囲まれた文字の任意のシーケンスとすることができる。
PICTURE属性の正しい構文については、適当な言語リファレンス・マニュアルを参照されたい。
PICOUT（COBOLおよびＰＬ／Ｉのみ）は、OUTマップまたはINOUTマップ内の出力フィールドに適用されるピクチャが生成されることを除いて、PICINに類似する。
COBOL出力マップの有効なピクチャ値は次の通りである：
A B E P S V X Z 0 9 , . + - $ CR DB / および (
ＰＬ／Ｉ出力マップの有効なピクチャ値は次の通りである：
A B E F G H I K M P R S T V X Y および Z
1 2 3 6 7 8 9 / + - , . * $ CR DB および (
ＰＬ／Ｉの場合、通貨記号をピクチャ文字として使用することができる。この記号は、たとえば＜ＤＭ＞など、＜と＞に囲まれた文字の任意のシーケンスとすることができる。
PICTURE属性の正しい構文については、適当な言語リファレンス・マニュアルを参照されたい。
注：COBOLは、PICTURE指定で、複数の通貨符号および複数文字の通貨符号をサポートする。
デフォルト通貨記号は、ドル記号（＄）であり、これは国の通貨記号を表す；たとえば、ドル（＄）、ポンド（£）、または円（￥）。
デフォルトの通貨ピクチャ記号を、SPECIAL NAMES文節で定義された異なる通貨ピクチャ記号に置換することができる。ピクチャ記号によって表される通貨符号は、同一の文節で定義される。たとえば：
SPECIAL NAMES.
CURRENCY SIGN IS '$' WITH PICTURE SYMBOL '$'.
CURRENCY SIGN IS '<pond>' WITH PICTURE SYMBOL '<pond>'.
CURRENCY SIGN IS 'EUR' WITH PICTURE SYMBOL '#'.
WORKING STORAGE SECTION.
01 USPRICE PIC $99.99.
01 UKPRICE PIC £99.99.
01 ECPRICE PIC #99.99.
１を超える長さの通貨符号に置換される、通貨記号を含むCOBOLピクチャがPICOUTで指定される場合に、LENGTHを指定しなければならない。
ＰＯＳは、フィールドの位置を指定する。このオペランドは、フィールドに先行する属性バイトが位置決めされる、マップ内の個々のアドレス可能文字位置を指定する。
Numberは、定義されるマップの先頭からの変位（０に対する相対変位）を指定する。
（line、column）は、定義されるマップ内の行および桁（０に対する相対値）を指定する。
出力媒体上のデータの位置も、ＤＦＨＭＤＩオペランドに依存する。
フィールドの最初の位置は、属性バイトのために予約される。非３２７０装置からの入力マッピングについてデータを供給する時に、入力データは、この属性バイトのスペースを許容しなければならない。入力データは、桁１から開始してはならず、桁２から開始することができる。
ＰＯＳオペランドには、フィールド内の最初の位置の場所が含まれ、これは、通常は、３２７０と通信する時には属性バイトである。グループの２番目以降のフィールドでは、ＰＯＳオペランドが、実際の属性バイトが必要でない場合であっても、データの先頭の前の、仮定される属性バイト位置を指す。フィールドが、互いに直接に連続する場合には、ＰＯＳオペランドは、グループ内の前のフィールドの最後の文字位置を指さなければならない。
３２７０の最後の文字位置を表す位置番号が指定される時には、２つの特別な規則が適用される：
ATTRIB=ICをコード化してはならない。カーソルは、SEND MAPコマンド、SENDCONTROLコマンド、またはSEND TEXTコマンドのCURSORオプションを使用することによって、位置０にセットすることができる。
フィールドが、SEND MAPコマンドのMAP=DATAONLYを伴う出力マッピング動作に使用される場合には、そのフィールドの属性バイトが、アプリケーション・プログラムによって記号マップ・データ構造体で供給されなければならない。
ＰＳは、プログラム式記号が使用されることを指定する。これは、ＤＦＨＭＤＩマクロまたはＤＦＨＭＳＤマクロによってセットされるＰＳオペランドのすべてをオーバーライドする。
BASEは、デフォルトであり、基本記号セットが使用されることを指定する。
psidは、使用されるプログラム式記号セットを識別する、単一のＥＢＣＤＩＣ文字、またはＸ’ｎｎ’の形の１６進コードを指定する。
ＰＳオペランドは、端末がプログラム式記号をサポートしない限り無視される。
ＳＯＳＩは、フィールドにＥＢＣＤＩＣデータとＤＢＣＳデータの混合が含まれる可能性があることを示す。ＥＢＣＤＩＣフィールド内のＤＢＣＳサブフィールドは、ＳＯ（シフト・アウト）文字およびＳＩ（シフト・イン）文字によって区切られる。ＳＯとＳＩの両方が、単一の画面位置を占める（通常はブランクとして表示される）。これらは、正しく対にされる場合に、出力の非ＤＢＣＳフィールドに含めることができる。端末ユーザは、これらがフィールドに既に存在する場合に、これらをインバウンドに送信できるが、これらをＥＢＣＤＩＣフィールドに追加できるのは、そのフィールドがＳＯＳＩ属性を有する場合に限られる。
ＴＲＡＮＳＰは、英数字フィールドの背景が透明または不透明のどちらであるか、すなわち、下にある（グラフィック）表示スペースが文字の間で可視であるかどうかを決定する。
BMSStatementから派生する
プライベート属性：
attributes : BMSAttributesType
case : boolean
color : BMSColorType
group : String
highlighting : BMSHighlightingType
initialValue : String
justify : BMSJustifyType
length : int
occurs : int
outlining : BMSOutliningType
pictureInput : String
pictureOutput : String
position : BMSPositionType
programmedSymbol : String
shiftOutShiftIn : String
transparent : boolean
validation : BMSValidationType
【０２９４】
BMSStatement
プライベート属性：
label : String
comments : String
【０２９５】
総計：
１論理パッケージ
４クラス
論理パッケージ構造
論理ビュー
bms
【０２９６】
６．ｃ．ＩＭＳ ＭＦＳ（メッセージ形式サービス）
図４３に、コネクタ・インターフェースを表すデータ構造体を定義するためにアプリケーション・プログラムによって使用可能なＭＦＳ言語メタモデルを示す。図４４に、ＭＦＳメタモデルのTDLangClassifier、TDLanguageComposedType、およびTDLanguageElementである、ＭＦＳメタモデルとTDLang基本クラスの間の関連を示す。図４５、および図４６に、ＭＦＳメタモデルのModeValues、BaseValues、LengthTypes、およびStringTypeValuesの列挙を示す。
【０２９７】
ＭＦＳのパッケージ文書化
下記の装置がサポートされる：
− ３２７０および３２７０−Ａｎ
− ３２７０Ｐ
下記の装置タイプはサポートされない：
− ２７４０または２７４１
− ３６００または４７００
− ＦＩＮ
− ＦＩＤＳ、ＦＩＤＳ３、ＦＩＤＳ４、またはＦＩＤＳ７
− ＦＩＪＰ、ＦＩＰＢ、またはＦＩＦＰ
− ＳＣＳ１
− ＳＣＳ２
− ＤＰＭ−Ａｎ
− ＤＰＭ−Ｂｎ
パーサを介して暗黙のうちにサポートされるステートメント：
− ALPHA
− COPY
− DO
− END
− ENDDO
− EQU
− FMTEND
− MSGEND
− RESCAN
− TABLEEND
許容されるステートメント：
− EJECT
− PD
− PDB
− PDBEND
− PPAGE
− PRINT
− RCD
− SPACE
− STACK
− TITLE
− UNSTACK
−
【０２９８】
MFSDeviceType
ＤＥＶステートメント
ＤＥＶステートメントでは、特定の装置の装置特性または特定の装置タイプのデータ・フォーマットを定義する。このＤＥＶステートメントに続くＤＦＬＤステートメントは、次のＤＥＶステートメントまたはＦＭＴＥＮＤステートメントに出会うまで、指定された特性を使用してマッピングされる。
サポートされない属性：
− ERASE
− FTAB
− FORMS
− HT
− HTAB
− LDEL
− MODE
− SLD
− VERSID
− VT
− VTAB
MFSStatementから派生する
プライベート属性：
card : String
CARD属性
データが入力される時にオペレータＩＤカード・データを受け取る入力フィールド名を定義する。この名前は、ＭＦＬＤステートメントによって参照することができ、このＤＥＶ定義内のＤＦＬＤステートメントのラベルとして使用してはならない。このオペランドは、３２７０ディスプレイが指定される場合に限って有効である。３２７０ディスプレイについてFEAT=NOCDが指定される場合には、FEATがCARDに変更される。このカード・フィールド名を参照する入力ＭＦＬＤにデータが提示される前に、すべての制御文字が磁気カード入力から除去される。
３２７０ディスプレイについて、磁気カード・データおよび制御文字を含むのに十分に大きい無保護フィールドが、ＤＦＬＤステートメントを介して定義されなければならない。カーソルをこのフィールドに位置決めし、カードをリーダに挿入して、カード情報を入力する。カード・データは、ＤＦＬＤステートメントで使用される名前ではなく、CARD＝フィールド名に論理的に関連付けられる。
dsca : String
ＤＳＣＡ属性
この装置フォーマットを使用する出力メッセージのデフォルト・システム制御域（ＤＳＣＡ）を指定する。ＤＳＣＡは、メッセージ出力記述子で指定されたＳＣＡと衝突する場合に、そのようなＳＣＡを取り替える。通常、両方のＳＣＡで指定された機能が実行される。ＤＳＣＡ＝のオペランドが３２７０Ｐについて指定される場合には、「音響装置警告」のビット設定を除いて、そのオペランドが無視される。このビットがＤＳＣＡ／ＳＣＡオプションで指定される場合には、そのビットが装置に送られる。
ここで指定される値は、６５５３５またはＸ’ｆｆｆｆ’を超えない１０進数でなければならない。その数が指定される場合には、その数は、内部でＸ’ｆｆｆｆ’に変換される。
３２７５ディスプレイに関して、バイト１のビット５にＢ’１’（無保護画面オプション）がセットされ、入力および出力の両方が、同時に発生する場合（競合）には、装置が切断される。非３２７５装置では、ＳＣＡオプションが無視される。バイト１のビット５にＢ’０’がセットされる場合には、アプリケーション・プログラムが、ＳＣＡ値にＢ’１’をセットすることによって、自動ページングされた出力を要求することができる。この要求は、出力メッセージの最初のLPAGEの最初のセグメントに存在する場合に限って順守される。
バイト０について、またはバイト１のビット６または７について、ゼロ以外の値が指定される場合に、ＭＦＳは、指定された値を０でオーバーライドする。
features : MFSFeatureType
FEAT属性
この装置またはプログラム・グループの機能を指定する。
IGNORE
装置機能が、この装置について無視されることを指定する。
120|126|132
３２８４および３２８６装置タイプ（TYPE＝３２７０Ｐ）にいて行の長さを指定する。
CARD
装置が３２７０オペレータＩＤカード・リーダを有することを指定する。ＮＯＣＤは、CARD機能がないことを指定する。
DEKYBD
データ入力キーボード機能を指定する。この機能は、ＰＦＫ機能を暗示し、したがって、ＰＦＫは、ＤＥＫＹＢＤが指定される場合には無効である。ＮＯＰＦＫは、ＰＦＫ機能およびＤＥＫＹＢＤ機能の不在を暗示する。
PFK
装置がプログラム・ファンクション・キーを有することを指定する。ＮＯＰＦＫは、ＰＦＫ機能およびＤＥＫＹＢＤ機能の不在を暗示する。
PEN
選択ライト・ペン検出機能を指定する。ＮＯＰＥＮは、ＰＥＮ機能の不在を指定する。
1|2|3|4|5|6|7|8|9|10
３２７０Ｐ装置タイプの顧客定義機能を指定する。
３２７０Ｐ装置について、FEAT＝によって、特殊な装置特性を有する装置のグループ化が可能になる。たとえば、FEAT＝１によって、最大８０個の印刷位置を有しＶＦＣを有しない装置をグループ化することができ、FEAT＝２によって１３２個の印刷位置とＶＦＣ機能を備える装置をグループ化することができる。FEAT＝IGNOREは、装置機能の最小限の組を有する装置を一緒にグループ化するために指定されなければならない。WIDTH＝が指定される時には、FEAT＝（１…１０）も指定されなければならない。FEAT＝（１…１０）が指定され、WIDTH＝が指定されない場合に、WIDTH＝のデフォルトは１２０になる。
IGNOREが指定される時には、他の値をFEAT＝オペランドにコピーしてはならない。システム定義中にTERMINALマクロでFEAT＝IGNOREが指定されない時には、ＭＳＧステートメントで、装置フォーマットのＳＯＲ＝オペランドでIGNORE指定を用いてIGNOREを指定しなければならない。FEAT＝IGNOREが使用されない限り、FEAT＝では、ＩＭＳシステム定義中にTERMINALマクロで指定されたものを正確に指定しなければならない。そうでない場合には、ＤＦＳ０５７エラー・メッセージが発行される。３２７０装置についてFEAT＝IGNOREまたは１から１０が指定される時には、まだオペランドＰＥＮ＝、CARD＝、およびＰＦＫ＝を指定することができる。TYPE＝３２７０ＰかつFEAT＝IGNOREの時には、ＭＦＳが、１２０文字の行幅を可能にする。
CARD、ＰＦＫ、ＤＥＫＹＢＤ、およびＰＥＮの機能値は、３２７０ディスプレイだけについて有効である。FEAT＝オペランドが省略される場合には、デフォルト機能は、３２７０ディスプレイについてはCARD、ＰＦＫ、およびＰＥＮになり、デフォルトの行幅は、TYPE＝３２７０Ｐについて１２０である。
１、２、３、４、５、６、７、８、９、および１０は、３２７０、３２７０Ｐ、および３２７０−Ａｎに限って有効な値である。３２７０ディスプレイに関して、１から５までのFEAT＝指定を使用して、特定の機能またはハードウェア・データ・ストリーム依存性を有する装置をグループ化することができる。
制約：このキーワードは、任意選択であり、３２７０ディスプレイの他の特徴指定と共に使用することはできない。
機能オペランド値は、任意の順序で、指定される必要が所望される値だけを、指定することができる。各垂直リストで１つの値だけを指定することができる。
page : MFSPageType
PAGE属性
下記のように出力パラメータを指定する：
number
プリンタ装置について、Numberによって、印刷されるページ上の印刷行数が定義され、カード装置について、Numberによって、DPAGEまたは物理ページ（ＤＦＬＤステートメントでｐｐパラメータが使用される場合）ごとに穿孔されるカードの数が定義される。この値は、有効性検査に使用される。指定される数は、１以上２５６未満でなければならない。デフォルトは５５である。
DEFN
ＤＦＬＤステートメントによる定義で行／カードが印刷／穿孔されることを指定する（行／カードは、除去されず、出力ページに追加されない）。
SPACE
各出力ページに、Numberパラメータで指定された正確な数の行／カードが含まれることを指定する。
FLOAT
フォーマットが削除された後のデータがない行／カード（すべてブランクまたはNULL）を指定する。
３２７０Ｐ装置の場合に、データを有しない（すなわち、すべてブランクまたはヌル）いくつかの行を、下記の情況で削除してはならない。
行に、１つまたは複数の行密度設定（ＳＬＤｘ＝）指定が含まれる。
拡張属性を有すると指定されたフィールドが、複数の行にまたがる。
pen : String
ＰＥＮ属性
スペースまたはヌル指定文字を有するフィールドの即時ライト・ペン検出が行われる時に、リテラル・データが格納される入力フィールド名を定義する。リテラル・データは、ＰＥＮ＝オペランドのＤＦＬＤステートメントで定義される（ＤＦＬＤステートメントについてはＰＥＮ＝オペランドを参照されたい）。この名前は、ＭＦＬＤステートメントによって参照される可能性があり、このＤＥＶ定義内のＤＦＬＤステートメントのラベルとして使用してはならない。ＰＥＮ＝オペランドは、３２７０ディスプレイのみについて有効である。FEAT=NOPENが指定された場合に、FEATがＰＥＮに変更される。
スペースまたはヌル指定文字を用いて定義されたフィールドに対して即時検出が行われ、もう１つのフィールドが、選択されるか修正されるかＭＯＤ属性を有するか、ＰＥＮ＝オペランドが、ＤＦＬＤに関して定義されていない場合に、疑問符（？）がＰＥＮ＝フィールド名に挿入される。
即時検出が行われないか、アンパサンド（＆）指定文字を用いて定義されたフィールドに対して即時検出が行われる場合には、ＰＥＮ＝オペランドが、ＭＦＬＤステートメントで指定された充てんによって埋め込まれる。
pfk : MFSFunctionKeyType
ＰＦＫ属性
プログラム・ファンクション・キー・リテラルまたは制御機能データを含む入力フィールド名（第１サブパラメータ）と、位置フォーマットまたはキーワード・フォーマットで、指定されたフィールドに配置されるリテラル・データ、または対応するファンクション・キーが押された時に実行される制御機能のいずれか（残りのサブパラメータ）を定義する。
第１サブパラメータの名前（プログラム・ファンクション・キー・リテラルまたは制御機能データを含む入力フィールド名）は、ＭＦＬＤステートメントによって参照される可能性があり、このＤＥＶ定義内のＤＦＬＤステートメントのラベルとして使用してはならない。残りのサブパラメータは、位置フォーマットまたはキーワード・フォーマットで指定することができる。サブパラメータが、キーワード・フォーマットの場合に、指定される整数は、両端を含めて１から３６までであり、重複してはならない。１つのＰＦＫ＝オペランド・フォーマット（位置またはキーワード）だけを、１つのＤＥＶステートメントで指定することができる。このオペランドは、３２７０ディスプレイのみについて有効である。実際のフォーマット・ブロックが作成される時に、各リテラルは、リスト内の最長のリテラルの長さまで、右側にブランクを埋め込まれる。最大リテラル長は、２５６バイトである。
装置が、ＩＭＳコピー機能をサポートする場合に、ＰＦＫ１２が、コピー機能を呼び出し、ＤＥＶステートメントのＰＦＫ１２の定義は無視され、そうでない場合には、ＰＦＫ１２の定義に従う。
FEAT=NOPFKが指定される場合には、FEATがＰＦＫに変更される。ユーザ定義ＰＦＫの最大個数は、３６である。
指定することができる制御機能は、次の通りである：
NEXTPP−−PAGE ADVANCE
現在の出力メッセージの次の物理ページの要求を指定する。進行中の出力メッセージがない場合には、明示的な応答は行われない。
NEXTMSG−−MESSAGE ADVANCE
進行中の出力メッセージ（ある場合に）を待機解除し、次の出力メッセージ（ある場合に）をキューに送る要求を指定する。
NEXTMSGP−−MESSAGE ADVANCE PROTECT
進行中の出力メッセージ（ある場合に）を待機解除し、次の出力メッセージを送るか、次のメッセージが存在しないことを示す情報メッセージを返す要求を指定する。
NEXTLP−−NEXT LOGICAL PAGE
現在のメッセージの次の論理ページの要求を指定する。
ENDMPPI−−END MULTIPLE PAGE INPUT
複数の物理ページ入力メッセージの終りを指定する。
substitution : String
ＳＵＢ属性
入力データ・ストリーム内のすべてのＸ’３Ｆ’文字を置換するのにＭＦＳが使用する文字を指定する。このパラメータが、Ｘ’３Ｆ’として指定されるか、パラメータが指定されないか、受け取られる入力がＭＦＳ編集を迂回する場合には、変換は行われない。指定されたＳＵＢ文字は、データ・ストリームのどこにも現れてはならず、したがって、非グラフィックでなければならない。
Ｘ’ｆｆ’
その１６進数表現が’ｆｆ’である文字によって、入力データ・ストリームのすべてのＸ’３Ｆ’が置換される。
Ｃ’ｃ’
文字’ｃ’によって、入力データ・ストリームのすべてのＸ’３Ｆ’が置換される。
type : String
TYPE属性
このフォーマット記述を使用する装置タイプおよび装置のモデル番号を指定する。３２７５に接続された３２８４−３プリンタは、TYPE＝３２７０Ｐとしてのみサポートされる。３２８４−３のフォーマットを定義する時に指定されるモデル番号は、関連する３２７５のモデル番号である。
TYPE＝３２７０−Ａｎは、ＩＭＳシステム定義中に定義される画面サイズと機能番号ｎ＝１−１５を有する３２７０およびＳＬＵ ２ディスプレイの記号名を指定する。この指定によって、ＭＦＳ言語ユーティリティが、ＭＦＳ装置特性テーブル（ＤＦＳＵＤＴ０ｘ）を読み取り、画面サイズを抽出する。
width : int
WIDTH属性
このＤＥＶタイプの最大行幅を、下記の１つとして指定する：
− 入力データまたは出力データの行ごとの印刷位置の数
− 入力データまたは出力データのカードごとの穿孔位置の数
− カード・リーダ入力データのカード幅
デフォルトは、３２７０Ｐ出力の１２０である。行幅は、ＨＴＡＢ＝キーワードで左マージン値が指定されるかどうかに無関係に、桁１に対して相対的に指定される。指定される幅は、１以上でなければならない。
３２７０Ｐ装置について、WIDTHが指定される場合に、FEAT＝（１…１０）も指定されなければならない。FEAT＝（１…１０）が指定され、WIDTH＝が指定されない場合に、WIDTH＝のデフォルトは１２０になる。
【０２９９】
MFSMessageDescriptor
ＭＳＧステートメント
ＭＳＧステートメントは、メッセージ入力定義またはメッセージ出力定義を開始し、命名する。
サポートされない属性：
− すべての属性がサポートされる
MFSStatementから派生する
プライベート属性：
fill : String
FILL属性
出力装置フィールドの充てん文字を指定する。このオペランドは、TYPE＝OUTPUTの場合に限って有効である。デフォルトは、Ｃ’ ’である。充てん指定は、ＦＭＴ定義のDPAGEステートメントでFILL=NONEが指定されない限り無視される。ＥＧＣＳフィールドが存在する時の３２７０出力に関して、FILL=PTまたはFILL=NULLだけを指定しなければならない。FILL=PTでは、データがフィールドに送られる時に限って出力フィールド（１バイト・フィールドまたは２バイト・フィールドのいずれか）を消去し、したがって、アプリケーション・プログラム・メッセージがＭＦＬＤを省略する場合に、ＤＦＬＤを消去しない。
Ｃ’ｃ’
文字’ｃ’が、装置フィールドを充てんするのに使用される。３２７０表示装置について、Ｘ’３Ｆ’未満の値を伴う指定のすべてが、制御文字は’００’、他の非グラフィック文字はＸ’４０’に変更される。すべての他の装置について、Ｘ’３Ｆ’未満の値を伴うFILL＝Ｃ’ｃ’指定のすべてが、無視され、デフォルトのＸ’３Ｆ’にされる（FILL=NULLの指定と同等である）。
NULL
フィールドが充てんされないことを指定する。
ＰＴ
３２７０ディスプレイを除いてNULLと同等である。３２７０ディスプレイについて、ＰＴは、装置フィールド（ＤＦＬＤ）を充てんしない出力フィールドに、前にフィールド内にあったデータを消去するために、プログラム・タブ文字が続くことを指定する。
ignoreSource : boolean
ＳＯＲ属性
ＤＥＶステートメントと共に、このメッセージ記述子によって処理される端末またはリモート・プログラムのデータ・フィールドを定義する、ＦＭＴステートメントのソース名を指定する。TYPE＝OUTPUTについてIGNOREを指定すると、ＭＦＳが、装置フォーマット定義でそのFEAT＝オペランドによってIGNOREが指定される装置に関して指定されるデータ・フィールドが使用されるようになる。TYPE＝INPUTの場合、IGNOREは、対応するメッセージ出力記述子でIGNOREが指定される場合に限って指定しなければならない。ＳＯＲ＝IGNOREを使用する場合には、メッセージ入力記述子とメッセージ出力記述子の両方でIGNOREを指定しなければならない。
option : int
ＯＰＴ属性
メッセージを編集するためにＭＦＳによって使用されるメッセージ・フォーマット・オプションを指定する。デフォルトは、１である。
paging : boolean
PAGE属性
オペレータ論理ページング（順方向および逆方向のページング）が、この制御ブロックを使用して編集されるメッセージについて提供されるか（YES）否か（NO）を指定する。このオペランドは、TYPE＝OUTPUTの場合に限って有効である。デフォルトはNOであり、これは、物理ページの順方向ページングだけが提供されることを意味する。
type : MFSDescriptorType
TYPE属性
この定義をメッセージINPUT制御ブロックまたはメッセージOUTPUT制御ブロックとして定義する。デフォルトはINPUTである。
【０３００】
MFSLogicalPage
LPAGEステートメント
任意選択のLPAGEステートメントでは、論理ページを含むセグメントのグループが定義される。存在しない場合には、暗黙指定される。
サポートされない属性：
− すべての属性がサポートされる
MFSStatementから派生する
プライベート属性：
condition : MFSConditionType
ＣＯＮＤ属性
成功の場合に、このLPAGEに従うセグメント定義およびフィールド定義が、この論理ページの出力編集に使用されることを指定する条件テストを記述する。このLPAGEを編集に使用するかどうかを判定するために、論理ページの最初のセグメントの指定された部分が、指定されたリテラル値より大きい（＞）、より小さい（＜）、以上（＜＝）、以下（＞＝）、等しい（＝）、等しくない（ｎｅ）かどうかを判定するために検査される。COND=は、ＭＳＧ定義の最後のLPAGEステートメントには不要である。
検査される区域は、フィールド名（mfldname）、フィールド内のオフセット（mfldname（ｐｐ）、このｐｐは、名前を指定されたフィールド内のオフセットである）、またはセグメント内のオフセット（segoffset）によって定義することができる。mfldname（ｐｐ）形式が使用される場合には、ｐｐは、１以上でなければならない。比較の長さは、指定されたリテラルの長さである。前のＭＳＧステートメントでＯＰＴ＝３が指定される場合には、検査される区域が、ＭＦＬＤステートメントで定義される１フィールド以内でなければならない。
segoffsetが使用される場合に、これは０に対する相対値であり、そのオフセットの指定は、セグメントのＬＬＺＺを考慮しなければならない（すなわち、最初のデータ・バイトがオフセット４にある）。
ｐｐが使用される場合に、オフセットは、名前を指定されたフィールドに関して１に対する相対値である（すなわち、フィールド内の最初のバイトが、０ではなくオフセット１にある）。指定されるmfldnameがATTR=YESを用いて定義されている場合には、ｐｐオフセットを使用しなければならない。指定される最小オフセットは、３でなければならない。すなわち、フィールド内のデータの最初のバイトが、２バイトの属性に続いて、オフセット３にある。
ATTR=nnが指定される場合には、最小オフセットは、１にｎｎの２倍を加えたものでなければならない。したがって、ATTR=2が指定される場合には、ｐｐは少なくとも５でなければならず、ATTR=（YES，2）が指定される場合には、ｐｐは少なくとも７でなければならない。
すべてのLPAGEに関する条件テストが失敗した場合に、このＭＳＧ定義の最後のLPAGEが、編集に使用される。
LPAGE選択が、コマンド・データ・フィールドを使用して指定される、すなわち、/FORMATmodname…（データ）である場合には、LPAGE COND=mfldnameパラメータで指定されるＭＦＬＤが、ＭＯＤの関連するLPAGEの最初の８バイト以内でなければならない。
promptValue : String
【０３０１】
LPAGE COND=mfldname
ＳＥＧステートメント
ＳＥＧステートメントは、メッセージ・セグメントの輪郭を描き、複数セグメント・メッセージ処理がアプリケーション・プログラムによって要求される場合に限って必要である。出力メッセージ・セグメントは、ユーザが指定したキュー・バッファ長を超えることができない。入力メッセージ宛先が単一のセグメント・コマンドまたはトランザクションとして定義される時に、TYPE=INPUT MSGについて、１つのセグメントだけを定義しなければならない。複数のセグメントが定義され、その定義が、単一のセグメント・コマンドまたはトランザクションを入力するのに指定される場合には、ユーザ入力が、編集後に１つのセグメントだけを作るようにするために注意しなければならない。存在しない場合には暗黙指定される。
サポートされない属性：
− すべての属性がサポートされる
MFSStatementから派生する
プライベート属性：
exit : MFSExitType
EXIT属性
このメッセージ・セグメントのセグメント編集出口ルーチン・インターフェースを記述する。exitNumは、出口ルーチン番号であり、exitvectは、このセグメントのために出口ルーチンが呼び出される時に出口ルーチンに渡される値である。exitNumは、０から１２７までの範囲とすることができる。exitvectは、０から２５５までの範囲とすることができる。この入力セグメントについて処理が完了した時に、ＳＥＧ出口が呼び出される。
graphic : boolean
GRAPHIC属性
MSG TYPE＝INPUTについて、宛先定義が大文字変換を要求する場合に、ＩＭＳがこのセグメントに対して大文字変換を実行するか（YES）否か（NO）を指定する（TRANSACTまたはNAMEマクロのEDIT＝パラメータを参照されたい）。デフォルトはYESである。入力セグメント・データが、非グラフィック・フォーマット（パック１０進、ＥＧＣＳ、２進、など）の場合には、GRAPHIC=NOを指定しなければならない。GRAPHIC=NOが指定される時に、このセグメント内のＭＦＬＤについて、FILL=NULLは無効である。
下のリストに、GRAPHIC=YESが指定され、入力メッセージ宛先が、大文字変換を要求するものとして定義される時に行われる変換を示す：
変換前 変換後
ａからｚまで ＡからＺまで
Ｘ’８１’からＸ’８９’まで Ｘ’Ｃ１’からＸ’Ｃ９’まで
Ｘ’９１’からＸ’９９’まで Ｘ’Ｄ１’からＸ’Ｄ９’まで
Ｘ’Ａ２’からＸ’Ａ９’まで Ｘ’Ｅ２’からＸ’Ｅ９’まで
GRAPHIC=YESとして定義されたセグメント内のＭＦＬＤについてFILL=NULLが指定される場合に、１６進文字Ｘ’３Ｆ’が、セグメントから圧縮される。ＳＥＧステートメントでGRAPHIC=NOおよびFILL=NULLが指定される場合に、非グラフィック・データ・ストリームのすべてのＸ’３Ｆ’が、セグメントから圧縮され、望ましくない結果が作られる可能性がある。非グラフィック・データは、固定長出力フィールドとして出力に送られなければならず、この場合にはFILL=NULLの使用は推奨されない。
MSG TYPE＝OUTPUTについて、GRAPHIC＝キーワードは、ＤＰＭだけに適用される。これは、ＩＭＳアプリケーション・プログラムからのデータ内の非グラフィック制御文字（Ｘ’００’からＸ’３Ｆ’まで）が、ブランクに置換されるか（YES）否か（NO）を指定する。デフォルト値はYESである。NOが指定される場合に、ＭＦＳは、ＩＭＳアプリケーション・プログラムから受け取るビット・ストリングのすべてが、ＭＦＳを介してリモート・プログラムに無変更で流れられるようにする。
制約：GRAPHIC=NOが指定される時に、Options １および２を使用するＩＭＳアプリケーション・プログラムは、LPAGEの途中でセグメントを省略するか、ヌル文字（Ｘ’３Ｆ’）を使用してセグメント内のフィールドを切り捨てるか省略することができない。
【０３０２】
MFSMessageField
ＭＦＬＤステートメント
ＭＦＬＤステートメントでは、メッセージ出力セグメントの一部としてアプリケーション・プログラムに提示されるメッセージ・フィールドを定義する。ＭＳＧ定義ごとに、少なくとも１つのＭＦＬＤステートメントを指定しなければならない。
サポートされない属性：
− すべての属性がサポートされる
MFSStatementから派生する
プライベート属性：
attributes : boolean
ＡＴＴＲ属性
アプリケーション・プログラムが３２７０属性および拡張属性（ｎｎ）を修正できるか（YES）否か（NO）を指定する。
YESの場合には、２バイトを、出力にアプリケーション・プログラムが充てんし、入力時にブランクに初期化される３２７０属性データとして予約しなければならない。これらの２バイトは、ＬＴＨ＝指定に含まれなければならない。
ｎｎに指定される値は、動的に修正することができる拡張属性の数である。ｎｎの値は、１から６までの数とすることができる。無効な指定は、デフォルトの１になる。属性ごとに２つの追加バイトが、出力時にアプリケーション・プログラムによって充てんされ、入力時に空白に初期化される拡張属性データのために予約されなければならない。この属性バイトは、ＭＦＬＤ ＬＴＨ＝指定に含まれなければならない。
例：下に示されているのは、ATTR=の有効な指定と、異なる指定ごとに予約されなければならないバイト数である。
MFLD,ATTR=(YES,nn)
2+(2×nn)
MFLD,ATTR=(NO,nn)
2×nn
MFLD,ATTR=(nn)
2×nn
MFLD,ATTR=YES
2
MFLD,ATTR=NO
0
ATTR=YESおよびｎｎは、出力メッセージで位置パラメータを介してリテラル値が指定された場合には無効である。
別のＩＭＳ ＩＳＣサブシステムに送られるフィールドの属性は、受け取るサブシステムのフォーマットでのATTR=指定に無関係に、ＭＦＳによって入力データとして扱われる。たとえば、ATTR=（YES，1）、ＬＴＨ＝５として定義されたメッセージ・フィールド（ＭＦＬＤ）に、下記が含まれる：
00A0C2F1C8C5D3D3D6
受け取るサブシステムのＭＦＬＤが、ATTR=なしでＬＴＨ＝９として定義される場合には、アプリケーション・プログラムが、下記を受け取る：
00A0C2F1C8C5D3D3D6
受け取るサブシステムのＭＦＬＤが、ＬＴＨ＝１３およびATTR=（YES，1）として定義される場合には、アプリケーション・プログラムが、下記を受け取る：
4040404000A0C2F1C8C5D3D3D6
受け取るサブシステムのＭＦＬＤが、ＬＴＨ＝５およびATTR=（YES，1）として定義される場合には、アプリケーション・プログラムが、下記を受け取る：
4040404000A0C2F1C8
入力ＳＥＧステートメントは、属性データの大文字への変換を避けるために、GRAPHIC=NOとして指定されなければならない。
exit : MFSExitType
EXIT属性
このメッセージ・フィールドのフィールド編集出口ルーチン・インターフェースを記述する。出口ルーチン番号は、exitNumで指定され、exitvectは、出口ルーチンがこのフィールドについて呼び出される時に出口ルーチンに渡される値である。exitNumの値は、０から１２７までの範囲とすることができる。exitvectの値は、０から２５５までの範囲とすることができる。ＭＦＳ編集後（オプション１および２に関するNULL圧縮の前）に存在するフィールドのアドレスが、そのフィールドについて定義されたベクトルと共に、編集出口ルーチンに渡される（ＤＰＭ装置についてNOFLDEXITが指定される場合には、出口ルーチンは呼び出されない）。出口ルーチンは、０から２５５までの値を有するコードを返すことができる。ＭＦＳは、セグメント編集ルーチンによる使用のために、セグメントごとに、そのような返される最大のコードを維持する。同一のＭＦＬＤステートメントで’リテラル’が指定される場合には、EXIT＝は無効である。
extendedAttributes : int
ＡＴＴＲ属性
アプリケーション・プログラムが３２７０属性および拡張属性（ｎｎ）を修正できるか（YES）否か（ＮＯ）を指定する。
YESの場合には、２バイトを、出力にアプリケーション・プログラムが充てんし、入力時にブランクに初期化される３２７０属性データとして予約しなければならない。これらの２バイトは、ＬＴＨ＝指定に含まれなければならない。
ｎｎに指定される値は、動的に修正することができる拡張属性の数である。ｎｎの値は、１から６までの数とすることができる。無効な指定は、デフォルトの１になる。属性ごとに２つの追加バイトが、出力時にアプリケーション・プログラムによって充てんされ、入力時に空白に初期化される拡張属性データのために予約されなければならない。この属性バイトは、ＭＦＬＤ ＬＴＨ＝指定に含まれなければならない。
例：下に示されているのは、ATTR=の有効な指定と、異なる指定ごとに予約されなければならないバイト数である。
MFLD,ATTR=(YES,nn)
2+(2×nn)
MFLD,ATTR=(NO,nn)
2×nn
MFLD,ATTR=(nn)
2×nn
MFLD,ATTR=YES
2
MFLD,ATTR=NO
0
ATTR=YESおよびｎｎは、出力メッセージで位置パラメータを介してリテラル値が指定された場合には無効である。
別のＩＭＳ ＩＳＣサブシステムに送られるフィールドの属性は、受け取るサブシステムのフォーマットでのATTR=指定に無関係に、ＭＦＳによって入力データとして扱われる。たとえば、ATTR=（YES，1）、ＬＴＨ＝５として定義されたメッセージ・フィールド（ＭＦＬＤ）に、下記が含まれる：
00A0C2F1C8C5D3D3D6
受け取るサブシステムのＭＦＬＤが、ATTR=なしでＬＴＨ＝９として定義される場合には、アプリケーション・プログラムが、下記を受け取る：
00A0C2F1C8C5D3D3D6
受け取るサブシステムのＭＦＬＤが、ＬＴＨ＝１３およびATTR=（YES，1）として定義される場合には、アプリケーション・プログラムが、下記を受け取る：
4040404000A0C2F1C8C5D3D3D6
受け取るサブシステムのＭＦＬＤが、ＬＴＨ＝５およびATTR=（YES，1）として定義される場合には、アプリケーション・プログラムが、下記を受け取る：
4040404000A0C2F1C8
入力ＳＥＧステートメントは、属性データの大文字への変換を避けるために、GRAPHIC=NOとして指定されなければならない。
fill : String
FILL属性
装置から受け取るデータの長さがこのフィールドの長さより短い時に、このフィールドに埋め込むのに使用される文字を指定する。この文字は、このフィールドについてデータが受け取られない時にも（ＭＳＧステートメントでオプション３が指定された時を除く）、埋込みに使用される。このオペランドは、TYPE＝INPUTの場合に限って有効である。デフォルトは、Ｘ’４０’である。
Ｘ’ｈｈ’
その１６進数表現がｈｈである文字が、フィールドを充てんするのに使用される。FILL＝Ｘ’３Ｆ’は、FILL=NULLと同一である。
Ｃ’ｃ’
文字’ｃ’によって、フィールドが充てんされる。
NULL
フィールド内の欠けているデータの量だけ左へのメッセージ・セグメントの圧縮が行われる。
justify : MFSJustifyType
JUST属性
データ・フィールドが、左寄せ（Ｌ）または右寄せ（Ｒ）され、装置フォーマット制御ブロックによって期待されるか提示されるデータの量に依存して、必要なだけ右切捨または左切捨が行われるデータ・フィールドを指定する。デフォルトはＬである。
length : MFSLengthType
ＬＴＨ属性
リテラルが位置オペランド（TYPE＝INPUT）で指定される場合に省略することができ、この場合には、リテラルについて指定された長さが使用される。ＬＴＨ＝がリテラル・フィールドについて指定される場合には、指定されるリテラルが、切り捨てられるか、指定された長さまでブランクを埋め込まれる。ＭＦＬＤステートメントがDOステートメントとENDDOステートメントの間にある場合には、ＬＴＨ＝がＭＦＬＤソース・ステートメントで指定されているかどうかに無関係に、長さの値が、生成されるＭＦＬＤステートメントに印刷される。
value : String
value属性
これは、以下の説明の’literal’フィールドに対応する。
装置フィールド名は、’deviceFields’関係を介して指定される。
入力データがそこから抽出されるか、出力データがそこに配置される装置フィールド名（ＤＥＶステートメントまたはＤＦＬＤステートメントを介して定義される）を指定する。メッセージ出力制御ブロックを定義する時にこのパラメータが省略された場合には、アプリケーション・プログラムによって供給されるデータが、出力装置に表示されない。ＭＦＳの反復生成機能（DOステートメントおよびENDDOステートメント）が使用される場合には、dfldnameが、６文字の最大長に制限されなければならない。ステートメントの各反復が生成される時に、２文字のシーケンス番号（０１から９９まで）が、dfldnameに付加される。ここで指定されるdfldnameが、６バイトを超え、反復生成が使用される場合に、dfldnameが６文字目で切り捨てられ、２文字のシーケンス番号が付加されて、８文字の名前が形成される。これが行われる場合に、エラー・メッセージは提供されない。このパラメータは、下記のフォーマットの１つで指定することができる：
dfldname
入力データがそこから抽出されるか、出力データがそこに配置される装置フィールド名を識別する。
’literal’
リテラル値が入力メッセージに挿入される場合に指定することができる。
（dfldname，’literal’）
TYPE＝OUTPUTの場合に、これによって、リテラル・データが名前付きＤＦＬＤに配置されることが記述される。この形が指定される時には、リテラルのスペースを、アプリケーション・プログラムによって供給される出力メッセージ・セグメント内で割り振ってはならない。
TYPE＝INPUTの場合に、これによって、このフィールドのデータが装置から受け取られない時にメッセージ・フィールドにリテラル・データが配置されることが記述される。このdfldnameが、ＤＥＶステートメントのＰＦＫパラメータで使用される場合には、このリテラルが、必ずＰＦキー・リテラルまたは制御機能によって置換される。しかし、このdfldnameがＰＦＫパラメータで指定されるが、ＰＦキーが使用されない時には、ＭＦＬＤステートメントで指定されたリテラルが、メッセージ・フィールドに移動される。物理ページングが使用される時に、リテラルは、フィールドに挿入されるが、論理ページの最後の物理ページが表示された後までは処理されない。
両方の場合で、ＬＴＨ＝オペランドが指定される場合には、ＬＴＨ＝指定の長さの必要に応じて、リテラルの長さが切り捨てられるか埋め込まれる。指定されたリテラルの長さが、定義されたフィールド長より短い場合には、リテラルに、TYPE＝OUTPUTならばブランク、TYPE＝INPUTならば指定された充てん文字（FILL＝）が埋め込まれる。充てん文字が入力について指定されない場合には、リテラルは、ブランクを充てんされる（デフォルト）。リテラル値の長さは、２５６バイトを超えることができない。
（dfldname，system-literal）
システム・リテラルのリストから名前を指定する。システム・リテラルは、リテラル値が、装置への送信の前のフォーマット中に作成されることを除いて、通常のリテラルと同様に機能する。ＬＴＨ＝オペランド、ATTR=オペランド、およびJUST＝オペランドを指定することはできない。この形が指定される時には、リテラルのスペースを、アプリケーション・プログラムによって供給される出力メッセージ・セグメント内で割り振ってはならない。
（，ＳＣＡ）
この出力フィールドを、出力装置に表示されないシステム制御域として定義する。１論理ページ（LPAGE）内に１つだけそのようなフィールドを設けることができ、このフィールドは、そのページの最初のメッセージ・セグメント内になければならない。論理ページが定義されない場合には、１つのＳＣＡフィールドだけを定義することができ、そのＳＣＡフィールドは、出力メッセージの最初のセグメント内になければならない。この指定は、前のＭＳＧステートメントでTYPE＝OUTPUTが指定された場合に限って有効である。
【０３０３】
MFSDevicePage
DPAGEステートメント
DPAGEステートメントでは、装置フォーマットの論理ページを定義する。このステートメントは、この装置フォーマット（ＦＭＴ）を参照するメッセージ記述子のどれにもLPAGEステートメントが含まれず、特定の装置オプションが不要である場合に、省略することができる。存在しない場合には、暗黙指定される。
サポートされない属性：
− ACTVPID
− COND
− OFTAB
− ORIGIN
− PD
− SELECT
MFSStatementから派生する
プライベート属性：
cursor : MFSCursorType
CURSOR属性
物理ページ上のカーソルの位置を指定する。論理ページまたはメッセージが複数の物理ページからなる場合に、複数のカーソル位置が必要になる可能性がある。値ｌｌｌが、行番号を指定し、ｃｃｃが、列を指定する；ｌｌｌおよびｃｃｃの両方が、１以上でなければならない。カーソル位置は、定義されたフィールド上またはデフォルトのどちらかでなければならない。３２７０ディスプレイのデフォルトｌｌｌ、ｃｃｃ値は、１、２である。財務ディスプレイ・コンポーネントについて、カーソル位置が指定されない場合に、ＭＦＳは、カーソルを位置決めしない−カーソルは、通常は、装置上の出力データの末尾に配置される。財務ディスプレイ・コンポーネントについて、ORIGIN＝パラメータが指定されたかどうかに無関係に、すべてのカーソル位置が絶対位置である。
ｄｆｌｄパラメータによって、入力時にアプリケーション・プログラムにカーソル情報を供給し、出力時にアプリケーション・プログラムがカーソル位置を指定できるようにする方法が提供される。
推奨：出力カーソル位置決めにはカーソル属性機能を使用する（ＭＦＬＤステートメントでATTR=YESを指定する）。
ｄｆｌｄパラメータによって、カーソル位置を含むフィールドの名前が指定される。この名前は、ＭＦＬＤステートメントによって参照される可能性があり、このＤＥＶ定義のＤＦＬＤステートメントのラベルとして使用してはならない。このフィールドのフォーマットは、それぞれ行と列の番号を含む２つの２進ハーフワードである。このフィールドが、メッセージ入力記述子によって参照される時に、このフィールドに、メッセージ入力時のカーソル位置が含まれる。メッセージ出力記述子によって参照される時に、アプリケーション・プログラムが、それぞれ行と列を含む２進ハーフワードとしてこのフィールドに所望のカーソル位置を置く。名前を指定されたフィールドに２進数０があると、指定されたｌｌｌ、ｃｃｃが、出力中にカーソル位置に使用されるようになる。入力中には、このフィールドの２進数０は、カーソル位置が定義されないことを示す。このｄｆｌｄを参照する入力ＭＦＬＤは、GRAPHIC=NOを指定されたセグメント内で定義されるか、２進数を１０進数に変換するためにEXIT＝（０，２）を使用しなければならない。
fill : String
FILL属性
出力装置フィールドの充てん文字を指定する。３２７０ディスプレイを除くすべての装置タイプのデフォルト値は、Ｘ’４０’であり、３２７０ディスプレイのデフォルトは、ＰＴである。ＥＧＣＳフィールドが存在する時の３２７０出力について、FILL=PTまたはFILL=NULLだけを指定しなければならない。FILL=PTでは、データがフィールドに送られる時に限って、出力フィールド（１バイト・フィールドまたは２バイト・フィールドのいずれか）が消去され、したがって、アプリケーション・プログラム・メッセージでＭＦＬＤが省略される場合に、ＤＦＬＤは消去されない。
NONE
メッセージ出力記述子からの充てん文字が、装置フィールドを充てんするのに使用される場合に指定されなければならない。
Ｘ’ｈｈ’
その１６進数表現がｈｈである文字が、装置フィールドを充てんするのに使用される。
Ｃ’ｃ’
文字’ｃ’が、装置フィールドを充てんするのに使用される。
NULL
フィールドが充てんされないことを指定する。３２７０ディスプレイ以外の装置について、メッセージ・データが装置フィールドを満たさない時に、「短縮された行」が作られる。
ＰＴ
装置フィールド（ＤＦＬＤ）を満たさない出力フィールドに、そのフィールドに前に存在したデータを消去するプログラム・タブ文字が続くことを指定する；それ以外は、この動作はFILL=NULLと同一である。
３２７０ディスプレイ装置について、Ｘ’３Ｆ’未満の値を有するすべての指定が、制御文字はＸ’００’、他の非グラフィック文字はＸ’４０’に変更される。
multiplePages : boolean
ＭＵＬＴ属性
このDPAGEについて複数の物理ページ入力メッセージが許容されることを指定する。
【０３０４】
MFSDeviceField
ＤＦＬＤステートメント
ＤＦＬＤステートメントでは、端末またはリモート・プログラムから読み取られるか書き込まれる、装置フォーマット内のフィールドを定義する。ＩＭＳまたはリモート・アプリケーション・プログラムに重要な区域だけを定義しなければならない。フォーマットのヌル・スペースは、定義する必要がない。
サポートされない属性：
− ＳＬＤ
MFSStatementから派生する
プライベート属性：
attributes : MFSAttributeType
ＡＴＴＲ属性
extendedAttributes : MFSExtendedAttributeType
ＥＡＴＴＲ属性
length : int
ＬＴＨ属性
フィールドの長さを指定する。このオペランドは、位置パラメータで’literal’が指定される場合には省略されなければならず、その場合には、リテラルの長さが、フィールド長として使用される。このオペランドが’literal’と共に使用され、この２つの長さが異なる場合に、予測不能な出力フォーマットが行われる可能性がある。指定されるＬＴＨ＝は、装置の物理ページ・サイズを超えることができない。
３２７０、３６０４ディスプレイ、およびRCDCT=NOSPANを伴うＤＰＭを除く最大の許容可能な長さは、８０００文字である。３２７０ディスプレイについて、最大長は、画面サイズより１つ少ない。たとえば、４８０文字ディスプレイについて、最大長は４７９文字である。０の長さを指定してはならない。ＳＣＡとＬＴＨ＝の両方が指定される場合には、ＬＴＨが２でなければならない。
ＰＯＳ＝およびＬＴＨ＝に、３２７０ディスプレイ装置またはATTR=YESを指定されたＤＦＬＤについて予約されている属性文字位置を含めてはならない。ディスプレイ／プリンタ・フォーマットの設計にこのバイトを含めることは、それがアプリケーション・プログラムによってアクセス可能でない場合であっても、それが、表示／印刷されるフィールドのそれぞれに先行する画面／印刷されるページ位置を占めるので、必要である。
３２７０プリンタのＤＦＬＤを定義する時には、ハードウェアATTRIBUTE文字は使用されない。したがって、フィールドは、ATTR=YESが指定されない限り、属性文字を許容しない並置を用いて定義しなければならない。しかし、３２７０Ｐとして定義されるプリンタについて、印刷行の最後の桁（FEAT＝、WIDTH＝、または装置のデフォルト幅に基づく）を使用することはできない。行の最後の桁は、ＩＭＳによって実行される紙送り制御動作用に予約されている。したがって、印刷行で１２０が指定され（FEAT＝１２０）、ＤＦＬＤでＰＯＳ＝（１，１）、ＬＴＨ＝１２０が指定される場合に、１１９文字が行１に印刷され、１文字が行２に印刷される。
検出可能フィールド（ＤＥＴまたはＩＤＥＴ）には、検出可能フィールドが表示行の最後のフィールドでない限り（この場合には、検出指定文字の１位置だけが必要）、１バイトの検出指定文字と３つの埋込み文字のための４つの位置が、ＰＯＳおよびＬＴＨに含まれなければならない。検出指定文字は、フィールド・データに先行しなければならず、埋込み文字（必要な場合）は、フィールド・データの後に続かなければならない。検出指定文字および必要な埋込み文字は、アプリケーション・プログラムまたはフィールド・データに伴うＭＦＬＤリテラルによって供給されなければならない。埋込み文字は、装置の先行するフィールドにも必要になる可能性がある。
pen : String
ＰＥＮ属性
このフィールドが検出される時に選択されるリテラルまたは実行されるオペレータ制御機能を指定する。（１）’literal’が指定され、（２）フィールドが即座に検出可能（ATTR=オペランド）として定義され、（３）ヌル文字またはスペース指定文字が含まれる場合に、フィールドが検出される時（他の装置フィールドが修正されない場合）に、指定されたリテラルが、前のＤＥＶステートメントのＰＥＮオペランドによって参照されるフィールドに配置される。装置の別のフィールドが修正される場合には、リテラルの代わりに疑問符（？）が供給される。リテラルの長さは、２５６バイトを超えてはならない。
（１）制御機能が指定され、（２）フィールドが即座に検出可能（ATTR=オペランド）として定義され、（３）ヌル文字またはスペース指定文字が含まれる場合に、フィールドが検出され、他の装置フィールドが修正されない時に、指定された制御機能が実行される。装置の別のフィールドが修正される場合には、疑問符（？）が提供され、機能は実行されない。指定することができる制御機能は次の通りである：
NEXTPP--PAGE ADVANCE
現在の出力メッセージの次の物理ページの要求を指定する。進行中の出力メッセージがない場合には、明示的な応答は行われない。
NEXTMSG--MESSAGE ADVANCE
進行中の出力メッセージ（ある場合に）を待機解除し、キューの次の出力メッセージ（ある場合に）を送る要求を指定する。
NEXTMSGP--MESSAGE ADVANCE PROTECT
進行中の出力メッセージ（ある場合に）を待機解除し、次の出力メッセージを送るか、次のメッセージが存在しないことを示す情報メッセージを返す要求を指定する。
NEXTLP--NEXT LOGICAL PAGE
現在のメッセージの次の論理ページの要求を指定する。
ENDMPPI--END MULTIPLE PAGE INPUT
複数の物理ページ入力メッセージの終りを指定する。
ＥＮＤＭＰＰＩは、データが受信された場合に限って有効であり、データ入力がない場合の複数ページ入力（ＭＰＰＩ）は終了されない。
position : MFSPositionType
ＰＯＳ属性
表示フォーマットの行（ｌｌｌ）、桁（ｃｃｃ）、および物理ページ（ｐｐ）に関してこのフィールドの最初のデータ位置を定義する。ｐｐが省略された場合には、１が仮定される。
DEV TYPE＝３２７０、３２７０−Ａｎ、または３２７０Ｐ用
ｌｌｌ，ｃｃｃ，ｐｐ
出力フィールドの行、桁、および、任意指定として物理ページ番号を指定する。ｌｌｌ、ｃｃｃ、およびｐｐは、１以上でなければならない。
３２７０ディスプレイについて、ＰＯＳ＝（１，１）を指定しなければならない。最下部から最上部にラップするフィールドを定義してはならない。
制約：３２７０のいくつかのモデルで、行１、桁２から始まるフィールドがアルファベット属性と保護属性の両方を有する時に、表示画面をコピーすることができない。
value : String
【０３０５】
MFSTable
TABLEステートメント
TABLEステートメントでは、ＤＦＬＤステートメントのＯＰＣＴＬキーワードによって参照することができるオペレータ制御テーブルを開始し、名前を付ける。TABLEステートメントおよびそれに続くＩＦおよびTABLEENDステートメントは、ＭＳＧ定義またはＦＭＴ定義の外になければならない。
サポートされない属性：
− すべての属性がサポートされる
MFSStatementから派生する
【０３０６】
MFSDeviceDivision
ＤＩＶステートメント
ＤＩＶステートメントでは、ＤＩＦまたはＤＯＦ内の装置フォーマットを定義する。フォーマットは、入力、出力、または入力と出力の両方として識別され、複数の物理ページから構成することができる。ＤＥＶごとに１つのＤＩＶステートメントだけが許容される。
サポートされない属性：
− RCDCTL
− HDRCTL
− OPTIONS
− OFTAB
− DPN
− PRN
− RDPN
− RPRN
MFSStatementから派生する
プライベート属性：
type : MFSDescriptorType
TYPE属性
入力専用フォーマット（INPUT）、出力専用フォーマット（OUTPUT）、または両方（INOUT）を記述する。
DIV TYPE＝OUTPUTまたはTYPE＝INPUTが指定される場合に、ある種のＤＥＶステートメント・キーワードが適用可能である。
compression : MFSCompressionType
ＣＯＭＰＲ属性
短いフィールド、固定長フィールド、またはアプリケーション・プログラムによって提示されるすべてのフィールドから末尾ブランクを除去するようにＭＦＳに要求する。
【０３０７】
MFSIfCondition
IFステートメント
IFステートメントでは、前のTABLEステートメントによって名前を付けられたテーブル内の項目を定義する。各ＩＦステートメントで、条件演算と、条件が真である場合に実行される関連する制御機能または分岐機能が定義される。
サポートされない属性：
− すべての属性がサポートされる
MFSStatementから派生する
プライベート属性：
condition : MFSConditionType
条件属性
条件は、下記のフォーマットを有する：
IF (DATA | LENGTH) (=,<,>,≠,≧,≦)
(literal | data-length) function
DATA
条件演算が、フィールドについて装置から受け取られたデータに対して実行されることを指定する。
LENGTH
条件演算が、フィールドについて入力された文字の数をテストすることを指定する。このフィールドのサイズ限界は、ＤＦＬＤと同一である（トピック２．５．１．５．８の「ＤＦＬＤステートメント」を参照されたい）。
=,<,>,≠,≧,≦
指定された制御機能を呼び出すために真にならなければならない条件関係を指定する。
’literal’
入力データが比較されるリテラル・ストリングである。比較は、入力を大文字に変換する前に行われる。’literal’が指定される場合には、DATAが第１オペランドで指定されなければならない。入力データ長が、リテラル・ストリング長と等しくない場合には、比較は、条件関係が≠でなく、データ長が０でない限り（この場合には制御機能が実行される）、短い方の長さを用いて実行される。入力が小文字の場合には、ALPHAステートメントを使用しなければならず、リテラルが小文字でコード化されなければならない。
data-length
比較されるフィールドの入力データがの文字の数の整数値を指定する。
ＮＯＦＵＮＣ
条件機能テストが終了することを指定する。
NEXTPP--PAGE ADVANCE
現在の出力メッセージの次の物理ページの要求を指定する。進行中の出力メッセージがない場合には、明示的な応答は行われない。
NEXTMSG--MESSAGE ADVANCE
進行中の出力メッセージ（ある場合に）を待機解除し、キューの次の出力メッセージ（ある場合に）を送る要求を指定する。
NEXTMSGP--MESSAGE ADVANCE PROTECT
進行中の出力メッセージ（ある場合に）を待機解除し、次の出力メッセージを送るか、次のメッセージが存在しないことを示す情報メッセージを返す要求を指定する。
NEXTLP--NEXT LOGICAL PAGE
現在のメッセージの次の論理ページの要求を指定する。
PAGEREQ--LOGICAL PAGE REQUEST
入力データの２番目から最後までの文字を論理ページ要求とみなさなければならないことを指定する。
ENDMPPI--END MULTIPLE PAGE INPUT
複数物理ページ入力の終り（この入力が、作成されるメッセージの最後の入力である）を指定する。
action : String
【０３０８】
MFSPassword
PASSWORDステートメント
PASSWORDステートメントでは、ＩＭＳパスワードとして使用される１つまたは複数のフィールドを識別する。使用される時に、PASSWORDステートメントおよびそれに関連するＭＦＬＤが、入力のLPAGEまたはＭＳＧの定義の最初のＳＥＧステートメントに先行しなければならない。８つまでのＭＦＬＤステートメントを、PASSWORDステートメントの後で指定することができるが、パスワードの全長が、８文字を超えてはならない。充てん文字は、Ｘ’４０’でなければならない。オプション１および２のメッセージについて、編集後のデータの最初の８文字が、ＩＭＳパスワードに使用される。オプション３のメッセージについて、編集後の第１フィールドのデータ内容が、ＩＭＳパスワードに使用される。
３２７０入力に関するパスワードは、ＤＦＬＤステートメントで定義することもできる。両方のパスワード方法が使用される場合には、ＭＳＧ定義で指定されたパスワードが使用される。
サポートされない属性：
− すべての属性がサポートされる
MFSStatementから派生する
【０３０９】
MFSDeviceDescriptor
ＦＭＴステートメント
ＦＭＴステートメントでは、ＤＥＶステートメントで指定される装置タイプおよび特徴でのみ異なる１つまたは複数の装置フォーマットを含むフォーマット定義を開始し、名前を付ける。このフォーマット定義に含まれる各装置フォーマットによって、装置またはリモート・プログラムから送信または受信されるデータのレイアウトが指定される。
サポートされない属性：
− すべての属性がサポートされる
MFSStatementから派生する
【０３１０】
ＭＦＳFunctionKeyType
プライベート属性：
fieldName : String
【０３１１】
ＭＦＳFunctionKeyValueType
プライベート属性：
index : int
function : String
【０３１２】
MFSFormatLibrary
このクラスは、FORMATLIBの効果を複製するために設計された。言い換えると、これは、ＭＦＳソース・ファイルがそれを中心にしてグループ化される中心点として働く。
このクラスは、他のソース・ファイル内のＭＳＧステートメントを参照するＭＳＧステートメントおよびLPAGEステートメントの問題に対処するために導入された。所与のformatlib内のすべてのソース・ファイルを１回で解析することをユーザに強制するのではなく、ＭＳＧポインタのコンテナとして働くためにこのクラスが追加された。詳細については、MFSMessagePointerの資料を参照されたい。
プライベート属性：
name : String
【０３１３】
MFSMessagePointer
このクラスは、ＭＳＧステートメントのプレースホルダとして働くように設計された。ＮＸＴ属性（nextMessage関係）から実際のＭＳＧステートメントを指すのではなく、ＭＳＧステートメントおよびLPAGEステートメントが、このクラスのインスタンスを指す。
このクラスの新しいインスタンスは、ＭＳＧステートメントまたはLPAGEステートメントが、この特定のFORMATLIBで表されないＭＳＧステートメントを指す時に作成される。新しいインスタンスは、ＭＳＧステートメントが解析され、そのステートメントがまだここで表されていない場合にも作成される。
プライベート属性：
name : String
【０３１４】
総計：
１論理パッケージ
１６クラス
論理パッケージ構造
論理ビュー
mfs
【０３１５】
７．共通アプリケーション・メタモデルおよびシステムの例示的アプリケーション
複数の個々のプラットフォームにまたがって発生するさまざまな複雑なトランザクションが、共通アプリケーション・メタモデルのシームレス性および透過性を必要とする。これらのトランザクションには、「リッチ」・トランザクション、高水準グループ・ウェア、および財務トランザクションが含まれる。
【０３１６】
図４７に、たとえば注文が端末で入力され、ウェブ・サーバに渡され、ウェブ・サーバを介して製造業者のアプリケーション・サーバに渡される、「リッチ」トランザクションに関する単純化されたネットワーク構成を示す。製造業者のアプリケーション・サーバは、それ自体のデータベース・サーバならびに、本明細書に記載のコネクタによって透過的に接続されたそのベンダの似ていない非互換のデータベース・サーバおよびデータベースを介して検索し、コンポーネントの状況、価格、および配送日付を照会し、注文を満足するのに必要なコンポーネントの注文を行う。
【０３１７】
制限ではなく厳密に例示のために、リッチ・トランザクションを、新しい自動車の構成および注文から、自動車の資金調達、新しい自動車の要素および構成要素の収集、自動車の組立、顧客への送達を介する、自動車の購入を用いて例示する。たとえば、自動車を構成する際に、たとえば技術的理由または性能的理由から、エンジンのあるサブセットを含めることを除外しながらエンジンの別のサブセットを含めることを必要とするトラクション・コントロール・モジュールを含めることを検討する。同様に、ある色の選択によって、たとえば在庫または使用可能性の理由から、ある車内装飾の組合せが排除される場合がある。もちろん、エンジンおよびトランスミッションを選択しない場合には、自動車は得られない。いくつかの選択を、行わなければならない。問題は、「’Ｘ’を選択する場合に、’Ｙ’および’Ｚ’も選択しなければならないが、’Ｙ’を選択する場合には、’Ａ’または’Ｂ’を得ることができず、既に‘Ａ’が選択されている」の１つである。すなわち、ある構成要素またはサブシステムの選択によって、前に選択された構成要素またはサブシステムがシステムから除去される場合がある。しばしば供給パイプラインの選択された要素の使用可能性に基づいて、自動車を構成した後に、注文が、製造スケジューリングを含めて実行のために製造業者のサーバに送信される。製造業者は、供給チェーンのベンダ、たとえばトランスミッション・ベンダに照会し、このベンダが、コントローラ・ベンダ、ギア・ベンダ、ハウジング・ベンダ、油圧導管ベンダなどに照会する。これらのベンダが、そのサブベンダに照会する。
【０３１８】
コネクタの方法およびシステムを使用して、ディーラおよび顧客が、端末３９０１で自動車を構成し、注文する。構成および注文の入力が、製造業者のサーバ３９１１に送信される。製造業者のサーバは、サーバ３９２１、３９３１、および３４４１（サーバ３９２１は、製造業者の自社構成要素事業およびその購入機能のサーバとすることができる）またはその直接ベンダに照会し、この直接ベンダが、第３のサブベンダのサーバ３９２３、３９３３、および３９４３に照会する。照会は、アクセス許可の対象になる「空白埋め」ＳＱＬ照会の形とすることができる。サブベンダのサーバ３９２３、３９３３、および３９４３は、クライアントとしてのベンダのサーバ３９２１、３９３１、および３４４１に特殊ビューを提示し、このベンダのサーバが、クライアントとしての製造業者のサーバ３９１１に特殊ビューを提示する。製造業者のサーバ３９１１に返されるデータは、最適化アプリケーションおよび生産スケジューリング・アプリケーションを用いて最適化して、ディーラのサーバ側の買い手に通し番号および送達日付を提示することができる。
【０３１９】
本発明のコネクタのもう１つの応用例が、グループウェアとの接続にあり、特に、「グループウェアの島」を一緒にリンクすることである。「グループウェア」は、グループの作業を容易にするように設計された技術に適用される広義の用語である。グループウェア技術は、通信、協力、調整、問題解決、競合、または折衝に使用することができる。アプリケーションのグループウェア・スイートは、人々が、互いに遠隔地に位置する場合であっても、一緒に協力して作業するのを助けるプログラムからなる。グループウェア・サービスには、カレンダの共用、集団執筆、電子メール処理、共用データベース・アクセス、電子会議、ビデオ会議、および他の活動を含めることができる。
【０３２０】
図４８に、複数の異なるプラットフォームで稼動し、本明細書に記載のコネクタによって接続される、複数のグループ・ウェア・アプリケーションにまたがって分散されたグループ・ウェア・セッションを示す。特に示されているのは、２つのグループウェア・システム４０１０および４０２０である。各システムには、電子メール、スケジュール／カレンダ、ワード・プロセッサ、スプレッド・シート、グラフィックス、およびＣＴＩ（コンピュータ・テレフォニー統合）などの電子メール対応アプリケーション４０１３および４０２３が含まれる。これらは、メッセージＡＰＩ４０１５および４０２５と、オペレーティング・システム４０１７および４０２７と、ローカル・グループウェア・サーバ４０１１および４０２１によってサポートされる。ローカル・グループウェア・サーバ４０１１および４０２１のそれぞれが、本発明のコネクタ、電子メール・サーバ、電子メール・データ・ベース、ディレクトリ・サーバ、および複製データベースを有する。２つのローカル・グループウェア・サーバ４０１１および４０２１は、インターネット、ＬＡＮ、ＷＡＮ、またはＰＳＴＮなどの遠隔通信媒体を介して通信する。
【０３２１】
電子メールは、断然一般的であり基本的なグループウェア・アプリケーションである。基本的な技術は、人の間で単純なメッセージを渡すように設計されているが、現在の比較的単純な電子メール・システムであっても、メッセージ転送、メッセージのファイリング、メーリング・グループの作成、およびメッセージへのファイルの添付の機能が含まれる。調査されてきた他の機能には、メッセージの内容ベースのソートおよび処理、メッセージの内容ベースのルーティング、および構造化された通信（ある情報を要求するメッセージ）が含まれる。
【０３２２】
ワークフロー・システムが、グループウェアのもう１つの要素である。ワーク・フロー・システムを用いると、比較的固定されたプロセスを介して、組織内で文書をルーティングできるようになる。ワークフロー・アプリケーションの単純な例が、組織の経費報告である：ある従業員が、経費報告を入力し、サブミットし、コピーが、アーカイブされ、その後、従業員の上司に許可のためにルーティングされ、上司が文書を受け取り、電子的に承認し、回送し、経費が、グループの口座に登録され、支払いのために会計部門に転送される。ワークフロー・システムは、ルーティング、フォームの開発、異なる役職および特権のサポートを提供することができる。
【０３２３】
ハイパーテキストは、テキスト文書を互いにリンクするシステムであり、ウェブが明白な例である。しかし、複数の人が文書を作成し、リンクする時には、必ず、そのシステムが、常に発展し、他人の作業に応答するグループ作業になる。ハイパーテキストのもう１つの一般的なマルチユーザ機能（ウェブではみられない）が、すべてのユーザがすべてのページからリンクを作成できるようにし、その結果、他のユーザが、元の作成者が知らない関連するリンクがある時に知ることができるようにすることである。
【０３２４】
グループ・カレンダリングが、グループウェアのもう１つの態様であり、これによって、多数の人の間のスケジューリング、プロジェクト管理、および調整が容易になり、スケジューリング機器のサポートも提供することができる。通常の特徴では、スケジュールが衝突する時が検出されるか、誰もが働く会議時間が発見される。グループ・カレンダは、人の居場所を知るのにも役立つ。
【０３２５】
協同執筆システムは、リアルタイム・サポートと非リアルタイム・サポートの両方を提供することができる。ワード・プロセッサは、原作者を示すことと、ユーザが変更を追跡し、文書に対する注釈を作成できるようにすることによって、非同期サポートを提供することができる。文書について協同作業する作成者に、文書の部分をロックする方法または別々に作成された文書をリンクする方法など、作成過程を計画し調整するのを助けるツールを与えることもできる。同期サポートを用いると、作成者が、変更を行う時に他者のそれぞれの変更を見ることができるようになり、通常は、作成者が作業する時に作成者に追加の通信チャネルを提供することが必要である。
【０３２６】
グループは、複数の人が、異なる位置からでも、共用される描画面を見、描くことができるようにする共用ホワイトボードなど、同期式またはリアル・タイムとすることができる。これは、たとえば、通話中に、各人がメモ（たとえば名前、電話番号、または地図など）を書き留めるか、視覚的問題について協同で作業するのに使用することができる。ほとんどの共用ホワイトボードは、形式ばらない会話のために設計されているが、協同グラフィック設計応用分野、出版応用分野、またはエンジニアリング応用分野など、構造化された通信またはより洗練された描画タスクをサービスすることもできる。共用ホワイトボードは、各人を識別するためにカラーコードされるかラベルを付けられるテレポインタによって、各人が描画している場所または指している場所を示すことができる。
【０３２７】
グループウェアのもう１つの態様が、ビデオ会議である。ビデオ会議システムは、生ビデオを伴う２方向または多方向の呼を可能にし、本質的には、調整用のタイム・スタンプを伴う追加の視覚的構成要素を有する電話システムである。
【０３２８】
意思決定支援が、グループウェアのもう１つの態様であり、グループの意思決定を促進するように設計される。これは、ブレインストーミング、アイデアの批評、事象および代替物に重みまたは確率を置くこと、および投票のツールを提供する。そのようなシステムは、おそらくは、より合理的で公平な決定を可能にする。これらは、主に会議を容易にするために設計されるが、たとえば、匿名性を提供するか交替を強制することによって、平等な参加を促進する。
【０３２９】
マルチプレイヤ・ゲームが、ゲームセンタで適度に一般的になったが、インターネットで非常に一般的になりつつある。初期の電子ゲームセンタ・ゲームの多数、たとえばPong、Space Wars、および自動車レース・ゲームが、マルチユーザであった。ゲームは、「非協同」マルチユーザ情況の原型的例であるが、競争的なゲームであっても、プレイヤがゲームのルールに従って協力することが必要である。ゲームは、チャット・システムまたはビデオ・システムなど、他の通信媒体によって機能強化することができる。
【０３３０】
グループウェアの製品の例には、Lotus NotesおよびMicrosoftExchangeが含まれ、この両方が、カレンダ共用、電子メール処理、分散システムを介するファイルの複製を容易にし、その結果、すべてのユーザが同一の情報を見られるようになる。
【０３３１】
本発明のコネクタを、グループウェア・アプリケーションにとって特に魅力的にしているのが、グループウェア提供と、グループ・サーバ・アーキテクチャ、実施形態、およびプラットフォームの多様性である。本発明のコネクタは、グループウェア・サーバへのフロント・エンドまたはゲートウェイとして働くことができる。
【０３３２】
図４９に、実際の商品が、売り手から買い手に出荷され、さまざまな形の電子支払いおよび保護された電子支払いが、売り手に支払うために買い手によって使用され、銀行および金融機関が、本明細書に記載のコネクタを介して接続される、商業トランザクションを示す。具体的に言うと、商人または製造業者の売り手４１０１が、「ヒストリ」を有しない顧客４１０３に製品を売る。製品が、出荷される４６０５。しかし、買い手である顧客４１０３は、商品を受け取り、検査し、承認し、「受け入れる」まで金を手放すことを望まず、売り手４１０１は、支払われるまで商品の制御を放棄することを望まない。この基本的な商取引の衝突が、さまざまなパラダイムにつながり、そのほとんどが、ハード・コピーの「擬似金銭」またはある形から別の形への法律文書を伴う。現在、財務トランザクションは、最も頻繁に電子資金転送と、メモ、法律文書、流通証券、荷為替手形、支払い指図書、信用状、倉庫証券、荷渡指図書、船荷証券（商品に対する請求権を含む、すなわち、商品の権利または物理的管理を運搬人または名前を指定された人に譲渡することを意味する権利証券）、および商品の担保権を伴うトランザクションである。通常、顧客４１０３は、売り手４１０１に払い渡す証書を実行し、買い手の銀行４１２１に、売り手の銀行４１２５を介して売り手４１０１に買い手の金を向ける。通常、これは、前に互いに取引した売り手と買い手の間の、前に互いに取引した、同一のまたは互換性があるソフトウェア・アプリケーションを使用している銀行または金融機関を介して扱われる、単純な電子トランザクションである。しかし、これらの事前条件が満足されない特別の場合には、本発明のコネクタによって、トランザクションの電子的な銀行間側を容易にする。
【０３３３】
単一のレベルのアプリケーション・プログラム・インターフェースまたはコンバータを有する応用例に関して本発明を説明し、図示してきたが、そのようなアプリケーション・プログラム・インターフェースまたはコンバータが、処理階層内のさまざまなレベルに、たとえばウェブ・クライアントとウェブ・サーバの間、ウェブ・サーバとアプリケーション・サーバの間、アプリケーション・サーバとデータベース・サーバの間、およびアプリケーション・サーバまたはデータベース・サーバまたはその両方とさまざまな特殊リポジトリの間に、存在することができることを理解されたい。
【０３３４】
本発明を、ある好ましい実施形態と、個々のクライアントおよび個々のサーバを有する例示を用いて説明し、図示してきたが、グループウェア・アプリケーションによって例証されるように、複数のクライアント、複数のサーバ、およびクライアントとサーバの両方として機能するアプリケーションが存在することができ、リッチ・トランザクションのシステム内で、アプリケーション・サーバ、データ・サーバ、およびデータベースの複数の並列の線または複数の階層レベルあるいはその両方が存在することができることも理解されたい。
【０３３５】
本発明を、ある好ましい実施形態および例示に関して説明してきたが、これによって本発明の範囲を制限することは意図されておらず、本発明の範囲は、請求項のみによって制限される。
【図面の簡単な説明】
【図１】 NetscapeまたはInternet Explorerブラウザ、SunSolarisサーバ上のNet.Commerce、データベース・サーバ上のOracleおよびＤＢ２、ＡＩＸで稼動するＳＡＰ、ＣＩＣＳ ３９０サーバ、ＩＭＳ ３９０サーバ、Ｓ／３９０プラットフォーム上のＤＢ２およびＤＬ／Ｉ、Windows(R)2000クライアント、およびHPUnix(R)サーバ上で稼動するＢａａｎを含む、複数のアプリケーション・コンポーネントを有するシステムを示す図である。
【図２】 実行時のエンタープライズ・アプリケーション統合を促進するために共通アプリケーション・メタモデルのメタデータ・リポジトリへの入力としてのメッセージ・セット、ＳＱＬストアド・プロシージャ、レガシ・アプリケーション、およびプログラミング言語の役割を示す図である。
【図３】 ３種類のメタモデルすなわち、呼出しメタモデル、アプリケーションドメイン・インターフェース・メタモデル、および言語メタモデルからなる本発明の共通アプリケーション・メタモデルを示す図である。所与のアプリケーションドメイン・メタモデルについて、１つまたは複数の言語メタモデルを使用することができ、０個以上の呼出しメタモデルを設けることができる。
【図４】 ＯＴＭＡ呼出しメタモデル、ＩＭＳトランザクション・メッセージ・メタモデル・アプリケーション・インターフェースを伴い、COBOLメタモデル、Ｃメタモデル、または他の言語メタモデルを使用することができる、ＩＭＳ ＯＴＭＡメタモデルを示す図である。
【図５】 アプリケーション・プログラミング・インターフェースを記述したＸＭＬ文書を生成するのにツールをどのように使用することができるかを示す図である。まず、オブジェクト・モデルすなわちＣＡＭメタモデルを作成して、アプリケーション・サーバに関するインターフェース定義を取り込む。その後、ツールが、アプリケーション・プログラムのソース定義を読み取り、解析し、オブジェクト・モデルの情報をリポジトリから検索することによってＸＭＬ文書を生成する。
【図６】 共通アプリケーション・メタモデルRoseファイル、たとえばCOBOLメタモデル、ＰＬ／Ｉメタモデル、ＭＦＳメタモデル、ＢＭＳメタモデル、および類似物をツールキットに読み取って、Roseモデル用のＤＴＤ、ＸＭＬスキーマ、およびJava(R)コードを生成する、開発フェーズのシナリオを示す図である。COBOLソース・ファイル、ＰＬ／Ｉソース・ファイル、ＭＦＳソース・ファイル、ＢＭＳソース・ファイル、および類似物としてのアプリケーションのソース・ファイルが、インポータに読み込まれる。インポータは、ソース・コードを解析し、アプリケーション・ソース・ファイルのRoseモデルのJava(R)コードを読み込むことによって、出力としてＸＭＩインスタンス・ファイルすなわちＸＭＬ文書を生成する。
【図７】 アプリケーション・コンポーネントの、フロー・モデルを含むイベント・ベース・メッセージング・モデルへの統合を可能にする、アプリケーション・インターフェースのメタモデルを示す図である。フローおよびメッセージング・ミドルウェアが、アプリケーション・インターフェースを介してアプリケーションを呼び出す。これらのインターフェースは、それを介してすべての入出力がミドルウェアに接続されるアプリケーションへのアクセス点である。インターフェースは、アプリケーション・インターフェース・メタモデルに関して記述される。メタモデルによる変換処理は、ソース／クライアント・アプリケーション、ターゲット・アプリケーション、またはゲートウェイで行うことができる。
【図８】 実行時中の共通アプリケーション・メタモデルの適用を示す図である。図からわかるように、ＣＡＭモデルが、バックエンドＩＭＳアプリケーションとウェブ・ファイル（たとえばＳＯＡＰ準拠ＸＭＬ文書）の間の接続性を促進する。これは、モデルに取り込まれた情報を使用して、図示の混合言語環境で、あるプラットフォームから別のプラットフォームへのデータ変換を行うことによって達成される。
【図９】 TypeDescriptorメタモデルが、全体的なデータ構造体名およびフィールド名の言語固有メタモデルを用い、言語モデルに存在する集約関連を複製せずに、実行時データ変換の処方またはテンプレートして使用される、TDLang基本クラスを示す図である。
【図１０】 TypeDescriptorメタモデルのＭ２レベルのＭＯＦクラス・インスタンスを示す図である。
【図１１】 TypeDescriptorメタモデルのＭ２レベルのＭＯＦクラス・インスタンスを示す図である。
【図１２】 TypeDescriptorメタモデルのＭ２レベルのＭＯＦクラス・インスタンスを示す図である。
【図１３】 TDLangメタモデルのTDLangElementとTypeDescriptorメタモデルのPlatformCompilerTypeとの間の関連を示す図である。
【図１４】 TypeDescriptorメタモデルのさまざまな列挙型、たとえば、signCoding、lengthEncoding、floatType、accessor、packedDecimalSign、およびbitModelPadを示す図である。
【図１５】 コネクタ・インターフェースを表すデータ構造体セマンティクスを定義するためのCOBOLメタモデルを示す図である。このメタモデルは、Ｍ２レベルのＭＯＦクラス・インスタンスでもある。
【図１６】 コネクタ・インターフェースを表すデータ構造体セマンティクスを定義するためのCOBOLメタモデルを示す図である。このメタモデルは、Ｍ２レベルのＭＯＦクラス・インスタンスでもある。
【図１７】 TDLangClassifier、TDLanguageComposedType、およびTDLangElementである、COBOLメタモデルとTDLang基本クラスの間の関連を示す図である。
【図１８】 COBOLメタモデルのCOBOLUsageValuesの列挙を示す図である。
【図１９】 コネクタ・インターフェースを表すデータ構造体を定義するためにアプリケーション・プログラムによって使用可能なＰＬ／Ｉ言語メタモデルを示す図である。このメタモデルは、Ｍ２レベルのＭＯＦクラス・インスタンスである。
【図２０】 コネクタ・インターフェースを表すデータ構造体を定義するためにアプリケーション・プログラムによって使用可能なＰＬ／Ｉ言語メタモデルを示す図である。このメタモデルは、Ｍ２レベルのＭＯＦクラス・インスタンスである。
【図２１】 コネクタ・インターフェースを表すデータ構造体を定義するためにアプリケーション・プログラムによって使用可能なＰＬ／Ｉ言語メタモデルを示す図である。このメタモデルは、Ｍ２レベルのＭＯＦクラス・インスタンスである。
【図２２】 ＰＬ／ＩメタモデルについてはTDLangClassifier、TDLanguageComposedType、およびTDLanguageElementである、ＰＬ／ＩメタモデルとTDLang基本クラスの関連を示す図である。
【図２３】 ＰＬ／ＩメタモデルのModeValues、BaseValues、LengthTypes、およびStringTypeValuesの列挙を示す図である。
【図２４】 Ｃ Main言語メタモデルを示す図である。
【図２５】 TDLangClassifier、TDLangComposedType、およびTDLangElementである、ＣメタモデルとTDLang基本クラスの間の関連を示す図である。
【図２６】 Ｃ言語メタモデルのTypedElement態様を示す図である。
【図２７】 Ｃ言語メタモデルでのユーザ定義データ型を含む、Ｃメタモデルのユーザ定義データ型を示す図である。
【図２８】 Ｃ言語メタモデルでのDatatype-StringおよびDatatype-Integer、ならびにDirectionKindの引数および戻り値の列挙およびBooleanデータ型のtrueおよびfalseの列挙を示す図である。
【図２９】 Ｃ Mainメタモデルから継承するC++ Mainメタモデルを示す図である。このモデルには、C++メタモデルのDerived、Structured、BehavioralFeatures、Field、およびDerivableTypesが含まれる。
【図３０】 C++メタモデルの可視性型の列挙を示す図である。C++が、オブジェクト指向言語であり、オブジェクト指向プログラミングに有用であり、public、private、およびprotectedの可視性をサポートすることに留意されたい。
【図３１】 ３種類のトランザクション・メッセージすなわち、プレフィックス付きのＩＭＳ−ＯＴＭＡメッセージ、デフォルトＯＴＭＡプレフィックスをＩＭＳが構築することができるプレフィックスなしのＩＭＳメッセージ、およびアプリケーション・プログラムに直接に送ることができるＩＭＳ基本メッセージを含む、ＩＭＳトランザクション・メッセージのメタモデルを示す図である。
【図３２】 ＯＴＭＡプレフィックス・メタデータ・モデルを示す図である。
【図３３】 制御データ定義データ型のＯＴＭＡプレフィックスを示す図である。
【図３４】 状態定義データ型のＯＴＭＡプレフィックスを示す図である。
【図３５】 セキュリティ定義型のＯＴＭＡプレフィックスを示す図である。
【図３６】 ＩＭＳメタモデルのＩＭＳメッセージ・プリミティブを示す図である。
【図３７】 コネクタ・インターフェースを表すデータ構造体セマンティクスを定義するHighLevel Assembly Language（HLASM）メタモデルを示す図である。このメタモデルは、Ｍ２レベルのＭＯＦクラス・インスタンスでもある。
【図３８】 TDLangClassifier、TDLanguageComposedType、およびTDLangElementである、HLASMメタモデルとTDLang基本クラスの間の関連を示す図である。
【図３９】 HLASMメタモデルでのHLASM使用値の列挙を示す図である。
【図４０】 コネクタ・インターフェースを表すデータ構造体を定義するためにアプリケーション・プログラムによって使用可能なＣＩＣＳ ＢＭＳ言語メタモデルを示す図である。
【図４１】 BMSMetaModelの属性、フィールド、属性値、およびマップを示す図である。
【図４２】 BMSMetaModelの属性、フィールド、属性値、およびマップを示す図である。
【図４３】 コネクタ・インターフェースを表すデータ構造体を定義するためにアプリケーション・プログラムによって使用可能なＭＦＳ言語メタモデルを示す図である。
【図４４】 ＭＦＳメタモデルのクラスの間の関連を示す図である。
【図４５】 ＭＦＳメタモデルのModeValues、BaseValues、LengthTypes、およびStringTypeValuesの列挙を示す図である。
【図４６】 ＭＦＳメタモデルのModeValues、BaseValues、LengthTypes、およびStringTypeValuesの列挙を示す図である。
【図４７】 たとえば注文が端末で入力され、ウェブ・サーバに渡され、ウェブ・サーバを介して製造業者のアプリケーション・サーバに渡される、「リッチ」トランザクションに関する単純化されたネットワーク構成を示す図である。製造業者のアプリケーション・サーバは、それ自体のデータベース・サーバならびに、本明細書に記載のコネクタによって透過的に接続されたそのベンダの似ていない非互換のデータベース・サーバおよびデータベースを介して検索し、構成要素の状況、価格、および配送日付を照会し、注文を満足するのに必要な構成要素の注文を行う。
【図４８】 複数の異なるプラットフォームで稼動し、本明細書に記載の共通アプリケーション・メタモデルを使用して接続される、複数のグループ・ウェア・アプリケーションにまたがって分散されたグループ・ウェア・セッションを示す図である。
【図４９】 実際の商品が売り手から買い手に出荷され、さまざまな形の電子支払いおよび保護された電子支払いが、売り手に支払うために買い手によって使用され、銀行および金融機関が、本明細書に記載の共通アプリケーション・メタモデルを使用して接続される、商取引を示す図である。

Claims (14)

  1. エンド・ユーザ・アプリケーションおよびアプリケーション・サーバでアプリケーション要求を処理する方法であって、
    ａ）第１アプリケーション・プログラムを用いて第１ソース言語で前記エンド・ユーザ・アプリケーション上で開始した前記アプリケーション要求を前記サーバが受信するステップと、
    ｂ）前記アプリケーション要求を前記エンド・ユーザ・アプリケーションの前記第１ソース言語から前記アプリケーション・サーバ上で稼動する第１ターゲット言語に変換するステップと、
    ｃ）前記アプリケーション・サーバ上で前記アプリケーション要求を処理するステップと、
    ｄ）前記アプリケーション要求に対する応答を、前記アプリケーション・サーバから前記エンド・ユーザ・アプリケーションに送信し、前記アプリケーション要求に対する前記応答を、前記アプリケーション・サーバ上で稼動する前記第１ターゲット言語から前記エンド・ユーザ・アプリケーションの前記第１ソース言語に変換するステップと
    を含み、
    ｅ）前記アプリケーション・サーバが、前記エンド・ユーザ・アプリケーションとの間の少なくとも１つのコネクタを有し、前記コネクタは、
    （ｉ）前記アプリケーション要求を、前記エンド・ユーザ・アプリケーションの前記第１ソース言語から前記アプリケーション・サーバ上で稼動する前記第１ターゲット言語に変換するステップと、
    （ｉｉ）前記アプリケーション要求に対する応答を、第２ソース言語である前記アプリケーション・サーバ上で稼動する前記第１ターゲット言語から第２ターゲット言語である前記第１エンド・ユーザ・アプリケーションの前記第１ソース言語に変換するステップとを含み、前記（ｉ）および（ｉｉ）の各ステップが、
    １）呼出しメタモデルとアプリケーション・インタフェース・メタモデルと言語メタモデルとを含み、各々のソース言語およびターゲット言語の前記コネクタ・メタモデルを呼び出すステップと、
    ２）前記各々のソース言語およびターゲット言語のそれぞれのメタモデル・メタデータを前記コネクタ・メタモデルに移植するステップと、
    ３）前記ソース言語を前記ターゲット言語に変換するステップと
    を含み、前記言語メタモデルは、前記アプリケーション・インタフェース・メタモデルにプラグインされる、方法。
  2. 前記エンド・ユーザ・アプリケーションが、ウェブ・ブラウザである、請求項１に記載の方法。
  3. 前記エンド・ユーザ・アプリケーションが、ウェブ・サーバを介して前記アプリケーション・サーバに接続され、前記ウェブ・サーバが、前記コネクタ・メタモデルを含む、請求項２に記載の方法。
  4. 前記メタモデル・メタデータが、呼出しメタモデル・メタデータ、アプリケーション・ドメイン・インターフェース・メタモデル・メタデータ、および型記述子メタモデル・メタデータを含む、請求項１に記載の方法。
  5. 前記アプリケーション・ドメイン・インターフェース・メタモデル・メタデータが、さらに、言語メタモデル・メタデータを含む、請求項４に記載の方法。
  6. 前記言語メタモデル・メタデータが、ソース言語とターゲット言語との間のマッピングを含む、請求項５に記載の方法。
  7. 前記ソース言語または前記ターゲット言語の１つが、ＣおよびＣ＋＋からなる群から選択される、請求項１に記載の方法。
  8. クライアント、サーバ、およびそれらの間の少なくとも１つのコネクタを含むトランザクション処理システムであって、
    ａ）前記サーバは、前記クライアントが、エンド・ユーザ・アプリケーションを有し、第１アプリケーション・プログラムを用いて第１ソース言語で前記サーバとのアプリケーション要求を開始し、前記アプリケーション要求を受信する手段と、
    ｂ）前記コネクタが、前記クライアントから前記アプリケーション要求を受信し、前記アプリケーション要求を前記クライアント上で稼動する前記エンド・ユーザ・アプリケーションの前記第１ソース言語から前記サーバ上で稼動する第１ターゲット言語に変換する手段と、
    ｃ）前記サーバが、前記第１ターゲット言語に変換されたアプリケーション要求を前記コネクタから受信し、前記サーバに常駐する第２アプリケーション・プログラムを用いて前記第１ターゲット言語で前記アプリケーション要求を処理し、その後、前記アプリケーション要求に対する応答を、前記コネクタを介して前記クライアント上の前記第１アプリケーション・プログラムに送信する手段とを含み、
    ｄ）前記コネクタが、前記サーバから前記アプリケーション要求に対する応答を受信し、前記アプリケーション要求に対する応答を前記アプリケーション・サーバ上で稼動する前記第１ターゲット言語から前記クライアント上で稼動する前記第１アプリケーション・プログラムの前記第１ソース言語に変換しており、
    ｅ）前記コネクタが、
    １）メタモデル・メタデータ・リポジトリから、呼出しメタモデルとアプリケーション・インタフェース・メタモデルと言語メタモデルとを含み、各々のソース言語およびターゲット言語のためのコネクタ・メタモデルを検索する手段と、
    ２）前記各々のソース言語およびターゲット言語のそれぞれの前記メタモデル・メタデータ・リポジトリからのメタモデル・データを前記コネクタ・メタモデルに移植するステップと、
    ３）前記検索され移植されたコネクタ・メタモデルを呼び出し、前記ソース言語を前記ターゲット言語に変換する手段と
    を含み、前記言語メタモデルは、前記アプリケーション・インタフェース・メタモデルにプラグインされ、
    （ｉ）前記アプリケーション要求を、前記クライアント上の前記クライアント・アプリケーションの前記第１ソース言語からターゲット言語としての前記アプリケーション・サーバ上で稼動する前記第１ターゲット言語に変換し、
    （ｉｉ）前記アプリケーション要求に対する前記応答を、第２ソース言語である前記アプリケーション・サーバ上で稼動する前記第１ターゲット言語から、第２ターゲット言語である前記クライアント上で稼動する前記クライアント・アプリケーションの前記第１ソース言語に変換する、
    トランザクション処理システム。
  9. 前記エンド・ユーザ・アプリケーションが、ウェブ・ブラウザである、請求項８に記載のシステム。
  10. 前記エンド・ユーザ・アプリケーションが、ウェブ・サーバを介して前記アプリケーション・サーバに接続され、前記ウェブ・サーバが、コネクタを含む、請求項９に記載のシステム。
  11. 前記メタモデル・メタデータが、呼出しメタモデル・メタデータ、アプリケーション・ドメイン・インターフェース・メタモデル・メタデータ、および型記述子メタモデル・メタデータを含む、請求項８に記載のシステム。
  12. 前記言語メタモデル・メタデータが、ソース言語とターゲット言語との間のマッピングを含む、請求項８に記載のシステム。
  13. 前記ソース言語または前記ターゲット言語の１つが、ＣおよびＣ＋＋からなる群から選択される、請求項８に記載のシステム。
  14. 請求項１〜７のいずれか１項の記載のアプリケーション要求を処理する方法を実行する装置実行可能なプログラムを記録した記録媒体。
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 JP2004506264A (ja) 2004-02-26
JP3842213B2 true 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 (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8127090B2 (en) 2007-03-19 2012-02-28 Ricoh Company, Limited Information processing method, and information processing system

Families Citing this family (160)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002087112A2 (en) 2001-04-18 2002-10-31 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
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
US7275038B1 (en) * 2000-08-18 2007-09-25 The Crawford Group, Inc. Web enabled business to business operating system for rental car 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
US9908608B2 (en) 2001-04-18 2018-03-06 Space Data Corporation Systems and applications of lighter-than-air (LTA) platforms
US9643706B2 (en) 2001-04-18 2017-05-09 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
US20030149740A1 (en) * 2002-02-04 2003-08-07 Wookey Michael J. Remote services delivery architecture
US20030149771A1 (en) * 2002-02-04 2003-08-07 Wookey Michael J. Remote services system back-channel multicasting
US7167448B2 (en) * 2002-02-04 2007-01-23 Sun Microsystems, Inc. Prioritization of remote services messages within a low bandwidth environment
US20030177259A1 (en) * 2002-02-04 2003-09-18 Wookey Michael J. Remote services systems data delivery mechanism
US20030163544A1 (en) * 2002-02-04 2003-08-28 Wookey Michael J. Remote service systems management interface
US20040015578A1 (en) * 2002-02-22 2004-01-22 Todd Karakashian Web services runtime architecture
US7769825B2 (en) * 2002-02-22 2010-08-03 Bea Systems, Inc. System and method for web services Java API-based invocation
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
US7240109B2 (en) * 2002-06-27 2007-07-03 Sun Microsystems, Inc. Remote services system service module interface
US7260623B2 (en) * 2002-06-27 2007-08-21 Sun Microsystems, Inc. Remote services system communication module
US7181455B2 (en) * 2002-06-27 2007-02-20 Sun Microsystems, Inc. Bandwidth management for remote services system
US8266239B2 (en) * 2002-06-27 2012-09-11 Oracle International Corporation Remote services system relocatable mid level manager
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
US20040103370A1 (en) * 2002-11-27 2004-05-27 International Business Machines Corporation System and method for rendering MFS XML documents for display
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
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
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
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
CN101091162B (zh) * 2004-12-30 2010-09-08 Nxp股份有限公司 数据处理装置和运行该装置的方法
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
US8050801B2 (en) * 2005-08-22 2011-11-01 Trane International Inc. Dynamically extensible and automatically configurable building automation system and architecture
US8099178B2 (en) * 2005-08-22 2012-01-17 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
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
US8024054B2 (en) * 2005-08-22 2011-09-20 Trane International, Inc. Building automation system facilitating user customization
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
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
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
JP5187308B2 (ja) * 2007-08-01 2013-04-24 日本電気株式会社 変換プログラム探索システムおよび変換プログラム探索方法
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
JP4635058B2 (ja) * 2008-01-09 2011-02-16 日本電信電話株式会社 機能分散型パケット転送システム及びこれを用いた制御方法
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
JP5124375B2 (ja) * 2008-07-18 2013-01-23 Ｋｄｄｉ株式会社 情報処理装置
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
US8219660B2 (en) 2010-02-26 2012-07-10 Trane International Inc. Simultaneous connectivity and management across multiple building automation system networks
US8793022B2 (en) 2010-02-26 2014-07-29 Trane International, Inc. Automated air source and VAV box association
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
KR101189773B1 (ko) 2010-12-31 2012-10-10 전자부품연구원 사용자 시청상황 정보를 적용한 스케일러블 애플리케이션 서비스 시스템 및 방법
US20120233584A1 (en) * 2011-03-09 2012-09-13 Nec Laboratories America, Inc. Analysis of Interactions of C and C++ Strings
JP5732926B2 (ja) * 2011-03-09 2015-06-10 日本電気株式会社 リモートプロシージャコール処理方法
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 大唐网络有限公司 数据处理方法及装置
EP2912579B1 (en) 2012-10-23 2020-08-19 IP Reservoir, LLC Method and apparatus for accelerated format translation of data in a delimited data format
US8756614B2 (en) 2013-06-05 2014-06-17 Splunk Inc. Central registry for binding features using dynamic pointers
US8756593B2 (en) * 2013-06-05 2014-06-17 Splunk Inc. Map generator for representing interrelationships between app features forged by dynamic pointers
US9594545B2 (en) 2013-06-05 2017-03-14 Splunk Inc. System for displaying notification dependencies between component instances
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
BR112017013836B1 (pt) 2014-12-24 2022-05-24 Space Data Corporation Separação de uma plataforma mediante colisão pendente
US10403160B2 (en) 2014-12-24 2019-09-03 Space Data Corporation Techniques for intelligent balloon/airship launch and recovery window location
CN104503942B (zh) * 2014-12-30 2017-10-31 合肥金星机电科技发展有限公司 串口指令解码方法
US10059421B2 (en) 2014-12-30 2018-08-28 Space Data Corporation Multifunctional balloon membrane
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
US10353534B2 (en) 2016-05-13 2019-07-16 Sap Se Overview page in multi application user interface
US10579238B2 (en) 2016-05-13 2020-03-03 Sap Se Flexible screen layout across multiple platforms
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
US11137988B2 (en) * 2017-06-02 2021-10-05 Mitsubishi Electric Corporation Program code generation device and computer readable medium
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 宋子杰 一种基于源代码聚合的嵌入式系统配置方法
CN118519638A (zh) * 2019-04-25 2024-08-20 阿里巴巴（中国）有限公司 代码生成方法及装置
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
US12012110B1 (en) 2023-10-20 2024-06-18 Crawford Group, Inc. Systems and methods for intelligently transforming data to generate improved output data using a probabilistic multi-application network

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 (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8127090B2 (en) 2007-03-19 2012-02-28 Ricoh Company, Limited Information processing method, and information processing system

Also Published As

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

Similar Documents

Publication Publication Date Title
JP3842213B2 (ja) Ｃ／ｃ＋＋メタモデルを含む共通アプリケーション・メタモデル
US6904598B2 (en) COBOL metamodel
US6964053B2 (en) Type descriptor language (TDLanguage) metamodel
US6915523B2 (en) PL/I metamodel
US6775680B2 (en) High level assembler metamodel
US6912719B2 (en) Type descriptor metamodel
US6948174B2 (en) IMS MFS (message format service) metamodel
US7559066B2 (en) CICS BMS (basic message service) meta model
US20020038336A1 (en) IMS transaction messages metamodel
KR100684680B1 (ko) 확장가능한 분산된 기업용 애플리케이션 통합 시스템
US6931623B2 (en) Method of accessing data and logic on existing systems through dynamic construction of software components
Brose et al. Java programming with CORBA: advanced techniques for building distributed applications
KR100898476B1 (ko) 스키마 기반의 계층적 데이터 구조를 단층적 데이터구조로 변환하기 위한 방법 및 시스템
US6349404B1 (en) Object-oriented repository, a system and method for reusing existing host-based application assets for the development of business-centric applications
US7028312B1 (en) XML remote procedure call (XML-RPC)
US7512957B2 (en) Interface infrastructure for creating and interacting with web services
US20060294048A1 (en) Data centric workflows
Serain Middleware and enterprise application integration: the architecture of e-business solutions
US20050278345A1 (en) A system and method for speeding xml construction for a business transaction using prebuilt xml with static and dynamic sections
Bergland et al. Integrating Systems Through Universal Transformation Using IBM WebSphere Transformation Extender
Akbay et al. Design and implementation of an enterprise information system utilizing a component based three-tier client/server database system
Min of the Paper
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 Request for written amendment filed

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 Request for written amendment filed

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