他のアプリケーション・プログラムにデータを送信する場合、送信側のプログラムはまずデータをレコードに格納します。Oracle Tuxedo ATMIクライアントは、型付きレコードを使用してATMIサーバーにメッセージを送ります。型付きレコードとは、データ・レコードと補助型レコードが対になったCOBOL言語のレコードです。データ・レコードは、静的領域内に定義され、別のアプリケーション・プログラムに渡すアプリケーション・データが入ります。データ・レコードには、補助型レコードが付加されます。これは、異機種間システム間で情報をやり取りする場合に、Oracle Tuxedoシステムで使用されるデータ・レコードの解釈と変換の規則を指定します。型付きレコードは、Oracle Tuxedoシステムでサポートされる分散プログラミング環境の基本要素の1つです。
なぜ
型付きレコードを使用するのでしょうか。分散環境では、アプリケーションが異機種システムにインストールされ、異なるプロトコルを使用して複数のネットワーク間で通信が行われます。レコード・タイプが異なると、初期化、メッセージの送受信、およびデータのエンコード/デコードにそれぞれ別のルーチンが必要になります。各レコードに特定のタイプが割り当てられていると、プログラマが介在しなくても、そのタイプに対応するルーチンを自動的に呼び出すことができます。
表3-1は、Oracle Tuxedoシステムでサポートされる型付きレコードと、そのレコードが次の条件を満たしているかどうかを示しています。
|
•
|
自己記述型であるかどうか。つまり、レコードのデータ型と長さが、タイプとサブタイプ、およびそのデータからわかるかどうか。 |
|
•
|
型付きレコードのデータ依存型ルーティングがシステムでサポートされているかどうか。 |
|
•
|
型付きレコードのエンコード/デコードがシステムでサポートされているかどうか。 |
ルーティング用のルーチンが必要な場合は、アプリケーション・プログラマが用意します。
|
|
|
|
|
|
|
|
|
未定義の文字配列。LOW-VALUEを含むことができます。Oracle Tuxedoシステムでは配列のセマンティクスは解釈されないので、この型付きレコードは曖昧なデータを処理する場合に使用します。 CARRAYは自己記述型ではないので、転送時には長さを指定する必要があります。システムではバイトは解釈されないので、マシン間のメッセージ送信ではエンコード/デコードはサポートされません。 |
|
|
|
|
|
|
Oracle Tuxedoシステム固有の自己記述型レコード・タイプ。このレコードでは、各データ・フィールドに対応する識別子、オカレンス番号、場合によっては長さを示す値が格納されています。型付きレコードでは、データからの独立性と柔軟性が確立されています。 FML型レコードでは、フィールド識別子とフィールド長に16ビットが使用されます。
|
|
|
|
|
|
|
FMLと同じ。ただし、フィールド識別子とフィールド長に32ビットが使用されます。より長いフィールドを多数使用できるので、レコード全体が大きくなります。
ただし、Cプログラミング言語で FML型レコードの操作に使用できる FMLルーチンは、COBOL言語では使用できません。COBOL言語で FML32を使用する主な目的は、単に VIEW32または FML32型レコードが使用されているC言語プログラムを操作することです。 |
|
|
|
|
|
|
最後がLOW-VALUE文字で終了する文字配列。異なる文字セットを使用するマシン間でデータを交換する場合は、Oracle Tuxedoシステムによってデータが自動的に変換されます。 |
|
|
|
|
|
|
アプリケーションで定義されるCOBOLデータ構造体。 VIEW型には、個々のデータ構造体を示すサブタイプが必要です。 VIEW記述ファイル(データ構造体のフィールドとタイプが定義されたファイル)は、 VIEW型レコードに定義されたデータ構造体を使用するクライアント・プロセスとサーバー・プロセスがアクセスできなければなりません。異なるタイプのマシン間でレコードがやり取りされる場合は、エンコード/デコードが自動的に行われます。詳細は、 3-7ページの「VIEW型レコードの使用」を参照してください。 |
|
|
|
|
|
|
VIEWと同じ。ただし、長さとカウントのフィールド長に32ビットが使用されます。より長いフィールドを多数使用できるので、レコード全体が大きくなります。
COBOL言語で VIEW32を使用する主な目的は、単に VIEW32または FML32型レコードが使用されているC言語プログラムを操作することです。 |
|
|
|
|
|
|
VIEWと同じ。ただし、このバッファ型はCOBOLとCプログラム間の互換性を取るために使用されます。フィールド・タイプとして使用できるのは、short、long、およびstringだけです。
|
|
|
|
|
|
|
|
•
|
ドキュメントの論理構造の記述と、その構造に関する情報 |
XML文書のルーティングは、要素の内容、または要素タイプと属性値に基づいて行われます。使用されている文字エンコーディングはXMLパーサーによって判別されます。エンコーディングがOracle Tuxedoの構成ファイル( UBBCONFIG(5)および DMCONFIG(5))で使用されているネイティブな文字セット(US-ASCIIまたはEBCDIC)と異なる場合、要素と属性名はUS-ASCIIまたはEBCDICに変換されます。詳細は、 3-20ページの「XML型レコードの使用」を参照してください。 |
|
|
|
|
|
|
|
|
|
|
|
すべてのレコード・タイプは、
$TUXDIR/libディレクトリの
tmtypesw.cファイルに定義されています。クライアント・プログラムとサーバー・プログラムで認識されるレコード・タイプは、
tmtypesw.cに定義されているものだけです。
tmtypesw.cファイルを編集して、レコード・タイプを追加したり削除できます。また、
UBBCONFIGの
BUFTYPEパラメータを使用して、特定のサービスで処理できるタイプとサブタイプを制限できます。
tmtypesw.cファイルは、共有オブジェクトや動的リンク・ライブラリのビルドに使用されます。このオブジェクトは、Oracle Tuxedo管理サーバー、およびアプリケーション・クライアントとアプリケーション・サーバーによって動的にロードされます。
TPTYPE-REC COBOL構造体は、アプリケーション・データの送受信に必ず使用されます。
次の表は、
TPTYPE-REC構造体のフィールドを示しています。
|
|
|
|
|
アプリケーションで送信または受信するレコード・タイプを指定します。 |
|
|
レコード( VIEWレコードなど)内でレコード・タイプをさらに細かく分類する場合は、そのサブタイプを指定します。 |
|
|
データの送信時に、送信バイト数を指定します。データ送信が正常に行われると、 LENには送信されたバイト数が格納されます。データの受信時に、 TPTYPE-RECの LENはデータ・レコードに送られるバイト数を指定します。呼出しが正常に行われると、 LENにはデータ・レコードに送られたバイト数が格納されます。受信メッセージのサイズが LENで指定されているサイズより大きい場合、データは切り詰められます。つまり、 LENを超えて受信されたデータは破棄され、 TPTYPE-STATUSに TPTRUNCATEが設定されます。 |
次のサンプル・コードは、
TPTYPEデータ構造体を示しています。
05 REC-TYPE PIC X(8).
88 X-OCTET VALUE "X_OCTET".
88 X-COMMON VALUE "X_COMMON".
05 SUB-TYPE PIC X(16).
05 LEN PIC S9(9) COMP-5.
88 NO-LENGTH VALUE 0.
05 TPTYPE-STATUS PIC S9(9) COMP-5.
88 TPTYPEOK VALUE 0.
88 TPTRUNCATE VALUE 1.
VIEW型レコードには2種類あります。1つは
FML VIEWで、
FMLレコードから生成されるCOBOLレコードです。もう1つは、単なる非依存型COBOLレコードです。
FMLレコードをCOBOLレコードに変換して再び元に戻す理由(および
FML VIEW型レコードを使用する目的)は、FML関数がCOBOLプログラミング環境では使用できないからです。
FML型レコードの詳細は、『Oracle Tuxedo ATMI FML関数リファレンス』
を参照してください。
VIEW型レコードを使用するには、次の手順に従います。
|
•
|
Oracle Tuxedo VIEWコンパイラviewc -Cを使用して、VIEW記述ファイルをコンパイルします。このコマンドを実行すると、1つ以上のCOBOLの COPYファイルが各VIEW記述ファイルに生成され、各COPYファイルには、データ記述レコードが記述されます。これらのレコードは、プログラムの要求に応じて、 DATA DIVISIONの LINKAGEセクションまたは WORKING STORAGEセクションで使用できます。
|
アプリケーションで
VIEW型レコードを使用するには、
表3-2の環境変数を設定します。
|
|
|
|
|
FMLまたは FML32型レコードのフィールド表ファイル名のカンマ区切りのリスト。 FML VIEW型のみで必要です。
|
|
|
FMLまたは FML32型レコードのフィールド表ファイルが検索されるディレクトリのコロン区切りのリスト。Microsoft Windowsでは、セミコロンで区切られます。 FML VIEW型のみで必要です。
|
|
|
VIEWまたは VIEW32記述ファイルに使用されるファイル名 のカンマ区切りのリスト。
|
|
|
VIEWまたは VIEW32ファイルが検索されるディレクトリのコロン区切りのリスト。Microsoft Windowsでは、セミコロンで区切られます。
|
VIEW型レコードを使用するには、VIEW記述ファイルにCOBOLレコードを定義する必要があります。VIEW記述ファイルには、各エントリのVIEW、およびCOBOLプロシージャのマッピングと
FML変換パターンを記述したVIEWが定義されています。VIEWの名前は、COBOLプログラムに含まれるcopyファイルの名前に相当します。
VIEW記述ファイルの各レコードは、次の形式で定義します。
$ /* VIEW構造体*/
VIEW viewname
type cname fbname count flag size null
表3-3は、VIEW記述ファイルに指定する必要がある各COBOLレコードのフィールドを示しています。
|
|
|
|
|
フィールドのデータ型。 short、 long、 float、 double、 char、 string、または carrayを指定できます。 |
|
|
|
|
|
FMLから VIEW、または VIEWから FMLへの変換ルーチンを使用する場合、対応する FML名をこのフィールドに指定する必要があります。このフィールド名は、FML フィールド表ファイルにも必要です。FMLに依存しないVIEWには必要ありません。
|
|
|
|
|
|
|
•
|
S - フィールド化レコードから構造体に一方向のマッピングを行います。 |
|
•
|
F - 構造体からフィールド化レコードへの一方向マッピングを行います。 |
|
•
|
C - 連想カウント・メンバー(ACM)に追加フィールドを生成します。 |
|
•
|
L - STRINGおよび CARRAYに転送されるバイト数を保持します。 |
|
|
|
STRINGまたは CARRAY型レコードの最大長を指定します。それ以外のレコード・タイプでは、このフィールドは無視されます。
|
|
|
ユーザー定義のLOW-VALUE値、または -の場合はフィールドのデフォルト値。 VIEW型レコードで使用されるLOW-VALUE値は、空のCOBOLレコード・メンバーを示します。 数値型の場合、デフォルトのLOW-VALUE値はすべて0 ( dec_tの場合は0.0)になります。文字型の場合、デフォルトのLOW-VALUE値は \0になります。 STRING型と CARRAY型の場合、デフォルトのLOW-VALUE値は" "になります。 エスケープ文字として使用されている定数も、LOW-VALUE値の指定に使用できます。VIEWコンパイラで認識されるエスケープ定数は、 \ddd ( dは8進数)、 \0、 \n、 \t、 \v、 \r、 \f、 \\、 \'、および \"です。 STRING、 CARRAY、およびLOW-VALUE値は、二重引用符または一重引用符で囲みます。VIEWコンパイラでは、ユーザー定義のLOW-VALUE値でエスケープされていない引用符は使用できません。
VIEWメンバー記述のLOW-VALUEフィールドにキーワードNONEを指定することもできます。このキーワードは、そのメンバーのLOW-VALUE値がないことを示します。文字列および文字配列メンバーの最大サイズのデフォルト値は2660文字です。詳細については、『Oracle Tuxedo ATMI FML関数リファレンス』 を参照してください。 |
行頭に#または$文字を付けてコメント行を挿入できます。行頭に$が挿入されたコード行は、
.hファイルに出力されます。
リスト3-1は、
FMLレコードに基づくVIEW記述サンプル・ファイルの一部です。この場合は、
fbnameフィールドを指定する必要があり、この値は対応する
フィールド表ファイルの値と一致している必要があります。
CARRAY1フィールドのオカレンス・カウントが
2に設定されていること、
Cフラグが設定されて追加のカウント要素の作成が定義されていることに注目してください。また、
Lフラグが設定され、アプリケーションが
CARRAY1フィールドを格納するときの文字数を示す長さ要素が定義されています。
リスト3-1
FML VIEWのVIEW記述ファイル
$ /* View structure */
VIEW MYVIEW
#type cname fbname count flag size null
float float1 FLOAT1 1 - - 0.0
double double1 DOUBLE1 1 - - 0.0
long long1 LONG1 1 - - 0
short short1 SHORT1 1 - - 0
int int1 INT1 1 - - 0
dec_t dec1 DEC1 1 - 9,16 0
char char1 CHAR1 1 - - '\0'
string string1 STRING1 1 - 20 '\0'
carray carray1 CARRAY1 2 CL 20 '\0'
END
リスト3-2は、同じVIEW記述ファイルで非依存型
VIEWのものを示しています。
リスト3-2
非依存型VIEWのVIEW記述ファイル
$ /* View data structure */
VIEW MYVIEW
#type cname fbname count flag size null
float float1 - 1 - - -
double double1 - 1 - - -
long long1 - 1 - - -
short short1 - 1 - - -
int int1 - 1 - - -
dec_t dec1 - 1 - 9,16 -
char char1 - 1 - - -
string string1 - 1 - 20 -
carray carray1 - 2 CL 20 -
END
この形式は
FML依存型VIEWと同じであることに注意してください。ただし、
fbnameフィールドと
nullフィールドには意味がなく、
viewcコンパイラで無視されます。これらのフィールドには、プレースホルダーとしてダッシュ(-)などの値を挿入する必要があります。
VIEW型レコードをコンパイルするには、引数としてVIEW記述ファイルの名前を指定して
viewc -Cコマンドを実行します。非依存型
VIEWを指定するには、
-nオプションを使用します。生成される出力ファイルを書き込むディレクトリを指定することもできます(オプション)。デフォルトでは、出力ファイルはカレント・ディレクトリに書き込まれます。
たとえば、
FML依存型
VIEWをコンパイルするには、次のようにコンパイラを実行します。
|
注意:
|
VIEW32型レコードをコンパイルするには、 viewc32 -Cコマンドを実行します。
|
非依存型
VIEWの場合、コマンド行で次のように
-nオプションを指定します。
|
•
|
MYVIEW.cblなど、1つ以上のCOBOLの COPYファイル
|
|
•
|
同じVIEWを共有するC言語ルーチンに対して、アプリケーション・プログラムで使用される構造体定義が記述されたヘッダー・ファイル |
|
•
|
myview.Vなど、バイナリ・バージョンのソース記述ファイル
|
|
注意:
|
Microsoft Windowsなど、大文字と小文字が区別されないプラットフォームでは、バイナリ・バージョンのソース記述ファイル名には、拡張子 vv ( myview.vvなど)が使用されます。 |
リスト3-3は、
viewcによって作成されるCOBOLの
COPYファイルを示しています。
リスト3-3
COBOLのCOPYファイルのサンプル・コード
* VIEWFILE: "myview.v"
* VIEWNAME: "MYVIEW"
05 FLOAT1 USAGE IS COMP-1.
05 DOUBLE1 USAGE IS COMP-2.
05 LONG1 PIC S9(9) USAGE IS COMP-5.
05 SHORT1 PIC S9(4) USAGE IS COMP-5.
05 FILLER PIC X(02).
05 INT1 PIC S9(9) USAGE IS COMP-5.
05 DEC1.
07 DEC-EXP PIC S9(4) USAGE IS COMP-5.
07 DEC-POS PIC S9(4) USAGE IS COMP-5.
07 DEC-NDGTS PIC S9(4) USAGE IS COMP-5.
* DEC-DGTS is the actual packed decimal value
07 DEC-DGTS PIC S9(1)V9(16) COMP-3.
07 FILLER PIC X(07).
05 CHAR1 PIC X(01).
05 STRING1 PIC X(20).
05 FILLER PIC X(01).
05 L-CARRAY1 OCCURS 2 TIMES PIC 9(4) USAGE IS COMP-5.
* LENGTH OF CARRAY1
05 C-CARRAY1 PIC S9(4) USAGE IS COMP-5.
* COUNT OF CARRAY1
05 CARRAY1 OCCURS 2 TIMES PIC X(20).
05 FILLER PIC X(02).
VIEWに対するCOBOLの
COPYファイルは、
COPY文を使用してクライアント・プログラムとサービス・サブルーチンに含める必要があります。
このサンプル・コードでは、コンパイラは
FILLERファイルを読み込んで、COBOL言語コードでのフィールドの配置をC言語コードでの配置と一致させています。
パック10進値の
DEC1は、5つのフィールドから構成されます。このうちの
DEC-EXP、
DEC-POS、
DEC-NDGTS、および
FILLERフィールドは、C言語だけで使用され、
dec_t型で定義されます。COBOLアプリケーションでは、これらのフィールドを使用しないでください。
5番目のフィールド(
DEC-DGTS)には、システムによって実際のパック10進値が格納されます。COBOLプログラムではこの値を使用する必要があります。ATMI呼出しは、
DEC-DGTSフィールドに以下の操作を行います。
|
•
|
C言語プログラムからCOBOL言語プログラムにレコードが渡される前にそのフィールドを生成します。 |
|
•
|
COBOL言語プログラムからC言語プログラムにフィールドが渡される場合、フィールドを dec_t型に変換し直します。 |
唯一の制約として、COBOL言語プログラムでは、ATMIインタフェース外からC言語関数に直接レコードを渡すことはできません。COBOL言語プログラムとC言語関数では10進数の形式が異なるからです。
最後に、COBOLの
COPYサンプル・ファイルで
L-CARRAY1長さフィールドが2回使用されていることに注目してください。つまり、
CARRAY1と
C-CARRAY1カウント・フィールドに対して1回ずつ使用されています。
viewcは、C言語バージョンのヘッダー・フィルを生成します。このファイルを使用すると、CとCOBOL言語のサービスやクライアント・プログラムを混在させることができます。
|
•
|
『Oracle Tuxedoコマンド・リファレンス』の 「viewc、viewc32(1)」
|
FMLインタフェースは、C言語で使用されるように設計されたものです。COBOL言語に対しては、ルーチンが提供されています。そのため、受信した
FML型レコードをCOBOLレコードに変換して処理した後で、
FML型に再度変換できます。
FML型レコードを使用するには、次の手順に従います。
|
•
|
FINITを使用して FMLレコードを初期化します。
|
|
•
|
FMLヘッダー・ファイルを作成し、アプリケーションで同じVIEWを共有するC言語ルーチンの #include文に、そのヘッダー・ファイルを指定します。
|
FMLルーチンは、フィールド化レコードからC構造体への変換、またその逆の変換など、型付きレコードを操作する場合に使用します。これらの関数を使用すると、データ構造やデータの格納状態がわからなくても、データ値にアクセスしたり更新できます。
FMLルーチンの詳細は、『Oracle Tuxedo ATMI FML関数リファレンス』
を参照してください。
アプリケーション・プログラムで
FML型レコードを使用するには、
表3-4の環境変数を設定する必要があります。
|
|
|
|
|
FMLまたは FML32型付きレコードのフィールド表ファイル名のカンマ区切りのリスト。
|
|
|
FMLまたは FML32型バッファのフィールド表ファイルが検索されるディレクトリのコロン区切りのリスト。Microsoft Windowsでは、セミコロンで区切られます。
|
FML型レコードや
FML依存型
VIEWを使用する場合は、常にフィールド表ファイルが必要です。フィールド表ファイルは、
FML型レコードのフィールドの論理名をそのフィールドをユニークに識別する文字列にマッピングします。
FMLフィールド表の各フィールドは、次の形式で定義します。
$ /* FML structure */
*base
value
name number type flags comments
表3-5は、
FMLフィールド表ファイルに指定する必要がある
FMLフィールドを示しています。
|
|
|
|
|
後続のフィールド番号をオフセットするためのベース値。関連するフィールドのセットを簡単にグループ分けし、番号を付け直すことができるようになります。 *baseオプションを使用すると、フィールド番号を再利用できます。16ビットのレコードの場合、ベース値とそれに関連する番号を加算した値が、100以上8191未満でなければなりません。このフィールドは省略可能です。
|
注意:
|
Oracle Tuxedoシステムでは、フィールド番号1 - 100と6000 - 7000は、内部使用のために予約されています。 FMLではフィールド番号101 - 8191、 FML32ではフィールド番号101 - 33、554、および431がアプリケーション定義のフィールド用に使用できます。 |
|
|
|
フィールドの識別子。この値は256文字以下の文字列で、英数字と下線文字だけを指定できます。 |
|
|
フィールドの相対数値。現在のベース値が指定されている場合、この値は現在のベース値に加算されて、フィールド番号が計算されます。 |
|
|
フィールドのタイプ。指定できるのは、 char、 string、 short、 long、 float、 double、または carrayです。 |
|
|
将来使用するために予約されたフィールド。プレースホルダーとしてダッシュ(-)を挿入します。 |
|
|
|
すべてのフィールドは省略可能です。また、複数個使用できます。
リスト3-4は、
FML依存型VIEWの例で使用されるフィールド表ファイルを示しています。
リスト3-4
FML VIEWのフィールド表ファイル
# name number type flags comments
FLOAT1 110 float - -
DOUBLE1 111 double - -
LONG1 112 long - -
SHORT1 113 short - -
INT1 114 long - -
DEC1 115 string - -
CHAR1 116 char - -
STRING1 117 string - -
CARRAY1 118 carray - -
FML型レコードは、
FINITプロシージャを使用して初期化する必要があります。
TPINITプロシージャは、指定された
FMLレコード(できればワード境界に配置されているレコード)を使用し、
FMLINFOレコードの
FML-LENGTHフィールドに長さとして指定された値を使用します。
TPNOCHANGEが設定されている場合は、プログラムによって(作成されたのではなく)受信された
FMLレコードが自動的に初期化されます。その場合、
FINITを呼び出す必要はありません。
WORKING-STORAGE SECTION.
*RECORD TYPE AND LENGTH
01 TPTYPE-REC.
COPY TPTYPE.
*STATUS OF CALL
01 TPSTATUS-REC.
COPY TPSTATUS.
* SERVICE CALL FLAGS/RECORD
01 TPSVCDEF-REC.
COPY TPSVCDEF.
* TPINIT FLAGS/RECORD
01 TPINFDEF-REC.
COPY TPINFDEF.
* FML CALL FLAGS/RECORD
01 FML-REC.
COPY FMLINFO.
*
*
* APPLICATION FML RECORD - ALIGNED
01 MYFML.
05 FBFR-DTA OCCURS 100 TIMES PIC S9(9) USAGE IS COMP-5.
* APPLICATION VIEW RECORD
01 MYVIEW.
COPY MYVIEW.
* INITIALIZE FML RECORD
MOVE LENGTH OF MYFML TO FML-LENGTH.
CALL "FINIT" USING MYFML FML-REC.
IF NOT FOK
MOVE "FINIT Failed" TO LOGMSG-TEXT
PERFORM DO-USERLOG
PERFORM EXIT-PROGRAM
END-IF.
* Convert VIEW to FML Record
SET FUPDATE TO TRUE.
MOVE "MYVIEW" TO VIEWNAME.
CALL "FVSTOF" USING MYFML MYVIEW FML-REC.
IF NOT FOK
MOVE "FVSTOF Failed" TO LOGMSG-TEXT
PERFORM DO-USERLOG
PERFORM EXIT-PROGRAM
END-IF.
* CALL THE SERVICE USING THE FML RECORD
MOVE "FML" TO REC-TYPE IN TPTYPE-REC.
MOVE SPACES TO SUB-TYPE IN TPTYPE-REC.
MOVE LENGTH OF MYFML TO LEN.
CALL "TPCALL" USING TPSVCDEF-REC
TPTYPE-REC
MYFML
TPTYPE-REC
MYFML
TPSTATUS-REC.
IF NOT TPOK
MOVE "TPCALL MYFML Failed" TO LOGMSG-TEXT
PERFORM DO-USERLOG
PERFORM EXIT-PROGRAM
END-IF.
* CONVERT THE FML RECORD BACK TO MYVIEW
CALL "FVFTOS" USING MYFML MYVIEW FML-REC.
IF NOT FOK
MOVE "FVFTOS Failed" TO LOGMSG-TEXT
PERFORM DO-USERLOG
PERFORM EXIT-PROGRAM
END-IF.
FVFTOSプロシージャは、
VIEWレコードを
FMLレコードに変換しています。パラメータは
FVSTOFプロシージャのパラメータと同じですが、
FML-MODEを設定する必要はありません。各フィールドは、VIEWの要素の記述に基づいて、フィールド化レコードから構造体にコピーされます。フィールド化レコードのフィールドに対応する要素がCOBOLレコードに存在しない場合、そのフィールドは無視されます。COBOLレコードに指定された要素に対応するフィールドがフィールド化レコードに存在しない場合、その要素にNULL値がコピーされます。使用するNULL値は、要素ごとにVIEW記述ファイルに定義できます。
フィールドの複数のオカレンスをCOBOLレコードに格納するには、レコード要素を
OCCURSで定義します。レコードのフィールドのオカレンス数が要素のオカレンス数より少ない場合は、余分な要素にはNULL値が割り当てられます。また、レコードのフィールドのオカレンス数が要素のオカレンス数より多い場合は、余分なオカレンスは無視されます。
FML32および
VIEW32では、
FINIT32、
FVSTOF32、および
FVFTOS32プロシージャを使用する必要があります。
正常終了した場合は、
FML-STATUSに
FOKが設定されます。エラーが発生した場合は、
FML-STATUSに0以外の値が設定されます。
クライアント・プログラムやサービス・サブルーチンで
FML型レコードを使用するには、
FMLヘッダー・ファイルを作成し、アプリケーションの
#include文にそのヘッダー・ファイルを指定する必要があります。
フィールド表ファイルから
FMLヘッダー・ファイルを作成するには、
mkfldhdr(1)コマンドを使用します。たとえば、
myview.flds.hというファイルを作成するには、次のコマンドを入力します。
FML32型レコードの場合は、
mkfldhdr32コマンドを使用します。
リスト3-6は、
mkfldhdrコマンドによって作成される
myview.flds.hヘッダー・ファイルを示しています。
リスト3-6
myview.flds.hヘッダー・ファイル
/* fname fldid */
/* ----- ----- */
#define FLOAT1 ((FLDID)24686) /* number: 110 type: float */
#define DOUBLE1 ((FLDID)32879) /* number: 111 type: double */
#define LONG1 ((FLDID)8304) /* number: 112 type: long */
#define SHORT1 ((FLDID)113) /* number: 113 type: short */
#define INT1 ((FLDID)8306) /* number: 114 type: long */
#define DEC1 ((FLDID)41075) /* number: 115 type: string */
#define CHAR1 ((FLDID)16500) /* number: 116 type: char */
#define STRING1 ((FLDID)41077) /* number: 117 type: string */
#define CARRAY1 ((FLDID)49270) /* number: 118 type: carray */
アプリケーションの
#include文に新しいヘッダー・ファイルを指定します。ヘッダー・ファイルがインクルードされると、シンボリック名でフィールドを参照できるようになります。
XML型レコードを使用すると、Oracle TuxedoアプリケーションでXMLを使用して、アプリケーション内やアプリケーション間でデータを交換できるようになります。Oracle Tuxedoアプリケーションでは、単純な
XML型レコードの送受信や、それらのレコードを適切なサーバーにルーティングできます。解析など、
XMLドキュメントのすべての処理ロジックはアプリケーション側にあります。
|
•
|
ドキュメントの論理構造の記述と、その構造に関する情報 |
イベント処理で行われるフォーマット処理とフィルタリングは、
STRING型レコードが使用されている場合はサポートされますが、
XML型レコードではサポートされません。そのため、
XML型レコードのレコード・タイプ・スイッチ内の
_tmfilterと
_tmformatのポインタは、LOW-VALUEに設定されます。
Oracle Tuxedoシステムの
XMLパーサーは、次の操作を行います。
XML型レコードでは、データ依存型ルーティングがサポートされています。
XML文書のルーティングは、要素の内容、または要素のタイプと属性値に基づいて行われます。使用される文字エンコーディングは
XMLパーサーによって判別されます。エンコーディングがOracle Tuxedoの構成ファイル(
UBBCONFIGと
DMCONFIG)で使用されるネイティブな文字セット(US-ASCIIまたはEBCDIC)と異なる場合、要素と属性名はUS-ASCIIまたはEBCDICに変換されます。
XMLドキュメントには、ルーティング用に設定する属性を含めなければなりません。属性がルーティング基準として設定されていても
XMLドキュメントに含まれていない場合、ルーティング処理は失敗します。
要素の内容と属性値は、ルーティング・フィールド値の構文とセマンティクスに従っていることが必要です。また、ルーティング・フィールド値のタイプも指定しなければなりません。
XMLでサポートされるのは文字データだけです。範囲フィールドが数値の場合、そのフィールドの内容や値はルーティング処理時に数値に変換されます。
