JP3842213B2 - C/c++メタモデルを含む共通アプリケーション・メタモデル - Google Patents
C/c++メタモデルを含む共通アプリケーション・メタモデル Download PDFInfo
- 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
Links
- 238000000034 method Methods 0.000 claims description 54
- 230000004044 response Effects 0.000 claims description 54
- 238000012545 processing Methods 0.000 claims description 39
- 238000013507 mapping Methods 0.000 claims description 21
- 230000008569 process Effects 0.000 claims description 13
- 230000000977 initiatory effect Effects 0.000 claims description 2
- 230000006870 function Effects 0.000 description 99
- 238000003860 storage Methods 0.000 description 74
- 238000007667 floating Methods 0.000 description 46
- 101000772194 Homo sapiens Transthyretin Proteins 0.000 description 37
- 102100029290 Transthyretin Human genes 0.000 description 37
- 238000010586 diagram Methods 0.000 description 31
- 238000006243 chemical reaction Methods 0.000 description 24
- 230000014509 gene expression Effects 0.000 description 19
- 230000001360 synchronised effect Effects 0.000 description 19
- 230000005540 biological transmission Effects 0.000 description 18
- 230000010354 integration Effects 0.000 description 17
- 101001074449 Crotalus durissus terrificus Phospholipase A2 inhibitor CNF Proteins 0.000 description 16
- 239000003607 modifier Substances 0.000 description 12
- 238000004891 communication Methods 0.000 description 11
- 241000220317 Rosa Species 0.000 description 10
- 230000002776 aggregation Effects 0.000 description 10
- 238000004220 aggregation Methods 0.000 description 10
- 230000003068 static effect Effects 0.000 description 10
- 101100386699 Neurospora crassa (strain ATCC 24698 / 74-OR23-1A / CBS 708.71 / DSM 1257 / FGSC 987) dcl-1 gene Proteins 0.000 description 9
- 238000001514 detection method Methods 0.000 description 9
- 230000000694 effects Effects 0.000 description 9
- 238000004364 calculation method Methods 0.000 description 8
- 238000011161 development Methods 0.000 description 7
- 238000012360 testing method Methods 0.000 description 7
- 238000012546 transfer Methods 0.000 description 7
- 238000003491 array Methods 0.000 description 6
- 238000012790 confirmation Methods 0.000 description 6
- 230000008859 change Effects 0.000 description 5
- 238000007726 management method Methods 0.000 description 5
- 230000007246 mechanism Effects 0.000 description 5
- 230000001052 transient effect Effects 0.000 description 5
- PBGKNXWGYQPUJK-UHFFFAOYSA-N 4-chloro-2-nitroaniline Chemical compound NC1=CC=C(Cl)C=C1[N+]([O-])=O PBGKNXWGYQPUJK-UHFFFAOYSA-N 0.000 description 4
- 230000027455 binding Effects 0.000 description 4
- 238000009739 binding Methods 0.000 description 4
- 238000013501 data transformation Methods 0.000 description 4
- 230000001419 dependent effect Effects 0.000 description 4
- 238000006073 displacement reaction Methods 0.000 description 4
- 239000000203 mixture Substances 0.000 description 4
- 230000000007 visual effect Effects 0.000 description 4
- 230000003542 behavioural effect Effects 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 238000004519 manufacturing process Methods 0.000 description 3
- 230000008520 organization Effects 0.000 description 3
- 230000010076 replication Effects 0.000 description 3
- 230000002441 reversible effect Effects 0.000 description 3
- 239000000344 soap Substances 0.000 description 3
- 238000000547 structure data Methods 0.000 description 3
- 238000010200 validation analysis Methods 0.000 description 3
- 101150012579 ADSL gene Proteins 0.000 description 2
- 101150026173 ARG2 gene Proteins 0.000 description 2
- 102100020775 Adenylosuccinate lyase Human genes 0.000 description 2
- 108700040193 Adenylosuccinate lyases Proteins 0.000 description 2
- 101100005166 Hypocrea virens cpa1 gene Proteins 0.000 description 2
- 235000006508 Nelumbo nucifera Nutrition 0.000 description 2
- 240000002853 Nelumbo nucifera Species 0.000 description 2
- 235000006510 Nelumbo pentapetala Nutrition 0.000 description 2
- 101100379633 Xenopus laevis arg2-a gene Proteins 0.000 description 2
- 101100379634 Xenopus laevis arg2-b gene Proteins 0.000 description 2
- 239000008186 active pharmaceutical agent Substances 0.000 description 2
- 238000004458 analytical method Methods 0.000 description 2
- 101150088826 arg1 gene Proteins 0.000 description 2
- 238000013475 authorization Methods 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 230000000295 complement effect Effects 0.000 description 2
- 230000006835 compression Effects 0.000 description 2
- 238000007906 compression Methods 0.000 description 2
- 238000013479 data entry Methods 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 230000007935 neutral effect Effects 0.000 description 2
- 238000005192 partition Methods 0.000 description 2
- 238000000275 quality assurance Methods 0.000 description 2
- 238000006467 substitution reaction Methods 0.000 description 2
- XGLWGCATXFVQIR-NUUCADPSSA-N (4s,5r)-5-(5-methyl-2-propan-2-ylcyclohexyl)oxy-4-phenylsulfanyloxolan-2-one Chemical compound CC(C)C1CCC(C)CC1O[C@H]1[C@@H](SC=2C=CC=CC=2)CC(=O)O1 XGLWGCATXFVQIR-NUUCADPSSA-N 0.000 description 1
- PLIKAWJENQZMHA-UHFFFAOYSA-N 4-aminophenol Chemical compound NC1=CC=C(O)C=C1 PLIKAWJENQZMHA-UHFFFAOYSA-N 0.000 description 1
- 241000143437 Aciculosporium take Species 0.000 description 1
- 101100138677 Arabidopsis thaliana NPF8.1 gene Proteins 0.000 description 1
- 101100031674 Arabidopsis thaliana NPF8.3 gene Proteins 0.000 description 1
- ZAKOWWREFLAJOT-CEFNRUSXSA-N D-alpha-tocopherylacetate Chemical compound CC(=O)OC1=C(C)C(C)=C2O[C@@](CCC[C@H](C)CCC[C@H](C)CCCC(C)C)(C)CCC2=C1C ZAKOWWREFLAJOT-CEFNRUSXSA-N 0.000 description 1
- RWSOTUBLDIXVET-UHFFFAOYSA-N Dihydrogen sulfide Chemical compound S RWSOTUBLDIXVET-UHFFFAOYSA-N 0.000 description 1
- 101100126169 Escherichia coli (strain K12) intF gene Proteins 0.000 description 1
- 102100030488 HEAT repeat-containing protein 6 Human genes 0.000 description 1
- 101000990566 Homo sapiens HEAT repeat-containing protein 6 Proteins 0.000 description 1
- 101000801684 Homo sapiens Phospholipid-transporting ATPase ABCA1 Proteins 0.000 description 1
- 235000000177 Indigofera tinctoria Nutrition 0.000 description 1
- 101150059273 PTR1 gene Proteins 0.000 description 1
- 101100262635 Saccharomyces cerevisiae (strain ATCC 204508 / S288c) UBR1 gene Proteins 0.000 description 1
- 101100235787 Schizosaccharomyces pombe (strain 972 / ATCC 24843) pim1 gene Proteins 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000001174 ascending effect Effects 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 238000003490 calendering Methods 0.000 description 1
- 230000002860 competitive effect Effects 0.000 description 1
- 239000002131 composite material Substances 0.000 description 1
- 238000005034 decoration Methods 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 230000009365 direct transmission Effects 0.000 description 1
- 238000009826 distribution Methods 0.000 description 1
- 238000005553 drilling Methods 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 238000007373 indentation Methods 0.000 description 1
- 229940097275 indigo Drugs 0.000 description 1
- COHYTHOBJLSHDF-UHFFFAOYSA-N indigo powder Natural products N1C2=CC=CC=C2C(=O)C1=C1C(=O)C2=CC=CC=C2N1 COHYTHOBJLSHDF-UHFFFAOYSA-N 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 238000011835 investigation Methods 0.000 description 1
- 239000011159 matrix material Substances 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 230000035755 proliferation Effects 0.000 description 1
- 230000001681 protective effect Effects 0.000 description 1
- 101150114015 ptr-2 gene Proteins 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- VLCQZHSMCYCDJL-UHFFFAOYSA-N tribenuron methyl Chemical compound COC(=O)C1=CC=CC=C1S(=O)(=O)NC(=O)N(C)C1=NC(C)=NC(OC)=N1 VLCQZHSMCYCDJL-UHFFFAOYSA-N 0.000 description 1
- PRBORDFJHHAISJ-UHFFFAOYSA-N tybamate Chemical group CCCCNC(=O)OCC(C)(CCC)COC(N)=O PRBORDFJHHAISJ-UHFFFAOYSA-N 0.000 description 1
- 238000012800 visualization Methods 0.000 description 1
- 239000011800 void material Substances 0.000 description 1
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
【発明の属する技術分野】
本発明は、データの転送、交換または処理が作動可能であることを知らせるための、またはアプリケーション間でのデータ転送に関する少なくとも1つまたは複数のパラメータを確立するためのアプリケーション間の命令またはデータあるいはその両方の交換と、データの転送および通信を容易にするためのパラメータの制御に関する。本発明は、さらに、たとえば複数のコンピュータ、複数のオペレーティング・システム、複数のアプリケーション・コンポーネント、複数の開発環境、複数の展開環境、または複数のテストおよび処理など、一方があるプラットフォームで実行され他方が別のプラットフォームで実行される異なるアプリケーションの統合と、全体的な目標を達成するためにデータまたはその一部に対するタスクの実行を容易にするためにアプリケーション間でデータまたは命令あるいはその両方を転送するための接続性を確立するためのお互いとのダイアログ(たとえばネゴシエーション)の確立とに関する。パラメータには、1つまたは複数のフォーマット、データ型、データ構造体、またはコマンドを含めることができる。
【0002】
【従来の技術】
関連出願の相互参照
本願は、米国特許法セクション111(b)および119(e)の下で、米国仮特許出願第60/223671号および米国特許出願第09/849107号の利益を主張する。
【0003】
本願は、本願と同一の日付に出願された下記の米国特許出願にも関する。
米国特許出願第09/849813号。
米国特許出願第09/849563号。
米国特許出願第09/849190号。
米国特許出願第09/849377号。
米国特許出願第09/849816号。
米国特許出願第09/849105号。
米国特許出願第09/849793号。
【0004】
e-businessの成長によって、レガシ・アプリケーションを統合し、インターネットに持ち込む重大な必要が生じた。これは、新しいアプリケーションが、エンド・ユーザ・アプリケーションの構成およびスケーラビリティを単純にするウェブ標準規格を包含するという現在の傾向のゆえである。さらに、新しいアプリケーションが作成される際に、それらを既存のシステムにシームレスに統合しながら、新しいビジネス・プロセスおよびパラダイムの導入を容易にすることが非常に重要である。
【0005】
既存のアプリケーションとの新しいアプリケーションの統合は、e-commerceに特に関連するデータを含む企業データの70%以上がメインフレーム・コンピュータ上にあると産業アナリストが推定しているので、特にクリティカルである。さらに、多数のe-commerceトランザクションが、Windows(R)、Mac、およびLinuxのエンド・ユーザ・プラットフォームで、さまざまなウェブ・ブラウザを使用して開始され、Windows(R)NTサーバおよびUnix(R)サーバを介して進むが、これらのトランザクションは、最終的にはメインフレーム・アプリケーションが稼動するメインフレーム・コンピュータで完了し、メインフレーム・データベースに格納されたデータに影響する。
【0006】
サーバ・レベル・アプリケーションを統合し、インターネットに持ち込むことに関するe-businessからの圧力がある。しかし、アプリケーションを統合またはe-business対応にする完全で簡単な機構はない。統合は、メッセージング、プロシージャ呼出し、またはデータベース照会のどれを介するものであっても、現在のビジネス問題の多数を解決するための鍵である。
【0007】
レガシ・アプリケーションと新しいソフトウェアの統合は、2つの異なるアプリケーションを結び付ける接続のそれぞれをカスタマイズする必要に大いに起因して、困難かつ高価な作業である。あるアプリケーションが別のアプリケーションによってそれ自体を呼び出されることを可能にする方法を記述する単一の機構はない。
【0008】
1つの結果が、複数の開発チームによって開発され、異なるプラットフォームで稼動する、異なるデータ型、データ構造体、コマンド、およびコマンド構文を有する複数のアプリケーションのe-commerce環境である。この環境は、アプリケーション・プログラム・インターフェースおよびコネクタを用いてつなぎ合わされる。コネクタは、e-commerceの総合的なアプリケーション・フレームワークの本質的な部分である。コネクタは、異なるアプリケーションのインターフェース要件を一致させ、異なるインターフェースの間でマッピングを行う。
【0009】
この新旧のソフトウェア・システムおよびアプリケーションの相互接続の増加によって、特にマークアップ言語(HTML、XML、Dynamic HTML、WML、および類似物など)の、SmallTalkおよびC++などのオブジェクト指向言語を介する、レガシ・アプリケーション・サーバ・アプリケーションの言語(COBOLなど)との相互接続および対話に関する、さまざまなミドル・ウェア・アプリケーションおよびコネクタ・アプリケーション、インターフェース仕様、インターフェース定義、およびコードがもたらされた。これらのインターフェース仕様、定義、およびコードは、言語、ツール、アプリケーション、オペレーティング・システム、およびネットワークにまたがって適用され、その結果、エンド・ユーザが自分の端末で単一のシームレスなアプリケーションのルック、フィール、および応答を経験するようにしなければならない。その代わりに、たとえばcommonobject Request Broker(CORBA)、Common Object Model(COM)、オブジェクトのリンクと埋込み(OLE)、SOM、ORBPlus、Object Broker、Orbixなどの標準規格、プロトコル、仕様、定義、およびコードの増殖が、その代わりに、e-commerceの「バベルの塔」を生み出した。
【0010】
アプリケーション統合の例が、ユビキタスであり、これは、ERPシステムのインストールから、IMSトランザクションを伴うオペレーショナル・データ・ストア(ODS)の更新またはMQSeriesからのCRMシステムの呼出しまでにおよび、これらのそれぞれが、同一の基本ステップを必要とする。第1に、ユーザは、自分が通信したいエンティティを見つけなければならず、その後、ユーザは、そのエンティティを呼び出す方法を見つけなければならず、最後に、ユーザは、あるネイティブ表現から別のネイティブ表現への変換を提供しなければならない。現在、これらのステップは、通常、手動調査およびハンド・コーディングを必要とし、開発者が、アプリケーションの間の維持しにくい接続の混乱状態に煩わされる。
【0011】
この情況を救済する試みには、アプリケーション・プログラム・インターフェースおよびコネクタが含まれ、これらは、しばしば、インターフェース定義言語に基づいて構築される。インターフェース定義言語は、宣言的であり、インターフェース定義言語によって、アプリケーション・プログラム・インターフェースが定義され、いくつかの場合に、エラー処理などの問題が生じる。ほとんどのインターフェース定義言語は、C++のサブセットであり、コンポーネントの属性、継承する元の親クラス、それが発生する例外、それが発行する型付きイベント、そのインターフェースがサポートするメソッド、入出力パラメータ、およびデータ型を指定する。コネクタ内のインターフェース定義言語の目標は、ハード・コーディングされたアプリケーション・プログラム・インターフェースなしで、異なるアプリケーションの間のコラボレーションを可能にすることである。
【0012】
理想的には、インターフェース定義言語およびそれを含むコネクタは、下記などの特徴を介して完全な実行時ソフトウェア・アプリケーション・コラボレーションを促進しなければならない。
・強い型検査を伴うメソッド呼出し、
・より高い柔軟性と実行時バインディングを伴う実行時メソッド呼出し、
・実装から分離されたインターフェースを伴う高水準言語バインディング、
・サーバの関数およびパラメータのリアル・タイム情報を含むインターフェース・リポジトリ。
【0013】
さらに、コネクタおよびそのインターフェース定義言語は、高速であり、効率的であり、スケーラブルであり、ポータブルであり、メタクラスをサポートし、構文レベルの拡張をサポートし、セマンティック・レベルの拡張をサポートしなければならない。
【0014】
【発明が解決しようとする課題】
新しいアプリケーション、たとえばe-commerceアプリケーションの、レガシ・アプリケーションとの統合に関連する問題が、本明細書に記載の共通アプリケーション・メタモデルのツール、方法、およびシステムによって除去される。本発明の共通アプリケーション・メタモデルの方法、ツール、およびシステムは、似ていない異なるアプリケーションの間のツーリング・ソリューション、データ変換、通信およびコラボレーションならびにアプリケーション・サーバ・インターフェース・ドメインとのインターフェースを介する完全な実行時ソフトウェア・アプリケーション・コラボレーションを容易にする。これは、メタデータ交換情報、強い型検査を伴うメソッド呼出し、実行時メソッド呼出し、実行時バインディング、および高水準言語バインディングを介して、実装から分離されたインターフェースと、クライアントおよびサーバのインターフェース・パラメータのリアル・タイム情報を格納するインターフェース・リポジトリとを用いて、達成される。
【0015】
さらに、本発明のツール、方法、およびシステムは、すべてのツールまたはミドルウェアから独立の、高速であり、効率的であり、スケーラブルである相互接続性を提供し、再利用可能であり、ポータブルであり、メタクラス、構文レベルの拡張、およびセマンティック・レベルの拡張をサポートし、特定のツールまたはミドルウェアから独立である。
【0016】
共通アプリケーション・メタモデルのツール、方法、およびシステムは、クライアント・アプリケーションとサーバ・アプリケーションの間で両方向であり、たとえばJava(R)、HTML、XML、C、またはC++アプリケーションと、COBOL、PL/I、またはHigh LevelAssemblerアプリケーションとの間、HTMLまたはXMLアプリケーションとJava(R)、C、またはC++アプリケーションとの間、またはJava(R)アプリケーションとCまたはC++アプリケーションとの間で両方向にコマンドおよびデータを送る、データ・トランスフォーマを提供するのに特に有用である。
【0017】
【課題を解決するための手段】
本発明の一実施形態は、エンド・ユーザ・アプリケーションおよび1つまたは複数のアプリケーション・サーバで、またはこれらの間でアプリケーション要求を処理する方法である。この方法には、エンド・ユーザ・アプリケーションに対するアプリケーション要求を第1言語で第1アプリケーション・プログラムを用いて開始するステップと、アプリケーション要求をサーバに送信し、アプリケーション要求を第1エンド・ユーザ・アプリケーションの第1言語からアプリケーション・サーバ上で稼動する言語に変換するステップが含まれる。通常、上で説明したように、クライアントは、シン・クライアントまたはウェブ・ブラウザであり、クライアント上で稼動するアプリケーションは、ウェブ・ブラウザ・アプリケーションまたはシン・クライアント接続性アプリケーションであり、クライアント・アプリケーションの言語は、Java(R)、C、C++、あるいは、HTMLまたは、XMLまたはDynamic HTMLまたはWMLなどのHTMLの派生物のマークアップ言語であり、サーバ上で稼動する言語は、COBOL、PL/I、HLASM(HighLevel Assembler)または類似物である。本発明は、アプリケーション要求をエンド・ユーザ・アプリケーションの第1言語からアプリケーション・サーバ上で稼動する言語に変換するトランスフォーマを促進する。変換の後に、変換されたアプリケーション要求が、アプリケーション・サーバ上で処理される。
【0018】
アプリケーションは、要求を処理し、その後、アプリケーション・サーバからエンド・ユーザ・アプリケーションに応答を送り返す。通常、上で説明したように、アプリケーション・サーバは、COBOLベースのアプリケーションを実行しており、クライアントは、Java(R)またはCまたはC++で記述されたシン・クライアント、もしくは、HTMLあるいはXMLまたはDynamicHTMLまたは類似物などのHTMLの派生物などのマークアップ言語の、ウェブ・ブラウザ・アプリケーションまたはシン・クライアント接続性アプリケーションを実行するウェブ・ブラウザである。本発明は、1つまたは複数のアプリケーション・サーバ上で稼動する1つまたは複数の言語から第1エンド・ユーザ・アプリケーションの第1言語に応答を変換するデータ・トランスフォーマを提供する。
【0019】
エンド・ユーザ・アプリケーションおよびアプリケーション・サーバは、その間に少なくとも1つのデータ・トランスフォーマを有する。この形で、(i)ソース言語としての第1エンド・ユーザ・アプリケーションの第1言語からターゲット言語としてのアプリケーション・サーバ上で稼動する言語に要求を変換するステップと、(ii)後続のソース言語としてのアプリケーション・サーバ上で稼動する言語から後続のターゲット言語としての第1エンド・ユーザ・アプリケーションの第1言語に応答を変換するステップとのそれぞれに、各々のソース言語およびターゲット言語の型記述子および言語メタモデルを呼び出すステップと、各々のソース言語およびターゲット言語のデータ項目および型のそれぞれを用いてメタモデルを移植するステップと、ソース言語をターゲット言語に変換するステップとが含まれる。
【0020】
エンド・ユーザ・アプリケーションは、ウェブ・ブラウザまたはシン・クライアントであることがしばしばである。エンド・ユーザ・アプリケーションが、ウェブ・ブラウザである時には、エンド・ユーザは、ウェブ・サーバを介してアプリケーション・サーバに接続される。本発明のもう1つの実施形態によれば、ウェブ・サーバに、コネクタまたはデータ・トランスフォーマを含めることができる。ウェブ・サーバに統合されたデータ・トランスフォーマは、要求、アプリケーション要求、またはメッセージを、ブラウザ指向の形からアプリケーション・サーバ言語または、XMLなどの中間のビジネス指向またはコマース指向のマークアップ言語に直接に変換することができる。
【0021】
コンバータを構成するのに使用されるCAMメタモデルには、呼出しメタモデル、アプリケーション・ドメイン・インターフェース・メタモデル、言語メタモデル、および型記述子メタモデルが含まれる。例示的な呼出しメタモデルには、メッセージ制御情報と、セキュリティ・データと、トランザクショナル・セマンティクスと、トレースおよびデバッグ情報と、事前条件リソースと、事後条件リソースと、ユーザ・データなどからなる群から選択された情報が含まれる。例示的なアプリケーション・ドメイン・インターフェース・メタモデルには、入力パラメータ・シグニチャ、出力パラメータ・シグニチャ、および戻りの型から選択される情報が含まれる。アプリケーション・ドメイン・インターフェース・メタモデルでは、COBOLまたはPL/Iメタモデルなどの1つまたは複数の言語メタモデルが使用される。
【0022】
型記述子メタモデルでは、物理的実現、ストレージ・マッピング、データ型、データ構造体、および実現制約が定義される。
【0023】
本発明の方法は、ソース言語またはターゲット言語の一方がオブジェクト指向であり、ターゲット言語またはソース言語の他方がオブジェクト指向でない情況に適用可能である。この情況では、言語メタモデルおよび型記述子メタモデルが、一緒に、オブジェクト指向言語のカプセル化されたオブジェクトを、オブジェクト指向でない言語のコードおよびデータにマッピングする。さらに、言語メタモデルおよび型記述子メタモデルは、オブジェクト指向言語のオブジェクト継承を、オブジェクト指向でない言語の参照およびポインタにマッピングする。本発明の方法は、異なるオブジェクト指向言語が異なるプラットフォーム上で稼動しており、ソース言語のカプセル化されたオブジェクト(コードおよびデータ)が、ターゲット言語のカプセル化されたオブジェクトにマッピングされる情況にも適用可能である。本発明の方法は、異なる手続き型言語が異なるプラットフォームまたはアプリケーションで稼動しており、ソース手続き型言語のコマンドおよびデータが、ターゲット手続き型言語にマッピングされる場合にも適用可能である。
【0024】
本発明の方法によれば、垂直(シーケンシャル、条件、または依存)処理用、水平(時間的に並列)処理用、または垂直処理と水平処理の両方の、複数のアプリケーションが存在することができる。これは、処理の複数の階層レベルおよび複数の並列シーケンスへおよびそれらを介するリッチ・トランザクションをサポートするためである。これは、財務、製造、スケジューリング、供給、出荷のデータベースおよびサーバを利用し、さまざまな市販セキュリティ器具を使用する、企業対企業のトランザクションにおいてそうである可能性がある。
【0025】
本発明のもう1つの態様は、クライアント、サーバ、クライアントと1つまたは複数のサーバの間の少なくとも1つのトランスフォーマを有する、クライアント−サーバ処理システムである。
【0026】
本発明のもう1つの態様は、クライアント・アプリケーションと相互作用するように構成され、制御される処理システムである。本発明のこの態様では、システムに、サーバと、サーバとクライアント・アプリケーションとの間の少なくとも1つのトランスフォーマが含まれ、クライアントが、エンド・ユーザ・アプリケーションを有し、第1アプリケーション・プログラムを用いて第1言語でサーバに関する要求を開始し、その要求をトランスフォーマを介して1つまたは複数のサーバに送信するように制御され、構成される。サーバは、要求を、第2言語を使用する第2ソフトウェア・アプリケーションで処理し、トランスフォーマを介してクライアントに応答を返す。
【0027】
本発明のもう1つの態様は、電子メール、ワード・プロセッシング、スプレッドシート、単純なデータベース管理(Lotus ApproachまたはMicrosoft Accessなど)、グラフィックスおよびグラフィックス編集、オーディオおよびオーディオ編集、およびコンピュータ・テレフォニ統合(「CTI」)などの、複数の電子メール対応エンド・ユーザ・アプリケーションを、クライアント・レベル・コンテンツ・データベース・クライアント・サービスおよびコンテンツ複製クライアント・サービスと共に有するグループウェア・システムである。グループウェアによって、これらの電子メール対応アプリケーションを、1つまたは複数のトランスフォーマと、トランスポート・サービス、ディレクトリ・サービス、およびコンテンツ・サーバと複製サーバとを含むストレージ・サービスとのアプリケーション・プログラム・インターフェースとを介して統合できるようになる。グループウェア・システムは、異なるエンド・ユーザ・アプリケーションの間、異なるサーバの間、および異なるサーバとエンド・ユーザ・アプリケーションの間で通信するように構成され、制御される。グループウェア・システムには、サーバとエンド・ユーザ・アプリケーションの間の少なくとも1つのトランスフォーマが含まれる。エンド・ユーザ・アプリケーションは、第1アプリケーション・プログラムの第1言語でサーバに関係するように制御され、構成され、サーバは、第2プログラムの第2言語でクライアントに関係するように構成され、制御される。
【0028】
トランスフォーマは、エンド・ユーザ・アプリケーションから要求を受信し、その要求を第1エンド・ユーザ・アプリケーションの第1言語からサーバで稼動する言語に変換するように構成され、制御される。サーバは、変換された要求をトランスフォーマから受信し、サーバに常駐する第2アプリケーション・プログラムを用いて第2言語で要求を処理し、その後、トランスフォーマを介してエンド・ユーザ・アプリケーションに応答を送り返すように構成され、制御される。
【0029】
本発明のもう1つの実施形態は、リッチ・トランザクション処理の提供である。リッチ・トランザクションは、複数のサーバへ、複数のサーバを介して、または複数のサーバにまたがって、およびあるいはこれらの組合せにスパンする、入れ子になったトランザクションである。入れ子になったサーバにまたがるスパンは、水平すなわち、並列の従属トランザクション、または垂直すなわち直列の従属トランザクションとすることができる。リッチ・トランザクションは、長寿命の進行中のトランザクション、または、複雑な企業対企業のトランザクション、特に複数の依存性または偶発性、大量および即座の支払いディスカウント、配送遅れおよび支払いの遅れのペナルティ、および、電子信用状、電子船荷証券、電子支払い保証、電子支払い、エスクロウ、商品の担保権、および類似物などの財務処理を伴うトランザクションとすることができる。リッチ・トランザクション環境では、いくつかのトランザクション・サーバを、リッチ・トランザクションを構成するあるサブ・トランザクションについて他のトランザクションに関するクライアントとして位置付けることができる。
【0030】
本発明のもう1つの実施形態は、プログラム製品が、呼出しメタモデル、アプリケーション・ドメイン・インターフェース・メタモデル、および言語メタモデルと、ソース言語メタモデルおよびターゲット言語メタモデルのメタモデル・リポジトリを構築するコンピュータ命令を有するストレージ・メディア(複数のコンピュータの1つの、テープ、フロッピ・ディスク、CD−ROM、または1つまたは複数のハード・ドライブなど)であることを特徴とする、ツールすなわち、ソフトウェア開発者キットである。プログラム製品には、メタモデルからコネクタ・スタブを構築するコンピュータ命令も含まれる。プログラム製品は、さらに、トランスフォーマを構築するコンピュータ命令を担持する。
【0031】
本発明を、単一のレベルのコネクタを有するものとして要約の形で説明したが、そのようなコネクタが、もちろんたとえばウェブ・クライアントとウェブ・サーバの間、ウェブ・サーバとアプリケーション・サーバの間、アプリケーション・サーバとデータベース・サーバの間、およびアプリケーション・サーバまたはデータベース・サーバもしくはその両方とさまざまな特殊リポジトリの間など、処理階層内のさまざまなレベルに存在することができることを理解されたい。
【0032】
本発明を個々のクライアントおよび個々のサーバに関して要約したが、グループウェア・アプリケーションによって例示されるように、複数のクライアント、複数のサーバ、およびクライアントとサーバの両方として機能するアプリケーションが存在することができ、リッチ・トランザクションのシステムのように、アプリケーション・サーバ、データ・サーバ、およびデータベースの、複数の並列のラインまたは複数の階層レベルもしくはその両方が存在することができることも理解されたい。
【0033】
【発明の実施の形態】
定義。本明細書で使用される時に、以下の用語は、示された意味を有する。「ハンドシェーク」は、各接続に先立つ、2つのアプリケーションの間の情報の交換と、その結果の、どの言語、機能、およびプロトコルを使用するかに関する合意である。
【0034】
「アプリケーション・プログラム・インターフェース」(API)は、コンピュータ・オペレーティング・システムまたは別のアプリケーション・プログラムによって規定される受動的な特定のメソッドであり、これによって、アプリケーション・プログラムを記述するプログラマが、オペレーティング・システムまたは別のアプリケーションに要求を行うことができる。例が、SAX(Simple API for XML)、すなわち、プログラマが、Extensible Markup Languageを使用するウェブ・ファイルすなわち、データの集合を記述するウェブ・ファイルを解釈できるようにするコネクタである。SAXは、「イベント駆動」インターフェースである。プログラマは、発生する可能性があるイベントを指定し、そのイベントが実際に発生した場合に、SAXが、制御を得、その状況を処理する。SAXは、直接にXMLパーサと共に作動する。
【0035】
本明細書で使用される「コネクタ」は、ターゲット・プラットフォームまたはプログラムの関数およびパラメータが格納されたプラットフォームの間の動的な実行時インターフェースであり、ターゲット・プラットフォーム・プログラムをリアル・タイムでバインドする。
【0036】
「スタブ」は、サーバへの静的インターフェースを提供する小さいプログラム・ルーチンである。事前にコンパイルされたスタブによって、クライアントがサーバ上の対応するサービスを呼び出す方法が定義される。スタブは、サーバ上のより長いプログラムに代わり、サーバ・オブジェクトに関するローカル呼出しまたはローカル・プロキシとして働く。スタブは、要求を受け入れ、その後、その要求をリモート・プロシージャに転送する(別のプログラムを介して)。そのプロシージャは、そのサービスを完了した時に、結果または他の状況をスタブに返し、スタブは、要求を行ったプログラムにそれを渡す。サーバ・サービスは、スタブ内で、インターフェース定義言語(「IDL」)を使用して定義される。クライアントは、それがアクセスするサーバ・インターフェースごとに1つのIDLスタブを有し、このIDLスタブに、マーシャルを実行するコードが含まれる。サーバ・スタブは、サーバによってエクスポートされる各サービスへの静的インターフェースを提供する。
【0037】
「CICS」(顧客情報管理システム)は、COBOL(Common BusinessOriented Language)プログラミング言語と共に、大企業メインフレーム・コンピューティングの世界で顧客トランザクション・アプリケーションを構築するツールの組である、IBM社のオンライン・トランザクション処理プログラムである。CICSによって供給されるプログラミング・インターフェースを使用して、CICS内で顧客レコードおよび他のレコード(注文、在庫額、顧客データなど)を記述することによって、プログラマが、IBM社のアクセス・メソッドを直接に使用するのではなく、CICS機能を使用して、オンライン・ユーザと通信し、データベース(通常は「データ・セット」と称する)から読み取るプログラムを記述することができる。CICSは、トランザクションが完了されることを保証し、そうでない場合には、部分的に完了したトランザクションを元に戻し、その結果、データ・レコードの保全性が維持されるようにすることができる。CICS製品は、OS/390オペレーティング・システム、UNIX(R)オペレーティング・システム、およびIntelPCオペレーティング・システム用に供給される。CICSを用いると、エンド・ユーザが、IBM社のTransaction Serverを使用して、インターネット・ユーザからのe-businessトランザクションを処理し、これらを、既存のCICS注文および在庫データベースにアクセスするメインフレーム・サーバに転送できるようになる。
【0038】
「IMS」(情報管理システム)は、IBM社のエンタープライズ・システム体系(IMS/ESA)と共に、トランザクション・マネージャおよび階層データベース・サーバを提供する、IBM社のシステムである。
【0039】
「MQ」は、そのコンポーネントが他のソフトウェア・アプリケーションを一緒に結び付けるのに使用され、その結果、それらが一緒に動作できるようにする、MQSeries IBMソフトウェア・ファミリである。このタイプのアプリケーションを、しばしば、ビジネス・インテグレーション・ソフトウェアまたはミドルウェアと称する。機能的には、MQSeriesは、異なるプラットフォーム上のアプリケーションの間の通信機構、ビジネス・オペレーション・ルールを集中化し、適用するインテグレータ、および、ビジネス・プロセスの取込、視覚化、および自動化を可能にするワークフロー・マネージャを提供する。MQSeriesは、異なった地理的位置にある、似ていないITインフラストラクチャを使用する、異なるコンピュータ・システムを接続し、その結果、シームレスな動作を実行できるようにする。IBM社のMQSeriesは、アプリケーション間および異なるシステム上のユーザおよびアプリケーションの組の間の通信を供給する。さらに、MQSeriesのメッセージング方式は、メッセージを受信するアプリケーションが受信を確認することを必要とする。確認が具体化されない場合には、メッセージが、MQSeriesによって再送信される。
【0040】
「Rose」は、エンタープライズレベル・ソフトウェア・アプリケーションのビジュアル・モデリングおよびコンポーネント構成に充てられるオブジェクト指向統一モデリング言語(UML)ソフトウェア設計ツールである。Roseは、ソフトウェア設計者が、記号のドラッグアンドドロップを使用して、シーケンス図でアクタ(スティック人形)、ユース・ケース要素(楕円)、オブジェクト(長方形)、およびメッセージ/関係(矢印)を用いてクラスの輪郭を描くことによって、アプリケーションのフレームワークを視覚的に作成(モデル化)できるようにする。Roseでは、図が、構成されつつある間に文書化され、その後、C++、VisualBasic、Java(R)、Oracle8、Corba、またはデータ定義言語のうちの設計者が選択したもののコードが生成される。
【0041】
共通アプリケーション・メタモデルの概要。共通アプリケーション・メタモデル(CAM)は、図1に示された環境に相互接続性をもたらす。図1には、NetscapeまたはInternet Explorerブラウザ103、Sun Solarisサーバ107上のNet.Commerce105、データベース・サーバ113上のOracle109およびDB2 111、AIX117で稼動するSAP115、CICS390サーバ119、IMS 390サーバ121、S/390プラットフォーム127上のDB2 123およびDL/I 125、Windows(R)2000クライアント129、およびHP Unix(R)サーバ133上で稼動するBaan131を含む、複数のアプリケーション・コンポーネントを有する通常のシステム101を示す図である。共通アプリケーション・メタモデル(CAM)は、図1内などのエンタープライズ・アプリケーションにソース言語でアクセスし、それらをターゲット言語に変換するのに必要な情報のマーシャルおよび適用のためのメタデータ交換の方法、ツール、およびシステムである。CAMは、図2に示されているように、言語メタモデルおよびアプリケーション・ドメイン・インターフェース・メタモデルからなり、図2には、エンタープライズ・アプリケーション統合221を促進するために共通アプリケーション・メタモデルのメタデータ・リポジトリ211への入力としてのメッセージ・セット203、SQLストアド・プロシージャ205、レガシ・アプリケーション207、およびプログラミング言語209の役割が示されている。
【0042】
例示的なメタモデルには、図3に示されているように、C、C++、Java(R)、COBOL、PL/I、HLAssembler、IMSトランザクション・メッセージ、IMS MFS、CICS BMS、およびMQSeriesメッセージ・モデルが含まれ、図3には、呼出しメタモデル301、アプリケーションドメイン・インターフェース・メタモデル303、および言語メタモデル305と共に、本発明の共通アプリケーション・メタモデルが示されている。
【0043】
図4に、OTMA呼出しメタモデル421、IMSトランザクション・メッセージ・メタモデル423、COBOLメタモデル425、およびCメタモデル427と共に、IMS OTMAアプリケーション・インターフェース・メタモデル411を示す。
【0044】
図5に、既存のアプリケーション501からインターフェース503を介してアプリケーション・インターフェース・メタデータを含むオブジェクト・モデルへの情報の流れを示す。このアプリケーション・インターフェース・メタモデルは、メタデータ・リポジトリ505に格納され、適当な時にメタデータ・リポジトリ505から検索され、生成ツール509でソース・プログラム507と組み合わされ、XMLファイルとしてのターゲット・ファイル511すなわちXMIインスタンス・ファイルの生成に使用される。CAMは、大いに再利用可能であり、特定のツールまたはミドルウェアから独立である。
【0045】
開発ステージ。CAMがあれば、ツーリングによって、エンタープライズ・アプリケーション、たとえばIMSアプリケーションへのアクセスに対する解決策を簡単に提供することができる。各ソース・ファイルを解析し、CAMモデル、COBOLコピーブック、PL/Iコピーブック、MFSソース、BMSソースなどに基づいてXML文書を生成することによって、ツールが、IMS、CICSなどに対するコネクタ解決策を提供することができる。
【0046】
これに関して、図6に、たとえばCOBOLメタモデル、PL/Iメタモデル、MFSメタモデル、BMSモデル、または類似物などの共通アプリケーション・メタモデルRoseファイル601が、ツールキット603に読み込まれて、RoseモデルのDTDおよびスキーマとRoseモデル605のJava(R)コードが生成される開発フェーズのシナリオを示す。COBOLソース・ファイル、PL/Iソース・ファイル、MFSソース・ファイル、BMSソース・ファイル、または類似物として、およびRoseモデル609のJava(R)コードとして、アプリケーションのソース・ファイル607が、インポータ611に読み込まれる。インポータは、ソース・コードを解析し、出力としてXMIインスタンス・ファイル613すなわちアプリケーション・ソース・ファイルのXML文書を提供する。
【0047】
図7に、アプリケーション・インターフェースのCAMメタモデルを示す。この図には、アプリケーション・インターフェース・メタモデル707に従って、既存のアプリケーション・プログラムのインターフェース定義を含むインターフェース705を介して既存のアプリケーション・プログラム703とインターフェースする、呼出し機能および変換機能を有する実行時コネクタ701が示されている。アプリケーション・インターフェース・メタデータは、メタデータ・リポジトリ709に格納される。
【0048】
フローおよびメッセージング・ミドルウェア713が、アプリケーション・インターフェース705を介してアプリケーション703を呼び出す。これらのインターフェース705は、それを介してすべての入出力がミドルウェア713に接続されるアプリケーション703へのアクセス点である。インターフェース705は、アプリケーション・インターフェース・メタモデルに関して記述される。メタモデルによる変換処理は、ソース/クライアント・アプリケーション、ターゲット・アプリケーション、またはゲートウェイで行うことができる。
【0049】
CAMは、データ型およびストレージ・マッピングの物理的表現を提供して、エンタープライズ・アプリケーション統合環境でのデータ変換をもサポートするので、エンタープライズ・アプリケーション用のウェブ・サービスを使用可能にする。開発時に、CAMは、下記を容易にする情報を取り込む。
a).コネクタまたはコネクタビルダ・ツールあるいはその両方、
b).アプリケーション生産性および品質保証に関するデータ駆動影響分析、および
c).開発者によるプログラミング言語データ宣言の考察。
【0050】
CAMメタモデル・ファイルは、CAMモデルを表すDTDファイル、XMLスキーマ、およびJava(R)クラスの生成に使用されるツールキットへの入力である。インポータは、各ソース・ファイル(たとえばCOBOLまたはPL/Iコピーブック、MFSソース、およびBMSなど)を解析し、その後、XMI/MOF2ツールキットによって生成されたJava(R)クラスに基づいてXML文書(すなわちXMLインスタンス・ファイル)を生成する。
【0051】
実行時。実行時に、CAMは、それが混合言語間のデータ型マッピングを提供するエンタープライズ・アプリケーション統合環境での変換を容易にする情報を提供し、ある言語およびプラットフォーム・ドメインから別の言語およびプラットフォーム・ドメインへのデータ変換を容易にする。
【0052】
図8に、実行時中の共通アプリケーション・メタモデルの適用を示す。図からわかるように、SOAP準拠XML文書803が、たとえばIBM WebSphereミドルウェア805内で受け取られ、このIBM WebSphereミドルウェア805は、Java(R)用のIMSConnector807を含み、XMLリポジトリ809と接触し、XMLリポジトリ809には、CAMモデルのXMIインスタンス・ファイルが含まれる。IBMWebSphereミドルウェアは、変換されたファイルをIMSシステム811に送り、IMSシステム811には、IMS接続813とIMSトランザクショナル・アプリケーション・プログラム815のインスタンスが含まれる。CAMは、バックエンドのIMSアプリケーション815とウェブ・ファイル(たとえばSOAP準拠XML文書)803の間の接続性を促進する。CAMは、CAMモデル情報(リポジトリ809からの)を使用して、図示の混合言語環境で、あるプラットフォームから別のプラットフォームへのデータ変換を実行することによって、これを達成する。
【0053】
TypeDescriptorメタモデル。CAMによって提供される1つの重要な特徴が、TypeDescriptorメタモデルである。TypeDescriptorメタモデルによって、物理的実現、ストレージ・マッピング、および実現に対する制約(位置調整など)が定義される。このメタモデルによって、所与のデータ構造体の個々のフィールドの物理的表現が提供される。エンタープライズ・アプリケーション統合環境でデータ変換をサポートする時に、このモデルによって、混合言語の間でのデータ型マッピングが提供される。このモデルによって、ある言語およびプラットフォーム・ドメインから別の言語およびプラットフォーム・ドメインへのデータ変換も容易になる。メタモデルは、全体的なデータ構造体名およびフィールド名の言語固有メタモデルを用いる実行時データ変換(またはマーシャル)に使用される。
【0054】
1.アプリケーション・インターフェースに関する共通アプリケーション・メタモデル
図1に示されたように、異なるオペレーティング・システム、物理プラットフォーム、および物理的実現を有する、異なるソフトウェア・プラットフォームで稼動する異なる似ていないアプリケーションは、相互接続メタデータを組み込んだコネクタを介して達成される。コネクタは、e-businessに関するアプリケーション・フレームワークの中心部分である。エンド・ユーザの要求は、興味を持たれるすべてのものにできる限りすばやくできる限り簡単に接続することである。
【0055】
アダプタとレガシ・アプリケーションのインターフェース要件を一致させるために、コネクタが必要である。2つのインターフェースの間でのマッピングも必要である。本明細書で提示されるアプリケーション・インターフェースの標準化されたメタモデルを用いると、複数のコネクタ・ツールでの情報の再利用が可能になる。これらの標準化されたメタモデルによって、コネクタを作成する作業が減るだけではなく、コネクタ・ビルダ・ツールを開発するのに必要な作業も減る。
【0056】
本発明の共通アプリケーション・メタモデルを使用して構築されるコネクタは、既存のアプリケーションとのインターオペラビリティを提供する。コネクタは、既存のアプリケーション・システム内で保持されるデータおよびビジネス・ロジックの活用および再利用をサポートする。コネクタの仕事は、あるアプリケーション・システム・サーバ・「インターフェース」から別のアプリケーション・システム・サーバ・インターフェースに接続することである。したがって、アプリケーションドメイン・インターフェース・メタモデルによって、所与のアプリケーション・システム・ドメイン(たとえばIMS、MQSeries)の入出力パラメータのシグニチャおよび戻りの型が記述されるが、これは、特定のIMSアプリケーション・プログラムまたはMQSeriesアプリケーション・プログラムに関するものではない。メタモデルには、構文インターフェース・メタデータおよびセマンティック・インターフェース・メタデータの両方が含まれる。
【0057】
1.a.共通アプリケーション・メタモデルを使用するエンドツーエンド・コネクタ使用
共通アプリケーション・メタモデル(CAM)は、特定のツールまたはミドルウェアから独立の、メッセージ・シグニチャのメタ定義からなる。異なるコネクタ・ビルダ・ツールが、この情報を使用して、これらのアプリケーション・プログラム間での、異なるツール、言語、およびミドルウェアにまたがる「ハンドシェーク」を保証することができる。たとえば、MQSeriesアプリケーションを呼び出す必要がある場合には、GUIツールからのデータを使用してMQメッセージを構築し、MQ APIを使用してそのメッセージを送達する必要がある。同様に、MQSeriesアプリケーションからメッセージを受け取った時には、MQSeriesからバッファを入手し、それを解析し、それをGUIツール・データ構造体に入れる必要がある。これらの機能は、アプリケーション・インターフェースの標準化メタモデルとしてCAMを使用するコネクタ・ビルダ・ツールによって、効率的に設計し、実装することができる。
【0058】
CAMを、コピー・ブックを含む多数のソースから移植して、入力を収集し出力を返すHTMLフォームおよびJava(R) Server Page(JSP)を生成することができる。前の図に示されたコネクタの例は、フローおよびメッセージ・ミドルウェアが、コネクタを呼び出すことによってエンタープライズ・アプリケーションへの関数呼出しを行い、このコネクタがエンタープライズ・アプリケーションAPIを呼び出すということである。コネクタは、言語およびデータ型のマッピングを行って、たとえば、XML文書とCOBOL入力の間で変換し、CAMに基づくデータ構造体を出力する。コネクタおよびCAMは、ミドルウェアとエンタープライズ・アプリケーションの間のエンドツーエンド統合を提供する。
【0059】
例としてIMSを使用する。自分のデスクトップ機からIMSトランザクション・アプリケーション・プログラムにアカウント番号を渡して、50.00ドルを引き出さなければならないと仮定する。CAMおよびコネクタ・ビルダ・ツールがあれば、まず、入力HTMLフォームおよび出力JSPを生成し、要求をサポートするのに必要なミドルウェア・コードを開発することになる。デスクトップ・アプリケーションが、要求データ構造体(すなわち、入力HTMLフォーム)に値を書き込み、ミドルウェアを呼び出す。ミドルウェア・サービス・コードは、GUIツールからデータを受け取り、IMS ConnectのXMLフォーマットのメッセージを構築し、そのメッセージを、TCP/IPを介してIMSゲートウェイ(すなわちIMSConnect)に送達する。IMS Connectは、CAMに取り込まれたメタデータ定義を使用して、XML文書とCOBOLのIMSメッセージ・データ構造体の間で変換する。その後、IMSConnectは、IMSメッセージ・データ構造体を、Open Transaction Manager Access(OTMA)を介してIMSに送る。IMS COBOLアプリケーション・プログラムが、稼動し、IMSConnectを介して出力メッセージをミドルウェア・サービス・コードに返す。ミドルウェア・サービス・コードは、メッセージを入手し、応答データを出力JSPページ(すなわち、前に生成されたGUIツール応答データ構造体)に移植する。その後、トランザクション出力データが、ユーザに提示される。
【0060】
2.共通アプリケーション・メタモデル
CAMは、共通のプログラミング・モデルで開発されたアプリケーションを、他のシステムと簡単に統合するのに必要な情報を記述するのに使用される。CAMメタモデルは、同期式呼出しと非同期式呼出しの両方に使用することができる。
【0061】
2.a.共通アプリケーション・メタモデル
以下で述べる共通アプリケーション・メタモデルは、呼出しメタモデルと、言語メタモデルを使用するアプリケーションドメイン・インターフェース・メタモデルからなる。所与のアプリケーションドメイン・インターフェース・メタモデルについて、そのメタモデルは、1つまたは複数の言語メタモデルを使用することができるが、0個以上の呼出しメタモデルを設けることができる。
【0062】
共通コネクタ・メタモデルを、図3に示す。これは、呼出しメタモデル301、アプリケーションドメイン・インターフェース・メタモデル303、および言語メタモデル305を有する。
【0063】
2.a.i.呼出しメタモデル
呼出しメタモデル301は、1つまたは複数の下記の可能なメタデータ要素からなる。しかし、特定の呼出しに関して、呼出しメタモデルに、1つまたは複数の下記のメタデータ要素だけを含めることができる。
【0064】
メッセージ制御情報。これには、メッセージ接続名、メッセージ・タイプ、シーケンス番号(ある場合)、および、応答、コミット確認、および処理オプション(これによって、クライアントまたはサーバが、メッセージ処理を同期式または非同期式になるように制御することができる)に関するさまざまなフラグおよびインジケータなどのメッセージ制御情報が含まれる。
【0065】
接続名は、すべての入出力を特定のクライアントに関連付けるために、アプリケーション・システム・サーバが使用することができる。メッセージ・タイプによって、メッセージが応答メッセージであること、またはコミットが完了したことが指定される。メッセージ・タイプによって、クライアントへのサーバ出力データまたはサーバへのクライアント入力データを示すこともできる。
【0066】
セキュリティ・データ −− これには、認証機構と、たとえばディジタル証明書、識別、ユーザ名およびパスワードなどのセキュリティ・データが含まれる。これには、ロール・ベースの認証またはACL(アクセス制御リスト)ベースの認証を介してデータを許可することができるかどうかを示す認証情報も含めることができる。
【0067】
トランザクション・セマンティクス −− これは、たとえばローカル・トランザクション対グローバル・トランザクション、2フェーズ・コミット対1フェーズ・コミット、およびトランザクション・コンテキストなどのトランザクション情報を搬送する。
【0068】
トレースおよびデバッグ −− トレースおよびデバッグ情報は、メタモデルの一部として指定される。
【0069】
事前条件リソースおよび事後条件リソース −− これによって、アプリケーション状態の事前条件および事後条件の関係が記述される。
【0070】
ユーザ・データ −− これには、クライアントによって要求される特殊な情報のすべてが含まれる。これには、どのようなデータでも含めることができる。
【0071】
2.a.ii.アプリケーションドメイン・インターフェース・メタモデル
前に述べたアプリケーションドメイン・インターフェース・メタモデル303によって、アプリケーション・システム・ドメインに関する、入出力パラメータのシグニチャおよび戻りの型が記述される。
【0072】
2.a.iii.言語メタモデル
たとえばCOBOLメタモデルなどの言語メタモデル305は、コネクタ・インターフェースを表すデータ構造体(セマンティクス)を定義するために、エンタープライズ・アプリケーション・システムによって使用される。コネクタ開発者に、ソース言語、ターゲット言語、およびこの2つの間のマッピングを見せることが、コネクタ・ツールにとって重要である。CAM言語メタモデルには、編集可能でないモデル(すなわち、読取専用モデル)内の宣言テキストも含まれる。コネクタ/アダプタ開発者は、おそらく、コメントおよび宣言の各フィールドによって演じられるビジネス・ロールを理解するのに役立つ他のドキュメンテーションを含めて、COBOLデータ宣言全体を見ることを好む。
【0073】
言語メタモデルは、アプリケーションの生産性および品質保証のためのデータ駆動影響分析もサポートする(しかし、コピーブックの複写をサポートすることは、CAMの意図ではない)。
【0074】
コネクタ・データを記述する言語メタモデルを、下にリストする。
* C
* C++
* COBOL
* PL/I
【0075】
2.a.iv.TypeDescriptorメタモデル
TypeDescriptorメタモデルは、言語中立であり、このメタモデルによって、物理的実現、ストレージ・マッピング、および位置調整などの実現に対する制約が定義される。このメタモデルによって、所与のデータ構造体の個々のフィールドの物理的表現が提供される。この型記述子メタモデルは、エンタープライズ・アプリケーション統合環境でデータ変換をサポートして、混合言語の間でのデータ型マッピングを提供するためのものである。このメタモデルによって、ある言語およびプラットフォーム・ドメインから別の言語およびプラットフォーム・ドメインへのデータ変換も容易になる。このメタモデルは、全体的なデータ構造体名およびフィールド名の言語固有メタモデルを用いる実行時データ変換(またはマーシャル)の処方として使用される。
【0076】
3.共通コネクタ・メタモデルの例
IMS OTMA(Open Transaction Manager Access)は、OS/390シスプレックス環境内のトランザクションベースのコネクションレス・クライアント/サーバ・プロトコルである。IMS OTMAトランザクション・メッセージは、OTMAプレフィックスと、入力要求および出力要求に関するメッセージ・セグメントからなる。入力メッセージ・セグメントと出力メッセージ・セグメントの両方に、llzz(すなわち、セグメントの長さと予約済みフィールド)と、アプリケーション・データが含まれる。最初の入力メッセージ・セグメントだけに、アプリケーション・データの前にトランザクション・コードが含まれる。IMSトランザクション・アプリケーション・プログラムは、COBOL、PL/I、C、およびJava(R)などのさまざまな言語で記述することができる。したがって、アプリケーション・データに、これらの言語のどれでも使用することができる。
【0077】
図4に示されているように、IMS OTMAアプリケーション・インターフェース・メタモデル411は、OTMA呼出しメタモデル421およびIMSトランザクション・メッセージ・メタモデル423ならびにCOBOLメタモデル425およびCメタモデル427からなる。図4に示されているように、OTMA呼出しメタモデル421は、OTMAプレフィックスであり、IMSトランザクション・メッセージ・メタモデル423は、言語メタモデルを使用するIMSアプリケーション・システムのアプリケーションドメイン・インターフェース・メタモデルである。COBOLメタモデル425およびCメタモデル427が示されている。
【0078】
4.TypeDescriptorメタモデル
型記述子メタモデルは、配列および構造型を含む実装型を記述する言語独立かつプラットフォーム独立の形を提示する。この情報は、ある言語およびプラットフォーム・ドメインから別の言語およびプラットフォーム・ドメインにデータを変換しなければならない、マーシャルおよびコネクタに必要である。異なる言語の型モデルの検査によって、言語型の一致可能性を判定することができる。たとえば、Java(R)のlong型は、しばしば、COBOLのbinary型(computational-5)と同一であり、その場合には、これらの型を、副作用なしで相互変換することができる。その一方で、COBOLのalphanumeric型は、サイズが固定されるが、Java(R)の型にマッピングされる場合に、この特性が失われる。Java(R)からCOBOLに再変換される時に、COBOLの切詰規則が適用されず、計算の例外がもたらされる可能性がある。さらに、サーバ環境で言語を混合するツール(たとえばCICSおよびIMSのJava(R)およびCOBOL)は、ある言語がどれほど忠実に別の言語の型を表現できるかを判定する方法としてこれが有用であることを見出すに違いない。したがって、型記述子メタモデルのインスタンスでは、特定のプラットフォームおよびコンパイラに関する特定のデータ型の物理的表現を記述する。
【0079】
4.a.TDLangメタモデル
TDLangメタモデルは、TypeDescriptorメタモデルとすべてのCAM言語メタモデルとの間の抽象のレイヤを提供することによって、CAM言語メタモデルに対する基本クラスとして働く。TDLangクラスのすべてが、抽象クラスであり、すべてのCAM言語メタモデルに共通である。TDLangクラス間のすべての関連が、その関連が言語メタモデルから派生したことを反映するために、”volatile”、”transient”、または”derived”としてマークされる。TDLangモデルは、独力では何の機能も提供しないが、TypeDescriptorメタモデルから言語メタモデルへの関連の型ターゲットである。
【0080】
図9に、TDLangClassifier901、TDLangComposedType903、およびTDLangElement905と共にTDLangメタモデルの構造を示す。
【0081】
TDLang基本クラスと共に、TypeDescriptorメタモデルを、全体的なデータ構造体名およびフィールド名の言語固有メタモデルを用い、言語モデルに存在する集約関連を複製せずに、実行時データ変換(またはマーシャル)の処方として使用することができる。
【0082】
4.b.TypeDescriptorメタモデル
このメタモデルは、M2レベルのMOFクラスのインスタンスである。図10、図11、および図12に、PlatformCompilerType、InstanceTDBase、ArrayTD、AggregateInstanceTD、SimpleInstanceTD、およびInstanceTypeを含む、型記述子メタモデル内の関係を示す。InstanceTypeには、StringTD、AddressTD、NumberTD、およびFloatTDの定義が含まれる。図13に、TDLanguageElement1100とPlatformCompilerType1101の高水準ビューを示す。図14に、signCoding1201、lengthEncoding1203、floatType1205、accessor1207、packedDecimalSign1209、およびbitModePad1211の列挙を示す。
【0083】
4.c.TypeDescriptorおよび言語モデル
TypeDescriptorモデルは、TDLangElementとInstanceTDBaseの間のナビゲート可能な関連によってCAM言語モデルに接続される。TDLangElementは、宣言されたデータ項目すなわち型のインスタンスを表すのに使用される基本言語モデル型である。InstanceTDBaseは、この同一の宣言されたデータ項目の実装固有インスタンスを表すのに使用される基本TypeDescriptorモデル型である。InstanceTDBaseは、抽象クラスであり、そのサブタイプの1つだけをインスタンス化することができる。
【0084】
プログラミング言語で宣言されたデータ項目が、異なる実装を有することができる可能性がある。これらの相違は、ハードウェア・プラットフォーム、システム・プラットフォーム、およびコンパイラの相違によって誘発される。この可能性は、PlatformCompilerTypeモデル型によってモデル化される。TDLangElementとPlatformCompilerTypeの間の関連は、多対1であり、PlatformCompilerTypeとInstanceTDBaseの間の関連は、1対1である。言語モデルからナビゲートするために、どのPlatformCompilerTypeが前提になっているかを知る必要がある。実装において、モデル・インスタンスをインポートする際に、重要でないPlatformCompilerTypeインスタンスをモデルから除去することが望まれる可能性がある。TDLangElementとInstanceTDBaseの間の関連を、この形でモデル化して、ハードウェア・プラットフォーム、システム・プラットフォーム、およびコンパイラをより完全に記述する新しい型とPlatformCompilerTypeの間の関連を含むようにモデルを拡張できるようにする。
【0085】
データ要素インスタンスを、繰り返されるグループまたは配列として定義することができる。これは、InstanceTDBaseとArrayTDモデル型の間の1対多関連としてモデル化することができる。データ要素の次元、添字、または独立のインデックスのそれぞれについて、この関連に1つのArrayTDインスタンスがある。これらのインスタンスは、限界およびアクセス計算に関する情報を保持する。
【0086】
関連は、言語モデル内の対応する関連と同一の順序で順序付けられ、プログラミング言語によって定義されるインデックスの構文的な順序付けを反映する。この選択の根本的な理由は、その結果の、言語モデルとTypeDescriptorモデルの間のナビゲーションおよび処理アルゴリズムの同等性である。おそらくマーシャル・エンジンにより有利なもう1つの選択は、インデックスの順序付けを、最小のストライドから最大のストライドにすることである。これによって、配列が普通の連続的な形で配置されると仮定して、マーシャル・エンジンが、配列を自然なストレージ順序で処理できるようになる。マーシャル・エンジンは、望まれる場合に、ストライド式に従って関連ターゲットをソートし直すことによって、この順序を計算することができる。
【0087】
配列情報は、データ要素またはその型の複雑な特性になる可能性があり、さまざまな言語およびプログラミングの実践が、このどちらかに含まれると思われる。Cおよび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];
を作成することができる。しかし、Xのサブコンポーネントのどれか、たとえばDまたはEを配列にする新しいtypedefを、Xから作成することは不可能である。この例および多数の他の例によって、型付き言語での配列定義の不明瞭な状況が示される。
【0088】
InstanceTDBase型は、2つの具象サブタイプ、SimpleInstanceTDおよびAggregateInstanceTDを有する。SimpleInstanceTDは、サブコンポーネントなしのデータ要素をモデル化し、AggregateInstanceTDは、サブコンポーネントを有するデータ要素をモデル化する。AggregateInstanceTDのサブコンポーネントを見つけるためには、CAM言語モデルの対応するデータ要素宣言まで逆にナビゲートしなければならない。そこで、集約型とそのサブコンポーネントの間の関連をナビゲートすることができ、これがサブコンポーネント・データ要素の組につながり、そのそれぞれが、TypeDescriptorモデルの1つまたは複数のインスタンスを有する。これによって、ある程度のモデル・ナビゲーションの複雑さが導入されるが、言語モデルとTypeDescriptorモデルの両方での集約階層の重複が回避される。トラバーサルの追加の処理の複雑さは、大きくはなく、モデルを修正して集約にサブコンポーネントを追加、削除、または再配置するアルゴリズムで、かなりの単純化が得られる。
【0089】
SimpleInstanceTDモデル型も、BaseTDモデル型に1対1で関連する。BaseTDモデル型は、同一の言語型のすべてのデータ要素に共通する実装情報を保持するように特殊化される。したがって、特定のハードウェア/ソフトウェア・プラットフォームでの32ビット符号付き2進整数を記述する情報は、この型を用いてどれほど多数のデータ要素が宣言されるかに無関係に、所与のモデル・インスタンス化において1回だけインスタンス化される。
【0090】
TDLangElementとInstanceTDBaseの間の関連に一致する、TDLangClassifierとBaseTDの間の関連を企図することができる。しかし、これには、言語が単純型(たとえばストリング)とみなす構造が、単純なハードウェア/ソフトウェア型に直接にマッピングされない可能性があるという点で問題がある。ストリング実装を記述するためにTypeDescriptorモデルにより多くの機構を導入するのではなく、共通のストリング実装を記述するBaseTDの特殊化を使用する。TypeDescriptorモデルのさまざまな属性に、ストリング”formula”の接尾辞が付けられている。これらの属性には、いくつかの場合に実行時にのみ作成されるデータにアクセスしなければ計算が不可能である可能性がある情報が含まれる。1つの例が、可変サイズ配列の現在の上限、またはサイズが実行時にのみ既知になる別の要素に続く要素へのオフセットである。そのような情報は、モデル・インスタンスに値として含めることができるが、これは、実行時インスタンスごとに1つのモデル・インスタンスを必要とし、モデルを実行時にのみ構成できることを意味し、モデル定義で、実行時にモデル・インスタンスを作成するためにファクトリおよび他の装置を含めることが必要になることを意味する。プラットフォームおよびコンパイラの知識から構成できるモデルは、はるかに有用であり、数式によって、実行時情報が使用可能である時に具象的な値を定義する方法が提供される。これらの数式は、マーシャル・エンジンによって解釈することができ、あるいは、数式を使用して、マーシャル・エンジンによってオンデマンドでロードされ実行されるマーシャル・コードを生成することができる。
【0091】
4.d.数式
数式に関して使用される時に、「フィールド」は、TypeDescriptorモデルによって記述される言語データ構造体の構成要素を指し、「属性」は、モデルの部分を指し、フィールドの「特性」を表す値を有する。したがって、フィールドの値は、言語データ構造体の特定のインスタンスの実行時値を意味し、属性の値は、言語データ構造体のフィールドの記述の一部であり、そのデータ構造体のすべてのインスタンスに適用され、データ構造対がモデル化される時に決定される。TypeDescriptorモデルのインスタンスのほとんどの属性について、属性の値は、インスタンスが構築される時に既知である。というのは、データ構造体内のサイズおよびオフセットなど、記述されるフィールドの特性が、不変であるからである。しかし、データ構造体のフィールドが、COBOLのOCCURSDEPENDING ON構造またはPL/IのRefer構造を使用して定義される場合には、フィールドのいくつかの特性(およびそのフィールドの値に依存する他のフィールドの特性)を、モデル・インスタンスが構築される時に判定できない。
【0092】
これらの言語構造を使用して定義できる特性が、ストリング長および配列の限界である。これらの言語構造に間接的に依存する可能性がある特性が、フィールドが可変サイズのフィールドに続く場合の、構造体内のフィールドのオフセットである。
【0093】
これらの言語構造を処理するために、これらの構造(したがって、対応する属性の値)に依存する可能性があるフィールドの特性を、モデルが使用される時に評価できる数式を指定するストリングを用いて定義する。
【0094】
しかし、あるフィールドの特性が、モデル・インスタンスが構築される時に既知である場合には、属性数式によって、単純に整数値が指定される。たとえば、ストリングが長さ17を有する場合には、その長さの数式が”17”になる。
【0095】
上で述べた数式は、下記に制限される。
*符号なし整数
*下記の算術整数関数
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
mod関数は、mod(x、y) = rとして定義され、ここで、rは、x−rがyによって割り切れるようになる最小の非負の整数である。したがって、mod(7、4)は3であるが、mod(−7、4)は1である。yが2のべきである場合には、mod(x、y)は、xとy−1のビット単位の論理ANDに等しい。
* val関数
val関数は、モデルによって記述されるフィールドの値を返す。val関数は、1つまたは複数の引数をとり、第1引数は、フィールドを含むレベル−1データ構造体を参照し、
*言語モデル内のレベル−1データ構造体の名前、または
*可変サイズ・フィールドのレベル−1親を示す整数1
のいずれかでなければならない。後者の場合に、可変サイズ・フィールドと、そのサイズを指定するフィールドが、同一のデータ構造体内にあり、したがって、共通のレベル−1親を有する。
後続の引数は、参照解除されなければならない(サブ)フィールドのサブ構造体内での序数を指定する整数である。
【0096】
デフォルトで、構造体内のCOBOLデータ・フィールドは、ストレージ内で型固有の境界に位置合せされない。たとえば、4バイト整数の「自然な」位置合せは、フルワード・ストレージ境界である。そのような位置合せは、宣言でSYNCHRONIZED文節を使用することによって指定することができる。そうでない場合には、データ・フィールドは、構造体内の先行するフィールドの末尾の直後から始まる。COBOLは、ビット・データを有しないので、フィールドは、必ずバイト全体の境界から始まる。
【0097】
PL/Iの場合に、状況はより複雑になる。位置合せは、Aligned宣言属性およびUnAligned宣言属性によって制御される。COBOLとは違って、データのほとんどの型、特に2進数および浮動小数点数が、デフォルトで自然な境界に位置合せされる。
【0098】
4.d.i)数式の例
4.d.i)a)COBOL
この例では、ドラフト規格からの提案されたインライン・コメント・インジケータ”*>”を使用する。これは、まだ正当なCOBOLの使用法ではない。
【0099】
1.下記のデータ記述を検討されたい。
*> フィールドオフセット
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のオフセットは、単純であり、数式”36”によって与えられる。Claimsのオフセットもそうであり、”112”である。
【0100】
しかし、配列Claimは、変化する回数だけ現れる可能性があるので、構造体Historyは、可変サイズ・フィールドである。したがって、Claimsの直後のPriceのオフセットは、配列ストライド(特定の次元に沿って連続する要素の間の距離)を含む、より複雑な数式を必要とする。Claimについて、1つの次元だけがあり、そのストライドの数式は”154”である。したがって、Priceのオフセットの数式は、次のようになる。
"add(112,mpy(val(1,2,2),154))"
【0101】
val関数の第1引数は1であり、これは、実行時に値を含むフィールドNumClaimsが、数式によってオフセットが指定されるフィールドPriceと同一のレベル−1構造体Used-Car内にあることを意味する。他の2つの引数は、2と2である。第1の2は、Used-Carの第2の即値サブコンポーネントHistoryを指す。第2の2は、参照解除されるフィールドが、Historyの第2コンポーネントすなわち、NumClaimsであることを意味する。
【0102】
OCCURS DEPENDING ONオブジェクトが、別の構造体、たとえばレベル−1構造体Car-Dataの第3サブコンポーネント内にある場合には、val関数が、”val(Car-Data、3)”になる。
【0103】
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)"
【0104】
2進フィールドを適当なハーフワード・ストレージ境界またはフルワード・ストレージ境界に位置決めするために、COBOLでは、「遊びバイト」と称する埋込みを構造体に導入する。トップダウンで作業して、この埋込みが、位置合わせを必要とするフィールドの直前に導入される。したがって、MileageとNumClaimsの間に1バイトの埋込みがある。
【0105】
Claimなどの配列について、COBOLは、要素内の埋込みを調整するだけではなく、配列の各要素の位置合わせも調整する。この例では、Claimの最初の出現が、フルワード境界の1バイト後に開始される。フィールドClaimNoは、正確にフルワードの長さなので、フルワード境界の1バイト後で終り、したがって、COBOLでは、2進数フルワード整数ClaimAmtの直前に3バイトの埋込みが挿入される。また、後続の出現を位置合わせし、その結果、それらも最初の出現のようにフルワード境界の1バイト後から始まり、したがって、同一の構成を有することができるようにするために、COBOLでは、各出現の末尾に3バイトの埋込みを追加する。
【0106】
最後に、埋込みの後に、Claimの各出現が、フルワード境界の1バイト後で(始まり、)終わるので、COBOLでは、2進フィールドPriceの後に3バイトの埋込みが置かれる。これらの余分なバイトのすべての結果として、Priceのオフセットの数式は、位置合わせされない例からかなり変更され、次のようになる。
"add(add(113,mpy(val(1,2,2),160)),3)"
【0107】
OCCURS DEPENDING ON構成とPL/IのReferオプションの間に、複数の相違がある。COBOL構造体のストレージは、必ず最大サイズで割り振られるが、PL/I構造体は、Referオプションによって指定される実際のサイズで割り振られる。可変サイズCOBOL配列の特定のインスタンスでの出現の数を変更することが、正しく、普通であり、これは、その配列に続くすべてのフィールドの位置およびオフセットが変化するという影響を有する。PL/Iについて、構造体の特定のインスタンスの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).
cとdの間に1バイトが挿入される。したがって、dの位置合わせは、bの2つの値すなわち、最大値5と2だけについて正しい。
【0108】
上で注記したように、数式は、構造体内のフィールドのオフセットだけではなく、境界およびストライドなど、配列の特性も記述する。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"
【0109】
プログラムは、たとえばd1(2)またはd2(3、4)など、上位コンテナ・フィールドを添字にすることによって配列のスライスを参照することができるが、普通の種類の参照は、たとえばel(4、5、6)など、添字のフル・シーケンスを使用して、下位レベルに対して行われる。このストライド数式を使用して要素el(m、n、o)を突き止めるためには、aのアドレスをとり、それを(m-1)×168+(n-1)×28+(o-1)×4に加算する。COBOLの場合に、配列添字の下限は、必ず1である。すなわち最初の要素は必ずElement(1)であり、逆も同様である。
【0110】
言うまでもなく、配列のすべての次元が、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
【0111】
特定の要素のアドレスの計算に、まだストライド数式が含まれるが、もはや単純な整数はない。上の例の要素el(m、n、o)のアドレスは、aのアドレスをとり、次式に加算することによって与えられる。
(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.
【0112】
同様に、これらのストライド数式は、bのオフセットに関する下記の数式に使用される。
"add(6,mpy(val(1,1),mpy(val(1,2),mpy(4,val(1,3)))))"
【0113】
4.d.i).b).PL/I
1.下記の構造体を与える
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)" */
;
c3のオフセットは、単純な数式”4”によって与えられるが、c10のオフセットは、下の数式によって与えられる。
"add(24,val(1,2,3))"
【0114】
上のval関数の第1引数は1であり、これは、現在の構造体cを示す。後続の引数は2と3であり、第2のレベル−2フィールドc4の第3引数c7が、参照解除されるフィールドであることを示す。
【0115】
c11のオフセットは、c10のオフセットにc10の長さを加えたものに等しく、次の数式によって与えられる。
"add(add(24,val(1,2,3)), 6)"
【0116】
PL/I構造体マッピングは、トップダウンではなく、これは、次の構造体のマッピングを調べることによって示すことができる。
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)"*/
【0117】
b1の値は、val(1、1、1)によって与えられ、c2を4バイト境界に置くために、PL/Iでは、cの前(c1とc2の間ではなく)に、必要な埋込みのすべてを置き、したがって、cのオフセットが、次の数式によって与えられる。
"add(8,mod(neg(val(1,1,1)),4))"
【0118】
したがって、b1に値3が含まれる場合に、この数式は、add(8、mod(neg(3)、4))になり、これは9と評価される。すなわち、構造体bと構造体cの間に1バイトの埋込みがある。
【0119】
このモデルでは、配列の境界およびストライドの指定にもこれらの数式が使用され、ここで、ストライドは、配列内の2つの連続する要素の間の距離として定義される。
【0120】
たとえば、下の構造体では、a.eの第2次元が、数式”4”によって指定されるストライドを有し、第1次元が、数式”20”によって指定されるストライドを有する。
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" */
【0121】
これは、要素a.e(m、n)を突き止めるために、a.eのアドレスをとり、
(m-1)*20 + (n-1)*4
に加算することを意味する。
【0122】
上の例がわずかに変更されて、
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" */
になる場合に、dとeの間に埋込みがあるが、型記述子のユーザは、全く気付かず、単にストライドとオフセットの数式を使用して、所与の配列要素を突き止めることができる。aのストライドは”40”であり、eのストライドは”4”であり、eのオフセットは”20”である。これは、要素a(m).e(n)を突き止めるために、aのアドレスをとり、(m-1)×40+20+(n-1)×4に加算することを意味する。
【0123】
最後に、上の例がまた変更されて、
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"*/
になる場合に、a.eの計算は、上と同一であるが、a.cの計算が、興味深いものになる。
【0124】
aのストライドは、まだ”40”であり、cのストライドは、”4”であり(この”4”は、ビットのカウントであってバイトではない)、cのオフセットは”4”である。要素a(m).c(n)を突き止めるためには、バイト・アドレスとビット・オフセットの両方が必要である。バイト・アドレスについては、aのアドレスをとり、(m-1)×40+4+((n-1)×4)/8に加算する。a(m).c(n)のビット・アドレスは、mod((n-1)×4、8)によって与えられる。
【0125】
4.e.TypeDescriptorの仕様
4.e.i.TDLangメタモデル仕様
TDLangクラス − 全般的な概要。TDLangクラスは、すべてのCAM言語モデルとTypeDescriptorモデルの間の抽象の1レイヤとして働く。
【0126】
どのCAM言語モデルでも、TDLangモデルにプラグ・インすることができるので、TypeDescriptorモデルは、CAM言語モデルにアクセスするために、TDLangとインターフェースする方法を理解するだけでよい。
【0127】
TDLangモデルは、独力では全く機能を提供せず、したがって、言語モデルに接続される時に限って意味を持つ。TDLangは、すべてのCAM言語モデルに共通し、TypeDescriptorモデルから言語モデルへの関連の型ターゲットである。
【0128】
すべてのTDLangクラスが、抽象クラスであり、言語メタモデルの基本クラスとして働くことに留意されたい。
【0129】
TDLangClassifier。TDLangClassifierは、すべての言語固有ClassifierクラスおよびTDLangComposedTypeの親クラスである。TDLangSharedType関連は、ElementクラスからClassiferクラスへの言語の”+SharedType”関連から派生する。関連は、その関連が言語モデルから派生したことを反映するために、”volatile”、”transient”、または”derived”としてマークされなければならない。TDLangClassifierは、TDLangModelElementから派生する。
【0130】
TDLangElement。TDLangElementは、すべての言語固有Elementクラスの親クラスである。tdLangTypedElement関連は、ClassifierクラスからElementクラスへの言語の”+TypedElement”関連から派生する。関連は、その関連が言語モデルから派生したことを反映するために、”volatile”、”transient”、または”derived”としてマークされなければならない。
【0131】
tdLangElement関連は、ClassifierクラスからElementクラスへの言語の”+Element”関連から派生する。関連は、その関連が言語モデルから派生したことを反映するために、”volatile”、”transient”、または”derived”としてマークされなければならない。
【0132】
TDLangComposedType。TDLangComposedTypeは、すべての言語固有ComposedTypesの親クラスである。TDLangGroup関連は、ElementクラスからComposedTypeクラスへの言語の”+group”関連から派生する。関連は、その関連が言語モデルから派生したことを反映するために、”volatile”、”transient”、または”derived”としてマークされなければならない。TDLangComposedTypeは、TDLangClassifierから派生する。
【0133】
4.e.ii.TypeDescriptorメタモデル仕様
TypeDescriptorパッケージでは、データ項目型の物理的実装を記述するモデルが定義される。このモデルは、言語中立であり、多数の言語の型を記述するのに使用することができる。異なる言語の型モデルの検査によって、言語型の一致可能性を判定することができる。たとえば、Java(R)のlong型は、しばしば、COBOLのbinary型と同一であり、その場合には、これらの型を、副作用なしで相互変換することができる。その一方で、COBOLのalphanumeric型は、サイズが固定されるが、Java(R)の型にマッピングされる場合に、この特性が失われる。Java(R)からCOBOLに再変換される時に、COBOLの切詰規則が適用されず、計算の例外がもたらされる可能性がある。
【0134】
AggregateInstanceTD。集約のインスタンスごとに、このクラスのインスタンスがある。この集約の子を探すためにには、関連を言語Classifierまで逆にナビゲートし、言語ComposedTypeにダウンキャストし、その子への関連に従わなければならない。
InstanceTDBaseから派生
パブリック属性:
union : boolean = false
集約が包含的(たとえば構造体)または排他的(たとえば共用体)のどちらであるかを区別する。
union = trueの場合には、ストレージがオーバーレイされ、その結果として内容の解釈が不確実になる可能性がある。
【0135】
ArrayTD。ArrayTDは、配列型の情報を保持する。
パブリック属性:
arraryAlign : int
配列内の各要素のアドレス可能単位での位置合わせ要件。
strideFormula : string
インデックスを与えられて、配列内の要素の変位アドレスを計算するのに使用することができる数式。
strideInBit : boolean
真は、strideFormula値がビット単位であることを示す。
偽は、strideFormula値がバイト単位であることを示す。
upperBoundFormula : String
この値が変数によって参照される時に、インスタンスのStringとして宣言される。この属性は、可変サイズ配列の上限値を供給する。
上限は、構造体全体を逆にトラバースする時に必要になる。
lowerBoundFormula : String
この値が変数によって参照される時に、インスタンスのStringとして宣言される。この属性は、可変サイズ配列の下限値を供給する。
【0136】
InstanceTDBase。InstanceTDBaseは、宣言された変数および構造体要素ごとにインスタンスを有する。
インスタンスの親(インスタンスが親を有する場合に)を見つけるためには、関連をTDLangElementまで逆にナビゲートし、TDLangClassifierへの関連に従って親を突き止め、その後、TypeDescriptorモデルへ逆に関連に従わなければならない。
パブリック属性:
offsetFormula : string
このインスタンスの先頭へのオフセットを計算する数式。
この属性は、このフィールドが必ず整数値であるとは限らないので、Stringである。たとえば、(value(n)+4)が、可能な値になる可能性がある。
注:オフセット値は、最上位の親から計算される(たとえば、2進木A→B、A→C、B→D、B→Eについて、Dへのオフセットは、BからDではなく、AからDへ計算される)。
contentSizeFormula : string
内容の現在のサイズを計算する数式。
allocSizeFormula : string
インスタンスの割り振られたサイズを計算する数式。
formulaInBit : boolean
真は、offsetFormula、contentSizeFormula、およびallocSizeFormulaの値がビット単位であることを示す。
偽は、offsetFormula、contentSizeFormula、およびallocSizeFormulaの値がバイト単位であることを示す。
defaultEncoding : String
物理的エンコーディング − コード・ポイントのエンコードに何ビットが使用され、コード・ポイントがビット・パターンにどのようにマッピングされるか
ストリング内容がどのようにエンコードされるかに関する情報:EBCDIC、ASCII、UNICODE、UTF−8、UTF−16、コードページ番号などが格納される。
accessor : enumeration
この要素のアクセス権を指定する。
defaultBigEndian : boolean
この要素がビッグ・エンディアン・フォーマットである場合に真。
floatType : enumeration
この要素の浮動型を指定する。
【0137】
PlatformCompilerType。特定のプラットフォームおよびコンパイラに関する特定のデータ型。
注:プラットフォームおよびコンパイラを識別する何らかの方法が必要である。
このクラスは、特殊化されるか属性を有することができ、あるいは、属性をInstanceTDBaseに置くことによって単純化することができる。
パブリック属性:
platformCompilerType : String
この属性は、言語モデル内のデータを作成するのに使用されたコンパイラの型を指定する。このストリングの使用法は、次の通りである。
”ベンダ名、言語、OS、ハードウェア・プラットフォーム”(たとえば、"IBM,COBOL, OS390, 390"または"IBM, PLI, WinNT, Intel")。
【0138】
SimpleInstanceTD。言語モデルのSimple型のインスタンス。
InstanceTDBaseから派生する。
【0139】
NumberTD
すべての数の表現。
現在は、IntegerとPacked Decimalが含まれる。
Numberのこれらの型に必要なフィールドに留意されたい:
*Integer*
Base=2
MSBU=0または 1
Signed/Unsigned
サイズ(バイト単位)=1、2、4、8(16)
*Packed Decimal*
Base=10
MSBU=0
Signed
幅=1-63
*Float*
Base=2(IEEE)、16(Hex)
MSBU=0または1
Signed
サイズ(バイト単位)=4、8、16
エンコーディングの詳細
BaseTDから派生する
パブリック属性:
base : int
この数の基数表現。2=2進、10=10進、16=16進、など
baseWidth : int
基数を表すのに使用されるビット数
たとえば、2進数=1、10進数=8、パック=4
baseInAddr : int
アドレス可能記憶単位内のbaseWidth単位の数。たとえば、アドレス可能単位がバイトの場合に、10進=1、パック=2、2進=8。アドレス可能単位が32ビット・ワードである場合には、10進が4、パックが8、2進が32になる。
baseUnits : int
数のbase単位の数。これとbasewidthの積は、widthとaddrUnitの積以下でなければならない。
たとえば、右に位置合わせされる32ビット・ワードの24ビット・アドレスは、base=1、basewidth=24、baseInAddr=8、width=4を有する。
signCoding : enumeration
列挙の組すなわち、2進数の場合に2の補数、1の補数、および符号絶対値、10進数の場合に0符号、パック10進数、符号なし2進数、および符合なし10進数の場合にパック符号。
checkValidity : boolean
ピクチャ・ストリング・サポートのために言語モデルが必要な場合に真。
packedDecimalSign : enumeration
COBOL10進数の符号のコード・ポイントを決定するのに使用される。符号は、先頭の数字または末尾の数字と組み合わされる。
【0140】
FloatTD
浮動小数点
BaseTDから派生する
パブリック属性:
floatType : enumeration
この要素の浮動型を指定する。
【0141】
StringTD
英数字型
BaseTDから派生する
パブリック属性:
encoding : String
物理的エンコーディング − コード・ポイントのエンコードに何ビットが使用され、コード・ポイントがビット・パターンにどのようにマッピングされるか ストリング内容がどのようにエンコードされるかに関する情報:EBCDIC、ASCII、UNICODE、UTF−8、UTF−16、コードページ番号などが格納される。
lengthEncoding : enumeration
lengthEncodingの可能な値:
−固定長(全長が宣言されたストリング長と等しい)
−長さプレフィックス付き(全長が、ストリングの長さとヘッダ・バイトの長さの和に等しい。ヘッダ・バイトは、通常は1バイト、2バイト、または4バイトである)。
−ヌル終端(PL/IではvaryingZストリングと称する)(ヌル記号がストリングの末尾に追加される。したがって、最大長さは、宣言されたストリング長と、ヌル記号を表す1バイトの合計までになる)
maxLengthFormula : String
このストリングの最大長さを指定する数式。
checkValidity : boolean
ピクチャ・ストリング・サポートのために言語モデルが必要な場合に真。
textType : String = Implicit
値は、’Implicit’または’Visual’である
orientation : StringTD = LTR
値は、’LTR’、’RTL’、’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’である
【0142】
AddressTD
ポインタ/アドレスを表す型
このクラスの理論的根拠:
アドレスは、NumberTDクラスとは別に考慮されなければならない。というのは、ある計算機(たとえばIBM400)上のいくつかの言語が、アクセス権タイプ(NumberTDクラスでは表現されない)などの追加情報を伴うアドレスを表すからである。
BaseTDから派生する
パブリック属性:
permission : String
このアドレスのアクセス権を表す。主にAS/400システムで使用される。
bitModePad : enumeration
このアドレスのビット数を指定する。埋込みの計算に使用される。
【0143】
BaseTD
TypeDescriptorの基本クラス。
BaseTDモデル型は、同一の言語型のすべてのデータ要素に共通する実装情報を保持するように特殊化される。したがって、特定のハードウェア/ソフトウェア・プラットフォームの32ビット符号付き2進整数を記述する情報は、この型を用いていくつのデータ要素が宣言されるかに無関係に、所与のモデル・インスタンス化で1回だけインスタンス化される。
パブリック属性:
addrUnit : enumeration
ストレージ・アドレス可能単位(bit/byte/word/dword)でのビット数
width : int
記述される型でのアドレス可能ストレージ単位の数。1ビット、8ビット、16ビット、32ビットにすることができる。
alignment : int
アドレス空間で型に必要な位置合わせ − たとえば、ワード位置合わせされる32ビット整数は、4のalignmentを有する。
nickname : int
基本要素の名前。これは、属性の組合せに基づく論理ではなく名前に基づく論理を可能にするために、単純型のインスタンスを一意に識別しなければならない。たとえば、32ビットS/290非拡大縮小2進整数は”S390Binary31_0”である。
bigEndian : boolean
この要素がビッグ・エンディアン・フォーマットである場合に真。
【0144】
ステレオタイプ
bitModePad
パブリック属性:
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プラットフォームで稼動するIEEE拡張浮動小数点
IEEEextendedAIX :
AIXプラットフォームで稼動するIEEE拡張浮動小数点
IEEEextendedOS390 :
OS/390プラットフォームで稼動するIEEE拡張浮動小数点
IEEEextendedAS400 :
AS400プラットフォームで稼動するIEEE拡張浮動小数点
IEEEnonextended :
IEEE非拡張浮動小数点
IBM390Hex :
IBM OS/390で稼動する16進浮動小数点
IBM400Hex :
IBM AS400で稼動する16進浮動小数点
accessor
パブリック属性:
ReadOnly :
WriteOnly :
ReadWrite :
NoAccess :
packedDecimalSign
パブリック属性:
MVS :
MVSCustom :
NT/OS2/AIX :
【0145】
5.言語メタモデル
5.a.COBOLメタモデル
COBOLメタモデルは、コネクタ・インターフェースを表すデータ構造体(セマンティクス)を定義するために、エンタープライズ・アプリケーション・プログラムによって使用される。
【0146】
図15、および図16に、コネクタ・インターフェースを表すデータ構造体セマンティクスを定義するためのCOBOLメタモデルを示す。このメタモデルは、M2レベルのMOFクラス・インスタンスでもある。図17に、TDLangClassifier、TDLanguageComposedType、およびTDLangElementである、COBOLメタモデルとTDLang基本クラスの間の関連を示す。図18に、COBOLメタモデルのCOBOL使用値の列挙を示す。
【0147】
このCOBOLモデルの目標は、Data Divisionで見つかるはずの情報を取り込むことである。このモデルは、COBOLのdatadivisionをそのXML同等物に変換するために、読取専用としてのみ使用されることを予定されている。このモデルは、XMLコードからCOBOLのdatadivisionの同等物へのコンバータとして使用されることを予定されていない。その結果、要素のinitialValueは、このモデルには取り込まれない。
【0148】
COBOLSimpleType
COBOLSimpleTypeは、COBOL言語のすべての単純型によって共用される属性を含む抽象クラスである。
COBOLClassifierから派生する
パブリック属性:
usage : COBOLUsageValues
usageには、COBOLUsageValuesで定義されるデータ型が含まれる。
usageでは、メモリ内のデータのフォーマットが定義される。COBOLソースで何も指定されていない場合には、デフォルトは”display”である。よく使われるCOMP−3が、パック10進数の同等物であることに留意されたい。
pictureString : String
これは、ソースで指定されるピクチャ・ストリングの正規形式である。これは、必ずしもプログラムで与えられるピクチャ・ストリングと同一「ではない」!
ピクチャ・ストリングの正規形式に達する手順は次の通りである:
1.括弧で囲まれた文字のすべてを展開する
2.4文字より長い同一の文字のすべてのシーケンスについて、括弧で囲まれた表現を構成する。
たとえば:
XXX999(3)から開始する
ステップ1の後に、XXX99999が得られる
ステップ2の後に、XXX9(5)が得られる
この正規形式は、最短の同等なピクチャ・ストリングをもたらす。正規形式は、同等性検査に有益である。
Synchronized : Boolean = false
このブール属性は、要素について任意選択として指定することができるSYNCHRONIZED文節またはSYNC文節に対応する。
COBOL言語で、SYNCHRONIZED文節に続けることができる追加の文節RIGHT/LEFTが定義されていることに留意されたい。しかし、COBOLのIBMの実装では、この追加の文節が、文書化のみとしてサポートされ、SYNCHRONIZEDとして定義されたすべての要素が、自動的に左に同期化される。
パブリック動作:
getCanonicalPictureString (pictureString :String) : String
このストリングの圧縮された値を返す。たとえば、pictureString属性に、9999v99のピクチャ・ストリングを含めることができるが、getCanonicalPictureString()は、値として9(4)v9(2)を返す。
【0149】
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
【0150】
COBOLVariableLengthArray
COBOLVariableLengthArrayは、COBOLElementのソースが下記の構文を有する時に、必ずインスタンス化されなければならない。
LEVEL ELEMENTNAME1 OCCURS X1 TO X2 TIMESDEPENDING ON ELEMENTNAME2.
ここで、X1およびX2は、0以上のすべての整数とすることができ、X2>X1である。ELEMENTNAME2は、ELEMENTNAME1の前に定義されていなければならない。
COBOLVariableLengthArrayは、この配列がどの要素に依存するかを指定する、単一の必要な関連を有する。
COBOLFixedLengthArrayから派生する
パブリック属性:
minUpper : Integer
maxUpper(最大上限)がVariableArrayに属する場合に、maxUpperは、メモリ内で割り振ることができる配列の絶対上限を示す。実際の最大値は、それが参照する要素の値によって示され、これは、”dependingOn”関連を呼び出すことによって入手される。
minUpper(最小上限)は、OCCURS 4 to 7 TIMESDEPENDING ON X1の形のCOBOL構文を取り込むのに使用される。この場合に、minUpperは4に等しく、maxUpperは7に等しく、実際の上限は、X1の値に依存する。
lower(下限)は、COBOLの場合には必ず1であるが、他の言語との一貫性および明瞭さのために含まれる。
【0151】
COBOLRedefiningElement
REDEFINES文節を用いると、同一のコンピュータ・ストレージ域を記述する異なるデータ記述項目を使用できるようになる。
この文節の使用の例は次の通りである:
1 TEST
2 Y PIC X(4)
2 YRREDEFINES Y BINARY PIC 9(5)
Typedef=再定義/共用体の場合に偽
COBOLElementから派生する
【0152】
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から派生する
【0153】
COBOL88Element
COBOL88Elementは、COBOL 88データ・レベルを表す。
たとえば:
1 TESTX PIC.
88 TRUEXVALUE 'T' 't'. *(TRUEXは2つの値を有する)
88 FALSEXVALUE 'F' 'f'. *(FALSEXは2つの値を有する)
ここで、TRUEXおよびFALSEXは、それぞれ、値が(’T’または’t’)または(’F’または’f’)と等しい場合のTESTX変数の条件名である。
したがって、TESTX=’T’または’t’の場合には、TRUEX=TRUEかつFALSEX=FALSEであり、
TESTX=’F’または’f’の場合には、FALSEX=TRUEかつTRUEX=FALSEである
パブリック属性:
name : String
COBOL88Elementの名前またはハンドルを指定する。
【0154】
COBOL88ElementValue
このクラスの使用の例は次の通りである:
1 TESTX PIC X.
88 TRUEXVALUE 'T' 't'. *(TRUEXは2つの値を有する)
88 FALSEXVALUE 'F' 'f'. *(FALSEXは2つの値を有する)
88 UA VALUE'A' THRU 'I' 'J' THRU 'R' 'S' THRU 'Z' '&' '-'.
*UAは5つの値を有し、最初の3つは範囲である
このクラスの理論的根拠:
・このクラスが存在するのは、各COBOL88Elementに複数の値を含めることができるからである。たとえば、TRUEXには、2つの値、’T’および’t’が含まれる。したがって、このクラスは、COBOL88Element(したがって、1…*基数)ごとに複数(だが少なくとも1回)インスタンス化することができる。
・UAの’A’ THRU ’I’などの範囲値について、lowerLimit=’A’、upperLimit=’I’であり、range=trueである。また、THRUキーワードを使用する時に、lowerLimitがupperLimit未満でなければならないことに留意されたい。
・’T’および’t’などの非範囲値について、lowerLimitフィールドを使用して値を表すと決定した。
パブリック属性:
lowerLimit : String
lowerLimitは、THROUGH範囲の下限を指す
upperLimit : String
upperLimitは、THROUGH範囲の上限を指す
range : Boolean
rangeに真がセットされる場合には、関連付けられたデータ項目がウィンドウ化日付フィールドでない限り、リテラル−1がリテラル−2未満でなければならない。
【0155】
COBOLAlphanumericType
PICTURE文字列は、下記のいずれかからなることが必要である:
・記号
・記号A、X、および9の組合せ(すべてAまたはすべて9を含む文字列は、英数字項目を定義しない。)
他の文節:USAGE DISPLAYが指定されるか、暗黙指定されなければならない。
すべての関連するVALUE文節で、非数字リテラルまたは表意定数を指定しなければならない。
COBOLSimpleTypeから派生する
パブリック属性:
JustifyRight : Boolean = false
このブール値は、JUSTIFIED(またはJUST)文節に対応する。JUSTとJUST RIGHTが同一の意味を持つことに留意されたい。
【0156】
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
このストリングは、たとえば$、£、DMなど、世界で使用される異なる通貨記号を表す。
Decimal : Boolean
Decimalブール値は、ピクチャ・ストリングおよび数値のピリオドおよびコンマの機能を入れ替える。
真の場合には、10進数が使用される(たとえば1,234.56)
偽の場合には、コンマが使用される(たとえば、1.234,56)
【0157】
COBOLNumericType
数値項目の型は、次の通りである:
・2進数
・パック10進数(内部10進数)
・ゾーン10進数(外部10進数)
PICTURE文字列には、記号9、P、S、およびVだけを含めることができる。数値データ・フィールドの場合に、PICTURE文字列に、記号9およびSだけを含めることができる。
有効な範囲の例
PICTURE 有効な値の範囲
9999 0から9999まで
S99 -99から+99まで
S999V9 -999.9から+999.9まで
PPP999 0から.000999まで
S999PPP -1000から-999000までおよび+1000から+999000までまたは0
他の文節:項目のUSAGEは、DISPLAY、BINARY、COMPUTATIONAL、PACKED-DECIMAL、COMPUTATIONAL-3、COMPUTATIONAL-4、またはCOMPUTATIONAL-5とすることができる。
このクラスの可能な使用値は、’binary’、’packedDecimal’、および’display’であり、これらは、それぞれcomp−1宣言およびcomp−2宣言によって表される。
COBOLSimpleTypeから派生する
パブリック属性:
Signed : Boolean
このブール値は、SIGN文節に対応する。
数が符号付きである場合に真。
SignLeading : Boolean
この属性は、LEADING(TRAILINGに対する)文節に対応する。
LEADINGの場合に真。
SignSeparate : Boolean
このブール値は、SEPARATE文節に対応する。
SEPARATEの場合に真。
currencySymbol : char
この文字は、COBOLでcurrencySignを表すのに使用される記号(たとえば、$=$、L=£、D=DMなど)を表す。
trunc : String
Truncオプションによって、2進データ項目について10進数ピクチャ制約を順守しなければならないかどうかが決定される。
Truncの値は次の通りである:
STD、OPT、およびBIN
TRUNC(STD)は、COBOL 85標準規格に準拠するが、TRUNC(OPT)およびTRUNC(BIN)は、IBM拡張である。
Trunc属性に関するさらなる情報については、「COBOL/VSEProgramming Guide」を参照されたい。
numproc : String
Numproc(PDF)は、10進符号値に関するより厳格な標準規格を負わせる。
Numprocの値は次の通りである:
NOPDF、PDF、およびMIG。
コンパイラに無効な符号の処理を実行させたい場合には、NUMPROC(NOPFD)を使用する。このオプションは、NUMPROC(PFD)ほど効率的ではない。オブジェクト・コード・サイズが増え、すべての符号付きデータを検証するために実行時オーバーヘッドが増える可能性がある。
NUMPROC(NOPFD)およびNUMPROC(MIG)は、COBOL 85標準規格に準拠する。
Decimal : Boolean
Decimalブール値は、ピクチャ・ストリングおよび数値のピリオドおよびコンマの機能を入れ替える。
真の場合には、10進数が使用される(たとえば1,234.56)
偽の場合には、コンマが使用される(たとえば、1.234,56)
【0158】
COBOL66Element
COBOL66Elementは、COBOL 66データ・レベルを表す。
たとえば:
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
COBOL66Elementの名前またはハンドルを指定する。
【0159】
COBOLFixedLengthArray
COBOLFixedLengthArrayは、COBOLElementのソースが下記の構文を有する時に、必ずインスタンス化されなければならない:
LEVEL ELEMENTNAME OCCURS X TIMES.
ここで、Xは、1以上の任意の整数とすることができる。
maxUpper(最大上限)がFixedArrayに属する場合に、maxUpperは、メモリ内で割り振られる配列の上限を示す。
lower(下限)は、COBOLの場合には必ず1であるが、他の言語との一貫性および明瞭さのために含まれる。
【0160】
COBOLDBCSType
PICTURE文字列に、記号G、GおよびB、またはNを含めることができる。G、B、またはNのそれぞれが、単一のDBCS文字位置を表す。DBCSリテラルの文字の範囲全体を使用することができる。
他の文節:PICTURE文節記号Gが使用される時には、USAGE DISPLAY−1を指定しなければならない。
PICTURE文節記号Nが使用される時には、USAGE DISPLAY−1が、仮定され、指定する必要ない。
すべての関連するVALUE文節で、DBCSリテラルまたは表意定数SPACE/SPACESを指定しなければならない。
DBCSTypeは、1文字ごとに2バイトを占有する。
COBOLSimpleTypeから派生する
【0161】
COBOLAlphanumericEditedType
PICTURE文字列に、下記の記号を含めることができる:
A X 9 B 0 /
ストリングには、少なくとも1つのAまたはXが含まれ、少なくとも1つのBまたは0(ゼロ)または/が含まれなければならない。
標準データ・フォーマットの項目の内容は、コンピュータの文字セットからの2つ以上の文字でなければならない。
他の文節:USAGE DISPLAYが指定されるか、暗黙指定されなければならない。
すべての関連するVALUE文節で、非数字リテラルまたは表意定数を指定しなければならない。リテラルは、正確に指定されたままで扱われ、編集は行われない。
編集される型は、数字が、編集される型の場合にメモリに保管され、編集されない型では保管されないという点で、編集されない型と異なる。
COBOLSimpleTypeから派生する
【0162】
COBOLClassifier
COBOLClassifierクラスは、COBOLComposedTypeおよびCOBOLSimpleTypeの親クラスであり、’typedef’属性を含む。
COBOLでのTYPEDEFの影響を考える最も良い方法は、単純なCマクロに似た字句置換である。TYPE文節を、TYPEDEFキーワードに続くすべてのものに置換する。その後、レベル番号を適当に調整した後に、結果が、正しいCOBOLにならなければならない(調整されるレベル番号自体(49を超えることができる)を除く)。実際のルールは、予想されるであろうように非常に複雑であり、したがって、説明するのではなく、例を示す:
財務データに関するショップ・スタンダードを実施する単純な方法:
定義:
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の名前またはハンドルを指定する。
【0163】
COBOLAlphabeticType
PICTURE文字列に、記号Aだけを含めることができる。
標準データ・フォーマットの項目の内容は、英語アルファベットの文字およびスペース文字のいずれかからなる必要がある。
他の文節:USAGE DISPLAYが指定されるか、暗黙指定されなければならない。
すべての関連するVALUE文節で、アルファベット文字、スペース、または表意定数の値としての記号文字だけを含む非数値リテラルを指定しなければならない。
COBOLSimpleTypeから派生する
パブリック属性:
JustifyRight : Boolean = false
このブール値は、JUSTIFIED(またはJUST)文節に対応する。JUSTとJUST RIGHTが同一の意味を持つことに留意されたい。
【0164】
COBOLObjectReferenceType
このオブジェクト参照型は、COBOLでUSAGE IS INDEX OBJECTREFERENCE METACLASS OF class-name-1(class-name-1は任意選択である)として宣言されたオブジェクトをポイントする。
COBOLSimpleTypeから派生する
パブリック属性:
className : String
このインスタンスが参照するオブジェクトの名前を参照する。
【0165】
COBOLSourceText
このクラスには、ソース・コード全体(コメントを含む)およびそれに関連する行番号が含まれる。
パブリック属性:
source : String
fileName : String
【0166】
COBOLUnicodeType
このユニコード型は、ユニコード・フォーマットで保管されたデータを表す。
COBOLSimpleTypeから派生する
【0167】
COBOLInternalFloatType
COBOLInternalFloat型は、浮動小数点がメモリ内で表される形を取り込む。たとえば、値123.45は、内部的に12345と表され、暗黙の小数部が、3と4の間でマークされる。
このクラスの可能な使用値は、’float’および’double’であり、これは、それぞれcomp−1宣言およびcomp−2宣言によって表される。
COBOLSimpleTypeから派生する
【0168】
COBOLExternalFloatType
COBOLExternalFloat型は、浮動小数点がユーザに表示される形を取り込む。COBOLExternalFloatTypesは、PICが、仮数および指数の前に+/−符号を有する点を除いて、COBOLNumericEditedTypesと同一である。たとえば、値123.45は、ExternalFloatTypeでは+12345E -2として表される。
このクラスの可能な使用値は、’binary’、’packedDecimal’、および’display’である。
COBOLSimpleTypeから派生する
【0169】
COBOLAddressingType
COBOLAddressingTypeは、インデックス値、ポインタ値、およびprocedurePointer値に使用される。
このクラスの可能な使用値は、’index’、’pointer’ 、および’procedurePointer’である。
COBOLSimpleTypeから派生する
【0170】
COBOLElementInitialValue
TDLangElementから派生する
パブリック属性:
initVal : String
valueKind : COBOLInitialValueKind =string_value
【0171】
総計:
1論理パッケージ
23クラス
論理パッケージ構造
論理ビュー
cobol
TDLang
【0172】
5.b.PL/Iメタモデル
PL/I言語メタモデルは、コネクタ・インターフェースを表すデータ構造体(セマンティクス)を定義するために、エンタープライズ・アプリケーション・プログラムによって使用される。このメタモデルは、M2レベルのMOFクラス・インスタンスである。図19、図20、および図21に、コネクタ・インターフェースを表すデータ構造体を定義するためにアプリケーション・プログラムによって使用可能なPL/I言語メタモデルを示す。このメタモデルは、M2レベルのMOFクラス・インスタンスである。図22に、PL/IメタモデルのTDLangClassifier、TDLanguageComposedType、およびTDLanguageElementを示す。図23に、PL/IメタモデルのModeValues、BaseValues、LengthTypes、およびStringTypeValuesの列挙を示す。
【0173】
5.b.i.PL/Iメタモデル仕様
PL/I
PL/I言語メタモデルは、コネクタ・インターフェースを表すデータ構造体(セマンティクス)を定義するために、エンタープライズ・アプリケーション・プログラムによって使用される。
このPL/Iの言語モデルは、PARAMETER、STATIC、またはBASEDのいずれかのストレージ・クラスを有するPL/I宣言を記述することを試みる。CONTROLLED、AUTOMATIC、およびDEFINEDはサポートされない。
PL/I言語では、エクステント(すなわち、ストリング長、区域サイズ、および配列の限界)が、一般に、定数として、実行時に評価される式として、アスタリスクとして、またはREFERオプションを介して定義されるものとして、宣言されるが、これらの選択肢のどれもが、すべてのストレージ・クラスに対して有効ではない。
エクステントが定数でなく、REFERオプションを介して定義されるのでない基底付き変数は、エクステントがアスタリスクを介して指定されるパラメータと同様に、このモデルから除外される。
INITIAL属性(どの場合にもパラメータについては無効である)は、このモデルでは無視される。
【0174】
PLISimpleType
PLISimpleTypeは、PL/I言語のすべての単純型によって共用される属性を含む抽象クラスである。
PLIClassifierから派生する
【0175】
PLIElement
*PLIDeclarationは、PL/Iプログラムのすべてのデータ定義を表す。
*たとえば:
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
【0176】
PLIComposedType
PLIComposedTypeは、構造体、共用体、または基本的な変数および配列とすることができる、メンバ要素の集合である。PLIComposedTypeは、この構成の一部であるすべての要素を含む単一の集約を有する。
構造体は、その要素が同一の属性を有する必要がないデータ集約である。配列と同様に、構造体全体に、データの集約全体を参照するのに使用することができる名前が与えられる。しかし、配列と異なって、構造体の各要素も名前を有する。
構造体は、異なるレベルを有する。第1レベルでは、構造体名が、主構造と呼ばれる。より深いレベルでは、構造体の名前を、小構造と呼ぶ。最も深いレベルでは、要素の名前を要素名と呼ぶ。構造体の要素名は、配列を表すことができ、この場合に、その要素は、要素変数ではなく配列変数である。
構造体の編成は、関連する名前に先立つレベル番号の使用を介して、DECLAREステートメントで指定され、レベル番号は、整数でなければならない。主構造名は、レベル番号1を用いて宣言される。
小構造および要素名は、1より大きいレベル番号を用いて宣言される。
主構造名の記述は、下記の1つによって終了する:
レベル番号1を有するもう1つの項目の宣言
レベル番号がないもう1つの項目の宣言
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 1 PAYROLL、 2 NAME、 3 LASTCHAR(20)、などとして、連続するストリングで記述することができる。
PAYROLLは、小構造NAME、HOURS、およびRATEを含む主構造として宣言される。各小構造に、2つの要素名が含まれる。この構造体全体を、名前PAYROLLによって参照することができ、また、この構造体の部分を、小構造体名によって参照することができる。要素は、要素名を引用することによって参照することができる。
連続するより深いレベルについて選択されるレベル番号は、連続的である必要がない。レベルnの小構造に、その小構造名とn以下のレベル番号を有する次の名前との間にある、nを超えるレベル番号を有するすべての名前が含まれる。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
【0177】
PLIElementInitialValue
INITIAL属性によって、ストレージが割り振られる時に変数に割り当てられる1つまたは複数の初期値が指定される。要素変数については、1つの初期値だけを指定することができる。配列変数については、複数を指定することができる。構造体変数または共用体変数は、要素変数であれ配列変数であれ、要素名の別々の初期化によってのみ初期化することができる。INITIAL属性は、定数、定義されるデータ、非制御パラメータでないパラメータ、および非LIMITED静的項目変数に与えることができない。
INITIAL属性は、3つの形を有する。
1.第1の形、INITIALでは、初期定数、式、または関数参照が指定され、これらについて、変数にストレージが割り振られる時に、変数に値が割り当てられる。
2.第2の形、INITIAL CALLでは、プロシージャが初期化を実行するために呼び出されることが(CALLオプションを用いて)指定される。変数は、呼び出されるルーチンの実行中の割当によって初期化される(このルーチンは、呼び出し点に値を返す関数としては呼び出されない)。
3.第3の形、INITIAL TOでは、ポインタ(またはポインタの配列)が、INITIALLISTで指定された文字列のアドレスを用いて初期化されることが指定される。このストリングは、TOキーワードによって示される属性も有する。
TDLangElementから派生する
パブリック属性:
initialValue : String
ValueType : PLIInitalValueType
【0178】
PLIClassifier
PLI型
TDLangClassifierから派生する
【0179】
PLISourceText
このクラスには、ソース・コード全体(コメントを含む)およびそれに関連する行番号が含まれる。
パブリック属性:
source : String
fileName : String
【0180】
PLIComputationalType
計算型は、所望の結果を作るために計算に使用される値を表す。算術データおよびストリング・データが、計算データを構成する。
PLISimpleTypeから派生する
【0181】
PLIArithmeticType
算術データは有理数である
PLIComputationalTypeから派生する
パブリック属性:
mode : ModeValues
【0182】
PLIStringType
ストリングは、連続する文字、ビット、widechar、およびgraphicの、単一のデータ項目として扱われるシーケンスである。
PLIComputationalTypeから派生する
【0183】
PLIIntegerType
Fixed Binとして宣言される。精度とスケール・ファクタを有する。精度は、総桁数であり、スケールは、2進小数点の右側の桁数である。
例
DCL bindata BINARY FIXED (7,3)
は、7データ・ビットであり、そのうちの3ビットが2進小数点の右にある数、1011.111Bを表すのに使用することができる。
PLIArithmeticTypeから派生する
パブリック属性:
precision : Integer
scale : Integer
Signed : Boolean
BigEndian : Boolean = true
【0184】
PLIFloatType
は、=Aを有する。10進浮動小数点定数は、仮数とそれに続く指数である。仮数は、10進固定小数点定数である。指数は、文字Eと、それに続く任意選択として符号付きの整数であり、これは10のべきを指定する。10進浮動小数点定数は、精度(p)を有し、このpは、仮数の桁数である。
例は次の通りである:
15E-23 は精度=2を有する
15E23 は精度=2を有する
4E-3 は精度=1を有する
1.96E+07 は精度=3を有する
438E0 は精度=3を有する
3141593E-6 は精度=7を有する
.003141593E3 は精度=9を有する
最後の2つの例は、同一の値を表す(精度は異なる)。
10進浮動小数点変数の宣言に関するデータ属性は、DECIMALおよびFLOATである。たとえば:
DECLARELIGHT_YEARS DECIMAL FLOAT(5);
LIGHT_YEARSは、少なくとも5つの10進数字を有する10進浮動小数点データ項目を表す。
2進浮動小数点定数は、仮数とそれに続く指数および文字Bである。仮数は、2進数固定小数点定数である。指数は、文字Eと、それに続く任意選択として符号付きの10進整数であり、これは2のべきを指定する。2進浮動小数点定数は、精度(p)を有し、このpは、仮数の2進数字の数である。例は次の通りである:
101101E5B は精度=6を有する
101.101E2B は精度=6を有する
11101E-28B は精度=5を有する
11.01E+42B は精度=4を有する
2進浮動小数点変数の宣言に関するデータ属性は、BINARYおよびFLOATである。たとえば:
DECLARE S BINARY FLOAT (16);
Sは、16個の2進数の精度を有する2進浮動小数点データ項目を表す。
デフォルトの精度は(21)である。指数は、10進数3個を超えることができない。2進浮動小数点データは、正規化された16進浮動小数点として保管される。宣言された精度が(21)以下である場合には、short浮動小数点形が使用される。宣言された精度が(21)を超え、(53)以下である場合には、long浮動小数点形が使用される。宣言された精度が(53)を超える場合には、extended浮動小数点形が使用される。
PLIArithmeticTypeから派生する
パブリック属性:
base : BaseValues
precision : Integer
IEEE : Boolean = false
BigEndian : Boolean = true
【0185】
PLIPackedType
10進固定小数点変数の宣言に関するデータ属性は、DECIMALおよびFIXEDである。たとえば:
declare A fixed decimal (5,4);
では、Aが5桁の10進固定小数点データを表し、5桁のうちの4桁が、小数点の右にあることが指定される。
次の2つの例:
declare B fixed (7,0) decimal;
declare Bfixed decimal(7);
の両方で、Bが7桁の整数を表すことが指定される。
次の例
declare C fixed (7,-2) decimal;
では、Cが−2の位取り係数を有することが指定される。これは、Cが、100の増分で範囲−9999999×100から9999999×100までの7桁を保持することを意味する。
次の例
declare D decimal fixed real(3,2);
では、Dが、3桁の固定小数点データを表し、3桁のうちの2桁が小数であることが指定される。
PLIArithmeticTypeから派生する
パブリック属性:
precision : Integer
scale : Integer
【0186】
PLIPictureType
数字ピクチャ・データは、文字形式で保持される数値データである
PLIArithmeticTypeから派生する
パブリック属性:
pictureString : String
【0187】
PLICodedStringType
PLIStringTypeから派生する
パブリック属性:
type : StringTypeValues
varying : LengthType
【0188】
PLIPictureStringType
文字ピクチャ指定では、固定小数点文字データ項目が記述され、データ項目内の任意の位置に、使用可能な文字の完全な組のあるサブセットからの文字だけが含まれることを指定する追加機能がある。
文字ピクチャ指定は、AまたはXのピクチャ指定文字の出現によって認識される。文字ピクチャ指定で有効な文字は、X、A、および9だけである。これらのそれぞれによって、文字値内の1つの文字位置の存在が指定され、これには、下記を含めることができる:
X 8ビット・バイトによって表される256個の可能なビット組合せのすべての文字。
A 英数字文字、#、@、$、またはブランク。
9 任意の数字またはブランク(数値文字指定での9ピクチャ指定文字は、対応する文字が数字だけである点で異なることに留意されたい)。
文字値がピクチャ形式文字データ項目に割り当てられるか転送される時に、各位置の特定の文字が、対応するピクチャ指定文字による指定に従って有効性を検査され、無効な文字についてCONVERSION状態が発生する(しかし、レコード指向伝送を介するか別名を使用することのいずれかによって値が変更される場合には、検査はない)。
たとえば:
DECLARE PART# PICTURE 'AAA99X';
PUT EDIT (PART#) (P'AAA99X');
次の値は、PART#について有効である:
'ABC12M'
'bbb09/'
'XYZb13'
次の値は、PART#について有効でない(無効な文字に下線を付ける):
'AB123_M'
'ABC1/_2'
'Mb#A5;_'
PLIStringTypeから派生する
パブリック属性:
pictureString : String
【0189】
PLINonComputationalType
プログラムの実行を制御するのに使用される値を表す。次のデータ型からなる。area、entry、label、file、format、pointer、およびoffset。
PLISimpleTypeから派生する
【0190】
PLILabelType
ラベルは、ラベル定数またはラベル変数の値である。
ラベル定数は、ステートメントのラベル・プレフィックス(PROCEDURE、ENTRY、PACKAGE、またはFORMAT以外)として記述され、その結果、実行中に、それへの参照を介してプログラム制御をそのステートメントに転送することができる名前である。次のコードの行では、たとえば、Abcdeがラベル定数である。
Abcde: Miles = Speed*Hours;
ラベル付きステートメントは、命令の通常のシーケンシャル実行、またはプログラム内の他の点からそのステートメントに制御を転送するためのGO TOステートメントの使用のいずれかによって実行することができる。
ラベル変数に、もう1つのラベル変数またはラベル定数を割り当てることができる。そのような割当が行われる時に、ソース・ラベルの環境が、ターゲットに割り当てられる。ラベルの静的配列が初期値を有するように宣言された場合には、その配列は、非割当可能として扱われる。
GO TOステートメントに使用されるラベル変数は、その値として、GO TOが実行される時にアクティブであるブロック内で使用されるラベル定数を有しなければならない。次の例を検討されたい:
declare Lbl_x label;
Lbl_a: statement;
.
.
.
Lbl_b: statement;
.
.
.
Lbl_x = Lbl_a;
.
.
.
go to Lbl_x;
Lbl_aおよびLbl_bは、ラベル定数であり、Lbl_xは、ラベル変数である。Lbl_aをLbl_xに割り当てることによって、ステートメントGO TO Lbl_xによって制御がLbl_aステートメントに転送される。このプログラムの他の場所に、Lbl_bをLbl_xに割り当てるステートメントを含めることができる。その場合に、Lbl_xへの参照は、どれもがLbl_bへの参照と同一になる。Lbl_xの値は、別の値が割り当てられるまで保持される。ラベル変数が無効な値を有する場合に、そのようなエラーの検出は保証されない。次の例では、転送が、Iの値に基づいて配列Zの特定の要素に対して行われる。
go to Z(1);
.
.
.
Z(1): if X=Y then return;
.
.
.
Z(2):A=A+B+C*D;
.
.
.
Z(3): A=A+10;
Z(2)が省略される場合に、I=2の時のGO TO Z(I)は、ERROR状態を発生させる。I<LBOUND(Z)またはI>HBOUND(Z)の時のGOTO Z(I)は、SUBSCRIPTRANGE条件がディスエーブルされている場合に、予測不能な結果を引き起こす。
PLINonComputationalTypeから派生する
【0191】
PLIFormatType
リモート(またはR)フォーマット項目は、FORMATステートメント内のフォーマット・リストを使用しなければならないことを指定する。
Rフォーマット項目および指定されたFORMATステートメントは、同一のブロックの中にある必要があり、そのブロックの同一の呼出しの中になければならない。
リモートFORMATステートメントに、ラベル参照としてそれ自体を参照するRフォーマット項目を含めることはできず、元の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は、ラベル変数として宣言されており、第2のGETステートメントは、2つのFORMATステートメントの一方と共に動作するようにすることができる。
データ・フォーマット項目によって、単一のデータ項目の文字またはグラフィック表現が記述される。それらは:
A - 文字
B - ビット
C - 複合
E - 浮動小数点
F - 固定小数点
G - グラフィック
P - ピクチャ
リモート・フォーマット項目では、その値がほかの位置にあるFORMATステートメントのラベル定数であるラベル参照が指定される。FORMATステートメントには、リモートに配置されたフォーマット項目が含まれる。ラベル参照項目は、Rである。
最初のデータ・フォーマット項目は、最初のデータ・リスト項目に関連し、2番目のデータ・フォーマット・項目は、2番目のデータ・リスト項目に関連し、以下同様である。フォーマット・リストに、関連するデータ・リストの項目より少ない数のデータ・フォーマット項目が含まれる場合には、フォーマット・リストが再利用される。フォーマット項目が多すぎる場合には、無視される。
フォーマット・リストに、5つのデータ・フォーマット項目が含まれ、それに関連するデータ・リストで、送信される10個の項目が指定されると仮定する。データ・リストの6番目の項目は、最初のデータ・フォーマット項目に関連し、以下同様である。フォーマット・リストに10個のデータ・フォーマット項目があり、それに関連するデータ・リストで、5つの項目だけが指定されると仮定する。6番目から10番目までのフォーマット項目が、無視される。
例:
GET EDIT (NAME, DATA, SALARY)(A(N), X(2), A(6), F(6,2));
この例では、ストリーム内の最初のN文字が、文字列として扱われ、NAMEに割り当てられることが指定される。次の2文字は、スキップされる。次の6文字は、文字フォーマットでDATAに割り当てられる。次の6文字は、任意選択として符号付きの10進固定小数点定数とみなされ、SALARYに割り当てられる。
PLINonComputationalTypeから派生する
【0192】
PLIEntryType
入り口データは、入り口定数または入り口変数の値とすることができる。
入り口定数は、PROCEDUREステートメントまたはENTRYステートメントに対するラベル・プレフィックスとして記述された名前、またはVARIABLE属性ではなくENTRY属性を用いて宣言された名前、または数学組込み関数の名前である。
入り口定数を、入り口変数に割り当てることができる。たとえば:
P: PROCEDURE;
DECLARE EV ENTRYVARIABLE,
(E1,E2) ENTRY;
EV=E1;
CALL EV;
EV = E2;
CALL EV;
P、E1、およびE2が、入り口定数である。EVは、入り口変数である。最初のCALLステートメントは、入口点E1を呼び出す。2番目のCALLは、入口点E2を呼び出す。
次の例には、添字付きの入り口参照が含まれる:
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;
5つの入り口A、B、C、D、およびEは、それぞれ、パラメータX、Y、およびZを用いて呼び出される。
内部プロシージャの入口点である入り口定数が、入り口変数に割り当てられる時に、割り当てられる値は、入り口定数が内部にあったブロックがアクティブである(および、再帰プロシージャの場合にカレントである)限り、有効なままになる。
ENTRYADDR組込み関数および擬似変数を用いると、入り口変数のPROCEDUREまたはENTRYの入口点のアドレスを入手するか設定することができるようになる。入口点のアドレスは、入り口が呼び出された場合に実行される最初の命令のアドレスである。たとえば:
PTR1 =ENTRYADDR(ENTRY_VBL);
では、入り口点のアドレスが得られ、
ENTRYADDR(ENTRY_VBL) = PTR2;
である。
PLINonComputationalTypeから派生する
パブリック属性:
Limited : Boolean
【0193】
PLIAreaType
区域変数では、基底付き変数の割振りのために予約されるストレージの区域が記述される。この予約されるストレージは、ALLOCATEステートメントによって基底付き変数に割り振り、FREEステートメントによって基底付き変数から解放することができる。区域変数は、任意のストレージ・クラスを有することができ、位置合わせされなければならない。
基底付き変数が割り振られ、区域が指定されない時に、ストレージは、使用可能であればどこからでも獲得される。その結果、割り振られる基底付き変数が、主記憶域全体に広く分散する可能性がある。これは、項目がポインタを使用して簡単にアクセスされるので、内部動作にとっては重要でない。しかし、これらの割振りが、データ・セットに送られる場合には、項目を一緒に収集しなければならない。区域変数を用いて割り振られる項目は、既に収集されており、別々の識別を保ちながら1単位として送るか割り振ることができる。
区域変数内の、区域変数の先頭に対する相対的な基底付き変数の位置を識別したい場合がある。オフセット変数が、この目的のために設けられている。区域を、それに含まれる割当を完備して割当または送信することができ、したがって、基底付き割振りの組を、各割当の個々の識別を保持しながら、割当および入出力に関する1単位として扱うことができる。
区域のサイズは、ストリング長または配列の限界と同じ形で調整可能であり、したがって、式またはアスタリスク(被制御区域または被制御パラメータの場合)またはREFERオプション(基底付き区域の場合)によって指定することができる。
ストレージ・クラスAUTOMATICまたはCONTROLLEDを有する区域の区域サイズは、その整数値によって予約されるバイト数が指定される式によって与えることができる。区域がBASED属性を有する場合に、その区域が基底付き構造体のメンバであり、REFERオプションが使用される場合を除いて、区域サイズは整数でなければならない。
静的ストレージ・クラスの区域のサイズは、整数として指定しなければならない。AREA宣言の例は次の通りである:
DECLARE AREA1 AREA(2000),
AREA2 AREA;
宣言されたサイズのほかに、余分な16バイトの制御情報が、区域の予約されたサイズの前に置かれる。この16バイトに、使用中のストレージの量などの詳細が含まれる。
実際に使用されている予約済みストレージの量を、区域のエクステントと称する。区域変数は、割り振られる時に、空である、すなわち、区域エクステントが0である。最大エクステントは、区域サイズによって表される。基底付き変数は、実行中にいつでも区域内で割り振り、解放することができ、したがって、区域のエクステントが変化する。
基底付き変数が解放される時に、それが占有したストレージが、他の割振りに使用可能になる。ある区域内の使用可能なストレージのチェーンが、維持され、このチェーンの先頭は、16バイトの制御情報内に保持される。不可避的に、異なるストレージ要件を有する基底付き変数が、割り振られ、解放されるので、割振りが使用可能なスペースと一致しない時に、区域内にギャップが生じる。これらのギャップは、区域のエクステントに含まれる。
比較を含めてどの演算子も、区域変数に適用することはできない。
PLINonComputationalTypeから派生する
【0194】
PLIPointerType
ポインタ変数は、基底付き変数の宣言内に、ロケータ修飾子として、BASED属性内に、あるいは、ALLOCATEステートメント、LOCATEステートメント、またはREADステートメントのSETオプション内に現れる場合に、コンテキスト的に宣言される。ポインタ変数を明示的に宣言することもできる。
PLINonComputationalTypeから派生する
【0195】
PLIFileType
FILE属性によって、関連する名前がファイル定数またはファイル変数であることが指定される。
FILE属性は、ファイル記述属性のいずれかによってファイル定数について暗黙指定することができる。名前を、入力ステートメントまたは出力ステートメントのFILEオプション内、または入力/出力条件に関するONステートメント内の出現を介して、ファイル定数としてコンテキスト的に宣言することができる。
PLINonComputationalTypeから派生する
【0196】
PLIOffsetType
区域変数内の、区域変数の先頭に対する相対的な基底付き変数の位置を識別したい場合がある。オフセット変数は、この目的のために設けられる。
PLINonComputationalTypeから派生する
パブリック属性:
BigEndian : Boolean = true
【0197】
PLIAlias
別名は、明示的なデータ型が許容される場所であればどこでも使用することができる型名である。DEFINE ALIASステートメントを使用して、データ属性の集合の別名を定義することができる。この形で、意味のある名前をデータ型に割り当て、プログラムの理解される能力を改善することができる。別名を定義することによって、データ属性の組のより短い表記を供給することもでき、これによってタイプの誤りを減らすことができる。
例
define alias Name char(31) varying;
define alias Salary fixed dec(7); /* デフォルトでreal */
define alias Zip char(5) /* デフォルトでnonvarying */
PLINamedTypeから派生する
【0198】
Attribute
指定することができる属性は、関数が返すことができる変数の属性のいずれかである(たとえば、RETURNSオプションおよび属性で有効な属性)。すなわち、配列または構造化された属性リストの別名を指定することはできない。しかし、DEFINEORDINALステートメントまたはDEFINE STRUCTUREステートメントあるいは別のDEFINE ALIASステートメントで定義された型の別名を指定することができる。また、RETURNSオプションおよび属性と同様に、ストリング長または区域サイズは、制限付き式でなければならない。
欠けているデータ属性は、PL/Iデフォルトを使用して供給される。
パブリック属性:
attribute : String
【0199】
PLIOrdinal
序数は、順序付きの値の名前付きの組である。DEFINE ORDINALステートメントを使用して、序数を定義し、その組を参照するのに使用される意味のある名前を割り当てることができる。たとえば、「color」と呼ばれる序数を定義することができる。「color」序数に、メンバ「red」、「yellow」、「blue」などを含めることができる。「color」組のメンバを、関連する固定された2進値によるのではなく、これらの名前によって参照することができ、コードがはるかに自己文書化的になる。さらに、序数型を用いて宣言された変数は、同一の型の序数またはその序数型のメンバだけを割り当てることができ、比較することができる。この自動的な検査によって、よりよいプログラムの信頼性がもたらされる。
下の例では、Redが値0を有し、Orangeが値1を有するなどである。しかしLowは値2を有し、Mediumは値3を有する。
例
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
【0200】
OrdinalValue
OrdinalValueでは、組内の特定のメンバの値を指定する。最初のメンバについてVALUE属性が省略された場合には、0の値が使用される。他のメンバについてVALUE属性が省略された場合には、次に大きい整数値が使用される。
所与の(または仮定される)VALUE属性の値は、整数でなければならず、符号付きとすることができ、厳密に増分しなければならない。所与の(または仮定される)VALUE属性の値は、XN定数として指定することもできる。
例
define ordinal Intesity (low value(2), middle, high value (5));
は、lowに2の値、middleに3の値、highに5の値を与える。
パブリック属性:
name : String
value : int
【0201】
PLIStructure
構造体は、構造体、共用体、または基本的な変数および配列とすることができるメンバ要素の集合である。共用体は、互いに重なり合い、同一のストレージを占めるメンバ要素の集合である。共用体は、通常は共通部分、セレクタ部分、および可変部分を含む可変レコードを宣言するのに使用することができる。
DEFINE STRUCTUREステートメントが、名前付きの構造体または共用体を指定するのに使用される。構造体は、強く型付けされる。すなわち、構造体として宣言された変数だけを、構造体として宣言された変数またはパラメータに割り当てることができる。
PLINamedType、PLIComposedTypeから派生する
【0202】
PLIHandleType
変数を構造体型へのポインタとして宣言するには、HANDLEを使用する。ハンドルは、強く型付けされる、すなわち、同一の構造体型のハンドルに割り当てるかそれと比較することができる。
PLINonComputationalTypeから派生する
パブリック属性:
structure : tPLIStructure
【0203】
PLINamedType
PL/Iでは、組込みデータ型を使用して、ユーザ自身が命名した型を定義することができる。これには、ユーザ定義型(別名、序数、構造体、および共用体)、これらの型を有する変数の宣言、ハンドル、および型関数が含まれる。
PLIClassifierから派生する
【0204】
PLIArray
配列は、同一の属性を有する要素のn次元集合である。
例
dcl List fixed decimal(3) dimension(8)
は、8つの固定小数点10進要素の1次元配列である。
dcl table (4,2) fixed dec (3)
は、3つの固定小数点10進要素の2次元配列であり、tableの2次元は、1つの次元に関して1の下界と4の上界を有し、他方の次元に関して1の下界と2の上界を有する。
REFERオプションは、構造体の割振り時に、式の値が、構造体内の変数に割り当てられ、構造体内の別の変数の長さ、限界、またはサイズを表すことを指定するために、基底付き構造体の宣言で使用される。REFERオプションを用いる長さ、限界、またはサイズの構文は、次の通りである:
expression REFER ( variable )
variableは、REFERオプションのオブジェクトと称するが、宣言される構造体のメンバでなければならない。REFERオブジェクトは、下記の規則に従わなければならない。
REAL FIXED BINARY(p,0)でなければならない。
REFERオプションを有するか、REFERオプションを有する要素を含む、最初のレベル2要素の前に置かなければならない。
ロケータ修飾または添字付きであってはならない。
配列の一部であってはならない。
たとえば:
DECLARE 1 STR BASED(P),
2 X FIXED BINARY,
2 Y (L REFER (X)),
L FIXED BINARY INIT(1000);
この宣言では、基底付き構造体STRが、配列Yおよび要素Xからなることが指定される。STRが割り振られる時に、上界にLの現在の値がセットされ、これがXに割り当てられる。PをセットするREADステートメントなど、Yへの他の参照について、限界の値は、Xからとられる。
同一のメンバについて、REFERオプションとINITIAL属性の両方が使用される場合には、REFERのオブジェクトが値を割り当てられた後に、初期化が行われる。
下記の制約の少なくとも1つが満足されるならば、任意の数のREFERオプションを、構造体の宣言に使用することができる:
REFERオプションのすべてのオブジェクトが、論理レベル2で宣言される、すなわち、小構造内で宣言されない。たとえば:
DECLARE 1 STR BASED,
2 (M,N),
2 ARR(I REFER(M),
J REFER(N)),
2 X;
この構造体が割り振られる時に、IおよびJに割り振られる値によって、2次元配列ARRの限界がセットされる。
構造体のメンバの間で埋込みが発生しないように構造体が宣言される。たとえば:
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;
この構造体は、UNALIGNED属性を有するので、すべての項目が、バイト位置合わせだけを必要とする。したがって、BおよびD(REFERオブジェクト)の値に無関係に、埋込みは行われない。Dが、小構造内で宣言されていることに留意されたい。
REFERオプションが、構造体宣言で1回だけ使用される場合に、下記が成り立つならば前の2つの制約を無視することができる:
ストリング長または区域サイズに関して、オプションが、構造体の最後の要素に適用される。
配列の限界に関して、オプションが、構造体の最後の要素または最後の要素を含む小構造のいずれかに適用される。配列の限界は、先行する次元の上界でなければならない。たとえば:
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);
配列の先行する次元は、上位レベルから継承することができる。上の例でSTR(4)を宣言した場合に、先行する次元は、STR(4)から継承され、したがって、DでREFERオプションを使用することが不可能になる。
この宣言は、前の2つの制約を満足しない。REFERオブジェクトMは、小構造内で宣言され、埋込みが行われる。しかし、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);
では、86要素のRECが書き込まれる。この時点でRECを解放する試みは、エラーになる。というのは、Nが、割り振られた時に有した値(すなわち100)に復元されなければならないからである。Nに100を超える値が割り当てられる場合には、WRITEステートメントに出会った時にエラーが発生する。
REFERオブジェクトの値が変更される時に、構造体への次の参照が、再マッピングを引き起こす。たとえば:
DCL 1 A BASED(P),
2 B,
2 C (I REFER(B)),
2D,
1 INIT(10);
ALLOCATE A;
B=5;
Bの割当の後のAへの次の参照によって、構造体が再マッピングされて、Cの上界が10から5に減り、DのストレージがCの新しい最後の要素に直接に続くように割り振られる。構造体は再マッピングされるが、データの再割当は行われず、ストレージのうちで構造体Aによって元々占有されていた部分の内容は、変更されない。再マッピングを考慮しない場合には、エラーが発生する可能性がある。次の例を検討されたい。この例では、1つの構造体に2つの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=10およびB=5のAのマッピングは、次のようになる:
| B | C | D | E |
|___|__________|___|________|
| B | C | D | E|
|___|_____|___|_ _ _ _ _ _
Dは、現在、元々は文字列変数Cに割り当てられていた部分のデータを参照する。このデータは、Dの属性すなわち固定小数点2進数に従って解釈され、得られる値がEの長さになる。したがって、Eの長さは予測不能である。
【0205】
PLIFixedLengthString
PLICodedStringTypeから派生する
パブリック属性:
length : Integer
【0206】
PLIVariableLengthString
PLICodedStringTypeから派生する
パブリック属性:
lengthToAllocate : String
【0207】
PLIFixedLengthArea
PLIAreaTypeから派生する
プライベート属性:
length : Integer
【0208】
PLIVariableLengthArea
区域のサイズは、ストリング長または配列の限界と同一の形で調整可能であり、したがって、式またはアスタリスク(被制御区域または被制御パラメータの場合)またはREFERオプション(基底付き区域の場合)によって指定することができる。
PLIAreaTypeから派生する
プライベート属性:
lengthToAllocate : String
【0209】
PLIFixedBoundArray
PLIArrayから派生する
パブリック属性:
lbound : Integer
ubound : Integer
【0210】
PLIFixedLboundArray
PLIArrayから派生する
パブリック属性:
lbound : Integer
HboundtoAllocate : String
【0211】
PLIHboundArray
PLIArrayから派生する
パブリック属性:
LboundtoAllocate : String
ubound : Integer
【0212】
PLIVariableBoundArray
PLIArrayから派生する
パブリック属性:
LboundToAllocate : String
HboundToAllocate : String
【0213】
総計:
1論理パッケージ
39クラス
論理パッケージ構造
論理ビュー
PLI
TDLang
【0214】
5.c.Cメタモデル
C MainおよびUser Types(すなわちユーザ定義型)を含むCメタモデルは、M2レベルのMOFクラス・インスタンスである。図24にC言語メタモデルを示す。図25に、C言語メタモデルのTDLangClassifier、TDLangComposedType、およびTDLangElementを示す。図26に、C言語メタモデルのTypedElement態様を示す。図27に、C言語メタモデルでのユーザ定義データ型を含むデータ型を示す。図28に、C言語メタモデルでのDatatype-StringおよびDatatype-Integer、ならびにDirectionKindの引数および戻り値の列挙およびBooleanデータ型のtrueおよびfalseの列挙を示す。
【0215】
5.c.i.Cメタモデル仕様
Cメタモデル仕様は、コネクタ・インターフェースを表すデータ構造体を定義するために、エンタープライズ・アプリケーション・プログラムによって使用される。
【0216】
Classifier
型指定子は、宣言されつつあるオブジェクトまたは関数の型を示す。
基本データ型は次の通りである:
文字
浮動小数点数
整数
列挙
Void
これらの型から、ユーザは下記を導出することができる:
ポインタ
配列
構造体
共用体
関数
整数型は、char、wchar_t(C++のみ)、およびすべてのサイズのintである。浮動小数点数は、型float、double、またはlong doubleを有することができる。整数型と浮動小数点型を、集合的に算術型と呼ぶことができる。C++のみにおいて、下記も導出することができる:
参照
クラス
メンバへのポインタ
C++では、列挙が、整数型ではないが、整数拡張の対象になり得る。これは、CMainで型を定義する基本クラスである。
列挙は、それに含まれるFeaturesの組を介するインスタンスの分類を提供する。
分類子は、主にFeaturesの構成によって定義される。
TDLangClassifierから派生する
パブリック属性:
name : String
【0217】
Structured
これは、構造型の抽象クラスである。
Classifier、TDLangComposedType、DerivableType、StructureContentsから派生する
【0218】
Struct
構造体には、データ・オブジェクトの順序付きグループが含まれる。配列の要素とは違って、構造体内のデータ・オブジェクトは、さまざまなデータ型を有することができる。構造体内の各データ・オブジェクトは、メンバまたはフィールドである。
構造体を使用して、論理的に関係するオブジェクトをグループ化する。たとえば、1つの住所の構成要素のストレージを割り振るために、次の変数を定義する:
int street_no;
char *street_name;
char *city;
char *prov;
char *postal_code;
複数の住所のストレージを割り振るためには、構造体データ型と、その構造体データ型を有するのに必要なだけの変数を定義することによって、各住所の構成要素をグループ化する。
次の例では、行1から7で、構造体タグ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";
構造体への参照のすべてを、完全に修飾しなければならない。この例では、4番目のフィールドをprovだけで参照することができない。このフィールドは、perm_address.provによって参照しなければならない。
同一のメンバを有するが異なる名前の構造体は、互換ではなく、互いに割り当てることができない。構造体は、ストレージを節約することを意図されていない。バイト・マッピングの直接制御が必要な場合には、ポインタを使用する。
Structuredから派生する
【0219】
Union
共用体は、名前付きメンバの組のどの1つでも保持することができるオブジェクトである。名前付きの組のメンバは、任意のデータ型とすることができる。C/C++は、ストレージ内でメンバをオーバーレイする。
共用体に割り振られるストレージは、共用体の最大のメンバに必要なストレージ(と、共用体がその最も厳密なメンバの自然な境界で終わるようにするのに必要な埋込み)である。
C++の注記:
1.C++では、共用体が、コンストラクタおよびデストラクタを含むメンバ関数を有することができるが、仮想メンバ関数を有することはできない。共用体を基本クラスとして使用することも、基本クラスから共用体を派生させることもできない。
2.C++の共用体メンバは、コンストラクタ、デストラクタ、またはオーバーロードされるコピー代入演算子を有するクラス・オブジェクトとすることができない。C++では、キーワードstaticを用いて共用体のメンバを宣言することができない。
Structuredから派生する
【0220】
BehavioralFeature
これによって、これを含むModelElementの動的特性が定義される。BehavioralFeatureは、FeatureとNamespaceの両方である。
パブリック属性:
name : String
【0221】
TypedElement
これは、定義に型指定を必要とする属性、パラメータおよび定数の基本クラスである。TypeElement型は、定義の一部として型を必要とする、ModelElementsの抽象である。TypeElementは、それ自体で型を定義するのではなく、Classifierに関連する。
TDLangElementから派生する
【0222】
StructuralFeature
それを含むModelElementの静的特性を定義する。
TypedElement、StructureContentsから派生する
パブリック属性:
name : String
【0223】
Parameter
Parameterは、動作および他のBehavioralFeaturesとの通信の手段を提供する。パラメータによって、その定義された型の値が渡されるか通信される。
関数宣言子に、関数に命名する識別子と、関数パラメータのリストが含まれる。必ずプロトタイプ関数宣言子を使用すべきである。というのは、これによって関数パラメータを検査できるからである。C++関数は、プロトタイプ関数宣言子を有しなければならない。
プロトタイプ関数宣言子:関数宣言子内で各パラメータを宣言すべきである。関数への呼出しでは、宣言にあるパラメータと同数の引数を渡さなければならない。
非プロトタイプ関数宣言子:宣言子に続くパラメータ宣言リストで各パラメータを宣言すべきである。パラメータを宣言しない場合には、そのパラメータは型intを有する。
コンパイラは、charパラメータおよびshortパラメータをintに拡幅し、floatパラメータをdoubleに拡幅する。コンパイラは、プロトタイプ宣言されていない関数の引数の型とパラメータの型の間の型検査を実行しない。また、コンパイラは、引数の数がパラメータの数と一致することを保証するための検査を行わない。
宣言に続くプロトタイプ宣言されない関数定義のパラメータ宣言リストで、関数が受け取る値のそれぞれの値を宣言すべきである。
パラメータ宣言によって、ストレージ・クラス指定子と値のデータ型が決定される。
C/C++が許容する唯一のストレージ・クラス指定子が、registerストレージ・クラス指定子である。これは、パラメータのすべての型指定子を受け入れる。registerストレージ・クラス指定子を指定しない場合には、パラメータは、autoストレージ・クラス指定子を有する。Cのみにおいて、型指定子を省略し、関数の定義にプロトタイプ形式を使用していない場合には、パラメータは、次のように型intを有する:
int func(i,j)
{
/* iおよびjは型intを有する */
}
Cのみにおいて、あるパラメータが宣言子にリストされていない場合に、パラメータ宣言リストでそのパラメータを宣言することはできない。
TypedElementから派生する
パブリック属性:
direction : Directionkind
プライベート属性:
name : String
【0224】
Datatype
これは、データ型および内部型を表す。
Classifierから派生する
【0225】
Derived
DerivableType、Classifierから派生する
【0226】
Field
Fieldは属性である。
StructuralFeatureから派生する
【0227】
Function
BehavioralFeature、DerivableTypeから派生する
パブリック属性:
isVarArg : Boolean
【0228】
StructureContents
Structured
これは、structured型の抽象クラスである。
Classifier、TDLangComposedType、DerivableType、StructureContentsから派生する
【0229】
TypedElement
これは、定義に型指定を必要とする属性、パラメータ、および定数の基本クラスである。TypeElement型は、定義の一部として型を必要とするModelElementsの抽象である。TypeElementは、それ自体で型を定義するのではなく、Classifierに関連する。
TDLangElementから派生する
【0230】
Typedef
Derivedから派生する
【0231】
Derived
DerivableType、Classifierから派生する
【0232】
Array
配列は、データ・オブジェクトの順序付きグループである。各オブジェクトを要素と呼ぶ。配列内のすべての要素が、同一のデータ型を有する。
配列の定義または宣言では、任意の型指定子を使用する。配列要素は、関数またはC++の参照以外のどのデータ型にもすることができる。しかし、関数へのポインタの配列を宣言することはできる。
Derivedから派生する
パブリック属性:
dimension : Integer
【0233】
Pointer
ポインタ型変数は、データ・オブジェクトまたは関数のアドレスを保持する。ポインタは、ビット・フィールドおよび参照を除くすべてのデータ型のオブジェクトを参照することができる。さらに、Cでは、ポインタが、register記憶クラスのオブジェクトを指すことができない。
ポインタの一般的な用途の一部を下に示す:
リンク・リスト、ツリー、キューなどの動的データ構造体にアクセスするため。
配列の要素、構造体のメンバ、またはC++クラスのメンバにアクセスするため。
ストリングとして文字の配列にアクセスするため。
変数のアドレスを関数に渡すため(C++では、参照を使用してこれを行うこともできる)。アドレスを介して変数を参照することによって、関数がその変数の内容を変更することができる。
Derivedから派生する
【0234】
Function
BehavioralFeature、DerivableTypeから派生する
パブリック属性:
isVarArg : Boolean
【0235】
DerivableType
【0236】
5.d.C++メタモデル
書籍「ANNOTATED C++ REFERENCE MANUAL」(MargaretA.Ellis,Bjarne Stoustrup著、1990年、「注解C++リファレンスマニュアル」足立高徳/小山裕司訳)に基づくC++メタモデルは、M2レベルのMOFクラス・インスタンスである。C++メタモデルは、C++Mainと、下に記載のモデル型からなる。
【0237】
5.d.i.C++ Mainメタモデル:
このメタモデルは、C Mainメタモデルから継承する。図29に、C++メタモデルのDerived、Structured、BehavioralFeatures、Field、およびDerivableTypesを含むC++Mainメタモデルを示す。図30に、C++メタモデルの可視性型の列挙を示す。C++が、オブジェクト指向言語であり、オブジェクト指向プログラミングに有用であり、public、private、およびprotectedの可視性をサポートすることに留意されたい。
Model Typesメタモデル:
【0238】
5.d.ii.C++メタモデル仕様
C++
C++メタモデルは、コネクタ・インターフェースを表すデータ構造体を定義するために、エンタープライズ・アプリケーション・プログラムによって使用される。
【0239】
Class
C++クラスは、C言語構造体の拡張である。構造体とクラスの唯一の相違は、構造体メンバがデフォルトでpublicアクセスを有するが、クラス・メンバがデフォルトでprivateアクセスを有することである。その結果、キーワードclassまたはstructを使用して、同等のクラスを定義することができる。
// この例では、クラスXが構造体Yと同等である
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である。次の例では、Xがキーワードclassを使用してして宣言されているが、main()がXのメンバにアクセスできる。
Structuredから派生する
パブリック属性:
isAbstract : Boolean
isVolatile : Boolean
プライベート属性:
visibility : VisibilityKind
【0240】
Member
データ・メンバには、基本型ならびに、ポインタ、参照、配列型、およびユーザ定義型を含む他の型のどれかを用いて宣言されるメンバが含まれる。データ・メンバは、変数と同一の形で宣言することができる。しかし、クラス定義の中に明示的な初期化指定子を配置することはできない。
配列をstaticでないクラス・メンバとして宣言する場合には、すべての配列次元を指定しなければならない。
Field、DerivableTypeから派生する
パブリック属性:
isStatic : Boolean
プライベート属性:
isVolatile : Boolean
isRegister : Boolean
visibility : VisibilityKind
【0241】
Reference
Derivedから派生する
【0242】
Operator
BehavioralFeature、StructureContentsから派生する
プライベート属性:
isInline : Boolean
visibility : VisibilityKind
【0243】
Operation
Function、StructureContentsから派生する
パブリック属性:
isStatic : Boolean
isExtern : Boolean
isInline : Boolean
isVirtual : Boolean
isPure : Boolean
visibility : VisibilityKind
isCtor : Boolean
プライベート属性:
isDtor : Boolean
【0244】
Extern
Externは、Derived型の一種である。Cとの関連付けに使用される。
Derivedから派生する
プライベート属性:
linkage : String
【0245】
Generalization
プライベート属性:
visibility : VisibilityKind
isVirtual : Boolean
【0246】
Const
Derivedから派生する
【0247】
Template
テンプレート宣言内の宣言では、下記の1つを定義または宣言しなければならない:
クラス
関数
テンプレート・クラスのstaticメンバ
型の識別子は、テンプレート宣言のスコープ内でtype_nameになる。テンプレート宣言は、グローバル宣言としてのみ行うことができる。
テンプレート引数(区切り文字<と>の中)によって、テンプレートをインスタンス化する時に指定しなければならないテンプレート内の型および定数を指定する。
下のテンプレートを与えられたものとして:
template<class L> class Key
{
L k;
L* kptr;
int length;
public:
Key(L);
// ..;
// ...
};
この宣言によって、次のオブジェクトが作成される:
型Key<int>のi
型Key<char*>のc
型Key<mytype>のm
この3つのクラスが、異なる名前を有することに留意されたい。かぎ括弧(<>)に含まれる型は、クラス名に対する引数ではなく、クラス名自体の一部である。Key<int>およびKey<char*>はクラス名である。この例のコンテキスト内で、Keyと呼ばれるクラス(テンプレート引数リストなし)は、未定義である。
C++では、下記の条件の下でテンプレート引数のデフォルト初期化指定子が許容される:
nontypeテンプレート引数だけに適用される。
関数のように、後端の引数だけに適用される。
後続のテンプレート宣言では、デフォルト初期化指定子を追加することができるが、既存のデフォルト初期化指定子を再定義することはできない。
関数テンプレート宣言ではなく、クラス・テンプレート宣言だけに適用される。
注:C++は、クラス・テンプレートのメンバ関数を定義するテンプレートを、関数テンプレートとみなす。そのようなテンプレートは、デフォルト初期化指定子を有することができない。
Derivedから派生する
【0248】
5.e.HLASM(High Level Assembler)
これは、OS390用のHLASMである。図37に、コネクタ・インターフェースを表すデータ構造体セマンティクスを定義するHighLevel Assembly Language(HLASM)メタモデルを示す。図38に、TDLangClassifier、TDLanguageComposedType、およびTDLangElementである、HLASMメタモデルとTDLang基本クラスの間の関連を示す。図39に、HLASMメタモデルでのHLASM使用値の列挙を示す。
【0249】
hlasm
HLASMDecimal
HLASMDecimal型は、10進数命令によって使用される。
コードは、10進数型(計算機フォーマット:パック10進数フォーマット)の場合に’P’である。
コードは、10進数型(計算機フォーマット:ゾーン10進数フォーマット)の場合に’Z’である。
例:
AP AREA,PCON
PCON DC P'100'
AREA DS P
HLASMSimpleTypeから派生する
プライベート属性:
exponent : int
exponent修飾子は、10進定数の公称値が、内部2進数表現に変換される前に乗算される10のべきを指定する。
packed : boolean
このブール値は、10進数型の計算機フォーマットに対応する。
真はパック(コードはP)である
偽はゾーン(コードはZ)である
scale : int
scale修飾子は、10進定数についてユーザが望む内部スケーリングの量を指定する。
【0250】
HLASMAddress
HLASMAddressは、主に固定小数点命令および他の命令の使用に関するアドレス情報を保持する。
コードは、アドレス型(計算機フォーマット:アドレスの値;通常はフルワード)の場合に、’A’である。
コードは、アドレス型(計算機フォーマット:アドレスの値;通常はダブルワード)の場合に、’AD’である。
コードは、アドレス型(計算機フォーマット:アドレスの値;通常はハーフワード)の場合に、’Y’である。
コードは、アドレス型(計算機フォーマット:基底レジスタおよび変位値;ハーフワード)の場合に、’S’である。
コードは、アドレス型(計算機フォーマット:外部シンボルアドレス用に予約された空間;通常はフルワード)の場合に、’V’である。
コードは、アドレス型(計算機フォーマット:クラスの長さまたはDXD用に予約された空間;通常はフルワード)の場合に、’J’である。
コードは、アドレス型(計算機フォーマット:外部ダミー・セクション・オフセット用に予約された空間)の場合に、’Q’である。
コードは、アドレス型(計算機フォーマット:PSECTアドレス用に予約された空間;通常はフルワード)の場合に、’R’である。
例:
L 5,ADCON
ADCON DC A(SOMWHERE)
HLASMSimpleTypeから派生する
プライベート属性:
type : HLASMAddressType
この要素のアドレス型を指定する。
【0251】
HLASMBinary
HLASMBinaryでは、ビット・パターンが定義される。
コードは、バイナリ形式(計算機フォーマット:2進フォーマット)の場合に、’B’である。
例:
FLAG DC B'00010000'
HLASMSimpleTypeから派生する
プライベート属性:
exponent : int
exponent修飾子は、2進定数の公称値が、内部2進数表現に変換される前に乗算される10のべきを指定する。
scale : int
scale修飾子は、2進定数についてユーザが望む内部スケーリングの量を指定する。
【0252】
HLASMCharacter
HLASMCharacterでは、文字列またはメッセージを定義する。
コードは、文字型(計算機フォーマット:文字ごとに8ビット)の場合に、’C’である。
コードは、ユニコード文字型(計算機フォーマット:文字ごとに16ビット・コード)の場合に、’CU’である。
コードは、グラフィック型(計算機フォーマット:文字ごとに16ビット・コード)の場合に、’G’である。
例:
CHAR DC C'string ofcharacters'
HLASMSimpleTypeから派生する
プライベート属性:
graphic : boolean
要素がグラフィックであるか否かを指定する。
グラフィックの場合に真(コードは’G’)。
通常の文字型の場合に偽。
type : HLASMCharacterType
この要素の文字型を指定する。
【0253】
HLASMFixedPoint
HLASMFixedPoint型は、固定小数点命令および他の命令によって使用される。
コードは、固定小数点型(計算機フォーマット:符号付き固定小数点2進フォーマット;通常はフルワード)の場合に、’F’である。
コードは、固定小数点型(計算機フォーマット:符号付き固定小数点2進フォーマット;通常はダブルワード)の場合に、’FD’である。
コードは、固定小数点型(計算機フォーマット:符号付き固定小数点2進フォーマット;通常はハーフワード)の場合に、’H’である。
例:
L 3,FCON
FCON DC F'100'
HLASMSimpleTypeから派生する
プライベート属性:
exponent : int
exponent修飾子は、固定小数点定数(H、F)の公称値が、内部2進数表現に変換される前に乗算される10のべきを指定する。
exponent修飾子は、Enとして記述され、このnは、10進自己定義項目または括弧で囲まれた絶対式のいずれかである。この10進自己定義項目または式の前に、符号を置くことができ、符号がない場合には、プラスの符号が仮定される。exponent修飾子の範囲は、−85から+75まである。浮動小数点定数を定義するために型拡張を使用する場合には、exponent修飾子を、−231から231−1までの範囲内とすることができる。公称値を正確に表現することができない場合には、警告メッセージが発行される。
scale : int
scale修飾子は、固定小数点定数(H、F)の2進数についてユーザが望む内部スケーリングの量すなわち、固定小数点定数の公称値が2進表現に変換される前で、最終的なスケーリングされた形に組み立てられる前に、固定小数点定数に乗算しなければならない2のべきを指定する。スケーリングによって、2進小数点が、右端のビット位置の右にある仮定される固定された位置から移動される。
定数のそれぞれの型の範囲は:
固定小数点定数H
−187から15まで
固定小数点定数F
−187から30まで
scale修飾子は、Snとして記述され、このnは、10進自己定義項目または括弧で囲まれた絶対式のいずれかである。
この修飾子の値nの両方の形の前に符号を置くことができ、符号が存在しない場合には、プラスの符号が仮定される。
注:
1.scale修飾子は、正の値を有する時に、2進数の小数部分が占める2進位置の数を示す。
2.scale修飾子は、負の値を有する時に、2進数の整数部分から削除される2進位置の数を示す。
3.スケーリングのゆえに(またはスケーリングが行われないので)下位の桁が失われる時に、失われる位置の左端のビットで丸めが行われる。丸めは、保存される右端の位置に反映される。
【0254】
HLASMFloatingPoint
HLASMFloatingPoint型は、浮動小数点命令によって使用される。
コードは、浮動小数点型(計算機フォーマット:short浮動小数点フォーマット:通常はフルワード)の場合に、’E’である。
コードは、浮動小数点型(計算機フォーマット:long浮動小数点フォーマット:通常はダブルワード)の場合に、’D’である。
コードは、浮動小数点型(計算機フォーマット:extended浮動小数点フォーマット:通常は複数のダブルワード)の場合に、’L’である。
例:
LE 2,ECON
ECONDC E'100.50'
HLASMSimpleTypeから派生する
プライベート属性:
exponent : int
exponent修飾子は、浮動小数点定数(E、D、およびL)の公称値が、内部2進数表現に変換される前に乗算される10のべきを指定する。
exponent修飾子は、Enとして記述され、このnは、10進自己定義項目または括弧で囲まれた絶対式のいずれかである。
この10進自己定義項目または式の前に、符号を置くことができ、符号がない場合には、プラスの符号が仮定される。exponent修飾子の範囲は、−85から+75まである。浮動小数点定数を定義するために型拡張を使用する場合には、exponent修飾子を、−231から231−1までの範囲内とすることができる。公称値を正確に表現することができない場合には、警告メッセージが発行される。
round : HLASMFloatingPointRoundType
この要素の浮動小数点丸めタイプを指定する。
scale : int
scale修飾子は、浮動小数点定数(E、D、およびL)の16進数についてユーザが望む内部スケーリングの量すなわち、浮動小数点定数の公称値が2進表現に変換される前で、最終的なスケーリングされた形に組み立てられる前に、浮動小数点定数に乗算しなければならない2のべきを指定する。スケーリングによって、2進小数点が、右端のビット位置の右にある仮定される固定された位置から移動される。
定数のそれぞれ型の範囲は:
浮動小数点定数E
0から5まで
浮動小数点定数D
0から13まで
浮動小数点定数L
0から27まで
scale修飾子は、Snとして記述され、このnは、10進自己定義項目または括弧で囲まれた絶対式のいずれかである。
この修飾子の値nの両方の形の前に符号を置くことができ、符号が存在しない場合には、プラスの符号が仮定される。
16進浮動小数点定数のscale修飾子:16進浮動小数点定数のscale修飾子は、正の値を有しなければならない。このscale修飾子は、浮動小数点定数の2進表現の小数部分を右にシフトする、16進位置の数を指定する。16進小数点は、小数フィールド内の左端の位置の左に固定されるものと仮定される。スケーリングを指定する時には、正規化されない16進小数が組み立てられることになる(正規化されないとは、小数の左端の位置に16進数の0が含まれることを意味する)。定数の指数部の指数が、それ相応に上に調整されるので、定数の大きさが保存される。非0の16進数位置が失われる時に、失われる部分の左端の16進数位置で丸めが行われる。丸めは、保存される右端の位置に反映される。
type : HLASMFloatingPointType
この要素の浮動小数点型を指定する。
【0255】
HLASMHexadecimal
HLASMHexadecimalでは、大きいビット・パターンを定義する。
コードは、16進数型(計算機フォーマット:16進数ごとに4ビット・コード)の場合に、’X’である。
例:
PATTERN DC X'FF00FF00'
HLASMSimpleTypeから派生する
【0256】
HLASMClassifier
HLASMClassifierは、HLASMComposedTypeおよびHLASMSimpleTypeの抽象親クラスである。
TDLangClassifierから派生する
【0257】
HLASMElement
HLASMElementは、HLASMプログラムのすべてのDC命令を表す。
たとえば:
CHAR DCC'string of characters'
PCON DCP'100'
PATTERN DC X'FF00FF00'
CHAR、PCON、およびPATTERNのすべてが、DC命令である
TDLangElementから派生する
【0258】
HLASMSimpleType
HLASMSimpleTypeは、HLASM言語のすべての単純型によって共用される属性を含む抽象クラスである。
HLASMClassifierから派生する
プライベート属性:
length : int
length修飾子は、定数がその中に組み立てられるストレージのバイト数を示す。これは、Lnとして記述され、このnは、10進自己定義項目または括弧で囲まれた絶対式のいずれかである。これは、正の値を有しなければならない。
length修飾子が指定される時には:
その値によって、定数に割り振られるストレージのバイト数が決定される。したがって、length修飾子によって、割り振られる空間におさまるように、定数の公称値を埋め込むか切り捨てる必要があるかどうかが決定される。
定数の型に従う境界位置合わせは、行われない。
その値は、定義される定数のさまざまな型について許容される最大長さを超えてはならない。
length修飾子が、C型定数でダブルバイト・データを切り捨ててはならない。
length修飾子は、G型またはCU型の定数では2の倍数でなければならない。
文字定数(C)、グラフィック定数(G)、16進定数(X)、2進定数(B)、および10進定数(PおよびZ)について長さが指定されない時に、定数全体が、その暗黙の長さに組み立てられる。
size : HLASMSizeType
この要素の境界位置合わせを指定する。
【0259】
HLASMComposedType
HLASMComposedTypeクラスは、追加の要素を含む入れ子になった宣言を表す。HLASMComposedTypeは、HLASMElementの集約である。HLASMComposedTypeは、HLASMUnionの親である。
HLASMClassifier、TDLangComposedTypeから派生する
プライベート属性:
union : boolean
要素が共用体であるか否かを指定する。
共用体の場合に真。
そうでない場合に偽。
【0260】
HLASMArray
HLASMArrayは、配列命令に関する情報を保持する。
プライベート属性:
size : int
sizeは、メモリ内で割り振られる配列の1次元サイズを表す。
【0261】
HLASMElementInitialValue
このクラスには、HLASMElementの初期値が含まれる。
TDLangElementから派生する
プライベート属性:
initVal : String
要素の初期値を指定する。例:’MIN’、’MAX’など
【0262】
HLASMSourceText
このクラスには、ソース・コード全体(コメントを含む)およびそれに関連する行番号が含まれる。
パブリック属性:
source : String
ソース・ファイル・ストリングを指定する。
fileName : String
ソース・ファイルのパスを指定する。
【0263】
総計:
1論理パッケージ
14クラス
論理パッケージ構造
論理ビュー
TDLang
hlasm
【0264】
6.アプリケーションドメイン・インターフェース・メタモデル
6.a.IMSトランザクション・メッセージ・メタモデル
IMSトランザクション・メッセージ・メタモデルは、図31に示されているように(図31に、3種類のトランザクション・メッセージすなわち、プレフィックス付きのIMS−OTMAメッセージ、デフォルトOTMAプレフィックスをIMSが構築することができるプレフィックスなしのIMSメッセージ、およびアプリケーション・プログラムに直接に送ることができるIMS基本メッセージを含む、IMSトランザクション・メッセージのメタモデルを示す)3種類のIMSトランザクション・メッセージすなわち:
*プレフィックス付きのIMS−OTMAメッセージ
*デフォルトOTMAプレフィックスをIMSが構築することができるプレフィックスなしのIMSメッセージ
*アプリケーション・プログラムに直接に送ることができるIMS基本メッセージ
を含む。
【0265】
6.a.i.IMS OTMAプレフィックス
IMS OTMAメッセージ・プレフィックスは、下記のコンポーネントから構成される。図32に、OTMAプレフィックス・メタデータ・モデルを示す。図33に、制御データ定義データ型のOTMAプレフィックスを示す。図34に、状態定義データ型のOTMAプレフィックスを示す。図35に、セキュリティ定義型のOTMAプレフィックスを示す。図36に、IMSメタモデルのIMSメッセージ・プリミティブを示す。
*制御データ:このセクションには、トランザクションパイプ名、メッセージ・タイプ、シーケンス番号、フラグ、およびインジケータが含まれる。
*状態データ:このセクションには、宛先オーバーライド、マップ名、同期レベル、コミット・モード、トークン、およびサーバ状態が含まれる。
*セキュリティ・データ:このセクションには、ユーザID、ユーザ・トークン、およびセキュリティ・フラグが含まれる。
*ユーザ・データ:このセクションには、クライアントが必要とする特殊な情報のすべてが含まれる。
【0266】
OTMAプレフィックス・メタモデルは、下記の特徴を有する。
1)OTMA Prefix − 制御データ定義型
2)OTMA Prefix − 状態データ定義型
3)OTMA Prefix − セキュリティ・データ定義型
【0267】
6.a.ii.IMSメッセージ・プリミティブ型
6.a.i.a).IMSTransactionMessageメタモデル仕様
IMSTransactionMessageメタモデルには、下記のIMSメッセージ・シナリオが含まれる:
・プレフィックス付きのIMS OTMAメッセージ
・プレフィックスなしのIMS OTMAメッセージ
・アプリケーション・プログラムに直接に送られるIMS基本メッセージ。
プライベート属性:
OTMAPrefixFormat : OTMAPrefixFormats = one
StandardFieldsFlag : boolean
【0268】
OTMAPrefixFormats
プライベート属性:
one :
two :
【0269】
StandardFields
StandardFields(LL、ZZ、およびトランザクション・コードを含む)は、下記のシナリオには含まれない。
・IMSトランザクション・アプリケーション・プログラムへのXML文書の直接送信
・IMSアプリケーションへのACKメッセージまたはNAKメッセージ
プライベート属性:
Length : TwoByteField
LLとも称する。
ReservedField : TwoByteField
ZZとも称する。
TransactionCode : VariableLengthField
TransactionCodeフィールドは、1バイトから8バイトまでの長さとすることができる。
TransactionCodeは、入力メッセーの最初のセグメントだけに現れる。
TransactionCodeは、LLZZの後に来る。
【0270】
OTMAPrefix
IMS OTMAプレフィックスは、すべてのメッセージ・セグメントの前、またはメッセージの最初のセグメントの前だけのいずれかに現れることができる。しかし、OTMAプレフィックスは、任意選択である。これが指定されない場合には、IMSゲートウェイが、要求のデフォルトのプレフィックスを構築する。
【0271】
ControlData
制御データは、メッセージ制御情報である。これには、トランザクションパイプ名、メッセージ・タイプ、シーケンス番号、フラグ、およびインジケータが含まれる。
プライベート属性:
ArchitectureLevel : OneByteField
OTMAアーキテクチャ・レベルを指定する。クライアントが、アーキテクチャ・レベルを指定し、サーバは、それが使用しているアーキテクチャ・レベルを応答メッセージで示す。クライアントとサーバによって使用されるアーキテクチャ・レベルは、一致しなければならない。
IMSバージョン6では、有効な値はX’01’だけである。
すべてのメッセージについて必須。
MessageType : TMessageType
メッセージ・タイプを指定する。すべてのOTMAメッセージで、メッセージ・タイプの値が指定されなければならない。値は、相互排他的ではない。たとえば、サーバが、クライアントがサブミットしたトランザクションに対するACKメッセージを送信する時に、トランザクション・フラグと応答フラグの両方がセットされる。
ResponseFlag : OneByteField
メッセージが応答メッセージであること、または応答が必要であることのいずれかを指定する。
トランザクションに対する肯定応答には、トランザクションで拡張応答要求が指定された場合に限って、メッセージ・プレフィックスのアプリケーションデータ・セクションに属性(そのトランザクションの)が含まれる。
CommitConfirmationFlag :TCommitConfirmationFlag
コミット要求の成功を指定する。コミット確認メッセージ内で、サーバによってクライアントに送信される。これらのメッセージは、送信後コミット(send-then-commit)トランザクションに関してのみ適用可能であり、メッセージ・プレフィックスの状態データ・セクションの同期レベル・フラグによって影響されない。
CommandType : TCommandType
OTMAプロトコル・コマンド・タイプを指定する。
IMS MTOコマンドは、メッセージのアプリケーションデータ・セクションで指定される。
ProcessingFlag : TProcessingFlag
クライアントまたはサーバがそれによってメッセージ処理を制御できるオプションを指定する。
TpipeName : EightByteField
トランザクションパイプ名を指定する。IMSの場合、この名前が、入出力PCB上のLTERM名をオーバーライドするのに使用される。このフィールドは、すべてのトランザクション・メッセージ・タイプ、データ・メッセージ・タイプ、およびコミット確認メッセージ・タイプに適用可能である。このフィールドは、いくつかの応答メッセージ・タイプおよびコマンド・メッセージタイプにも適用可能である。
ChainFlag : TChainFlag
メッセージに含まれるセグメント数を指定する。このフラグは、トランザクション・メッセージ・タイプおよびデータ・メッセージ・タイプに適用可能であり、複数セグメント・メッセージに必須である。
PrefixFlag : TPrefixFlag
OTMAメッセージに付加されるメッセージ・プレフィックスのセクションを指定する。すべてのメッセージが、メッセージ制御情報セクションを有しなければならないが、他のセクションの任意の組合せを、OTMAメッセージと共に送信することができる。
SendSequenceNumber : FourByteField
トランザクション・パイプのシーケンス番号を指定する。このシーケンス番号は、メッセージまたはトランザクションを送信する時に、クライアントおよびサーバによって更新される。
推奨:トランザクション・パイプごとに別々に番号を増分されたい。
この番号は、ACKメッセージまたはNAKメッセージを、肯定応答される指定されたメッセージと一致させるのにも使用することができる。
SenseCode : TwoByteField
NAKメッセージに付随するセンス・コードを指定する。
ReasonCode : TwoByteField
NAKメッセージに付随する理由コードを指定する。このコードが、さらに、センス・コードを修飾することができる。
RecoverableSequenceNumber : FourByteField
トランザクション・パイプの回復可能シーケンス番号を指定する。
同期化されるトランザクション・パイプを使用する回復可能メッセージの送信ごとに増分される。クライアントとサーバの両方が、回復可能シーケンス番号を増分し、送信シーケンス番号とは別に維持する。
SegmentSequenceNumber : TwoByteField
複数セグメント・メッセージのセグメントのシーケンス番号を指定する。
この番号は、セグメントごとに更新されなければならない。というのは、メッセージが、必ずしもXCFによってシーケンシャルに送達されるのではないからである。
この番号は、メッセージが1つだけセグメントを有する場合に、0(ゼロ)の値を有しなければならない。
Reserved : TwoByteField
【0272】
DefinedTypes
TMessageType
プライベート属性:
Data : String
データ(値X’80’)
クライアントに送信されるサーバ出力を指定する。クライアントが、メッセージ・プレフィックスの状態データ・セクションで同期レベルConfirmを指定する場合に、サーバも、応答フラグの応答要求をセットする。クライアントが同期レベルを指定しない場合には、サーバは、デフォルトのConfirmを使用する。
Transaction : String
トランザクション(値X’40’)
サーバへの入力データを指定する。
Response : String
応答(値X’20’)
メッセージが応答メッセージであることを指定し、このメッセージがそれに対する応答であるメッセージで応答フラグの応答要求が指定される場合に限ってセットされる。
このフラグがセットされる場合には、応答フラグでACKまたはNAKのいずれかを指定する。
送信シーケンス番号が、元のデータ・メッセージおよび応答メッセージに関して一致しなければならない。サーバへのチェーン・トランザクション入力メッセージでは、必ず、次のトランザクション(特定のトランザクション・パイプに関する)が送信される前に、応答を要求しなければならない。
Command : String
コマンド(値X’10’) OTMAプロトコル・コマンドを指定する。OTMAコマンドでは、必ず、応答フラグの応答要求を指定しなければならない。
CommitConfirmation : String
CommitConfirmation(値X’08’) コミットが完了することを指定する。これは、同期点が完了した時にサーバによって送信され、送信後コミット・トランザクションについてのみ適用可能である。コミット確認フラグもセットされる。
【0273】
TResponseFlag
プライベート属性:
ACK : String
ACK(値X’80’) 肯定の応答を指定する。
NAK : String
NAK(値X’40’) 否定の応答を指定する。
NAKの理由に関する情報については、センス・コード・フィールドを参照されたい。
ResponseRequested : String
応答要求(値X’20’) このメッセージに関して応答が要求されることを示す。これは、データ、トランザクション、またはコマンドのメッセージ・タイプについてセットすることができる。
送信後コミットIMSコマンド出力を送信する時に、IMSは、同期レベルに無関係に、ACKを要求しない。
ExtendedResponseRequested : String
拡張要求応答(値X’10’) このメッセージに関して拡張応答が要求されることを指定する。クライアントによって、トランザクションについてのみ(またはトランザクション・コードではなくIMSコマンドを指定するトランザクションについて)セットすることができる。このフラグが、トランザクションについてセットされる場合に、IMSは、ACKメッセージのアプリケーションデータ・セクションで、そのトランザクションの設計済み属性を返す。このフラグが、コマンドについてセットされる場合に、IMSは、ACKメッセージのアプリケーションデータ・セクションで設計済み属性を返す。このフラグは、IMSコマンド/DISPLAY TRANSACTIONおよび/DISPLAY TRANSACTION ALLについてセットすることができる。
【0274】
TCommitConfirmationFlag
プライベート属性:
Committed : String
コミット済み(値X’80’) サーバが成功裡にコミットしたことを指定する。
Aborted : String
打切り(値X’40’) サーバがコミットを打ち切ったことを指定する。
【0275】
TCommandType
プライベート属性:
ClientBid : String
クライアント送信権要求(値X’04’) クライアントがOTMAサーバに送信する最初のメッセージを指定する。このコマンドによって、メッセージ・プレフィックスのメッセージ制御情報セクションの応答要求フラグおよびセキュリティ・フラグもセットされる。適当な状態データ・フィールド(たとえばMember Name)もセットされなければならない。セキュリティデータ・プレフィックスでは、OTMAサーバがOTMAクライアントとして働くためのクライアントの権限を検証できるように、Utokenフィールドを指定しなければならない。サーバは、クライアント送信権要求要求に応答することができるので、このメッセージは、クライアントがデータ・メッセージの受け入れを開始する準備ができるまで、送信してはならない。
ServerAvailable : String
サーバ使用可能(値X’08’) サーバがクライアントに送信する最初のメッセージを指定する。これは、クライアントが接続される前に、サーバがXCFグループに接続した時に送信される。クライアントは、サーバ使用可能メッセージに対して、クライアント送信権要求要求を用いて応答する。適当な状態データ・フィールド(たとえばMember Name)もセットされなければならない。クライアントは、初めて接続する場合に、サーバが接続した時にXCFによって通知され、クライアント送信権要求要求を用いて処理を開始する。
CBresynch : String
CBresynch(値X’0C’) 再同期のためのクライアントによる要求を伴うクライアント送信権要求要求メッセージを指定する。このコマンドは、任意選択であり、サーバに、SRVresynchメッセージをクライアントに送信させる。CBresynchコマンドは、クライアントがIMSとの再同期を試み、既存の同期化されたTpipesがそのクライアントのために存在する時に、クライアントがOTMAサーバに送信する最初のメッセージである。メッセージ・プレフィックス内のCBresynchメッセージ・インジケータ以外の、メッセージ・プレフィックスに必要な情報は、クライアント送信権要求要求コマンドと同一でなければならない。IMSが、クライアントに関するクライアント送信権要求要求を受信し、IMSが、既存の同期化されたTpipesを知っている場合に、IMSは、情報メッセージDFS2394IをMTOに発行する。IMSは、すべての同期化されたTpipesについて、回復可能送信シーケンス番号または回復可能受信シーケンス番号を0(ゼロ)にリセットする。
SuspendProcessingForAllTpipes : String
すべてのTpipesに関する処理の延期(値X’14’) サーバが、クライアントとのすべてのメッセージ・アクティビティを延期しようとしていることを指定する。すべての後続のデータ入力で、サーバからのNAKメッセージが受信される。同様に、クライアントは、すべての後続のサーバ・メッセージに関してNAKメッセージを送信しなければならない。クライアントは、特定のトランザクション・パイプに関して処理を延期することを望む場合には、OTMAメッセージとして/STOPTPIPEコマンドをサブミットしなければならない。
ResumeProcessingForAllTpipes : String
すべてのTpipesに関する処理の再開(値X’18’) サーバが、クライアントとのメッセージ・アクティビティを再開しようとしていることを指定する。クライアントは、停止された特定のトランザクション・パイプに関する処理を再開することを望む場合に、OTMAメッセージとして/STARTTPIPEコマンドをサブミットしなければならない。
SuspendInputForTpipe : String
Tpipeの入力延期(値X’1C’) サーバが、過負荷であり、トランザクション・パイプに関する入力を一時的に延期しようとしていることを指定する。すべての後続のクライアント入力で、メッセージ・プレフィックスのメッセージ制御情報セクションで指定されたトランザクション・パイプに関するNAKメッセージが受信される。このコマンドに関して、応答は不要である。この設計済みコマンドは、マスタ端末オペレータが/STOPTPIPEコマンドを入力した時にも、IMSによって送信される。
ResumeInputForTpipe : String
Tpipeの入力再開(値X’20’) サーバが、前のTpipeの入力延期コマンドの後に、クライアント入力を再開する準備ができたことを指定する。このコマンドに関して、応答は不要である。このコマンドは、IMSマスタ端末オペレータが/STARTTPIPEコマンドを入力した時にも、IMSによって送信される。
SRVresynch : String
SRVresynch(値X’2C’) クライアントのCBresynchコマンドに対するサーバの応答を指定する。このコマンドでは、サーバ内の同期化されたトランザクション・パイプの状態(送信シーケンス番号および受信シーケンス番号)を指定する。このコマンドは、単一のメッセージ(単一または複数のセグメントを有する)として送信され、ACKが要求される。
REQresynch : String
REQresynch(値X’30’) 特定のTpipeの送信シーケンス番号および受信シーケンス番号を指定する。REQresynchは、IMSからクライアントに送信される。
REPresynch : String
REPresynch(値X’34’) Tpipeに関するクライアントの所望の状態情報を指定する。クライアントは、IMSから受信したREQresynchコマンドに応答して、IMSにREPresynchコマンドを送信する。
TBresynch : String
TBresynch(値X’38’) クライアントが、IMSからREQresynchコマンドを受信する準備ができていることを指定する。
【0276】
TProcessingFlag
プライベート属性:
SynchronizedTpipe : String
同期化されたTpipe(値X’40’) トランザクション・パイプが同期化されることを指定する。障害がある場合に、クライアントがトランザクション・パイプを再同期化できるようにする。コミット後送信トランザクションについてのみ有効。このフラグは、入力および出力のシーケンス番号がトランザクション・パイプに関して維持されるようにする。そのトランザクション・パイプを介して経路指定されるすべてのトランザクションが、矛盾がないように(オンまたはオフのいずれか)このフラグを指定しなければならない。
AsynchronousOutput: String
非同期出力(値X’20’) サーバが、非送信請求待機出力をクライアントに送信しつつあることを指定する。これは、IMSが、代替PCBにメッセージを挿入する時に発生する可能性がある。いくつかのIMSコマンドは、コミット後送信としてサブミットされる時に、IMSに、このフラグをセットされた出力をクライアントに送信させる場合がある。この場合に、OTMAプレフィックスに、出力を元のコマンド・メッセージに相関させるのにクライアントが使用できる識別情報が含まれない。これらのコマンド出力データ・メッセージは、単に、トランザクションパイプ名を識別する。IMSは、トランザクションパイプ名だけを有する非送信請求エラー・メッセージを送信することもできる。
ErrorMessageFollows : String
エラー・メッセージが続く(値X’10’) このメッセージにエラー・メッセージが続くことを指定する。このフラグは、サーバからのNAKメッセージについてセットされる。その後、追加のエラー・メッセージが、クライアントに送信される。非同期出力フラグは、エラー・データ・メッセージではセットされない。というのは、この出力がIMSアプリケーションによって生成されないからである。
【0277】
TChainFlag
プライベート属性:
FirstInChain : String
先頭チェーン(値X’80’) 複数セグメント・メッセージを含むセグメントのチェーンの最初のセグメントを指定する。このメッセージの後続セグメントは、メッセージ・プレフィックスのメッセージ制御情報セクションだけを必要とする。他の適用可能なプレフィックス・セグメント(たとえば、トランザクション・メッセージ上でクライアントによって指定されるもの)は、最初のセグメントと共に送信されるだけである(先頭チェーン・フラグをセットされて)。OTMAメッセージが、1つのセグメントだけを有する場合には、チェーン内での最後フラグもセットされなければならない。
MiddleInChain : String
中間チェーン(値X’40’) 複数セグメント・メッセージを含むセグメントのチェーンの最初でも最後でもないセグメントを指定する。これらのセグメントは、メッセージ・プレフィックスのメッセージ制御情報セクションだけを必要とする。
制約:クライアント・トークンおよびサーバ・トークンが、メッセージ・プレフィックスの状態データ・セクションにあるので、これらを使用して、セグメント化されたメッセージを相関させ、組み合わせることはできない。トランザクションパイプ名および送信シーケンス番号を、この目的に使用することができる。これは、各セグメントのメッセージ・プレフィックスのメッセージ制御情報セクションにある。
LastInChain : String
チェーン内での最後(値X’20’) 複数セグメント・メッセージの最後のセグメントを指定する。
DiscardChain : String
チェーン破棄(値X’10’) 複数セグメント・メッセージのチェーン全体を破棄しなければならないことを指定する。チェーン内での最後フラグもセットしなければならない。
【0278】
TPrefixFlag
プライベート属性:
StateData : String
状態データ(値X’80’) このメッセージに、メッセージ・プレフィックスの状態データ・セクションが含まれることを指定する。
SecurityData : String
セキュリティ(値X’40’) このメッセージに、メッセージ・プレフィックスのセキュリティデータ・セクションが含まれることを指定する。
UserData : String
ユーザ・データ(値X’20’) このメッセージに、メッセージ・プレフィックスのユーザデータ・セクションが含まれることを指定する。
ApplicationData : String
アプリケーション・データ(値X’10’) このメッセージに、メッセージ・プレフィックスのアプリケーションデータ・セクションが含まれることを指定する。
【0279】
StateData
StateData
これには、宛先オーバーライド、マップ名、同期レベル、コミット・モード、トークン、およびサーバ状態が含まれる。これが、トランザクションに関する状態データであることに留意されたい。OTMAは、サーバ使用可能コマンド、クライアント送信権要求コマンド、SRVresynchコマンド、REQresynchコマンド、REPresynchコマンドに関する状態データ・ヘッダもサポートする。しかし、これらのコマンドは、絶対にクライアント装置によって生成されず、したがって、コマンド・メッセージが、絶対にIMS接続インターフェースに入らず、したがって、これらをモデル化する必要はない。
プライベート属性:
Length : TwoByteField
ServerState : TServerState トランザクションが実行されているモードを指定する。
SynchronizationFlag : TSynchronizationFlag トランザクションのコミット・モードを指定する。このフラグによって、クライアントとサーバの間のデータの流れが制御され、同期化される。
SynchronizationLevel :TSynchronizationLevel トランザクション同期化レベルすなわち、クライアントとサーバのトランザクション・プログラム(たとえばIMSアプリケーション・プログラム)がプログラム出力メッセージと対話する形を指定する。デフォルトはConfirmである。IMSは、コミット後送信出力をクライアントに送信する時に、必ず応答を要求する。
Reserved : OneByteField
MapName : EightByteField 出力データ・ストリーム(たとえば3270データ・ストリーム)をマッピングするのにサーバによって使用されるフォーマット設定マップを指定する。OTMAは、MFSサポートを提供しないが、ユーザは、マップ名を指定して、出力データ・ストリームを定義することができる。名前は、入出力PCB内に配置される8バイトMOD名である。IMSは、メッセージが挿入される時に、プレフィックス内のこのフィールドを、入出力PCB内のマップ名に置換する。
マップ名は任意選択である。
ServerToken : SixteenByteField サーバ名を指定する。サーバ・トークンが、応答メッセージ(ACKまたはNAK)でクライアントによってサーバに返されなければならない。会話型トランザクションの場合には、サーバ・トークンが、後続の会話入力でもクライアントによって返されなければならない。
CorrelatorToken : SixteenByteField 入力を出力に相関させるクライアント・トークンを指定する。このトークンは、任意選択であり、サーバによって使用されることはない。
推奨:クライアントは、トランザクションの管理を助けるためにこのトークンを使用すべきである。
ContextID : SixteenByteField
SYNCLVL=02および保護会話と共に使用されるRRS/MVSトークンを指定する。
DestinationOverride : EightByteField IMSアプリケーション・プログラムの入出力PCB内のLTERM名をオーバーライドするのに使用されるLTERM名を指定する。このオーバーライドは、クライアントが、入出力PCB内のLTERM名をトランザクションパイプ名にオーバーライドしたくない場合に使用される。この任意選択のオーバーライドは、ブランクから開始される場合に、使用されない。
ServerUserDataLength : TwoByteField サーバ・ユーザ・データがある場合に、その長さを指定する。サーバ・ユーザ・データの最大長は、256バイトである。
ServerUserData : VariableLengthField サーバが必要とするデータを指定する。クライアントによってトランザクション・メッセージに含められる場合に、これは、出力データ・メッセージ内でサーバによって返される。
【0280】
DefinedTypes
TServerState
プライベート属性:
ConversationalState : String
会話状態(値X’80’) 会話モード・トランザクションを指定する。サーバは、会話モード・トランザクションを処理する時に、この状態をセットする。この状態は、クライアントによって、後続IMS会話データ・メッセージをIMSに送信する時にもセットされる。
ResponseMode : String
応答モード(値X’40’) 応答モード・トランザクションを指定する。応答モード・トランザクションを処理する時に、サーバによってセットされる。OTMAはセッションまたは端末を使用しないので、この状態は、OTMAサーバにとってほとんど意味がない。
【0281】
TSynchronizationFlag
プライベート属性:
CommitThenSend : String
コミット後送信(値X’40’) コミット後送信トランザクションを指定する。サーバは、出力を送信する前にコミットする;たとえば、IMSが、IMSメッセージ・キューに出力を挿入する。
SendThenCommit : String
送信後コミット(値X’20’) 送信後コミット・トランザクションを指定する。サーバは、出力をコミットする前にクライアントに送信する。
【0282】
TSynchronizationLevel
プライベート属性:
None : String
なし(値X’00’) 同期化が不要であることを指定する。サーバ・アプリケーション・プログラムは、クライアントに出力を送信する時に、ACKメッセージを要求しない。Noneは、送信後コミット・トランザクションに限って有効である。
Confirm : String
確認(値X’01’) 同期化が必要であることを指定する。サーバは、メッセージ・プレフィックスのメッセージ制御情報セクションの応答フラグに応答要求をセットして出力を送信する。確認は、コミット後送信トランザクションまたは送信後コミット・トランザクションのいずれかに使用することができる。
SYNCPT : String
SYNCPT(値X’02’) プログラムが、RRS/MVS回復プラットフォームの下での変換中に更新されるリソースに対する整合コミット処理に参加することを指定する。このレベルとの会話を、保護会話とも称する。
【0283】
SecurityData
SecurityData
これには、ユーザID、ユーザ・トークン、およびセキュリティ・フラグが含まれる。
セキュリティデータ・セクションは、すべてのトランザクションに必須であり、OTMAコマンド・メッセージのために存在することができる。
プライベート属性:
Length : TwoByteField メッセージ・プレフィックスのセキュリティデータ・セクションの、長さフィールドを含む長さを指定する。
SecurityFlag : TSecurityFlag 実行されるセキュリティ検査のタイプを指定する。ユーザIDおよびパスワードが既に検証されていると仮定する。
LengthOfSecurityFields : OneByteField セキュリティ・データ・フィールドすなわちユーザID、プロファイル、およびUtokenの長さを指定する。この3つのフィールドは、任意の順序とすることができ、省略することができる。それぞれが、次の構造体を有する:Lengthフィールド、その後のFieldタイプ、およびその後のDataフィールド。ユーザIDまたはプロファイルの実際の長さは、各フィールドの長さについて指定された値未満になってはならない。長さは、0にすることができる。
tokenLength : OneByteField
ユーザ・トークンの長さを指定する。
長さには、長さフィールド自体は含まれない。
UtokenType : OneByteField このフィールドにユーザ・トークンが含まれることを指定する(値X’00’)。
Utoken : VariableLengthField ユーザ・トークンを指定する。ユーザIDおよびプロファイルが、ユーザ・トークンの作成に使用される。ユーザ・トークンは、IMS依存領域に渡される。クライアントは、既にRACFを呼び出している場合に、フィールド・タイプX’00’を有するUtokenを渡し、その結果、RACFがもう一度呼び出されないようにしなければならない。
1バイトから80バイトまでの可変長。
UserIDLength : OneByteField ユーザIDの長さを指定する。長さには、長さフィールド自体は含まれない。
UserIDType : OneByteField このフィールドにユーザIDが含まれることを指定する(値X’02’)。
UserID : VariableLengthField 実際のユーザIDを指定する。
1バイトから10バイトまでの可変長。
ProfileLength : OneByteField プロファイルの長さを指定する。長さには、長さフィールド自体は含まれない。
ProfileType : OneByteField このフィールドにプロファイルが含まれることを指定する(値X’03’)。
Profile : VariableLengthField システム許可機能(SAF)プロファイルを指定する。RACFに関して、これはグループ名である。
1バイトから10バイトまでの可変長。
【0284】
DefinedTypes
TSecurityFlag
プライベート属性:
NoSecurity : String
セキュリティなし(値X’N’) セキュリティ検査が行われないことを指定する。
Check : String
検査(値X’C’) トランザクションおよびコマンドのセキュリティ検査を実行しなければならないことを指定する。
Full : String
完全(値X’F’)
トランザクション、コマンド、およびMPP領域のセキュリティ検査を実行しなければならないことを指定する。
【0285】
UserData
UserData
これには、クライアントが必要とする特殊な情報のすべてが含まれる。
ユーザデータ・セクションは、可変長であり、メッセージ・プレフィックスのセキュリティデータ・セクションに続く。ユーザデータ・セクションには、どのようなデータでも含めることができる。
プライベート属性:
Length : TwoByteField
メッセージ・プレフィックスのユーザデータ・セクションの、長さフィールドを含む長さを指定する。ユーザ・データの最大長は、1024バイトである。
UserData : VariableLengthField
任意選択のユーザ・データを指定する。このデータは、クライアントによって管理され、DFSYDRU0出口ルーチンを使用して作成し、更新することができる。サーバは、すべての出力メッセージの最初のセグメントとして、このセクションを無変更でクライアントに返す。
【0286】
Primitives
OneByteField
TwoByteField
FourByteField
EightByteField
SixteenByteField
SixByteField
VariableLengthField
【0287】
ApplicationData
ApplicationData
アプリケーション・データ・クラスには、LL、ZZ、およびトランザクション・コードを除くすべてのメッセージ・データが含まれる。
注:このモデルは、メッセージ・セグメントの概念を取り込まない。このモデルを使用する時には、使用しているシステムが、最大セグメント・サイズなどの制限を有するかどうかをユーザが憶えていなければならない。IMSコネクタ(OTMAまたはSNAを介する)は、「アプリケーション・データ」をIMSメッセージ・セグメントに分解する機能をサポートしなければならない。たとえば、ユーザが、このXMLメッセージをIMSメッセージ・キューに直接に送信し、メッセージ・キューが32kの制限を有する場合に、ユーザは、XMLメッセージをとり、32kチャンクに分解しなければならない。IMS上のアプリケーションは、32kチャンクを1つずつ寄せ集めなければならない。XML文書を直接に受信するIMSの新しいアプリケーションは、複数のセグメントでXML文書を受信することができなければならない。ACKメッセージまたはNAKメッセージに関して、メッセージに含まれるアプリケーション・データはない。
【0288】
Field
アプリケーション・データのコピーブック内で定義される各データ・フィールドは、データ型の型記述子に関連する。
【0289】
6.b.CICS BMS(基本マッピング・サポート)メタモデル
図40に、コネクタ・インターフェースを表すデータ構造体を定義するためにアプリケーション・プログラムによって使用可能なBMS言語メタモデルを示す。図41、および図42に、BMSメタモデルの属性、フィールド、属性値、およびマップを示す。
【0290】
BMSFieldAttributes
プライベート属性:
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"
【0291】
BMSMap
DFHMDIマクロによって実装される
MAPNAMEは、マップの名前であり、1つから7つまでの文字からなる。
COLUMNは、マップが配置される行内の桁を指定する、すなわち、左または右のマップ・マージンを確立する。
JUSTIFYは、マップおよびページのマージン選択および桁カウントが、ページの左側または右側のどちらから行われるかを制御する。指定されたマップ・マージンとページ・マージンの間の桁は、マップに含まれる行に関してそのページでの後続の使用に利用可能ではない。
NUMBERは、左または右のページ・マージンから、左または右のマップ・マージンが確立される桁である。
NEXTは、左または右のマップ・マージンが、現在の行の左または右からの次に使用可能な桁に配置されることを示す。
SAMEは、左または右のマップ・マージンが、COLUMN=Numberを指定した最後に使用された非ヘッダ・マップまたは非トレーラ・マップと同一の桁で、このマクロと同一のJUSTIFYオペランドで確立されることを示す。入力動作に関して、マップは、JUSTIFY=LEFTまたはJUSTIFY=RIGHTのどちらが指定されたかに応じて、左端または右端に位置決めされる。
LINEは、マップのデータがフォーマットされるページの開始行を指定する。
NUMBERは、開始行番号を指定する、1から240までの範囲の値である。前のBMSコマンドに応答してフォーマットされたデータを、行および列にマップする要求によって、現在のページが完了したかのように扱われる。新しいデータは、新しいページの要求された行および列でフォーマットされる。
NEXTは、データのフォーマットが、次に使用可能な完全に空の行で開始されることを指定する。LINE=NEXTがDFHMDIマクロで指定される場合には、入力動作に関してそれが無視され、LINE=1が仮定される。
SAMEは、データのフォーマットが、前のBMSコマンドに使用されたものと同一の行で開始されることを指定する。COLUMN=NEXTが指定された場合に、入力動作についてはこれが無視され、COLUMN=1が仮定される。データが同一行におさまらない場合には、そのデータは、完全に空の次に使用可能な行に配置される。
SIZE(arg1,arg2)は、マップのサイズを指定する。arg2=lineは、1から240までの範囲の値であり、行数としてマップの奥行きを指定する。arg1=columnは、1から240までの範囲の値であり、桁数としてマップの幅を指定する。
このオペランドは、次の場合に必要である:
POSオペランドに関連するDFHMDFマクロが使用される。
マップが、ACCUMオプション付きのSEND MAPコマンドで参照される。
マップが、3270端末以外からの入力データをRECEIVE MAPコマンドで参照する時に使用される。
SOSIから、フィールドにEBCDICデータとDBCSデータの混合が含まれる可能性があることが示される。EBCDICフィールド内のDBCSサブフィールドは、SO(シフト・アウト)文字およびSI(シフト・イン)文字によって区切られる。SOとSIの両方が、単一の画面位置を占める(通常はブランクとして表示される)。これらは、正しく対にされる場合に、出力の非DBCSフィールドに含めることができる。端末ユーザは、これらがフィールドに既に存在する場合に、これらをインバウンドに送信できるが、これらをEBCDICフィールドに追加できるのは、そのフィールドがSOSI属性を有する場合に限られる。
TIOAPFXは、BMSが、未使用のTIOAプレフィックスを可能にするために記号記述マップに充てん文字を含めなければならないことを指定する。このオペランドは、DFHMSDマクロについて指定されたTIOAPFXオペランドをオーバーライドする。
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
【0292】
BMSMapset
DFHMSDマクロによって実装される
このマクロのプログラミング属性
type=DSECT|MAP|FINAL。 必須、これは、BMSエンティティの2ビットを生成する。
mode=OUT|IN|INOUT。 OUTがデフォルトである。INOUTは、INおよびOUTの両方の処理を指す。INの場合に、Iがマップ名に付加され、OUTの場合に、Oがマップ名に付加される。
lang=ASM|COBOL|COBOL2|PLI|C。 ASMがデフォルトである。
fold=LOWER|UPPER。 LOWERがデフォルトである。Cだけに適用される。
dsect=ADS|ADSL。 ADSがデフォルトである。ADSLはlang=Cを必要とする。
trigraph=YES lang=Cだけに適用される。
BASEは、同一のストレージ・ベースが、複数のマップセットからの記号記述マップに使用されることを指定する。同一の名前が、同一のストレージ・ベースを共用するマップセットごとに指定される。
同一のベースを有するすべてのマップセットが、同一のストレージを記述するので、前に使用されたマップセットに関連するデータは、新しいマップセットが使用される時に上書きされる可能性がある。同一のマップセット内の異なるマップも、互いにオーバーレイする。
このオペランドは、アセンブラ言語プログラムには有効でなく、STORAGE=AUTOが指定された時に使用することはできない。
term=type 各端末タイプが、1文字によって表される。3270は、デフォルトであり、ブランクである。MAPSET名に追加されるか、suffix=Numcharであり、これが、やはりマップセット名に追加される。
CURSLOCは、3270端末上でこのマップを使用するすべてのRECEIVEMAP動作について、BMSが、カーソルが位置するフィールドのアプリケーション・データ構造体要素内のフラグをセットすることを示す。
STORAGE
このオペランドの意味は、下記のように、アプリケーション・プログラムが記述された言語に依存する:
COBOLプログラムの場合に、STORAGE=AUTOは、マップセット内の記号記述マップが、ストレージの別々の(すなわち、再定義されない)区域を占めることを指定する。このオペランドは、記号記述マップが、作業記憶セクションにコピーされ、マップセット内の別々のマップのストレージが、並列に使用される時に使用される。
Cプログラムの場合に、STORAGE=AUTOは、記号記述マップが、自動ストレージ・クラスを有するものとして定義されることを指定する。STORAGE=AUTOが指定されない場合には、記号記述マップが、ポインタとして宣言される。同一のマップセットについてBASE=nameとSTORAGE=AUTOの両方を指定することはできない。
STORAGE=AUTOが指定され、TIOAPFXが指定されない場合には、TIOAPFX=YESが仮定される。
PL/Iプログラムの場合に、STORAGE=AUTOは、記号記述マップが、AUTOMATICストレージ・クラスを有するものとして宣言されることを指定する。STORAGE=AUTOが指定されない場合には、記号記述マップが、BASEDとして宣言される。同一のマップセットについてBASE=nameとSTORAGE=AUTOの両方を指定することはできない。STORAGE=AUTOが指定され、TIOAPFXが指定されない場合には、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
【0293】
BMSField
DFHMDFマクロによって実装される。
GRPNAMEは、記号ストレージ定義を生成し、1つのグループ名の下で特定のフィールドを組み合わせるのに使用される名前である。同一のグループ名が、グループに属するフィールドごとに指定されなければならない。名前の長さは、30文字までであるが、コンパイラ・マニュアルを参照して、長さに対する他の制約がないことを確認されたい。
このオペランドが指定される場合には、OCCURSオペランドを指定することはできない。
グループ内のフィールドは、連続しなければならない。グループ内のフィールドの間に、ギャップを置くことはできるが、グループの外からの他のフィールドは置けない。フィールド名は、グループに属するすべてのフィールドについて指定されなければならず、フィールドが互いに続くことを保証するために、POSオペランドも指定されなければならない。グループのフィールドを定義するDFHMDFマクロのすべてが、一緒に配置されなければならず、正しい順序(POS値の数字の昇順)でなければならない。
たとえば、マップの最初の6行の最初の20桁を、最初の5行の残りの桁がフィールドして定義されない限り、6フィールドのグループとして定義することができる。
グループの最初のフィールドに対して指定されるATTRBオペランドは、グループ内のすべてのフィールドに適用される。
LENGTHは、フィールドまたはフィールドのグループの長さ(1から256バイト)を指定する。この長さは、フィールドに入力されるアプリケーション・プログラム・データに必要な最大長さでなければならず、後続処理での使用のためにCICSによってフィールドに付加される1バイト属性インジケータを含んではならない。1グループ内の各個々のサブフィールドの長さが、256バイトを超えてはならない。PICINまたはPICOUTが指定される場合には、LENGTHを省略することができるが、それ以外の場合にはLENGTHが必要である。DFHMDFマクロでラベル(フィールド名)を省略する場合に限って、0の長さを指定することができる。すなわち、フィールドは、アプリケーション・データ構造体の一部ではなく、アプリケーション・プログラムが、フィールドの属性を変更することはできない。0の長さのフィールドを使用して、マップの入力フィールドを区切ることができる。
マップを定義するDFHMDIマクロのSIZEオペランドで指定されるマップ寸法は、端末に関して定義される実際のページ・サイズまたは画面サイズより小さいものにすることができる。
DFHMDFマクロのLENGTH指定によって、同一行のマップによって定義される境界を超える場合には、出力画面のフィールドは、ラップによって継続される。
OCCURSは、フィールドの示された数の項目が、マップ内で生成されることと、フィールドが行列または配列の項目としてアドレス可能な形でマップ定義が生成されることを指定する。これによって、フィールドごとに一意の名前を生成せずに、複数のデータ・フィールドを同一の名前(添字付き)によってアドレッシングできるようになる。
OCCURSとGRPNAMEは、相互に排他的である、すなわち、OCCURSは、フィールドがグループ名の下で定義された時には使用することができない。このオペランドが省略される場合には、OCCURS=1の値が仮定される。
PICIN(COBOLおよびPL/Iのみ)は、INマップまたはINOUTマップの入力フィールドに適用されるピクチャを指定する。このピクチャは、アプリケーション・プログラムに渡される編集指定として働き、したがって、ユーザがCOBOLまたはPL/Iの編集機能を利用できるようになる。BMSは、指定された文字がマップの言語の有効なピクチャ指定であることを検査する。
しかし、入力データの有効性は、マップが使用される時には、BMSまたは高水準言語によって検査されず、したがって、所望の検査のすべてを、アプリケーション・プログラムが実行しなければならない。「値」に関連するデータの長さは、LENGTHが指定される場合に、LENGTHオペランドで指定されるものと同一でなければならない。PICINとPICOUTの両方が使用される場合には、その計算された長さが一致しない場合に、エラー・メッセージが作られ、2つの長さの短い方が使用される。フィールド定義についてPICINまたはPICOUTがコード化されない場合には、ATTRB=NUMなど、コード化される他のオペランドに無関係に、フィールドの文字定義が自動的に生成される。
注:COBOL入力マップの有効なピクチャ値は次の通りである:
A P S V X 9 / および (
PL/I入力マップの有効なピクチャ値は次の通りである:
A B E F G H I K M P R S T V X Y および Z
1 2 3 6 7 8 9 / + - , . * $ および (
PL/Iの場合に、通貨記号をピクチャ文字として使用することができる。この記号は、たとえば<DM>など、<と>に囲まれた文字の任意のシーケンスとすることができる。
PICTURE属性の正しい構文については、適当な言語リファレンス・マニュアルを参照されたい。
PICOUT(COBOLおよびPL/Iのみ)は、OUTマップまたはINOUTマップ内の出力フィールドに適用されるピクチャが生成されることを除いて、PICINに類似する。
COBOL出力マップの有効なピクチャ値は次の通りである:
A B E P S V X Z 0 9 , . + - $ CR DB / および (
PL/I出力マップの有効なピクチャ値は次の通りである:
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 および (
PL/Iの場合、通貨記号をピクチャ文字として使用することができる。この記号は、たとえば<DM>など、<と>に囲まれた文字の任意のシーケンスとすることができる。
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.
1を超える長さの通貨符号に置換される、通貨記号を含むCOBOLピクチャがPICOUTで指定される場合に、LENGTHを指定しなければならない。
POSは、フィールドの位置を指定する。このオペランドは、フィールドに先行する属性バイトが位置決めされる、マップ内の個々のアドレス可能文字位置を指定する。
Numberは、定義されるマップの先頭からの変位(0に対する相対変位)を指定する。
(line、column)は、定義されるマップ内の行および桁(0に対する相対値)を指定する。
出力媒体上のデータの位置も、DFHMDIオペランドに依存する。
フィールドの最初の位置は、属性バイトのために予約される。非3270装置からの入力マッピングについてデータを供給する時に、入力データは、この属性バイトのスペースを許容しなければならない。入力データは、桁1から開始してはならず、桁2から開始することができる。
POSオペランドには、フィールド内の最初の位置の場所が含まれ、これは、通常は、3270と通信する時には属性バイトである。グループの2番目以降のフィールドでは、POSオペランドが、実際の属性バイトが必要でない場合であっても、データの先頭の前の、仮定される属性バイト位置を指す。フィールドが、互いに直接に連続する場合には、POSオペランドは、グループ内の前のフィールドの最後の文字位置を指さなければならない。
3270の最後の文字位置を表す位置番号が指定される時には、2つの特別な規則が適用される:
ATTRIB=ICをコード化してはならない。カーソルは、SEND MAPコマンド、SENDCONTROLコマンド、またはSEND TEXTコマンドのCURSORオプションを使用することによって、位置0にセットすることができる。
フィールドが、SEND MAPコマンドのMAP=DATAONLYを伴う出力マッピング動作に使用される場合には、そのフィールドの属性バイトが、アプリケーション・プログラムによって記号マップ・データ構造体で供給されなければならない。
PSは、プログラム式記号が使用されることを指定する。これは、DFHMDIマクロまたはDFHMSDマクロによってセットされるPSオペランドのすべてをオーバーライドする。
BASEは、デフォルトであり、基本記号セットが使用されることを指定する。
psidは、使用されるプログラム式記号セットを識別する、単一のEBCDIC文字、またはX’nn’の形の16進コードを指定する。
PSオペランドは、端末がプログラム式記号をサポートしない限り無視される。
SOSIは、フィールドにEBCDICデータとDBCSデータの混合が含まれる可能性があることを示す。EBCDICフィールド内のDBCSサブフィールドは、SO(シフト・アウト)文字およびSI(シフト・イン)文字によって区切られる。SOとSIの両方が、単一の画面位置を占める(通常はブランクとして表示される)。これらは、正しく対にされる場合に、出力の非DBCSフィールドに含めることができる。端末ユーザは、これらがフィールドに既に存在する場合に、これらをインバウンドに送信できるが、これらをEBCDICフィールドに追加できるのは、そのフィールドがSOSI属性を有する場合に限られる。
TRANSPは、英数字フィールドの背景が透明または不透明のどちらであるか、すなわち、下にある(グラフィック)表示スペースが文字の間で可視であるかどうかを決定する。
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
【0294】
BMSStatement
プライベート属性:
label : String
comments : String
【0295】
総計:
1論理パッケージ
4クラス
論理パッケージ構造
論理ビュー
bms
【0296】
6.c.IMS MFS(メッセージ形式サービス)
図43に、コネクタ・インターフェースを表すデータ構造体を定義するためにアプリケーション・プログラムによって使用可能なMFS言語メタモデルを示す。図44に、MFSメタモデルのTDLangClassifier、TDLanguageComposedType、およびTDLanguageElementである、MFSメタモデルとTDLang基本クラスの間の関連を示す。図45、および図46に、MFSメタモデルのModeValues、BaseValues、LengthTypes、およびStringTypeValuesの列挙を示す。
【0297】
MFSのパッケージ文書化
下記の装置がサポートされる:
− 3270および3270−An
− 3270P
下記の装置タイプはサポートされない:
− 2740または2741
− 3600または4700
− FIN
− FIDS、FIDS3、FIDS4、またはFIDS7
− FIJP、FIPB、またはFIFP
− SCS1
− SCS2
− DPM−An
− DPM−Bn
パーサを介して暗黙のうちにサポートされるステートメント:
− ALPHA
− COPY
− DO
− END
− ENDDO
− EQU
− FMTEND
− MSGEND
− RESCAN
− TABLEEND
許容されるステートメント:
− EJECT
− PD
− PDB
− PDBEND
− PPAGE
− RCD
− SPACE
− STACK
− TITLE
− UNSTACK
−
【0298】
MFSDeviceType
DEVステートメント
DEVステートメントでは、特定の装置の装置特性または特定の装置タイプのデータ・フォーマットを定義する。このDEVステートメントに続くDFLDステートメントは、次のDEVステートメントまたはFMTENDステートメントに出会うまで、指定された特性を使用してマッピングされる。
サポートされない属性:
− ERASE
− FTAB
− FORMS
− HT
− HTAB
− LDEL
− MODE
− SLD
− VERSID
− VT
− VTAB
MFSStatementから派生する
プライベート属性:
card : String
CARD属性
データが入力される時にオペレータIDカード・データを受け取る入力フィールド名を定義する。この名前は、MFLDステートメントによって参照することができ、このDEV定義内のDFLDステートメントのラベルとして使用してはならない。このオペランドは、3270ディスプレイが指定される場合に限って有効である。3270ディスプレイについてFEAT=NOCDが指定される場合には、FEATがCARDに変更される。このカード・フィールド名を参照する入力MFLDにデータが提示される前に、すべての制御文字が磁気カード入力から除去される。
3270ディスプレイについて、磁気カード・データおよび制御文字を含むのに十分に大きい無保護フィールドが、DFLDステートメントを介して定義されなければならない。カーソルをこのフィールドに位置決めし、カードをリーダに挿入して、カード情報を入力する。カード・データは、DFLDステートメントで使用される名前ではなく、CARD=フィールド名に論理的に関連付けられる。
dsca : String
DSCA属性
この装置フォーマットを使用する出力メッセージのデフォルト・システム制御域(DSCA)を指定する。DSCAは、メッセージ出力記述子で指定されたSCAと衝突する場合に、そのようなSCAを取り替える。通常、両方のSCAで指定された機能が実行される。DSCA=のオペランドが3270Pについて指定される場合には、「音響装置警告」のビット設定を除いて、そのオペランドが無視される。このビットがDSCA/SCAオプションで指定される場合には、そのビットが装置に送られる。
ここで指定される値は、65535またはX’ffff’を超えない10進数でなければならない。その数が指定される場合には、その数は、内部でX’ffff’に変換される。
3275ディスプレイに関して、バイト1のビット5にB’1’(無保護画面オプション)がセットされ、入力および出力の両方が、同時に発生する場合(競合)には、装置が切断される。非3275装置では、SCAオプションが無視される。バイト1のビット5にB’0’がセットされる場合には、アプリケーション・プログラムが、SCA値にB’1’をセットすることによって、自動ページングされた出力を要求することができる。この要求は、出力メッセージの最初のLPAGEの最初のセグメントに存在する場合に限って順守される。
バイト0について、またはバイト1のビット6または7について、ゼロ以外の値が指定される場合に、MFSは、指定された値を0でオーバーライドする。
features : MFSFeatureType
FEAT属性
この装置またはプログラム・グループの機能を指定する。
IGNORE
装置機能が、この装置について無視されることを指定する。
120|126|132
3284および3286装置タイプ(TYPE=3270P)にいて行の長さを指定する。
CARD
装置が3270オペレータIDカード・リーダを有することを指定する。NOCDは、CARD機能がないことを指定する。
DEKYBD
データ入力キーボード機能を指定する。この機能は、PFK機能を暗示し、したがって、PFKは、DEKYBDが指定される場合には無効である。NOPFKは、PFK機能およびDEKYBD機能の不在を暗示する。
PFK
装置がプログラム・ファンクション・キーを有することを指定する。NOPFKは、PFK機能およびDEKYBD機能の不在を暗示する。
PEN
選択ライト・ペン検出機能を指定する。NOPENは、PEN機能の不在を指定する。
1|2|3|4|5|6|7|8|9|10
3270P装置タイプの顧客定義機能を指定する。
3270P装置について、FEAT=によって、特殊な装置特性を有する装置のグループ化が可能になる。たとえば、FEAT=1によって、最大80個の印刷位置を有しVFCを有しない装置をグループ化することができ、FEAT=2によって132個の印刷位置とVFC機能を備える装置をグループ化することができる。FEAT=IGNOREは、装置機能の最小限の組を有する装置を一緒にグループ化するために指定されなければならない。WIDTH=が指定される時には、FEAT=(1…10)も指定されなければならない。FEAT=(1…10)が指定され、WIDTH=が指定されない場合に、WIDTH=のデフォルトは120になる。
IGNOREが指定される時には、他の値をFEAT=オペランドにコピーしてはならない。システム定義中にTERMINALマクロでFEAT=IGNOREが指定されない時には、MSGステートメントで、装置フォーマットのSOR=オペランドでIGNORE指定を用いてIGNOREを指定しなければならない。FEAT=IGNOREが使用されない限り、FEAT=では、IMSシステム定義中にTERMINALマクロで指定されたものを正確に指定しなければならない。そうでない場合には、DFS057エラー・メッセージが発行される。3270装置についてFEAT=IGNOREまたは1から10が指定される時には、まだオペランドPEN=、CARD=、およびPFK=を指定することができる。TYPE=3270PかつFEAT=IGNOREの時には、MFSが、120文字の行幅を可能にする。
CARD、PFK、DEKYBD、およびPENの機能値は、3270ディスプレイだけについて有効である。FEAT=オペランドが省略される場合には、デフォルト機能は、3270ディスプレイについてはCARD、PFK、およびPENになり、デフォルトの行幅は、TYPE=3270Pについて120である。
1、2、3、4、5、6、7、8、9、および10は、3270、3270P、および3270−Anに限って有効な値である。3270ディスプレイに関して、1から5までのFEAT=指定を使用して、特定の機能またはハードウェア・データ・ストリーム依存性を有する装置をグループ化することができる。
制約:このキーワードは、任意選択であり、3270ディスプレイの他の特徴指定と共に使用することはできない。
機能オペランド値は、任意の順序で、指定される必要が所望される値だけを、指定することができる。各垂直リストで1つの値だけを指定することができる。
page : MFSPageType
PAGE属性
下記のように出力パラメータを指定する:
number
プリンタ装置について、Numberによって、印刷されるページ上の印刷行数が定義され、カード装置について、Numberによって、DPAGEまたは物理ページ(DFLDステートメントでppパラメータが使用される場合)ごとに穿孔されるカードの数が定義される。この値は、有効性検査に使用される。指定される数は、1以上256未満でなければならない。デフォルトは55である。
DEFN
DFLDステートメントによる定義で行/カードが印刷/穿孔されることを指定する(行/カードは、除去されず、出力ページに追加されない)。
SPACE
各出力ページに、Numberパラメータで指定された正確な数の行/カードが含まれることを指定する。
FLOAT
フォーマットが削除された後のデータがない行/カード(すべてブランクまたはNULL)を指定する。
3270P装置の場合に、データを有しない(すなわち、すべてブランクまたはヌル)いくつかの行を、下記の情況で削除してはならない。
行に、1つまたは複数の行密度設定(SLDx=)指定が含まれる。
拡張属性を有すると指定されたフィールドが、複数の行にまたがる。
pen : String
PEN属性
スペースまたはヌル指定文字を有するフィールドの即時ライト・ペン検出が行われる時に、リテラル・データが格納される入力フィールド名を定義する。リテラル・データは、PEN=オペランドのDFLDステートメントで定義される(DFLDステートメントについてはPEN=オペランドを参照されたい)。この名前は、MFLDステートメントによって参照される可能性があり、このDEV定義内のDFLDステートメントのラベルとして使用してはならない。PEN=オペランドは、3270ディスプレイのみについて有効である。FEAT=NOPENが指定された場合に、FEATがPENに変更される。
スペースまたはヌル指定文字を用いて定義されたフィールドに対して即時検出が行われ、もう1つのフィールドが、選択されるか修正されるかMOD属性を有するか、PEN=オペランドが、DFLDに関して定義されていない場合に、疑問符(?)がPEN=フィールド名に挿入される。
即時検出が行われないか、アンパサンド(&)指定文字を用いて定義されたフィールドに対して即時検出が行われる場合には、PEN=オペランドが、MFLDステートメントで指定された充てんによって埋め込まれる。
pfk : MFSFunctionKeyType
PFK属性
プログラム・ファンクション・キー・リテラルまたは制御機能データを含む入力フィールド名(第1サブパラメータ)と、位置フォーマットまたはキーワード・フォーマットで、指定されたフィールドに配置されるリテラル・データ、または対応するファンクション・キーが押された時に実行される制御機能のいずれか(残りのサブパラメータ)を定義する。
第1サブパラメータの名前(プログラム・ファンクション・キー・リテラルまたは制御機能データを含む入力フィールド名)は、MFLDステートメントによって参照される可能性があり、このDEV定義内のDFLDステートメントのラベルとして使用してはならない。残りのサブパラメータは、位置フォーマットまたはキーワード・フォーマットで指定することができる。サブパラメータが、キーワード・フォーマットの場合に、指定される整数は、両端を含めて1から36までであり、重複してはならない。1つのPFK=オペランド・フォーマット(位置またはキーワード)だけを、1つのDEVステートメントで指定することができる。このオペランドは、3270ディスプレイのみについて有効である。実際のフォーマット・ブロックが作成される時に、各リテラルは、リスト内の最長のリテラルの長さまで、右側にブランクを埋め込まれる。最大リテラル長は、256バイトである。
装置が、IMSコピー機能をサポートする場合に、PFK12が、コピー機能を呼び出し、DEVステートメントのPFK12の定義は無視され、そうでない場合には、PFK12の定義に従う。
FEAT=NOPFKが指定される場合には、FEATがPFKに変更される。ユーザ定義PFKの最大個数は、36である。
指定することができる制御機能は、次の通りである:
NEXTPP−−PAGE ADVANCE
現在の出力メッセージの次の物理ページの要求を指定する。進行中の出力メッセージがない場合には、明示的な応答は行われない。
NEXTMSG−−MESSAGE ADVANCE
進行中の出力メッセージ(ある場合に)を待機解除し、次の出力メッセージ(ある場合に)をキューに送る要求を指定する。
NEXTMSGP−−MESSAGE ADVANCE PROTECT
進行中の出力メッセージ(ある場合に)を待機解除し、次の出力メッセージを送るか、次のメッセージが存在しないことを示す情報メッセージを返す要求を指定する。
NEXTLP−−NEXT LOGICAL PAGE
現在のメッセージの次の論理ページの要求を指定する。
ENDMPPI−−END MULTIPLE PAGE INPUT
複数の物理ページ入力メッセージの終りを指定する。
substitution : String
SUB属性
入力データ・ストリーム内のすべてのX’3F’文字を置換するのにMFSが使用する文字を指定する。このパラメータが、X’3F’として指定されるか、パラメータが指定されないか、受け取られる入力がMFS編集を迂回する場合には、変換は行われない。指定されたSUB文字は、データ・ストリームのどこにも現れてはならず、したがって、非グラフィックでなければならない。
X’ff’
その16進数表現が’ff’である文字によって、入力データ・ストリームのすべてのX’3F’が置換される。
C’c’
文字’c’によって、入力データ・ストリームのすべてのX’3F’が置換される。
type : String
TYPE属性
このフォーマット記述を使用する装置タイプおよび装置のモデル番号を指定する。3275に接続された3284−3プリンタは、TYPE=3270Pとしてのみサポートされる。3284−3のフォーマットを定義する時に指定されるモデル番号は、関連する3275のモデル番号である。
TYPE=3270−Anは、IMSシステム定義中に定義される画面サイズと機能番号n=1−15を有する3270およびSLU 2ディスプレイの記号名を指定する。この指定によって、MFS言語ユーティリティが、MFS装置特性テーブル(DFSUDT0x)を読み取り、画面サイズを抽出する。
width : int
WIDTH属性
このDEVタイプの最大行幅を、下記の1つとして指定する:
− 入力データまたは出力データの行ごとの印刷位置の数
− 入力データまたは出力データのカードごとの穿孔位置の数
− カード・リーダ入力データのカード幅
デフォルトは、3270P出力の120である。行幅は、HTAB=キーワードで左マージン値が指定されるかどうかに無関係に、桁1に対して相対的に指定される。指定される幅は、1以上でなければならない。
3270P装置について、WIDTHが指定される場合に、FEAT=(1…10)も指定されなければならない。FEAT=(1…10)が指定され、WIDTH=が指定されない場合に、WIDTH=のデフォルトは120になる。
【0299】
MFSMessageDescriptor
MSGステートメント
MSGステートメントは、メッセージ入力定義またはメッセージ出力定義を開始し、命名する。
サポートされない属性:
− すべての属性がサポートされる
MFSStatementから派生する
プライベート属性:
fill : String
FILL属性
出力装置フィールドの充てん文字を指定する。このオペランドは、TYPE=OUTPUTの場合に限って有効である。デフォルトは、C’ ’である。充てん指定は、FMT定義のDPAGEステートメントでFILL=NONEが指定されない限り無視される。EGCSフィールドが存在する時の3270出力に関して、FILL=PTまたはFILL=NULLだけを指定しなければならない。FILL=PTでは、データがフィールドに送られる時に限って出力フィールド(1バイト・フィールドまたは2バイト・フィールドのいずれか)を消去し、したがって、アプリケーション・プログラム・メッセージがMFLDを省略する場合に、DFLDを消去しない。
C’c’
文字’c’が、装置フィールドを充てんするのに使用される。3270表示装置について、X’3F’未満の値を伴う指定のすべてが、制御文字は’00’、他の非グラフィック文字はX’40’に変更される。すべての他の装置について、X’3F’未満の値を伴うFILL=C’c’指定のすべてが、無視され、デフォルトのX’3F’にされる(FILL=NULLの指定と同等である)。
NULL
フィールドが充てんされないことを指定する。
PT
3270ディスプレイを除いてNULLと同等である。3270ディスプレイについて、PTは、装置フィールド(DFLD)を充てんしない出力フィールドに、前にフィールド内にあったデータを消去するために、プログラム・タブ文字が続くことを指定する。
ignoreSource : boolean
SOR属性
DEVステートメントと共に、このメッセージ記述子によって処理される端末またはリモート・プログラムのデータ・フィールドを定義する、FMTステートメントのソース名を指定する。TYPE=OUTPUTについてIGNOREを指定すると、MFSが、装置フォーマット定義でそのFEAT=オペランドによってIGNOREが指定される装置に関して指定されるデータ・フィールドが使用されるようになる。TYPE=INPUTの場合、IGNOREは、対応するメッセージ出力記述子でIGNOREが指定される場合に限って指定しなければならない。SOR=IGNOREを使用する場合には、メッセージ入力記述子とメッセージ出力記述子の両方でIGNOREを指定しなければならない。
option : int
OPT属性
メッセージを編集するためにMFSによって使用されるメッセージ・フォーマット・オプションを指定する。デフォルトは、1である。
paging : boolean
PAGE属性
オペレータ論理ページング(順方向および逆方向のページング)が、この制御ブロックを使用して編集されるメッセージについて提供されるか(YES)否か(NO)を指定する。このオペランドは、TYPE=OUTPUTの場合に限って有効である。デフォルトはNOであり、これは、物理ページの順方向ページングだけが提供されることを意味する。
type : MFSDescriptorType
TYPE属性
この定義をメッセージINPUT制御ブロックまたはメッセージOUTPUT制御ブロックとして定義する。デフォルトはINPUTである。
【0300】
MFSLogicalPage
LPAGEステートメント
任意選択のLPAGEステートメントでは、論理ページを含むセグメントのグループが定義される。存在しない場合には、暗黙指定される。
サポートされない属性:
− すべての属性がサポートされる
MFSStatementから派生する
プライベート属性:
condition : MFSConditionType
COND属性
成功の場合に、このLPAGEに従うセグメント定義およびフィールド定義が、この論理ページの出力編集に使用されることを指定する条件テストを記述する。このLPAGEを編集に使用するかどうかを判定するために、論理ページの最初のセグメントの指定された部分が、指定されたリテラル値より大きい(>)、より小さい(<)、以上(<=)、以下(>=)、等しい(=)、等しくない(ne)かどうかを判定するために検査される。COND=は、MSG定義の最後のLPAGEステートメントには不要である。
検査される区域は、フィールド名(mfldname)、フィールド内のオフセット(mfldname(pp)、このppは、名前を指定されたフィールド内のオフセットである)、またはセグメント内のオフセット(segoffset)によって定義することができる。mfldname(pp)形式が使用される場合には、ppは、1以上でなければならない。比較の長さは、指定されたリテラルの長さである。前のMSGステートメントでOPT=3が指定される場合には、検査される区域が、MFLDステートメントで定義される1フィールド以内でなければならない。
segoffsetが使用される場合に、これは0に対する相対値であり、そのオフセットの指定は、セグメントのLLZZを考慮しなければならない(すなわち、最初のデータ・バイトがオフセット4にある)。
ppが使用される場合に、オフセットは、名前を指定されたフィールドに関して1に対する相対値である(すなわち、フィールド内の最初のバイトが、0ではなくオフセット1にある)。指定されるmfldnameがATTR=YESを用いて定義されている場合には、ppオフセットを使用しなければならない。指定される最小オフセットは、3でなければならない。すなわち、フィールド内のデータの最初のバイトが、2バイトの属性に続いて、オフセット3にある。
ATTR=nnが指定される場合には、最小オフセットは、1にnnの2倍を加えたものでなければならない。したがって、ATTR=2が指定される場合には、ppは少なくとも5でなければならず、ATTR=(YES,2)が指定される場合には、ppは少なくとも7でなければならない。
すべてのLPAGEに関する条件テストが失敗した場合に、このMSG定義の最後のLPAGEが、編集に使用される。
LPAGE選択が、コマンド・データ・フィールドを使用して指定される、すなわち、/FORMATmodname…(データ)である場合には、LPAGE COND=mfldnameパラメータで指定されるMFLDが、MODの関連するLPAGEの最初の8バイト以内でなければならない。
promptValue : String
【0301】
LPAGE COND=mfldname
SEGステートメント
SEGステートメントは、メッセージ・セグメントの輪郭を描き、複数セグメント・メッセージ処理がアプリケーション・プログラムによって要求される場合に限って必要である。出力メッセージ・セグメントは、ユーザが指定したキュー・バッファ長を超えることができない。入力メッセージ宛先が単一のセグメント・コマンドまたはトランザクションとして定義される時に、TYPE=INPUT MSGについて、1つのセグメントだけを定義しなければならない。複数のセグメントが定義され、その定義が、単一のセグメント・コマンドまたはトランザクションを入力するのに指定される場合には、ユーザ入力が、編集後に1つのセグメントだけを作るようにするために注意しなければならない。存在しない場合には暗黙指定される。
サポートされない属性:
− すべての属性がサポートされる
MFSStatementから派生する
プライベート属性:
exit : MFSExitType
EXIT属性
このメッセージ・セグメントのセグメント編集出口ルーチン・インターフェースを記述する。exitNumは、出口ルーチン番号であり、exitvectは、このセグメントのために出口ルーチンが呼び出される時に出口ルーチンに渡される値である。exitNumは、0から127までの範囲とすることができる。exitvectは、0から255までの範囲とすることができる。この入力セグメントについて処理が完了した時に、SEG出口が呼び出される。
graphic : boolean
GRAPHIC属性
MSG TYPE=INPUTについて、宛先定義が大文字変換を要求する場合に、IMSがこのセグメントに対して大文字変換を実行するか(YES)否か(NO)を指定する(TRANSACTまたはNAMEマクロのEDIT=パラメータを参照されたい)。デフォルトはYESである。入力セグメント・データが、非グラフィック・フォーマット(パック10進、EGCS、2進、など)の場合には、GRAPHIC=NOを指定しなければならない。GRAPHIC=NOが指定される時に、このセグメント内のMFLDについて、FILL=NULLは無効である。
下のリストに、GRAPHIC=YESが指定され、入力メッセージ宛先が、大文字変換を要求するものとして定義される時に行われる変換を示す:
変換前 変換後
aからzまで AからZまで
X’81’からX’89’まで X’C1’からX’C9’まで
X’91’からX’99’まで X’D1’からX’D9’まで
X’A2’からX’A9’まで X’E2’からX’E9’まで
GRAPHIC=YESとして定義されたセグメント内のMFLDについてFILL=NULLが指定される場合に、16進文字X’3F’が、セグメントから圧縮される。SEGステートメントでGRAPHIC=NOおよびFILL=NULLが指定される場合に、非グラフィック・データ・ストリームのすべてのX’3F’が、セグメントから圧縮され、望ましくない結果が作られる可能性がある。非グラフィック・データは、固定長出力フィールドとして出力に送られなければならず、この場合にはFILL=NULLの使用は推奨されない。
MSG TYPE=OUTPUTについて、GRAPHIC=キーワードは、DPMだけに適用される。これは、IMSアプリケーション・プログラムからのデータ内の非グラフィック制御文字(X’00’からX’3F’まで)が、ブランクに置換されるか(YES)否か(NO)を指定する。デフォルト値はYESである。NOが指定される場合に、MFSは、IMSアプリケーション・プログラムから受け取るビット・ストリングのすべてが、MFSを介してリモート・プログラムに無変更で流れられるようにする。
制約:GRAPHIC=NOが指定される時に、Options 1および2を使用するIMSアプリケーション・プログラムは、LPAGEの途中でセグメントを省略するか、ヌル文字(X’3F’)を使用してセグメント内のフィールドを切り捨てるか省略することができない。
【0302】
MFSMessageField
MFLDステートメント
MFLDステートメントでは、メッセージ出力セグメントの一部としてアプリケーション・プログラムに提示されるメッセージ・フィールドを定義する。MSG定義ごとに、少なくとも1つのMFLDステートメントを指定しなければならない。
サポートされない属性:
− すべての属性がサポートされる
MFSStatementから派生する
プライベート属性:
attributes : boolean
ATTR属性
アプリケーション・プログラムが3270属性および拡張属性(nn)を修正できるか(YES)否か(NO)を指定する。
YESの場合には、2バイトを、出力にアプリケーション・プログラムが充てんし、入力時にブランクに初期化される3270属性データとして予約しなければならない。これらの2バイトは、LTH=指定に含まれなければならない。
nnに指定される値は、動的に修正することができる拡張属性の数である。nnの値は、1から6までの数とすることができる。無効な指定は、デフォルトの1になる。属性ごとに2つの追加バイトが、出力時にアプリケーション・プログラムによって充てんされ、入力時に空白に初期化される拡張属性データのために予約されなければならない。この属性バイトは、MFLD LTH=指定に含まれなければならない。
例:下に示されているのは、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およびnnは、出力メッセージで位置パラメータを介してリテラル値が指定された場合には無効である。
別のIMS ISCサブシステムに送られるフィールドの属性は、受け取るサブシステムのフォーマットでのATTR=指定に無関係に、MFSによって入力データとして扱われる。たとえば、ATTR=(YES,1)、LTH=5として定義されたメッセージ・フィールド(MFLD)に、下記が含まれる:
00A0C2F1C8C5D3D3D6
受け取るサブシステムのMFLDが、ATTR=なしでLTH=9として定義される場合には、アプリケーション・プログラムが、下記を受け取る:
00A0C2F1C8C5D3D3D6
受け取るサブシステムのMFLDが、LTH=13およびATTR=(YES,1)として定義される場合には、アプリケーション・プログラムが、下記を受け取る:
4040404000A0C2F1C8C5D3D3D6
受け取るサブシステムのMFLDが、LTH=5およびATTR=(YES,1)として定義される場合には、アプリケーション・プログラムが、下記を受け取る:
4040404000A0C2F1C8
入力SEGステートメントは、属性データの大文字への変換を避けるために、GRAPHIC=NOとして指定されなければならない。
exit : MFSExitType
EXIT属性
このメッセージ・フィールドのフィールド編集出口ルーチン・インターフェースを記述する。出口ルーチン番号は、exitNumで指定され、exitvectは、出口ルーチンがこのフィールドについて呼び出される時に出口ルーチンに渡される値である。exitNumの値は、0から127までの範囲とすることができる。exitvectの値は、0から255までの範囲とすることができる。MFS編集後(オプション1および2に関するNULL圧縮の前)に存在するフィールドのアドレスが、そのフィールドについて定義されたベクトルと共に、編集出口ルーチンに渡される(DPM装置についてNOFLDEXITが指定される場合には、出口ルーチンは呼び出されない)。出口ルーチンは、0から255までの値を有するコードを返すことができる。MFSは、セグメント編集ルーチンによる使用のために、セグメントごとに、そのような返される最大のコードを維持する。同一のMFLDステートメントで’リテラル’が指定される場合には、EXIT=は無効である。
extendedAttributes : int
ATTR属性
アプリケーション・プログラムが3270属性および拡張属性(nn)を修正できるか(YES)否か(NO)を指定する。
YESの場合には、2バイトを、出力にアプリケーション・プログラムが充てんし、入力時にブランクに初期化される3270属性データとして予約しなければならない。これらの2バイトは、LTH=指定に含まれなければならない。
nnに指定される値は、動的に修正することができる拡張属性の数である。nnの値は、1から6までの数とすることができる。無効な指定は、デフォルトの1になる。属性ごとに2つの追加バイトが、出力時にアプリケーション・プログラムによって充てんされ、入力時に空白に初期化される拡張属性データのために予約されなければならない。この属性バイトは、MFLD LTH=指定に含まれなければならない。
例:下に示されているのは、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およびnnは、出力メッセージで位置パラメータを介してリテラル値が指定された場合には無効である。
別のIMS ISCサブシステムに送られるフィールドの属性は、受け取るサブシステムのフォーマットでのATTR=指定に無関係に、MFSによって入力データとして扱われる。たとえば、ATTR=(YES,1)、LTH=5として定義されたメッセージ・フィールド(MFLD)に、下記が含まれる:
00A0C2F1C8C5D3D3D6
受け取るサブシステムのMFLDが、ATTR=なしでLTH=9として定義される場合には、アプリケーション・プログラムが、下記を受け取る:
00A0C2F1C8C5D3D3D6
受け取るサブシステムのMFLDが、LTH=13およびATTR=(YES,1)として定義される場合には、アプリケーション・プログラムが、下記を受け取る:
4040404000A0C2F1C8C5D3D3D6
受け取るサブシステムのMFLDが、LTH=5およびATTR=(YES,1)として定義される場合には、アプリケーション・プログラムが、下記を受け取る:
4040404000A0C2F1C8
入力SEGステートメントは、属性データの大文字への変換を避けるために、GRAPHIC=NOとして指定されなければならない。
fill : String
FILL属性
装置から受け取るデータの長さがこのフィールドの長さより短い時に、このフィールドに埋め込むのに使用される文字を指定する。この文字は、このフィールドについてデータが受け取られない時にも(MSGステートメントでオプション3が指定された時を除く)、埋込みに使用される。このオペランドは、TYPE=INPUTの場合に限って有効である。デフォルトは、X’40’である。
X’hh’
その16進数表現がhhである文字が、フィールドを充てんするのに使用される。FILL=X’3F’は、FILL=NULLと同一である。
C’c’
文字’c’によって、フィールドが充てんされる。
NULL
フィールド内の欠けているデータの量だけ左へのメッセージ・セグメントの圧縮が行われる。
justify : MFSJustifyType
JUST属性
データ・フィールドが、左寄せ(L)または右寄せ(R)され、装置フォーマット制御ブロックによって期待されるか提示されるデータの量に依存して、必要なだけ右切捨または左切捨が行われるデータ・フィールドを指定する。デフォルトはLである。
length : MFSLengthType
LTH属性
リテラルが位置オペランド(TYPE=INPUT)で指定される場合に省略することができ、この場合には、リテラルについて指定された長さが使用される。LTH=がリテラル・フィールドについて指定される場合には、指定されるリテラルが、切り捨てられるか、指定された長さまでブランクを埋め込まれる。MFLDステートメントがDOステートメントとENDDOステートメントの間にある場合には、LTH=がMFLDソース・ステートメントで指定されているかどうかに無関係に、長さの値が、生成されるMFLDステートメントに印刷される。
value : String
value属性
これは、以下の説明の’literal’フィールドに対応する。
装置フィールド名は、’deviceFields’関係を介して指定される。
入力データがそこから抽出されるか、出力データがそこに配置される装置フィールド名(DEVステートメントまたはDFLDステートメントを介して定義される)を指定する。メッセージ出力制御ブロックを定義する時にこのパラメータが省略された場合には、アプリケーション・プログラムによって供給されるデータが、出力装置に表示されない。MFSの反復生成機能(DOステートメントおよびENDDOステートメント)が使用される場合には、dfldnameが、6文字の最大長に制限されなければならない。ステートメントの各反復が生成される時に、2文字のシーケンス番号(01から99まで)が、dfldnameに付加される。ここで指定されるdfldnameが、6バイトを超え、反復生成が使用される場合に、dfldnameが6文字目で切り捨てられ、2文字のシーケンス番号が付加されて、8文字の名前が形成される。これが行われる場合に、エラー・メッセージは提供されない。このパラメータは、下記のフォーマットの1つで指定することができる:
dfldname
入力データがそこから抽出されるか、出力データがそこに配置される装置フィールド名を識別する。
’literal’
リテラル値が入力メッセージに挿入される場合に指定することができる。
(dfldname,’literal’)
TYPE=OUTPUTの場合に、これによって、リテラル・データが名前付きDFLDに配置されることが記述される。この形が指定される時には、リテラルのスペースを、アプリケーション・プログラムによって供給される出力メッセージ・セグメント内で割り振ってはならない。
TYPE=INPUTの場合に、これによって、このフィールドのデータが装置から受け取られない時にメッセージ・フィールドにリテラル・データが配置されることが記述される。このdfldnameが、DEVステートメントのPFKパラメータで使用される場合には、このリテラルが、必ずPFキー・リテラルまたは制御機能によって置換される。しかし、このdfldnameがPFKパラメータで指定されるが、PFキーが使用されない時には、MFLDステートメントで指定されたリテラルが、メッセージ・フィールドに移動される。物理ページングが使用される時に、リテラルは、フィールドに挿入されるが、論理ページの最後の物理ページが表示された後までは処理されない。
両方の場合で、LTH=オペランドが指定される場合には、LTH=指定の長さの必要に応じて、リテラルの長さが切り捨てられるか埋め込まれる。指定されたリテラルの長さが、定義されたフィールド長より短い場合には、リテラルに、TYPE=OUTPUTならばブランク、TYPE=INPUTならば指定された充てん文字(FILL=)が埋め込まれる。充てん文字が入力について指定されない場合には、リテラルは、ブランクを充てんされる(デフォルト)。リテラル値の長さは、256バイトを超えることができない。
(dfldname,system-literal)
システム・リテラルのリストから名前を指定する。システム・リテラルは、リテラル値が、装置への送信の前のフォーマット中に作成されることを除いて、通常のリテラルと同様に機能する。LTH=オペランド、ATTR=オペランド、およびJUST=オペランドを指定することはできない。この形が指定される時には、リテラルのスペースを、アプリケーション・プログラムによって供給される出力メッセージ・セグメント内で割り振ってはならない。
(,SCA)
この出力フィールドを、出力装置に表示されないシステム制御域として定義する。1論理ページ(LPAGE)内に1つだけそのようなフィールドを設けることができ、このフィールドは、そのページの最初のメッセージ・セグメント内になければならない。論理ページが定義されない場合には、1つのSCAフィールドだけを定義することができ、そのSCAフィールドは、出力メッセージの最初のセグメント内になければならない。この指定は、前のMSGステートメントでTYPE=OUTPUTが指定された場合に限って有効である。
【0303】
MFSDevicePage
DPAGEステートメント
DPAGEステートメントでは、装置フォーマットの論理ページを定義する。このステートメントは、この装置フォーマット(FMT)を参照するメッセージ記述子のどれにもLPAGEステートメントが含まれず、特定の装置オプションが不要である場合に、省略することができる。存在しない場合には、暗黙指定される。
サポートされない属性:
− ACTVPID
− COND
− OFTAB
− ORIGIN
− PD
− SELECT
MFSStatementから派生する
プライベート属性:
cursor : MFSCursorType
CURSOR属性
物理ページ上のカーソルの位置を指定する。論理ページまたはメッセージが複数の物理ページからなる場合に、複数のカーソル位置が必要になる可能性がある。値lllが、行番号を指定し、cccが、列を指定する;lllおよびcccの両方が、1以上でなければならない。カーソル位置は、定義されたフィールド上またはデフォルトのどちらかでなければならない。3270ディスプレイのデフォルトlll、ccc値は、1、2である。財務ディスプレイ・コンポーネントについて、カーソル位置が指定されない場合に、MFSは、カーソルを位置決めしない−カーソルは、通常は、装置上の出力データの末尾に配置される。財務ディスプレイ・コンポーネントについて、ORIGIN=パラメータが指定されたかどうかに無関係に、すべてのカーソル位置が絶対位置である。
dfldパラメータによって、入力時にアプリケーション・プログラムにカーソル情報を供給し、出力時にアプリケーション・プログラムがカーソル位置を指定できるようにする方法が提供される。
推奨:出力カーソル位置決めにはカーソル属性機能を使用する(MFLDステートメントでATTR=YESを指定する)。
dfldパラメータによって、カーソル位置を含むフィールドの名前が指定される。この名前は、MFLDステートメントによって参照される可能性があり、このDEV定義のDFLDステートメントのラベルとして使用してはならない。このフィールドのフォーマットは、それぞれ行と列の番号を含む2つの2進ハーフワードである。このフィールドが、メッセージ入力記述子によって参照される時に、このフィールドに、メッセージ入力時のカーソル位置が含まれる。メッセージ出力記述子によって参照される時に、アプリケーション・プログラムが、それぞれ行と列を含む2進ハーフワードとしてこのフィールドに所望のカーソル位置を置く。名前を指定されたフィールドに2進数0があると、指定されたlll、cccが、出力中にカーソル位置に使用されるようになる。入力中には、このフィールドの2進数0は、カーソル位置が定義されないことを示す。このdfldを参照する入力MFLDは、GRAPHIC=NOを指定されたセグメント内で定義されるか、2進数を10進数に変換するためにEXIT=(0,2)を使用しなければならない。
fill : String
FILL属性
出力装置フィールドの充てん文字を指定する。3270ディスプレイを除くすべての装置タイプのデフォルト値は、X’40’であり、3270ディスプレイのデフォルトは、PTである。EGCSフィールドが存在する時の3270出力について、FILL=PTまたはFILL=NULLだけを指定しなければならない。FILL=PTでは、データがフィールドに送られる時に限って、出力フィールド(1バイト・フィールドまたは2バイト・フィールドのいずれか)が消去され、したがって、アプリケーション・プログラム・メッセージでMFLDが省略される場合に、DFLDは消去されない。
NONE
メッセージ出力記述子からの充てん文字が、装置フィールドを充てんするのに使用される場合に指定されなければならない。
X’hh’
その16進数表現がhhである文字が、装置フィールドを充てんするのに使用される。
C’c’
文字’c’が、装置フィールドを充てんするのに使用される。
NULL
フィールドが充てんされないことを指定する。3270ディスプレイ以外の装置について、メッセージ・データが装置フィールドを満たさない時に、「短縮された行」が作られる。
PT
装置フィールド(DFLD)を満たさない出力フィールドに、そのフィールドに前に存在したデータを消去するプログラム・タブ文字が続くことを指定する;それ以外は、この動作はFILL=NULLと同一である。
3270ディスプレイ装置について、X’3F’未満の値を有するすべての指定が、制御文字はX’00’、他の非グラフィック文字はX’40’に変更される。
multiplePages : boolean
MULT属性
このDPAGEについて複数の物理ページ入力メッセージが許容されることを指定する。
【0304】
MFSDeviceField
DFLDステートメント
DFLDステートメントでは、端末またはリモート・プログラムから読み取られるか書き込まれる、装置フォーマット内のフィールドを定義する。IMSまたはリモート・アプリケーション・プログラムに重要な区域だけを定義しなければならない。フォーマットのヌル・スペースは、定義する必要がない。
サポートされない属性:
− SLD
MFSStatementから派生する
プライベート属性:
attributes : MFSAttributeType
ATTR属性
extendedAttributes : MFSExtendedAttributeType
EATTR属性
length : int
LTH属性
フィールドの長さを指定する。このオペランドは、位置パラメータで’literal’が指定される場合には省略されなければならず、その場合には、リテラルの長さが、フィールド長として使用される。このオペランドが’literal’と共に使用され、この2つの長さが異なる場合に、予測不能な出力フォーマットが行われる可能性がある。指定されるLTH=は、装置の物理ページ・サイズを超えることができない。
3270、3604ディスプレイ、およびRCDCT=NOSPANを伴うDPMを除く最大の許容可能な長さは、8000文字である。3270ディスプレイについて、最大長は、画面サイズより1つ少ない。たとえば、480文字ディスプレイについて、最大長は479文字である。0の長さを指定してはならない。SCAとLTH=の両方が指定される場合には、LTHが2でなければならない。
POS=およびLTH=に、3270ディスプレイ装置またはATTR=YESを指定されたDFLDについて予約されている属性文字位置を含めてはならない。ディスプレイ/プリンタ・フォーマットの設計にこのバイトを含めることは、それがアプリケーション・プログラムによってアクセス可能でない場合であっても、それが、表示/印刷されるフィールドのそれぞれに先行する画面/印刷されるページ位置を占めるので、必要である。
3270プリンタのDFLDを定義する時には、ハードウェアATTRIBUTE文字は使用されない。したがって、フィールドは、ATTR=YESが指定されない限り、属性文字を許容しない並置を用いて定義しなければならない。しかし、3270Pとして定義されるプリンタについて、印刷行の最後の桁(FEAT=、WIDTH=、または装置のデフォルト幅に基づく)を使用することはできない。行の最後の桁は、IMSによって実行される紙送り制御動作用に予約されている。したがって、印刷行で120が指定され(FEAT=120)、DFLDでPOS=(1,1)、LTH=120が指定される場合に、119文字が行1に印刷され、1文字が行2に印刷される。
検出可能フィールド(DETまたはIDET)には、検出可能フィールドが表示行の最後のフィールドでない限り(この場合には、検出指定文字の1位置だけが必要)、1バイトの検出指定文字と3つの埋込み文字のための4つの位置が、POSおよびLTHに含まれなければならない。検出指定文字は、フィールド・データに先行しなければならず、埋込み文字(必要な場合)は、フィールド・データの後に続かなければならない。検出指定文字および必要な埋込み文字は、アプリケーション・プログラムまたはフィールド・データに伴うMFLDリテラルによって供給されなければならない。埋込み文字は、装置の先行するフィールドにも必要になる可能性がある。
pen : String
PEN属性
このフィールドが検出される時に選択されるリテラルまたは実行されるオペレータ制御機能を指定する。(1)’literal’が指定され、(2)フィールドが即座に検出可能(ATTR=オペランド)として定義され、(3)ヌル文字またはスペース指定文字が含まれる場合に、フィールドが検出される時(他の装置フィールドが修正されない場合)に、指定されたリテラルが、前のDEVステートメントのPENオペランドによって参照されるフィールドに配置される。装置の別のフィールドが修正される場合には、リテラルの代わりに疑問符(?)が供給される。リテラルの長さは、256バイトを超えてはならない。
(1)制御機能が指定され、(2)フィールドが即座に検出可能(ATTR=オペランド)として定義され、(3)ヌル文字またはスペース指定文字が含まれる場合に、フィールドが検出され、他の装置フィールドが修正されない時に、指定された制御機能が実行される。装置の別のフィールドが修正される場合には、疑問符(?)が提供され、機能は実行されない。指定することができる制御機能は次の通りである:
NEXTPP--PAGE ADVANCE
現在の出力メッセージの次の物理ページの要求を指定する。進行中の出力メッセージがない場合には、明示的な応答は行われない。
NEXTMSG--MESSAGE ADVANCE
進行中の出力メッセージ(ある場合に)を待機解除し、キューの次の出力メッセージ(ある場合に)を送る要求を指定する。
NEXTMSGP--MESSAGE ADVANCE PROTECT
進行中の出力メッセージ(ある場合に)を待機解除し、次の出力メッセージを送るか、次のメッセージが存在しないことを示す情報メッセージを返す要求を指定する。
NEXTLP--NEXT LOGICAL PAGE
現在のメッセージの次の論理ページの要求を指定する。
ENDMPPI--END MULTIPLE PAGE INPUT
複数の物理ページ入力メッセージの終りを指定する。
ENDMPPIは、データが受信された場合に限って有効であり、データ入力がない場合の複数ページ入力(MPPI)は終了されない。
position : MFSPositionType
POS属性
表示フォーマットの行(lll)、桁(ccc)、および物理ページ(pp)に関してこのフィールドの最初のデータ位置を定義する。ppが省略された場合には、1が仮定される。
DEV TYPE=3270、3270−An、または3270P用
lll,ccc,pp
出力フィールドの行、桁、および、任意指定として物理ページ番号を指定する。lll、ccc、およびppは、1以上でなければならない。
3270ディスプレイについて、POS=(1,1)を指定しなければならない。最下部から最上部にラップするフィールドを定義してはならない。
制約:3270のいくつかのモデルで、行1、桁2から始まるフィールドがアルファベット属性と保護属性の両方を有する時に、表示画面をコピーすることができない。
value : String
【0305】
MFSTable
TABLEステートメント
TABLEステートメントでは、DFLDステートメントのOPCTLキーワードによって参照することができるオペレータ制御テーブルを開始し、名前を付ける。TABLEステートメントおよびそれに続くIFおよびTABLEENDステートメントは、MSG定義またはFMT定義の外になければならない。
サポートされない属性:
− すべての属性がサポートされる
MFSStatementから派生する
【0306】
MFSDeviceDivision
DIVステートメント
DIVステートメントでは、DIFまたはDOF内の装置フォーマットを定義する。フォーマットは、入力、出力、または入力と出力の両方として識別され、複数の物理ページから構成することができる。DEVごとに1つのDIVステートメントだけが許容される。
サポートされない属性:
− RCDCTL
− HDRCTL
− OPTIONS
− OFTAB
− DPN
− PRN
− RDPN
− RPRN
MFSStatementから派生する
プライベート属性:
type : MFSDescriptorType
TYPE属性
入力専用フォーマット(INPUT)、出力専用フォーマット(OUTPUT)、または両方(INOUT)を記述する。
DIV TYPE=OUTPUTまたはTYPE=INPUTが指定される場合に、ある種のDEVステートメント・キーワードが適用可能である。
compression : MFSCompressionType
COMPR属性
短いフィールド、固定長フィールド、またはアプリケーション・プログラムによって提示されるすべてのフィールドから末尾ブランクを除去するようにMFSに要求する。
【0307】
MFSIfCondition
IFステートメント
IFステートメントでは、前のTABLEステートメントによって名前を付けられたテーブル内の項目を定義する。各IFステートメントで、条件演算と、条件が真である場合に実行される関連する制御機能または分岐機能が定義される。
サポートされない属性:
− すべての属性がサポートされる
MFSStatementから派生する
プライベート属性:
condition : MFSConditionType
条件属性
条件は、下記のフォーマットを有する:
IF (DATA | LENGTH) (=,<,>,≠,≧,≦)
(literal | data-length) function
DATA
条件演算が、フィールドについて装置から受け取られたデータに対して実行されることを指定する。
LENGTH
条件演算が、フィールドについて入力された文字の数をテストすることを指定する。このフィールドのサイズ限界は、DFLDと同一である(トピック2.5.1.5.8の「DFLDステートメント」を参照されたい)。
=,<,>,≠,≧,≦
指定された制御機能を呼び出すために真にならなければならない条件関係を指定する。
’literal’
入力データが比較されるリテラル・ストリングである。比較は、入力を大文字に変換する前に行われる。’literal’が指定される場合には、DATAが第1オペランドで指定されなければならない。入力データ長が、リテラル・ストリング長と等しくない場合には、比較は、条件関係が≠でなく、データ長が0でない限り(この場合には制御機能が実行される)、短い方の長さを用いて実行される。入力が小文字の場合には、ALPHAステートメントを使用しなければならず、リテラルが小文字でコード化されなければならない。
data-length
比較されるフィールドの入力データがの文字の数の整数値を指定する。
NOFUNC
条件機能テストが終了することを指定する。
NEXTPP--PAGE ADVANCE
現在の出力メッセージの次の物理ページの要求を指定する。進行中の出力メッセージがない場合には、明示的な応答は行われない。
NEXTMSG--MESSAGE ADVANCE
進行中の出力メッセージ(ある場合に)を待機解除し、キューの次の出力メッセージ(ある場合に)を送る要求を指定する。
NEXTMSGP--MESSAGE ADVANCE PROTECT
進行中の出力メッセージ(ある場合に)を待機解除し、次の出力メッセージを送るか、次のメッセージが存在しないことを示す情報メッセージを返す要求を指定する。
NEXTLP--NEXT LOGICAL PAGE
現在のメッセージの次の論理ページの要求を指定する。
PAGEREQ--LOGICAL PAGE REQUEST
入力データの2番目から最後までの文字を論理ページ要求とみなさなければならないことを指定する。
ENDMPPI--END MULTIPLE PAGE INPUT
複数物理ページ入力の終り(この入力が、作成されるメッセージの最後の入力である)を指定する。
action : String
【0308】
MFSPassword
PASSWORDステートメント
PASSWORDステートメントでは、IMSパスワードとして使用される1つまたは複数のフィールドを識別する。使用される時に、PASSWORDステートメントおよびそれに関連するMFLDが、入力のLPAGEまたはMSGの定義の最初のSEGステートメントに先行しなければならない。8つまでのMFLDステートメントを、PASSWORDステートメントの後で指定することができるが、パスワードの全長が、8文字を超えてはならない。充てん文字は、X’40’でなければならない。オプション1および2のメッセージについて、編集後のデータの最初の8文字が、IMSパスワードに使用される。オプション3のメッセージについて、編集後の第1フィールドのデータ内容が、IMSパスワードに使用される。
3270入力に関するパスワードは、DFLDステートメントで定義することもできる。両方のパスワード方法が使用される場合には、MSG定義で指定されたパスワードが使用される。
サポートされない属性:
− すべての属性がサポートされる
MFSStatementから派生する
【0309】
MFSDeviceDescriptor
FMTステートメント
FMTステートメントでは、DEVステートメントで指定される装置タイプおよび特徴でのみ異なる1つまたは複数の装置フォーマットを含むフォーマット定義を開始し、名前を付ける。このフォーマット定義に含まれる各装置フォーマットによって、装置またはリモート・プログラムから送信または受信されるデータのレイアウトが指定される。
サポートされない属性:
− すべての属性がサポートされる
MFSStatementから派生する
【0310】
MFSFunctionKeyType
プライベート属性:
fieldName : String
【0311】
MFSFunctionKeyValueType
プライベート属性:
index : int
function : String
【0312】
MFSFormatLibrary
このクラスは、FORMATLIBの効果を複製するために設計された。言い換えると、これは、MFSソース・ファイルがそれを中心にしてグループ化される中心点として働く。
このクラスは、他のソース・ファイル内のMSGステートメントを参照するMSGステートメントおよびLPAGEステートメントの問題に対処するために導入された。所与のformatlib内のすべてのソース・ファイルを1回で解析することをユーザに強制するのではなく、MSGポインタのコンテナとして働くためにこのクラスが追加された。詳細については、MFSMessagePointerの資料を参照されたい。
プライベート属性:
name : String
【0313】
MFSMessagePointer
このクラスは、MSGステートメントのプレースホルダとして働くように設計された。NXT属性(nextMessage関係)から実際のMSGステートメントを指すのではなく、MSGステートメントおよびLPAGEステートメントが、このクラスのインスタンスを指す。
このクラスの新しいインスタンスは、MSGステートメントまたはLPAGEステートメントが、この特定のFORMATLIBで表されないMSGステートメントを指す時に作成される。新しいインスタンスは、MSGステートメントが解析され、そのステートメントがまだここで表されていない場合にも作成される。
プライベート属性:
name : String
【0314】
総計:
1論理パッケージ
16クラス
論理パッケージ構造
論理ビュー
mfs
【0315】
7.共通アプリケーション・メタモデルおよびシステムの例示的アプリケーション
複数の個々のプラットフォームにまたがって発生するさまざまな複雑なトランザクションが、共通アプリケーション・メタモデルのシームレス性および透過性を必要とする。これらのトランザクションには、「リッチ」・トランザクション、高水準グループ・ウェア、および財務トランザクションが含まれる。
【0316】
図47に、たとえば注文が端末で入力され、ウェブ・サーバに渡され、ウェブ・サーバを介して製造業者のアプリケーション・サーバに渡される、「リッチ」トランザクションに関する単純化されたネットワーク構成を示す。製造業者のアプリケーション・サーバは、それ自体のデータベース・サーバならびに、本明細書に記載のコネクタによって透過的に接続されたそのベンダの似ていない非互換のデータベース・サーバおよびデータベースを介して検索し、コンポーネントの状況、価格、および配送日付を照会し、注文を満足するのに必要なコンポーネントの注文を行う。
【0317】
制限ではなく厳密に例示のために、リッチ・トランザクションを、新しい自動車の構成および注文から、自動車の資金調達、新しい自動車の要素および構成要素の収集、自動車の組立、顧客への送達を介する、自動車の購入を用いて例示する。たとえば、自動車を構成する際に、たとえば技術的理由または性能的理由から、エンジンのあるサブセットを含めることを除外しながらエンジンの別のサブセットを含めることを必要とするトラクション・コントロール・モジュールを含めることを検討する。同様に、ある色の選択によって、たとえば在庫または使用可能性の理由から、ある車内装飾の組合せが排除される場合がある。もちろん、エンジンおよびトランスミッションを選択しない場合には、自動車は得られない。いくつかの選択を、行わなければならない。問題は、「’X’を選択する場合に、’Y’および’Z’も選択しなければならないが、’Y’を選択する場合には、’A’または’B’を得ることができず、既に‘A’が選択されている」の1つである。すなわち、ある構成要素またはサブシステムの選択によって、前に選択された構成要素またはサブシステムがシステムから除去される場合がある。しばしば供給パイプラインの選択された要素の使用可能性に基づいて、自動車を構成した後に、注文が、製造スケジューリングを含めて実行のために製造業者のサーバに送信される。製造業者は、供給チェーンのベンダ、たとえばトランスミッション・ベンダに照会し、このベンダが、コントローラ・ベンダ、ギア・ベンダ、ハウジング・ベンダ、油圧導管ベンダなどに照会する。これらのベンダが、そのサブベンダに照会する。
【0318】
コネクタの方法およびシステムを使用して、ディーラおよび顧客が、端末3901で自動車を構成し、注文する。構成および注文の入力が、製造業者のサーバ3911に送信される。製造業者のサーバは、サーバ3921、3931、および3441(サーバ3921は、製造業者の自社構成要素事業およびその購入機能のサーバとすることができる)またはその直接ベンダに照会し、この直接ベンダが、第3のサブベンダのサーバ3923、3933、および3943に照会する。照会は、アクセス許可の対象になる「空白埋め」SQL照会の形とすることができる。サブベンダのサーバ3923、3933、および3943は、クライアントとしてのベンダのサーバ3921、3931、および3441に特殊ビューを提示し、このベンダのサーバが、クライアントとしての製造業者のサーバ3911に特殊ビューを提示する。製造業者のサーバ3911に返されるデータは、最適化アプリケーションおよび生産スケジューリング・アプリケーションを用いて最適化して、ディーラのサーバ側の買い手に通し番号および送達日付を提示することができる。
【0319】
本発明のコネクタのもう1つの応用例が、グループウェアとの接続にあり、特に、「グループウェアの島」を一緒にリンクすることである。「グループウェア」は、グループの作業を容易にするように設計された技術に適用される広義の用語である。グループウェア技術は、通信、協力、調整、問題解決、競合、または折衝に使用することができる。アプリケーションのグループウェア・スイートは、人々が、互いに遠隔地に位置する場合であっても、一緒に協力して作業するのを助けるプログラムからなる。グループウェア・サービスには、カレンダの共用、集団執筆、電子メール処理、共用データベース・アクセス、電子会議、ビデオ会議、および他の活動を含めることができる。
【0320】
図48に、複数の異なるプラットフォームで稼動し、本明細書に記載のコネクタによって接続される、複数のグループ・ウェア・アプリケーションにまたがって分散されたグループ・ウェア・セッションを示す。特に示されているのは、2つのグループウェア・システム4010および4020である。各システムには、電子メール、スケジュール/カレンダ、ワード・プロセッサ、スプレッド・シート、グラフィックス、およびCTI(コンピュータ・テレフォニー統合)などの電子メール対応アプリケーション4013および4023が含まれる。これらは、メッセージAPI4015および4025と、オペレーティング・システム4017および4027と、ローカル・グループウェア・サーバ4011および4021によってサポートされる。ローカル・グループウェア・サーバ4011および4021のそれぞれが、本発明のコネクタ、電子メール・サーバ、電子メール・データ・ベース、ディレクトリ・サーバ、および複製データベースを有する。2つのローカル・グループウェア・サーバ4011および4021は、インターネット、LAN、WAN、またはPSTNなどの遠隔通信媒体を介して通信する。
【0321】
電子メールは、断然一般的であり基本的なグループウェア・アプリケーションである。基本的な技術は、人の間で単純なメッセージを渡すように設計されているが、現在の比較的単純な電子メール・システムであっても、メッセージ転送、メッセージのファイリング、メーリング・グループの作成、およびメッセージへのファイルの添付の機能が含まれる。調査されてきた他の機能には、メッセージの内容ベースのソートおよび処理、メッセージの内容ベースのルーティング、および構造化された通信(ある情報を要求するメッセージ)が含まれる。
【0322】
ワークフロー・システムが、グループウェアのもう1つの要素である。ワーク・フロー・システムを用いると、比較的固定されたプロセスを介して、組織内で文書をルーティングできるようになる。ワークフロー・アプリケーションの単純な例が、組織の経費報告である:ある従業員が、経費報告を入力し、サブミットし、コピーが、アーカイブされ、その後、従業員の上司に許可のためにルーティングされ、上司が文書を受け取り、電子的に承認し、回送し、経費が、グループの口座に登録され、支払いのために会計部門に転送される。ワークフロー・システムは、ルーティング、フォームの開発、異なる役職および特権のサポートを提供することができる。
【0323】
ハイパーテキストは、テキスト文書を互いにリンクするシステムであり、ウェブが明白な例である。しかし、複数の人が文書を作成し、リンクする時には、必ず、そのシステムが、常に発展し、他人の作業に応答するグループ作業になる。ハイパーテキストのもう1つの一般的なマルチユーザ機能(ウェブではみられない)が、すべてのユーザがすべてのページからリンクを作成できるようにし、その結果、他のユーザが、元の作成者が知らない関連するリンクがある時に知ることができるようにすることである。
【0324】
グループ・カレンダリングが、グループウェアのもう1つの態様であり、これによって、多数の人の間のスケジューリング、プロジェクト管理、および調整が容易になり、スケジューリング機器のサポートも提供することができる。通常の特徴では、スケジュールが衝突する時が検出されるか、誰もが働く会議時間が発見される。グループ・カレンダは、人の居場所を知るのにも役立つ。
【0325】
協同執筆システムは、リアルタイム・サポートと非リアルタイム・サポートの両方を提供することができる。ワード・プロセッサは、原作者を示すことと、ユーザが変更を追跡し、文書に対する注釈を作成できるようにすることによって、非同期サポートを提供することができる。文書について協同作業する作成者に、文書の部分をロックする方法または別々に作成された文書をリンクする方法など、作成過程を計画し調整するのを助けるツールを与えることもできる。同期サポートを用いると、作成者が、変更を行う時に他者のそれぞれの変更を見ることができるようになり、通常は、作成者が作業する時に作成者に追加の通信チャネルを提供することが必要である。
【0326】
グループは、複数の人が、異なる位置からでも、共用される描画面を見、描くことができるようにする共用ホワイトボードなど、同期式またはリアル・タイムとすることができる。これは、たとえば、通話中に、各人がメモ(たとえば名前、電話番号、または地図など)を書き留めるか、視覚的問題について協同で作業するのに使用することができる。ほとんどの共用ホワイトボードは、形式ばらない会話のために設計されているが、協同グラフィック設計応用分野、出版応用分野、またはエンジニアリング応用分野など、構造化された通信またはより洗練された描画タスクをサービスすることもできる。共用ホワイトボードは、各人を識別するためにカラーコードされるかラベルを付けられるテレポインタによって、各人が描画している場所または指している場所を示すことができる。
【0327】
グループウェアのもう1つの態様が、ビデオ会議である。ビデオ会議システムは、生ビデオを伴う2方向または多方向の呼を可能にし、本質的には、調整用のタイム・スタンプを伴う追加の視覚的構成要素を有する電話システムである。
【0328】
意思決定支援が、グループウェアのもう1つの態様であり、グループの意思決定を促進するように設計される。これは、ブレインストーミング、アイデアの批評、事象および代替物に重みまたは確率を置くこと、および投票のツールを提供する。そのようなシステムは、おそらくは、より合理的で公平な決定を可能にする。これらは、主に会議を容易にするために設計されるが、たとえば、匿名性を提供するか交替を強制することによって、平等な参加を促進する。
【0329】
マルチプレイヤ・ゲームが、ゲームセンタで適度に一般的になったが、インターネットで非常に一般的になりつつある。初期の電子ゲームセンタ・ゲームの多数、たとえばPong、Space Wars、および自動車レース・ゲームが、マルチユーザであった。ゲームは、「非協同」マルチユーザ情況の原型的例であるが、競争的なゲームであっても、プレイヤがゲームのルールに従って協力することが必要である。ゲームは、チャット・システムまたはビデオ・システムなど、他の通信媒体によって機能強化することができる。
【0330】
グループウェアの製品の例には、Lotus NotesおよびMicrosoftExchangeが含まれ、この両方が、カレンダ共用、電子メール処理、分散システムを介するファイルの複製を容易にし、その結果、すべてのユーザが同一の情報を見られるようになる。
【0331】
本発明のコネクタを、グループウェア・アプリケーションにとって特に魅力的にしているのが、グループウェア提供と、グループ・サーバ・アーキテクチャ、実施形態、およびプラットフォームの多様性である。本発明のコネクタは、グループウェア・サーバへのフロント・エンドまたはゲートウェイとして働くことができる。
【0332】
図49に、実際の商品が、売り手から買い手に出荷され、さまざまな形の電子支払いおよび保護された電子支払いが、売り手に支払うために買い手によって使用され、銀行および金融機関が、本明細書に記載のコネクタを介して接続される、商業トランザクションを示す。具体的に言うと、商人または製造業者の売り手4101が、「ヒストリ」を有しない顧客4103に製品を売る。製品が、出荷される4605。しかし、買い手である顧客4103は、商品を受け取り、検査し、承認し、「受け入れる」まで金を手放すことを望まず、売り手4101は、支払われるまで商品の制御を放棄することを望まない。この基本的な商取引の衝突が、さまざまなパラダイムにつながり、そのほとんどが、ハード・コピーの「擬似金銭」またはある形から別の形への法律文書を伴う。現在、財務トランザクションは、最も頻繁に電子資金転送と、メモ、法律文書、流通証券、荷為替手形、支払い指図書、信用状、倉庫証券、荷渡指図書、船荷証券(商品に対する請求権を含む、すなわち、商品の権利または物理的管理を運搬人または名前を指定された人に譲渡することを意味する権利証券)、および商品の担保権を伴うトランザクションである。通常、顧客4103は、売り手4101に払い渡す証書を実行し、買い手の銀行4121に、売り手の銀行4125を介して売り手4101に買い手の金を向ける。通常、これは、前に互いに取引した売り手と買い手の間の、前に互いに取引した、同一のまたは互換性があるソフトウェア・アプリケーションを使用している銀行または金融機関を介して扱われる、単純な電子トランザクションである。しかし、これらの事前条件が満足されない特別の場合には、本発明のコネクタによって、トランザクションの電子的な銀行間側を容易にする。
【0333】
単一のレベルのアプリケーション・プログラム・インターフェースまたはコンバータを有する応用例に関して本発明を説明し、図示してきたが、そのようなアプリケーション・プログラム・インターフェースまたはコンバータが、処理階層内のさまざまなレベルに、たとえばウェブ・クライアントとウェブ・サーバの間、ウェブ・サーバとアプリケーション・サーバの間、アプリケーション・サーバとデータベース・サーバの間、およびアプリケーション・サーバまたはデータベース・サーバまたはその両方とさまざまな特殊リポジトリの間に、存在することができることを理解されたい。
【0334】
本発明を、ある好ましい実施形態と、個々のクライアントおよび個々のサーバを有する例示を用いて説明し、図示してきたが、グループウェア・アプリケーションによって例証されるように、複数のクライアント、複数のサーバ、およびクライアントとサーバの両方として機能するアプリケーションが存在することができ、リッチ・トランザクションのシステム内で、アプリケーション・サーバ、データ・サーバ、およびデータベースの複数の並列の線または複数の階層レベルあるいはその両方が存在することができることも理解されたい。
【0335】
本発明を、ある好ましい実施形態および例示に関して説明してきたが、これによって本発明の範囲を制限することは意図されておらず、本発明の範囲は、請求項のみによって制限される。
【図面の簡単な説明】
【図1】 NetscapeまたはInternet Explorerブラウザ、SunSolarisサーバ上のNet.Commerce、データベース・サーバ上のOracleおよびDB2、AIXで稼動するSAP、CICS 390サーバ、IMS 390サーバ、S/390プラットフォーム上のDB2およびDL/I、Windows(R)2000クライアント、およびHPUnix(R)サーバ上で稼動するBaanを含む、複数のアプリケーション・コンポーネントを有するシステムを示す図である。
【図2】 実行時のエンタープライズ・アプリケーション統合を促進するために共通アプリケーション・メタモデルのメタデータ・リポジトリへの入力としてのメッセージ・セット、SQLストアド・プロシージャ、レガシ・アプリケーション、およびプログラミング言語の役割を示す図である。
【図3】 3種類のメタモデルすなわち、呼出しメタモデル、アプリケーションドメイン・インターフェース・メタモデル、および言語メタモデルからなる本発明の共通アプリケーション・メタモデルを示す図である。所与のアプリケーションドメイン・メタモデルについて、1つまたは複数の言語メタモデルを使用することができ、0個以上の呼出しメタモデルを設けることができる。
【図4】 OTMA呼出しメタモデル、IMSトランザクション・メッセージ・メタモデル・アプリケーション・インターフェースを伴い、COBOLメタモデル、Cメタモデル、または他の言語メタモデルを使用することができる、IMS OTMAメタモデルを示す図である。
【図5】 アプリケーション・プログラミング・インターフェースを記述したXML文書を生成するのにツールをどのように使用することができるかを示す図である。まず、オブジェクト・モデルすなわちCAMメタモデルを作成して、アプリケーション・サーバに関するインターフェース定義を取り込む。その後、ツールが、アプリケーション・プログラムのソース定義を読み取り、解析し、オブジェクト・モデルの情報をリポジトリから検索することによってXML文書を生成する。
【図6】 共通アプリケーション・メタモデルRoseファイル、たとえばCOBOLメタモデル、PL/Iメタモデル、MFSメタモデル、BMSメタモデル、および類似物をツールキットに読み取って、Roseモデル用のDTD、XMLスキーマ、およびJava(R)コードを生成する、開発フェーズのシナリオを示す図である。COBOLソース・ファイル、PL/Iソース・ファイル、MFSソース・ファイル、BMSソース・ファイル、および類似物としてのアプリケーションのソース・ファイルが、インポータに読み込まれる。インポータは、ソース・コードを解析し、アプリケーション・ソース・ファイルのRoseモデルのJava(R)コードを読み込むことによって、出力としてXMIインスタンス・ファイルすなわちXML文書を生成する。
【図7】 アプリケーション・コンポーネントの、フロー・モデルを含むイベント・ベース・メッセージング・モデルへの統合を可能にする、アプリケーション・インターフェースのメタモデルを示す図である。フローおよびメッセージング・ミドルウェアが、アプリケーション・インターフェースを介してアプリケーションを呼び出す。これらのインターフェースは、それを介してすべての入出力がミドルウェアに接続されるアプリケーションへのアクセス点である。インターフェースは、アプリケーション・インターフェース・メタモデルに関して記述される。メタモデルによる変換処理は、ソース/クライアント・アプリケーション、ターゲット・アプリケーション、またはゲートウェイで行うことができる。
【図8】 実行時中の共通アプリケーション・メタモデルの適用を示す図である。図からわかるように、CAMモデルが、バックエンドIMSアプリケーションとウェブ・ファイル(たとえばSOAP準拠XML文書)の間の接続性を促進する。これは、モデルに取り込まれた情報を使用して、図示の混合言語環境で、あるプラットフォームから別のプラットフォームへのデータ変換を行うことによって達成される。
【図9】 TypeDescriptorメタモデルが、全体的なデータ構造体名およびフィールド名の言語固有メタモデルを用い、言語モデルに存在する集約関連を複製せずに、実行時データ変換の処方またはテンプレートして使用される、TDLang基本クラスを示す図である。
【図10】 TypeDescriptorメタモデルのM2レベルのMOFクラス・インスタンスを示す図である。
【図11】 TypeDescriptorメタモデルのM2レベルのMOFクラス・インスタンスを示す図である。
【図12】 TypeDescriptorメタモデルのM2レベルのMOFクラス・インスタンスを示す図である。
【図13】 TDLangメタモデルのTDLangElementとTypeDescriptorメタモデルのPlatformCompilerTypeとの間の関連を示す図である。
【図14】 TypeDescriptorメタモデルのさまざまな列挙型、たとえば、signCoding、lengthEncoding、floatType、accessor、packedDecimalSign、およびbitModelPadを示す図である。
【図15】 コネクタ・インターフェースを表すデータ構造体セマンティクスを定義するためのCOBOLメタモデルを示す図である。このメタモデルは、M2レベルのMOFクラス・インスタンスでもある。
【図16】 コネクタ・インターフェースを表すデータ構造体セマンティクスを定義するためのCOBOLメタモデルを示す図である。このメタモデルは、M2レベルのMOFクラス・インスタンスでもある。
【図17】 TDLangClassifier、TDLanguageComposedType、およびTDLangElementである、COBOLメタモデルとTDLang基本クラスの間の関連を示す図である。
【図18】 COBOLメタモデルのCOBOLUsageValuesの列挙を示す図である。
【図19】 コネクタ・インターフェースを表すデータ構造体を定義するためにアプリケーション・プログラムによって使用可能なPL/I言語メタモデルを示す図である。このメタモデルは、M2レベルのMOFクラス・インスタンスである。
【図20】 コネクタ・インターフェースを表すデータ構造体を定義するためにアプリケーション・プログラムによって使用可能なPL/I言語メタモデルを示す図である。このメタモデルは、M2レベルのMOFクラス・インスタンスである。
【図21】 コネクタ・インターフェースを表すデータ構造体を定義するためにアプリケーション・プログラムによって使用可能なPL/I言語メタモデルを示す図である。このメタモデルは、M2レベルのMOFクラス・インスタンスである。
【図22】 PL/IメタモデルについてはTDLangClassifier、TDLanguageComposedType、およびTDLanguageElementである、PL/IメタモデルとTDLang基本クラスの関連を示す図である。
【図23】 PL/IメタモデルのModeValues、BaseValues、LengthTypes、およびStringTypeValuesの列挙を示す図である。
【図24】 C Main言語メタモデルを示す図である。
【図25】 TDLangClassifier、TDLangComposedType、およびTDLangElementである、CメタモデルとTDLang基本クラスの間の関連を示す図である。
【図26】 C言語メタモデルのTypedElement態様を示す図である。
【図27】 C言語メタモデルでのユーザ定義データ型を含む、Cメタモデルのユーザ定義データ型を示す図である。
【図28】 C言語メタモデルでのDatatype-StringおよびDatatype-Integer、ならびにDirectionKindの引数および戻り値の列挙およびBooleanデータ型のtrueおよびfalseの列挙を示す図である。
【図29】 C Mainメタモデルから継承するC++ Mainメタモデルを示す図である。このモデルには、C++メタモデルのDerived、Structured、BehavioralFeatures、Field、およびDerivableTypesが含まれる。
【図30】 C++メタモデルの可視性型の列挙を示す図である。C++が、オブジェクト指向言語であり、オブジェクト指向プログラミングに有用であり、public、private、およびprotectedの可視性をサポートすることに留意されたい。
【図31】 3種類のトランザクション・メッセージすなわち、プレフィックス付きのIMS−OTMAメッセージ、デフォルトOTMAプレフィックスをIMSが構築することができるプレフィックスなしのIMSメッセージ、およびアプリケーション・プログラムに直接に送ることができるIMS基本メッセージを含む、IMSトランザクション・メッセージのメタモデルを示す図である。
【図32】 OTMAプレフィックス・メタデータ・モデルを示す図である。
【図33】 制御データ定義データ型のOTMAプレフィックスを示す図である。
【図34】 状態定義データ型のOTMAプレフィックスを示す図である。
【図35】 セキュリティ定義型のOTMAプレフィックスを示す図である。
【図36】 IMSメタモデルのIMSメッセージ・プリミティブを示す図である。
【図37】 コネクタ・インターフェースを表すデータ構造体セマンティクスを定義するHighLevel Assembly Language(HLASM)メタモデルを示す図である。このメタモデルは、M2レベルのMOFクラス・インスタンスでもある。
【図38】 TDLangClassifier、TDLanguageComposedType、およびTDLangElementである、HLASMメタモデルとTDLang基本クラスの間の関連を示す図である。
【図39】 HLASMメタモデルでのHLASM使用値の列挙を示す図である。
【図40】 コネクタ・インターフェースを表すデータ構造体を定義するためにアプリケーション・プログラムによって使用可能なCICS BMS言語メタモデルを示す図である。
【図41】 BMSMetaModelの属性、フィールド、属性値、およびマップを示す図である。
【図42】 BMSMetaModelの属性、フィールド、属性値、およびマップを示す図である。
【図43】 コネクタ・インターフェースを表すデータ構造体を定義するためにアプリケーション・プログラムによって使用可能なMFS言語メタモデルを示す図である。
【図44】 MFSメタモデルのクラスの間の関連を示す図である。
【図45】 MFSメタモデルのModeValues、BaseValues、LengthTypes、およびStringTypeValuesの列挙を示す図である。
【図46】 MFSメタモデルのModeValues、BaseValues、LengthTypes、およびStringTypeValuesの列挙を示す図である。
【図47】 たとえば注文が端末で入力され、ウェブ・サーバに渡され、ウェブ・サーバを介して製造業者のアプリケーション・サーバに渡される、「リッチ」トランザクションに関する単純化されたネットワーク構成を示す図である。製造業者のアプリケーション・サーバは、それ自体のデータベース・サーバならびに、本明細書に記載のコネクタによって透過的に接続されたそのベンダの似ていない非互換のデータベース・サーバおよびデータベースを介して検索し、構成要素の状況、価格、および配送日付を照会し、注文を満足するのに必要な構成要素の注文を行う。
【図48】 複数の異なるプラットフォームで稼動し、本明細書に記載の共通アプリケーション・メタモデルを使用して接続される、複数のグループ・ウェア・アプリケーションにまたがって分散されたグループ・ウェア・セッションを示す図である。
【図49】 実際の商品が売り手から買い手に出荷され、さまざまな形の電子支払いおよび保護された電子支払いが、売り手に支払うために買い手によって使用され、銀行および金融機関が、本明細書に記載の共通アプリケーション・メタモデルを使用して接続される、商取引を示す図である。
Claims (14)
- エンド・ユーザ・アプリケーションおよびアプリケーション・サーバでアプリケーション要求を処理する方法であって、
a)第1アプリケーション・プログラムを用いて第1ソース言語で前記エンド・ユーザ・アプリケーション上で開始した前記アプリケーション要求を前記サーバが受信するステップと、
b)前記アプリケーション要求を前記エンド・ユーザ・アプリケーションの前記第1ソース言語から前記アプリケーション・サーバ上で稼動する第1ターゲット言語に変換するステップと、
c)前記アプリケーション・サーバ上で前記アプリケーション要求を処理するステップと、
d)前記アプリケーション要求に対する応答を、前記アプリケーション・サーバから前記エンド・ユーザ・アプリケーションに送信し、前記アプリケーション要求に対する前記応答を、前記アプリケーション・サーバ上で稼動する前記第1ターゲット言語から前記エンド・ユーザ・アプリケーションの前記第1ソース言語に変換するステップと
を含み、
e)前記アプリケーション・サーバが、前記エンド・ユーザ・アプリケーションとの間の少なくとも1つのコネクタを有し、前記コネクタは、
(i)前記アプリケーション要求を、前記エンド・ユーザ・アプリケーションの前記第1ソース言語から前記アプリケーション・サーバ上で稼動する前記第1ターゲット言語に変換するステップと、
(ii)前記アプリケーション要求に対する応答を、第2ソース言語である前記アプリケーション・サーバ上で稼動する前記第1ターゲット言語から第2ターゲット言語である前記第1エンド・ユーザ・アプリケーションの前記第1ソース言語に変換するステップとを含み、前記(i)および(ii)の各ステップが、
1)呼出しメタモデルとアプリケーション・インタフェース・メタモデルと言語メタモデルとを含み、各々のソース言語およびターゲット言語の前記コネクタ・メタモデルを呼び出すステップと、
2)前記各々のソース言語およびターゲット言語のそれぞれのメタモデル・メタデータを前記コネクタ・メタモデルに移植するステップと、
3)前記ソース言語を前記ターゲット言語に変換するステップと
を含み、前記言語メタモデルは、前記アプリケーション・インタフェース・メタモデルにプラグインされる、方法。 - 前記エンド・ユーザ・アプリケーションが、ウェブ・ブラウザである、請求項1に記載の方法。
- 前記エンド・ユーザ・アプリケーションが、ウェブ・サーバを介して前記アプリケーション・サーバに接続され、前記ウェブ・サーバが、前記コネクタ・メタモデルを含む、請求項2に記載の方法。
- 前記メタモデル・メタデータが、呼出しメタモデル・メタデータ、アプリケーション・ドメイン・インターフェース・メタモデル・メタデータ、および型記述子メタモデル・メタデータを含む、請求項1に記載の方法。
- 前記アプリケーション・ドメイン・インターフェース・メタモデル・メタデータが、さらに、言語メタモデル・メタデータを含む、請求項4に記載の方法。
- 前記言語メタモデル・メタデータが、ソース言語とターゲット言語との間のマッピングを含む、請求項5に記載の方法。
- 前記ソース言語または前記ターゲット言語の1つが、CおよびC++からなる群から選択される、請求項1に記載の方法。
- クライアント、サーバ、およびそれらの間の少なくとも1つのコネクタを含むトランザクション処理システムであって、
a)前記サーバは、前記クライアントが、エンド・ユーザ・アプリケーションを有し、第1アプリケーション・プログラムを用いて第1ソース言語で前記サーバとのアプリケーション要求を開始し、前記アプリケーション要求を受信する手段と、
b)前記コネクタが、前記クライアントから前記アプリケーション要求を受信し、前記アプリケーション要求を前記クライアント上で稼動する前記エンド・ユーザ・アプリケーションの前記第1ソース言語から前記サーバ上で稼動する第1ターゲット言語に変換する手段と、
c)前記サーバが、前記第1ターゲット言語に変換されたアプリケーション要求を前記コネクタから受信し、前記サーバに常駐する第2アプリケーション・プログラムを用いて前記第1ターゲット言語で前記アプリケーション要求を処理し、その後、前記アプリケーション要求に対する応答を、前記コネクタを介して前記クライアント上の前記第1アプリケーション・プログラムに送信する手段とを含み、
d)前記コネクタが、前記サーバから前記アプリケーション要求に対する応答を受信し、前記アプリケーション要求に対する応答を前記アプリケーション・サーバ上で稼動する前記第1ターゲット言語から前記クライアント上で稼動する前記第1アプリケーション・プログラムの前記第1ソース言語に変換しており、
e)前記コネクタが、
1)メタモデル・メタデータ・リポジトリから、呼出しメタモデルとアプリケーション・インタフェース・メタモデルと言語メタモデルとを含み、各々のソース言語およびターゲット言語のためのコネクタ・メタモデルを検索する手段と、
2)前記各々のソース言語およびターゲット言語のそれぞれの前記メタモデル・メタデータ・リポジトリからのメタモデル・データを前記コネクタ・メタモデルに移植するステップと、
3)前記検索され移植されたコネクタ・メタモデルを呼び出し、前記ソース言語を前記ターゲット言語に変換する手段と
を含み、前記言語メタモデルは、前記アプリケーション・インタフェース・メタモデルにプラグインされ、
(i)前記アプリケーション要求を、前記クライアント上の前記クライアント・アプリケーションの前記第1ソース言語からターゲット言語としての前記アプリケーション・サーバ上で稼動する前記第1ターゲット言語に変換し、
(ii)前記アプリケーション要求に対する前記応答を、第2ソース言語である前記アプリケーション・サーバ上で稼動する前記第1ターゲット言語から、第2ターゲット言語である前記クライアント上で稼動する前記クライアント・アプリケーションの前記第1ソース言語に変換する、
トランザクション処理システム。 - 前記エンド・ユーザ・アプリケーションが、ウェブ・ブラウザである、請求項8に記載のシステム。
- 前記エンド・ユーザ・アプリケーションが、ウェブ・サーバを介して前記アプリケーション・サーバに接続され、前記ウェブ・サーバが、コネクタを含む、請求項9に記載のシステム。
- 前記メタモデル・メタデータが、呼出しメタモデル・メタデータ、アプリケーション・ドメイン・インターフェース・メタモデル・メタデータ、および型記述子メタモデル・メタデータを含む、請求項8に記載のシステム。
- 前記言語メタモデル・メタデータが、ソース言語とターゲット言語との間のマッピングを含む、請求項8に記載のシステム。
- 前記ソース言語または前記ターゲット言語の1つが、CおよびC++からなる群から選択される、請求項8に記載のシステム。
- 請求項1〜7のいずれか1項の記載のアプリケーション要求を処理する方法を実行する装置実行可能なプログラムを記録した記録媒体。
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 | C/c++メタモデルを含む共通アプリケーション・メタモデル |
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)
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)
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 | Kddi株式会社 | 情報処理装置 |
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)
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 |
-
2001
- 2001-05-04 US US09/849,107 patent/US7275079B2/en not_active Expired - Lifetime
- 2001-08-02 WO PCT/US2001/024280 patent/WO2002013007A1/en active Application Filing
- 2001-08-02 JP JP2002517625A patent/JP3842213B2/ja not_active Expired - Fee Related
- 2001-08-02 EP EP01956109A patent/EP1323034A4/en not_active Withdrawn
- 2001-08-02 AU AU2001278142A patent/AU2001278142A1/en not_active Abandoned
- 2001-08-02 CN CNB018168086A patent/CN1267820C/zh not_active Expired - Lifetime
- 2001-08-02 CA CA002412312A patent/CA2412312A1/en not_active Abandoned
Cited By (1)
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) | C/c++メタモデルを含む共通アプリケーション・メタモデル | |
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 |