|
|
他のアプリケーション・プログラムにデータを送信する場合、送信側のプログラムはまずデータをレコードに格納します。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アプリケーションでは、これらのフィールドを使用しないでください。
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 */
*basevaluename 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でサポートされるのは文字データだけです。範囲フィールドが数値の場合、そのフィールドの内容や値はルーティング処理時に数値に変換されます。
  
|