![]() ![]() ![]() ![]() ![]() ![]() |
他のアプリケーション・プログラムにデータを送信する場合、送信側のプログラムはまずデータをレコードに格納します。Oracle Tuxedo ATMIクライアントは、型付きレコードを使用してATMIサーバーにメッセージを送ります。型付きレコードとは、データ・レコードと補助型レコードが対になったCOBOL言語のレコードです。データ・レコードは、静的領域内に定義され、別のアプリケーション・プログラムに渡すアプリケーション・データが入ります。データ・レコードには、補助型レコードが付加されます。これは、異機種間システム間で情報をやり取りする場合に、Oracle Tuxedoシステムで使用されるデータ・レコードの解釈と変換の規則を指定します。型付きレコードは、Oracle Tuxedoシステムでサポートされる分散プログラミング環境の基本要素の1つです。
なぜ「型付き」レコードを使用するのでしょうか。 分散環境では、アプリケーションが異機種システムにインストールされ、異なるプロトコルを使用して複数のネットワーク間で通信が行われます。 レコード・タイプが異なると、初期化、メッセージの送受信、およびデータのエンコード/デコードにそれぞれ別のルーチンが必要になります。 各レコードに特定のタイプが割り当てられていると、プログラマが介在しなくても、そのタイプに対応するルーチンを自動的に呼び出すことができます。
表3-1は、Oracle Tuxedoシステムでサポートされる型付きレコードと、そのレコードが次の条件を満たしているかどうかを示しています。
ルーティング用のルーチンが必要な場合は、アプリケーション・プログラマが用意します。
Oracle Tuxedoシステム固有の自己記述型レコード・タイプ。このレコードでは、各データ・フィールドに対応する識別子、オカレンス番号、場合によっては長さを示す値が格納されています。 型付きレコードでは、データからの独立性と柔軟性が確立されています。
詳細は、「FML型レコード」を参照してください。
|
|||||
ただし、Cプログラミング言語で
FML 型レコードの操作に使用できるFML ルーチンは、COBOL言語では使用できません。COBOL言語でFML32 を使用する主な目的は、単にVIEW32 またはFML32 型レコードが使用されているC言語プログラムを操作することです。
詳細は、「FML型レコード」を参照してください。
|
|||||
アプリケーションで定義されるCOBOLデータ構造体。
VIEW 型には、個々のデータ構造体を示すサブタイプが必要です。VIEW記述ファイル (データ構造体のフィールドとタイプが定義されたファイル)は、VIEW 型レコードに定義されたデータ構造体を使用するクライアント・プロセスとサーバー・プロセスがアクセスできなければなりません。異なるタイプのマシン間でレコードがやり取りされる場合は、エンコード/デコードが自動的に行われます。詳細は、「VIEW型レコード」を参照してください。
|
|||||
詳細は、「VIEW型レコード」を参照してください。
|
|||||
XMLドキュメントのルーティングは、要素の内容、または要素タイプと属性値に基づいて行われます。使用されている文字エンコーディングはXMLパーサによって判別されます。エンコーディングがOracle Tuxedoの構成ファイル(UBBCONFIG(5)とDMCONFIG(5))で使用されているネイティブな文字セット(US-ASCIIまたはEBCDIC)と異なる場合、要素と属性名はUS-ASCIIまたはEBCDICに変換されます。詳細は、「XML型レコード」を参照してください。
|
|||||
すべてのレコード・タイプは、$TUXDIR/lib
ディレクトリのtmtypesw.c
ファイルに定義されています。 クライアント・プログラムとサーバー・プログラムで認識されるレコード・タイプは、tmtypesw.c
に定義されているものだけです。 tmtypesw.c
ファイルを編集して、レコード・タイプを追加したり削除できます。 また、UBBCONFIG
のBUFTYPE
パラメータを使用して、特定のサービスで処理できるタイプとサブタイプを制限できます。
tmtypesw.c
ファイルは、共用オブジェクトやダイナミック・リンク・ライブラリのビルドに使用されます。 このオブジェクトは、Oracle Tuxedo管理サーバー、およびアプリケーション・クライアントとアプリケーション・サーバーによって動的にロードされます。
TPTYPE-REC
COBOL構造体は、アプリケーション・データの送受信に必ず使用されます。
次の表は、TPTYPE-REC
構造体のフィールドを示しています。
次のサンプル・コードは、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関数リファレンス』を参照してください。
COPY
ファイルが各VIEW記述ファイルに生成され、各COPYファイルには、データ記述レコードが記述されます。これらのレコードは、プログラムの要求に応じて、DATA DIVISION
のLINKAGE
セクションまたはWORKING STORAGE
セクションで使用できます。 アプリケーションでVIEW
型レコードを使用するには、表3-2の環境変数を設定します。
VIEW
型レコードを使用するには、VIEW記述ファイルにCOBOLレコードを定義する必要があります。 VIEW記述ファイルには、各エントリのVIEW、およびCOBOLプロシージャのマッピングとFML
変換パターンを記述したVIEWが定義されています。 VIEWの名前は、COBOLプログラムに含まれるcopyファイルの名前に相当します。
$ /* VIEW構造体*/
VIEW viewname
type cname fbname count flag size null
表3-3は、VIEW記述ファイルに指定する必要がある各COBOLレコードのフィールドを示しています。
FML からVIEW 、またはVIEW からFML への変換ルーチンを使用する場合、対応するFML 名をこのフィールドに指定する必要があります。このフィールド名は、FML フィールド表ファイルにも必要です。FMLに依存しないVIEWには必要ありません。
|
|
数値型の場合、デフォルトの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 、\\ 、\’ 、および\” です。
|
行頭に#または$文字を付けてコメント行を挿入できます。 行頭に$が挿入されたコード行は、.h
ファイルに出力されます。
リスト3-11は、FML
レコードに基づくVIEW記述サンプル・ファイルの一部です。この場合は、fbname
フィールドを指定する必要があり、この値は対応するフィールド表ファイルの値と一致している必要があります。CARRAY1
フィールドのオカレンス・カウントが2
に設定されていること、C
フラグが設定されて追加のカウント要素の作成が定義されていることに注目してください。また、L
フラグが設定され、アプリケーションがCARRAY1
フィールドを格納するときの文字数を示す長さ要素が定義されています。
$ /* 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
のものを示しています。
$ /* 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
をコンパイルするには、次のようにコンパイラを実行します。
viewc -C myview.v
注意: | VIEW32 型レコードをコンパイルするには、viewc32 -C コマンドを実行します。 |
非依存型VIEW
の場合、コマンドラインで次のように-n
オプションを指定します。
viewc -C -n myview.v
リスト3-3は、viewc
によって生成される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レコードの配置を満たすために取り込まれます。 COBOLアプリケーションでは、これらのフィールドを使用しないでください。
5番目のフィールド(DEC-DGTS
)には、システムによって実際のパック10進値が格納されます。 COBOLプログラムではこの値を使用する必要があります。 ATMI呼出しは、DEC-DGTS
フィールドに以下の操作を行います。
唯一の制約として、COBOL言語プログラムでは、ATMIインタフェース外からC言語関数に直接レコードを渡すことはできません。COBOL言語プログラムとC言語関数では10進数の形式が異なるからです。
最後に、COBOLのCOPY
サンプル・ファイルでL-CARRAY1
長さフィールドが2回使用されていることに注目してください。つまり、CARRAY1
とC-CARRAY1
カウント・フィールドに対して1回ずつ使用されています。
viewc
は、C言語バージョンのヘッダー・フィルを生成します。このファイルを使用すると、CとCOBOL言語のサービスやクライアント・プログラムを混在させることができます。
FML
インタフェースは、C言語で使用されるように設計されたものです。 COBOL言語に対しては、ルーチンが提供されています。そのため、受信したFML
型レコードをCOBOLレコードに変換して処理した後で、FML
型に再度変換できます。
FINIT
を使用してFML
レコードを初期化します。FML
ヘッダー・ファイルを作成し、アプリケーションで同じVIEWを共有するC言語ルーチンの#include
文に、そのヘッダー・ファイルを指定します。 FML
ルーチンは、フィールド化レコードからC構造体への変換、またその逆の変換など、型付きレコードを操作する場合に使用します。これらの関数を使用すると、データ構造やデータの格納状態がわからなくても、データ値にアクセスしたり更新できます。FML
ルーチンの詳細は、『Oracle Tuxedo ATMI FML関数リファレンス』を参照してください。
アプリケーション・プログラムでFML
型レコードを使用するには、表3-4の環境変数を設定します。
FML
型レコードやFML
依存型VIEW
を使用する場合は、常にフィールド表ファイルが必要です。フィールド表ファイルは、FML
型レコードのフィールドの論理名をそのフィールドをユニークに識別する文字列にマッピングします。
$ /* FML structure */
*basevalue
name number type flags comments
表3-5は、FML
フィールド表ファイルに指定する必要があるFML
フィールドを示しています。
すべてのフィールドは省略可能です。また、複数個使用できます。
リスト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
を呼び出す必要はありません。
リスト3-5は、初期化の実行方法を示しています。
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.
.....
* MOVE DATA INTO 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.
このサンプル・コードでは、FVSTOF
プロシージャでFML
レコードをVIEW
レコードに変換しています。 VIEWを定義するために、VIEWコンパイラによって生成されたcopyファイルが読み込まれています。 FML-REC
レコードにはVIEWNAME
とFML-MODE
転送モードがあり、転送モードにはFUPDATE
、FOJOIN
、FJOIN
、またはFCONCAT
を設定できます。 これらのモードで行われる処理は、Fupdate、Fupdate32(3fml)、Fojoin、Fojoin32(3fml)、Fjoin、Fjoin32(3fml)、およびFconcat、Fconcat32(3fml)での処理と同じです。
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
というファイルを作成するには、次のコマンドを入力します。
mkfldhdr myview.flds
FML32
型レコードの場合は、mkfldhdr32
コマンドを使用します。
リスト3-6は、mkfldhdr
コマンドによって作成される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
でサポートされるのは文字データだけです。 範囲フィールドが数値の場合、そのフィールドの内容や値はルーティング処理時に数値に変換されます。
![]() ![]() ![]() |