Oracle TMA TCP Gatewayのデータ・マッピングに関する構成

システム間の透過性を高いレベルに維持する上で、Tuxedo Mainframe Adapter for TCP Gateway (以後TMA TCP Gatewayと呼ぶ)の構成が重要になります。データ・フォーマットなどの環境の違いは、このメカニズムによってプログラマやプログラムからは遮蔽されます。

このドキュメントでは、次のトピックについて説明します。

•

入出力データの変換

•	バッファおよびレコード変換用パラメータの管理

•

データの変換

•	COBOLのデータ型のエンコーディング

•	コード・ページ変換表の使用方法

•	マルチバイト文字セット(MBCS)変換の使用

このドキュメントでは、VIEW定義の作成についても説明します。VIEW定義とは、Oracle Tuxedo環境の入出力に使用するデータ構造を記述したものです。TMA TCP Gateway製品はVIEW定義に基づいて、ターゲット・システムで受付け可能なフォーマットに入出力データを変換する方法を判断します。

TMA TCP Gatewayの構成ファイル(GWICONFIGとDMCONFIG)の更新に関する詳細は、「Oracle TMA TCP Gatewayの構成」の項を参照してください。

注意:	データ・マッピングを構成する手順は、Oracle Tuxedoのプログラミング環境に対する知識が必要になるという点で、プログラミングという行為と考えて差し支えありません。しかし、構成パラメータの影響を受けるアプリケーション・プログラムは多数に及ぶため、通常は管理者が構成を担当します。

入出力データの変換

この項では、TMA TCP Gatewayが入出力データの処理や変換を行う際に従う手順について説明します。

バッファおよびレコード

このガイドでは、入出力データを説明する上で次の用語を使用しています。

バッファ

ローカルのOracle Tuxedoリージョンに存在するときの入出力データ。この定義の中には、Oracle Tuxedoソフトウェアがサポートしているすべてのバッファ・タイプ(Oracle Tuxedo ATMIバッファ・タイプとX/Open XATMIバッファ・タイプ)が含まれます。

レコード

ローカルのOracle Tuxedoリージョンの外側(異なるタイプのシステム)に存在するときの入出力データ。

これらの用語を知っておけば、TMA TCP Gatewayがどのように入出力データを扱うのかを理解しやすくなります。

ローカル・プログラムから受信したバッファ

TMA TCP Gatewayはローカル・プログラムからのバッファを次のように処理します。

1.	TMA TCP Gatewayはローカル・プログラムからバッファを受信するときに、バッファのタイプを自動的に判断します。

TMA TCP Gateway製品は、ローカルのクライアント・プログラムからリモート・サービスに送信される入力バッファのタイプを自動的に判定します。

TMA TCP Gateway製品は、ローカル・サービスからリモートのクライアント・プログラムに戻される出力バッファのタイプを自動的に判定します。

2.	TMA TCP Gatewayはバッファのタイプを判定した後に、構成ファイル(GWICONFIG)を参照して、そのバッファを別のフォーマットに変換する必要があるかどうかを確認します。

リモート・サービスに送信されたクライアント・リクエストは、これらのサービスで意味のあるレコード形式に変換する必要があります。

リモート・クライアント・プログラムに戻されたサーバー・レスポンスは、これらのプログラムで意味のあるレコード形式に変換する必要があります。

3.	構成に変換が必要との情報がある場合には、TMA TCP Gatewayは、構成に指定されているレコード・フォーマットにバッファを変換します。

リモート・プログラムから受信したレコード

TMA TCP Gatewayはリモート・プログラムのバッファを次のように処理します。

1.	TMA TCP Gatewayはリモート・システムからレコードを受信するときに、構成ファイル(GWICONFIG)の定義を参照してレコードのタイプを判断します。

2.	TMA TCP Gatewayはレコードのタイプを判断した後に、ドメイン構成(DMCONFIG)の定義を参照して、そのレコードを別のフォーマットに変換する必要があるかどうかを確認します。

リモート・クライアント・プログラムからのクライアント・リクエストは、ローカル・サービス・ルーチンで受入れ可能なバッファ形式に変換する必要があります。

リモート・サービスから戻されたサーバー・レスポンスは、ローカル・クライアント・プログラムで受入れ可能なバッファ形式に変換する必要があります。

3.	構成に変換が必要との情報がある場合には、TMA TCP Gatewayは、構成に指定されているバッファ・フォーマットにレコードを変換します。

バッファおよびレコード変換用パラメータの管理

TMA TCP Gateway製品には、バッファとレコードのマップに使用できる構成パラメータが用意されています。バッファとレコードの詳細は、「バッファおよびレコード」の項を参照してください。

ドメイン構成ファイル(DMCONFIG)に次のバッファ構成パラメータを指定します。

INBUFTYPE

TuxedoクライアントまたはTuxedoサーバーから受信するバッファのタイプ(さらに場合によってはフォーマット)を指定します。

OUTBUFTYPE

TuxedoクライアントまたはTuxedoサーバーに送信するバッファのタイプ(さらに場合によってはフォーマット)を指定します。

ゲートウェイ構成ファイル(GWICONFIG)に次のレコード構成パラメータを指定します。

INRECTYPE

リモート・ゲートウェイに送信するバッファのタイプ(さらに場合によってはフォーマット)を指定します。

OUTRECTYPE

リモート・ゲートウェイから受信するバッファのタイプ(さらに場合によってはフォーマット)を指定します。

これらの4つのパラメータには、それぞれ想定される意味合い(解釈)が2つあり、1つはサービス・リクエストがローカルから発行されるときの意味合いであり、もう1つはリモート・システムから発行されるときの意味合いです。

これからの項で説明する「ローカルからの呼出しの場合のパラメータ」と「リモートからの呼出しの場合のパラメータ」で、これらの意味合いのそれぞれについて詳細に説明します。

ローカルによる呼出し用パラメータ

この項では、TMA TCP Gatewayがどのようにローカル(こちら側のOracle Tuxedoリージョンの中)からのサービス呼出しを処理しているのかについて詳しく説明します。また、ローカルのクライアント・プログラムとリモート・サービスの間でやり取りされるバッファやレコードの変換を管理するために、INBUFTYPE、INRECTYPE、OUTRECTYPEおよびOUTBUFTYPEの各パラメータをどのように使用するのかについても説明します。

次の図は、ローカルのOracle Tuxedoクライアント・プログラムから発行されたサービス呼出しが、ローカルのTMA TCP GatewayからTMA TCP Gatewayを経由してリモート・サーバーに届くまでを示しています。

図3-1 ローカルからの呼出しにおけるパラメータのマップの仕組み

このような状況では、図に示す4つのパラメータは次のような意味を持ちます。

•	INBUFTYPEパラメータは、ローカルのクライアント・プログラムからOracle Tuxedoソフトウェアを介してTMA TCP Gatewayに渡されるOracle Tuxedoの入力バッファを表します。

•	INRECTYPEパラメータは、リモート・システム上のサービスに送信される入力レコードを示しています。

•	OUTRECTYPEパラメータは、リモート・システム上のサービスから受信する出力レコードを示しています。

•	OUTBUFTYPEパラメータは、ローカル・クライアント・プログラムに戻されるOracle Tuxedo出力バッファを示しています。

入力バッファから入力レコードへのマッピング・ガイドライン

次の項では、ローカルによるサービス呼出し(ローカル・クライアント・プログラムからのリモート・サービスの呼出し)におけるINBUFTYPEおよびINRECTYPEパラメータの使用方法について詳しく説明します。

INBUFTYPE

INBUFTYPEパラメータの用途は、ローカルのクライアント・プログラムがサービス・リクエストを発行するときに、ローカルのTMA TCP Gatewayに渡されるリクエストがどのバッファ・タイプなのかを指定することです。

ゲートウェイは実行時にクライアント・リクエストのバッファのタイプを自動的に判断するため、このパラメータをここに記述する意味合いは単に、概念的な一貫性を持たせることです。

INRECTYPE

INRECTYPEパラメータは、特定のリモート・サービスから要求されるリクエスト・レコードのタイプ(さらに場合によってはフォーマット)の指定に使用します。TMA TCP Gatewayは、この情報を使用して、リモート・サービスによる処理が可能なレコードにOracle Tuxedoのリクエスト・バッファを変換します。

次の表に記述されている状況のいずかに該当する場合は、INRECTYPEパラメータを指定する必要があります。

 

状況	説明
リモート・サービスが、クライアント・プログラムのリクエスト・バッファとは異なる構造の入力レコードを使用する場合。	この場合、リモート・サービスはクライアント・プログラムのVIEW、X_C_TYPE、X_COMMONのどのバッファとも異なる構造のレコードを使用します。たとえば、リモート・サービスが、並び順の異なる構造体メンバーを受け取ることを前提にしているケースもあります。
リモート・サービスで、タイプと構造の両方がクライアント・プログラムのリクエスト・バッファとは異なるリクエスト・レコードが使用される場合。	この場合、クライアント・プログラムはOracle TuxedoのFMLバッファを使用し、リモート・サービスは、それに相当する、適切な構造を持つレコードを受け取ることを前提にします。

INRECTYPEパラメータは、リクエスト・バッファのタイプと構造がリモート・サービスで想定されるリクエスト・レコードと同じ場合は省略されます。

出力レコードから出力バッファへのマッピング・ガイドライン

次の項では、ローカルによるサービス呼出し(ローカル・クライアント・プログラムからのリモート・サービスの呼出しおよびサービスからの出力の受信)におけるOUTRECTYPEおよびOUTBUFTYPEパラメータの使用方法について詳しく説明します。

OUTBUFTYPE

OUTBUFTYPEパラメータは、ローカルのクライアント・プログラム側で前提にしている応答バッファのタイプ(さらに場合によっては構造)の指定に使用します。TMA TCP Gatewayは、この情報を使用して、リモート・サービスからの応答レコードを適切なタイプの応答バッファにマップします。

OUTRECTYPE

OUTRECTYPEパラメータは、特定のリモート・サービスからローカルのTMA TCP Gatewayに戻される応答レコードのタイプ(さらに場合によってはフォーマット)の指定に使用します。

次の表に記述されている状況のいずかに該当する場合は、OUTRECTYPEパラメータを指定する必要があります。

 

状況	説明
ローカルのクライアント・プログラム側で前提としている応答バッファとは異なる構造の応答レコードをリモート・サービスが戻す場合。	この場合、リモート・サービスは、クライアント・プログラムのVIEW、X_C_TYPE、X_COMMONのいずれのバッファとも異なる構造のレコードを戻します。たとえば、出力レコードの構造体メンバーが、出力バッファの構造体メンバーと異なる並び順になっていることがあります。
リモート・サービスで、クライアント・プログラムが想定する応答バッファとは異なるタイプおよび構造の応答レコードが戻される場合。	この場合、リモート・サービスは所定のレコードを戻し、ローカルのクライアント・プログラムは、対応するOracle TuxedoのFMLバッファを受け取る前提で待ちます。

OUTRECTYPEパラメータは、リモート・サービスから戻される応答レコードのタイプと構造がローカル・クライアント・プログラムで想定される応答バッファと同じ場合は省略されます。

リモートによる呼出し用パラメータ

この項では、TMA TCP Gatewayがどのようにリモート・コンピュータ(ローカルのOracle Tuxedoリージョンの外側)からのサービス呼出しを処理しているのかについて詳しく説明します。また、リモートのクライアント・プログラムとローカル・サービスの間でやり取りされるバッファやレコードの変換を管理するために、INRECTYPE、INBUFTYPE、OUTBUFTYPEおよびOUTRECTYPEの各パラメータをどのように使用するのかについても説明します。

次の図では、リモートのクライアント・プログラムがサービス・リクエストを発行し、そのリクエストはリモートのTMA TCP GatewayからローカルのTMA TCP Gatewayに送信されます。ゲートウェイはネットワークからリクエストを受信すると、ローカルのOracle Tuxedoサーバーにそのリクエストを渡します。

図3-2 リモートからの呼出しにおけるパラメータのマップの仕組み

 

このような状況では、図に示す4つのパラメータは次のような意味を持ちます。

•	OUTRECTYPEパラメータは、リモート・クライアントからTMA TCP Gatewayに送信される出力レコードを表します。

•	OUTBUFTYPEパラメータは、ローカル・サーバーに渡されるOracle Tuxedoの出力バッファを表します。

•	INBUFTYPEパラメータは、ローカル・サーバーからTMA TCP Gatewayに戻されるOracle Tuxedoの入力バッファを表します。

•	INRECTYPEパラメータは、ローカルのTMA TCP Gatewayからリモートのクライアント・プログラムに戻される入力レコードを表します。

入力レコードから入力バッファへのマッピング・ガイドライン

これより、リモート・システム(リモートのクライアント・プログラムからのローカル・サービス呼出しを行うシステム)からサービスを呼び出す際に、INRECTYPEパラメータとINBUFTYPEパラメータをどのように使用するのかについて詳しく説明します。

INBUFTYPE

INBUFTYPEパラメータは、TMA TCP Gatewayがローカル・サーバーから受け取るときの前提にしている、応答バッファのタイプ(さらに場合によっては構造)の指定に使用します。TMA TCP Gatewayは、この情報を使用して、ローカル・サーバーのプログラムからの応答バッファを適切なタイプの応答レコードにマップします。

ゲートウェイは実行時に着信バッファのタイプを自動的に判断するため、このパラメータをここに記述する意味合いは単に、概念的な一貫性を持たせることです。

INRECTYPE

INRECTYPEパラメータは、ローカルのTMA TCP Gatewayからリモート・クライアントに送信される応答レコードのタイプ(さらに場合によってはフォーマット)の指定に使用します。

次の表に記述されている状況のいずかに該当する場合は、INRECTYPEパラメータを指定する必要があります。

 

状況	説明
ローカル・サービスから渡される応答バッファとは異なる構造の応答レコードをリモートのクライアント・プログラムが要求する場合。	この場合、リモートのクライアント・プログラムは、ローカル・サービスのVIEW、X_C_TYPE、X_COMMONのいずれのバッファとも異なる構造のレコードを戻します。たとえば、入力レコードの構造体メンバーが、入力バッファの構造体メンバーと異なる並び順になっていることがあります。
リモート・クライアント・プログラムで、ローカル・サービスから送信される応答バッファとな異なるタイプおよび構造の応答レコードが必要とされる場合。	この場合、リモートのクライアント・プログラムは所定のレコードを要求し、ローカル・サービスは対応するOracle TuxedoのFMLバッファを戻します。

ローカル・サーバーのプログラムが送信する応答バッファが、タイプ面でも構造面でも、リモート・クライアント側で前提としている応答レコードと一致するのであれば、INRECTYPEパラメータは省略してもかまいません。

出力バッファから出力レコードへのマッピング・ガイドライン

これより、リモート・コンピュータ(リモートのクライアント・プログラムからのローカル・サービス呼出しと、そのサービスからの出力の受取りを行うコンピュータ)からサービスを呼び出す際に、OUTBUFTYPEパラメータとOUTRECTYPEパラメータをどのように使用するのかについて詳しく説明します。

OUTBUFTYPE

OUTBUFTYPEパラメータは、ローカルのTMA TCP Gatewayからローカル・サーバーに渡されるリクエスト・バッファのタイプを表します。

OUTRECTYPE

OUTRECTYPEパラメータは、特定のリモートのクライアント・プログラムからTMA TCP Gatewayに送信されるリクエスト・レコードのタイプ(さらに場合によってはフォーマット)の指定に使用します。TMA TCP Gatewayは、この情報を使用して、ローカル・サーバーのプログラムによる処理が可能なバッファに、リモート・クライアントからのリクエスト・レコードを変換します。

次の表に記述されている状況のいずかに該当する場合は、OUTRECTYPEパラメータを指定する必要があります。

 

状況	説明
ローカル・サービスのリクエスト・バッファとは異なる構造のリクエスト・レコードがリモートのクライアント・プログラムから渡される場合。	この場合、リモートのクライアント・プログラムは、ローカル・サービスのVIEW、X_C_TYPE、X_COMMONのいずれのバッファとも異なる構造のレコードを示します。たとえば、ローカル・サーバーのプログラムが、並び順が異なる構造体メンバーを受け取ることを前提にしているケースもあります。
ローカル・サービスのリクエスト・バッファとはタイプも構造も異なるリクエスト・レコードがリモートのクライアント・プログラムから渡される場合。	この場合、リモート・クライアントはレコードを出力し、ローカルのクライアント・プログラムは、対応するOracle TuxedoのFMLバッファを受け取る前提で待ちます。

OUTRECTYPEパラメータは、ローカル・サービスのリクエスト・バッファのタイプと構造がリモート・クライアント・プログラムから送信されるリクエスト・レコードと同じ場合は省略されます。

バッファからレコードへのマッピング

バッファをレコードにマップするパターンとして想定しうるものをすべて表すと、次の図のようになります。TMA TCP Gatewayの役割は、TMA TCP Gateway構成の中で確認した情報に基づいて、バッファをレコードにマップすることです。このマッピングの対象になるものは、TuxedoクライアントのリクエストとTuxedoサーバーのレスポンスです。

図3-3 バッファからレコードへのマッピング

INBUFTYPEパラメータとINRECTYPEパラメータの設定

前述の図に示した想定しうるマッピングのパターンの一部と、INBUFTYPEパラメータとINRECTYPEパラメータの設定に関する説明を次の表にまとめています。

 

1	Oracle TuxedoのCARRAY型の入力バッファをCARRAY型の入力レコードにコピーできます。CARRAY型のバッファには、レイアウトもデータ型も変換されない、そのままの状態のデータが格納されます。INBUFTYPEパラメータをCARRAYに設定し、INRECTYPEパラメータは指定しません。 CARRAY型の入力バッファはSTRING型の入力レコードにもコピーできます。この場合は、レイアウトもデータ型も変換されずに文字列が作成されます。処理結果のバッファは、元のCARRAY型バッファの長さです。文字がすべてコピーされるため、CARRAY型バッファにNULL文字が含まれている場合は、後でそのバッファがSTRING型として扱われるときに影響を与えます。INBUFTYPEパラメータをCARRAYに設定し、INRECTYPEパラメータをSTRINGに設定する必要があります。
2	Oracle TuxedoのSTRING型の入力バッファをCARRAY型の入力レコードにマップできます。データのレイアウトも型も変更されません。左端にNULL文字が格納されている場合にのみ、STRING型バッファはコピーされます。INBUFTYPEパラメータをSTRINGに設定し、INRECTYPEパラメータをCARRAYに設定します。
3	Oracle TuxedoのSTRING型の入力バッファをSTRING型の入力レコードにマップできます。バッファはデータ型の変換(ASCIIからEBCDICへの変換など)の対象になります。INBUFTYPEパラメータSTRINGに設定し、INRECTYPEパラメータは指定しません。
4	Oracle TuxedoのVIEW型の入力バッファを、それに相当するOracle TuxedoのVIEW型の入力レコードにマップできます。この場合は、リモート・サービス側で前提にしているデータ構造が、クライアント・プログラムが使用するデータ構造と一致します。新しくVIEW定義を作成する必要はありません。かわりに、入力レコードのタイプ(VIEW)と既存のVIEW定義(クライアント・プログラムが現在使用している定義)の名前の両方をINBUFTYPEパラメータに指定し、INRECTYPEパラメータは指定しません。
5	Oracle TuxedoのVIEW型の入力バッファを、任意に組み合せたVIEW型の入力レコードにマップできます。しかし、この場合は、リモート・サービス側で前提にしているデータ構造(図3-3のマッピングのパターンのVIEW 'B')と、クライアント・プログラムが使用するデータ構造(図3-3ではVIEW 'A')は異なります。したがって、次の操作が必要です。 1. リモート・サービスで想定されるデータ構造のVIEW定義を作成します。 2. このVIEW定義で必要なレコード・タイプと名前をINRECTYPEパラメータ内で指定します。 3. INBUFTYPEパラメータをVIEW:original-viewnameに設定します。
6	Oracle TuxedoのFML型の入力バッファを、FMLをサポートしていないリモート・サービスに送信できるように、VIEW、X_C_TYPEまたはX_COMMONのいずれかの入力レコード・タイプにマップする必要があります。また、リモート・サービス側で前提にしている入力データ構造に合わせてVIEW定義を作成する必要もあります。INBUFTYPEをFMLに設定し、INRECTYPEをVIEW:viewnameに設定します。 注意: DMCONFIGファイルでは、FMLまたはFML32をINBUFTYPEまたはOUTBUFTYPEとして指定する場合は、タイプの後にコロン(:)を付ける必要があります。(例: INBUFTYPE="FML32:")

レコードからバッファへのマッピング

レコードをバッファにマップするパターンとして想定しうるものをすべて表すと、次の図のようになります。TMA TCP Gatewayの役割は、TMA TCP Gateway構成の中で確認した情報に基づいて、レコードをバッファにマップすることです。このマッピングの対象になるものは、リモートのクライアント・リクエストとリモートのサーバー・レスポンスです。

図3-4 レコードからバッファへのマッピング

 

OUTRECTYPEパラメータとOUTBUFTYPEパラメータの設定

前述の図に示した想定しうるマッピングのパターンの一部と、OUTRECTYPEパラメータとOUTBUFTYPEパラメータ(ローカルからのサービス呼出しに使用するパラメータ)の設定に関する説明を次の表にまとめています。

 

1	Oracle TuxedoのCARRAY型の出力レコードをCARRAY型の出力バッファにコピーできます。CARRAY型のバッファには、レイアウトもデータ型も変換されない、そのままの状態のデータが格納されます。OUTBUFTYPEパラメータをCARRAYに設定します。OUTRECTYPEパラメータを設定する必要はありません。 Oracle TuxedoのCARRAY型の出力レコードはSTRING型の出力バッファにもコピーできます。この場合は、レイアウトもデータ型も変換されずに文字列が作成されます。処理結果のバッファは、元のCARRAY型バッファの長さです。文字がすべてコピーされるため、CARRAY型バッファにNULL文字が含まれている場合は、後でそのバッファがSTRING型として扱われるときに影響を与えます。OUTRECTYPEパラメータをCARRAYに設定し、OUTBUFTYPEパラメータをSTRINGに設定する必要があります。
2	Oracle TuxedoのSTRING型の出力レコードをCARRAY型の出力バッファにマップできます。データのレイアウトも型も変更されません。左端にNULL文字が格納されている場合にのみ、STRING型のバッファはコピーされます。OUTRECTYPEパラメータをSTRINGに設定し、OUTBUFTYPEパラメータをCARRAYに設定します。
3	Oracle TuxedoのSTRING型の出力レコードをSTRING型の出力バッファにマップできます。バッファはデータ型の変換(ASCIIからEBCDICへの変換など)の対象になります。OUTBUFTYPEパラメータとOUTRECTYPEパラメータをSTRINGに設定します。
4	Oracle TuxedoのVIEW型の出力レコードを、それに相当するOracle TuxedoのVIEW型の出力バッファにマップできます。この場合は、リモート・サービスから戻されるデータ構造が、ローカルのクライアント・プログラム側で前提にしているデータ構造と一致します。新しくVIEW定義を作成する必要はありません。かわりに、OUTBUFTYPEパラメータを使用して、VIEWバッファ・タイプと既存のVIEW定義の名前を指定します。OUTRECTYPEパラメータをVIEW:viewnameに設定してもかまいませんが、必須ではありません。
5	Oracle TuxedoのVIEW型の出力レコードを、任意に組み合せたVIEW型の出力バッファにマップできます。しかし、この場合は、リモート・サービスから戻されるデータ構造(図3-4のVIEW 'B')と、クライアント・プログラム側で前提にしているデータ構造(図3-4のVIEW 'A')は異なります。変換処理を円滑に行うために、次の操作を行います。 1. リモート・サービスから戻されるデータ構造のVIEW定義を作成します。 2. VIEW定義に付与した名前と、リモート・サービスから戻される名前(つまりATMIバッファ・サブタイプ)が異なる場合は、OUTRECTYPEパラメータを指定して、出力レコードのタイプとVIEW 'B'の名前を指定します。(こうすると、TMA TCP Gatewayのリクエスタが自動的に検出する値がオーバーライドされます。) 3. OUTBUFTYPEパラメータで指定されている既存ビュー(図のVIEW ‘A')の出力バッファ・タイプと名前を指定します。
6	Oracle TuxedoのVIEW型の出力レコードをFML型の出力バッファにマップできます。変換処理が円滑に行われるように、次の操作を行う必要があります。 1. リモート・サービスから戻されるデータ構造のVIEW定義を作成します。 2. VIEW定義に付与した名前と、リモート・サービスから戻される名前(つまりATMIバッファ・サブタイプ)が異なる場合は、OUTRECTYPEパラメータを指定して、出力レコードのタイプとVIEW定義の名前を指定します。(こうすると、TMA TCP Gatewayのリクエスタが自動的に検出する値がオーバーライドされます。) 3. OUTBUFTYPEパラメータをFMLに設定します。 注意: DMCONFIGファイルでは、FMLまたはFML32をINBUFTYPEまたはOUTBUFTYPEとして指定する場合は、タイプの後にコロン(:)を付ける必要があります。(例: INBUFTYPE="FML32:")

バッファの変換を円滑に行うためのVIEW定義の作成

VIEW定義は、リモート・システムとの間で送受信する入出力レコードの記述に使用します。これは、データ要素を記述し、データ要素の型と並びがどのようになっているかを示します。これらの記述に基づいて、TMA TCP Gatewayは必要に応じて、フィールドのデータ型を変換して、異なるタイプのシステム間の透過性を維持します。

TMA TCP Gatewayを構成する前に、VIEW定義を作成する必要があります。VIEW定義と関連項目の詳細は、Oracle Tuxedoのドキュメントを参照してください。

TMA TCP Gatewayのバッファ変換とレコード変換の特性は、性能と柔軟性が非常に高いことです。このような特性を最大限活かすには、Oracle TuxedoのVIEW定義の仕組みを十分に理解することが重要です。

VIEW定義を使用すると、複合的なデータ構造の指定が可能になるため、次のようなケースのデータのやり取りに応用が利きます。

•	異なるタイプのマシン間

•	異なるプログラミング言語間

VIEW定義の準備

処理の対象にするリモートのアプリケーション・プログラムの入出力レコードのレイアウトが決まったら、VIEW定義を用意し、その定義を構成ファイルに指定する必要があります。

注意:	TMA TCP Gatewayが変換するVIEWには、必ずFMLフィールドを指定するようにしてください。つまり、INRECTYPE、OUTRECTYPE、INBUFTYPEまたはOUTBUFTYPEとして指定したVIEWの定義には、常に適切なFMLフィールド(VIEW定義のFNAME列にダッシュ記号なし)を指定する必要があります。FMLフィールド同士が一致する場合は、これらのVIEWを-nオプションの指定なしでコンパイルする必要があります。

1.	標準的なOracle TuxedoのVIEW定義をファイル内に作成します。

2.	viewcまたはviewc32 VIEWコンパイラを実行します。

3.	必要に応じて、Oracle TuxedoのENVFILEを使用して、VIEWFILES、VIEWDIR、FIELDTBLSおよびFLDTBLDIR環境変数を設定します(TMA TCP Gatewayサーバーが実行時にバイナリのVIEWファイルとフィールド表ファイルを検出できるようになります)。

4.	これらの手順が完了すると、GWICONFIGファイルやDMCONFIGファイルにVIEW定義を指定できます(必要に応じて、INRECTYPE、OUTRECTYPE、INBUFTYPEおよびOUTBUFTYPEパラメータにVIEW定義の名前を関連付けることで指定が可能)。

TMA TCP Gatewayの構成の詳細は、「Oracle TMA TCP Gatewayの構成」の項を参照してください。

データの変換

ローカルのクライアント・プログラムが別タイプのコンピュータのサービス・ルーチンとの間でデータを送受信するときに、データは必要に応じてTMA TCP Gatewayによって自動的に変換されます。変換の処理内容は、ワード長やバイト・オーダーのような属性を変更することで、そのデータ型本来の表現をそのまま移し替えることです。

次の項で説明するルールに従って、入出力データは必要に応じてTMA TCP Gatewayによって自動的に変換されます。VIEW定義を作成する前に、情報をよく読んでから(バッファの変換処理を円滑に実行できるように)、TMA TCP Gatewayを構成します。

TMA TCP Gatewayがどのようにデータを変換するかの基本的なルールは次の項で説明しています。TMA TCP Gatewayが文字列データや数値データをどのように扱うかの詳細は、「文字列の長さの計算におけるNULL文字の扱い(Cプログラム)」の項を参照してください。

TMA TCP Gatewayでは、マルチバイト文字セット(MBCS)変換もサポートされています。詳細は、「マルチバイト文字セット(MBCS)変換の使用」を参照してください。

データ変換のルール

TMA TCP Gatewayが従うデータ変換のルールをまとめると次のようになります。

•	CARRAYフィールドは、そのままのバイトの並びで変換されずに渡されます。

•	STRINGおよびCHARフィールドは、必要に応じてSBCS (ASCIIからEBCDICに)変換またはMBCS変換されます。

•	SHORTおよびLONGフィールドはそれぞれ、S9(4) COMPとS9(9) COMPに変換されます。

•	FLOATおよびDOUBLEフィールドはそれぞれ、COMP-1とCOMP-2に変換されます。

•	XMLフィールドは必要に応じてSBCS (ASCIIからEBCDICに)変換されます。

警告:	dec_tをVIEW変換の対象にすることはできません。

注意:	Oracle Tuxedoには、VIEW内の10進数値をサポートするdec_tという名前のフィールド・タイプがあります。TMA TCP Gatewayは、これらのフィールドをマシンに依存しない表現形態であるパック10進数に変換します。たとえば、dec_t(m,n)とすると、S9(2*m-(n+1))V9(n) COMP-3という結果になります。したがって、8,5というサイズの10進数のフィールドはS9(10)V9(5) COMP-3になります。

次の表に関係をまとめます。

 

表3-1 データ変換の関係

リモートのデータ型	説明	VIEWのフィールドの タイプ/長さ
PIC X(n)	英数字	string / n
PIC X	英数字1文字	char
PIC X(n)	ロー・バイト	carray / n
PIC 9	1バイト数値	carray / 1
PIC S9(4) COMP	16ビットの整数	short
PIC S9(9) COMP	32ビットの整数	long
COMP-1	単精度浮動小数点	float
COMP-2	倍精度浮動小数点	double
PIC S9((m+(n+1))/2)V9(n) COMP-3	パック10進数	dec_t / m,n

文字列の長さの計算におけるNULL文字の扱い(Cプログラム)

C言語アプリケーションによって使用される入出力バッファのVIEW定義を作成する場合は、文字列フィールドで使用されるNULL終端文字の分までを余分に指定する必要があります。

たとえば、ローカルのアプリケーション・プログラム側では出力バッファ内の文字列が10バイトであることを前提にしている場合は、文字列の長さである10にNULL終端文字分の1を足した11を、そのフィールドの長さとして指定します。

文字列の長さの計算におけるNULL文字の扱い(COBOLプログラム)

COBOL言語アプリケーションによって使用される入出力バッファのVIEW定義を作成する場合は、文字列フィールドで使用されるNULL終端文字を含む余分な部分まで指定しないでください。

たとえば、リモートのCOBOLアプリケーション・プログラム側では入力レコードが10文字であることを前提にしている場合は、そのフィールドの長さとして10+1 (NULL終端文字も含む長さ)ではなく、10と指定してください。

注意:	TMA TCP Gatewayでは文字列のNULL終端は不要ですが、NULL終端文字があれば文字列の終了と見なされます。したがって、TMA TCP Gatewayは、文字列内にNULL(ゼロ)文字を検出すると、その以降の文字を処理しません。NULL値が埋め込まれた8ビットのデータ全体を渡す場合は、CARRAYタイプのフィールドまたはバッファを使用してください。

TMA TCP Gateway製品は、ASCIIとEBCDICとの間を相互に変換する標準的な文字変換機能を備えています。STRINGデータ型の場合、TMA TCP Gateway製品は自動的にこの変換を実行します。

数値データの変換

中間データの型と変換先の型で表現可能な範囲な中に、表現する必要がある最大値が収まるのであれば、数値データを別のデータ型に簡単に変換できます。

たとえば、数値と文字列との間でも変換が可能です。たとえば、FMLバッファをdec_t型に直接変換することはできませんが、10進数値をSTRINGフィールドに格納し、そのフィールドをVIEW定義のdec_tフィールドにマップすることができます。

COBOLのデータ型のエンコーディング

COBOLデータ型を使用するTuxedoクライアント用に、ConvMVSCというエンコーディング用ライブラリも用意されています。このライブラリ(ConvMVSC)は、デフォルトのライブラリであるConvMVSと基本的に同じですが、次の点に違いがあります。

•	STRINGデータ型の場合、ConvMVSCもConvMVSも、ASCIIとEBCDICとの間の相互変換を実行します。

•	リモート・ゲートウェイに送信される文字列の場合、どちらのライブラリもASCIIからEBCDICへの変換を実行し、メインフレームに文字列に転送します。

•	リモート・ゲートウェイから受信する文字列の場合、ConvMVSライブラリはEBCDICからASCIIへの変換を実行し、末尾に空白文字があれば切り詰め、NULL終端文字を付加します。ConvMVSCライブラリは変換を実行しますが、空白文字の切り詰めも終端文字の追加も行いません。

•	VIEWデータ型の場合、ConvMVSライブラリとConvMVSCライブラリは、STRINGを除くすべてフィールドのタイプを同じものとして扱います。

•	リモート・ゲートウェイに送信するビューのSTRINGフィールドの場合、ConvMVSはASCIIからEBCDICへの変換を行い、フィールドのサイズまで空白文字列で埋まるように空白文字を付加します。ConvMVSCは文字を変換しますが、埋込みはしません。

•	リモート・ゲートウェイから受信するビューのSTRINGフィールドの場合、ConvMVSはEBCDICからASCIIへの変換を行い、末尾に空白文字があれば切り詰め、NULL終端文字を付加します。ConvMVSCライブラリは文字変換を行いますが、空白文字の切り詰めも終端文字の付加も行いません。

COBOLデータのエンコーディング用ライブラリの使用方法

COBOLデータのエンコーディング用ライブラリを有効にする方法は2つあります。

•	すべてのサービスを対象にしたCOBOLデータのエンコーディング

•	特定ホストとの間でやり取りするメッセージを対象にしたCOBOLデータのエンコーディング

すべてのサービスを対象にしたエンコーディング

ゲートウェイの全サービスを対象にCOBOLデータのエンコーディングを有効にするには、GWICONFIGファイルのGLOBALセクションにパラメータDFLTTYPE="MVSC"を設定します。

リスト3-1 すべてのサービスを対象にしたエンコーディング

*GLOBAL

DFLTTYPE=”MVSC”

 

特定のホストとの間でやり取りするメッセージのエンコーディング

特定ホストとの間でやり取りするメッセージを対象にCOBOLデータのエンコーディングを有効にするには、GWICONFIGファイルのFOREIGNエントリに、そのホスト用のパラメータTYPE="MVSC"を設定します。

リスト3-2 特定ホストとの間でやり取りするメッセージのエンコーディング

*FOREIGN

HOST_NAME
TYPE=”MVSC”

 

コード・ページ変換表の使用方法

1バイト文字セット(SBCS)をASCIIとEBCDICとの間で変換できるように、TMA TCPソフトウェアには変換表が付属しています。これらの表は、IBM社が規定しているコード・セットに準拠しており、デフォルトのTuxedoコード・ページ(以前のリリースのTMA TCPで使用されていたデフォルトのコード・ページ変換表)を含んでいます。

それぞれの変換表は、発信時の変換(Tuxedoからメインフレームへの変換)の表と、着信時の変換(メインフレームからTuxedoへの変換)の表という、2つのマッピング表から構成されます。変換元と変換先が何かを指定する必要はありませんが、ホスト・アプリケーションがどの国の言語で記述されているかを確認しておく必要があります。次の図にコード・ページ変換を示します。

図3-5 TMA TCPのコード・ページ変換

図は、Latin-1版のASCIIコード・ページCP-00819文字セットを使用しているTuxedoアプリケーションと、ドイツ語版のEBCDICコード・ページCP-00273を使用しているホスト・アプリケーションとの間の処理がどのようになるかを示しています。TMA TCPの変換表00819x00273が、着信時にも発信時にも変換に使用されます。

変換表の指定

アプリケーション用の変換表を指定するには、リモート・ドメインごとにDMCONFIGファイルの定義を作成します。DMCONFIGファイルのDM_REMOTE_DOMAINSセクションでCODEPAGEパラメータを使用します。使用する変換表を指定します。

リモート・ホストが使用するデフォルトのコード・ページ変換を指定するには、DMCONFIGファイルのDM_LOCAL_DOMAINSセクションにあるローカル・ゲートウェイ・エントリ用のCODEPAGEパラメータに変換表のファイル名を指定します。

次の表に、TMA TCPソフトウェアに付属のSBCS変換表を示します。

 

表3-2 TMA TCPのコード・ページ変換表

国	ファイル名	ASCIIコード・セット	EBCDICコード・セット
Tuxedoのデフォルト	TUXEDO	TUXEDO-ASCII	TUXEDO-EBCDIC
米国	00819x00037	CP-00819	CP-00037
イギリス	00819x00285	CP-00819	CP-00285
フランス	00819x00297	CP-00819	CP-00297
ポルトガル	00819x00860	CP-00819	CP-00860
スペイン	00819x00284	CP-00819	CP-00284
ベルギー	00819x00500	CP-00819	CP-00500
ドイツ	00819x00273	CP-00819	CP-00273
フィンランド	00819x00278	CP-00819	CP-00278
スウェーデン	00819x00278	CP-00819	CP-00278
Latin-1	00819x01047	CP-00819	CP-01047
Latin-2	00912x00870	CP-00912	CP-00870

注意:	TuxedoのデフォルトのASCIIとEBCDICのコード・ページはCP-00819とCP-00037とは若干違っています。

変換表の処理の仕組み

TMA TCP Gatewayは、起動時にリモート・ドメインごとの変換表をロードします。

アプリケーションに必要とされる変換に合わせて、どの表を変更してもかまいませんが、Tuxedoのデフォルトの表はハードコード化されているため変更できません。変換表の定義になんらかの変更を加えたら、ゲートウェイを再起動する必要があります。TMA TCPの変換表は、$TUXDIR/udataobj/codepageにあります。表の内容は、「コード・ページ変換表」の項を参照してください。

リモート・ドメイン用のCODEPAGEの指定がない場合、TMA TCP GatewayソフトウェアはTuxedoのデフォルトの変換表を使用します。

注意:	製品ソフトウェアにはTuxedoのデフォルトの変換表のコピー版が付属しており、$TUXDIR/udataobj/codepageの中に入っています。アプリケーションの要件に応じて、これらのコピーを変更できるようになっています。これらのコピーは、ゲートウェイによって使用される実際のデフォルトの表ではありません。Tuxedoのデフォルトの表はハードコード化されているため、変更できません。

変換表関連のエラーのトラブルシューティング

これより、ゲートウェイのエラーの原因となる、変換表関連のエラーを解決する方法について説明します。指定の変換表に関連するエラーが発生したときに、ゲートウェイは次のメッセージを発行します。

1072:ERROR Cannot read CODEPAGE <filename> for <LOCAL | REMOTE> DOMAIN <domainname>

エラー・メッセージの説明は、「エラー・メッセージと情報メッセージ」の項を参照してください。ゲートウェイが前述のエラーを発行した場合は、次の原因が考えられます。

•	ゲートウェイが変換表ファイルを見つけることができません。

、DMCONFIGファイルのDM_REMOTE_DOMAINセクションのCODEPAGEパラメータに正しいコード・ページ名を指定していること、そのファイルが$TUXDIR/udataobj/codepageに存在していることを確認します。

•	ソフトウェアが変換表ファイルを読み取ることができません。

CODEPAGEパラメータに指定したファイル名が正しいことを確認します。また、指定したファイルが破損していないことも確認します。

•	アクセス権限により、ソフトウェアが変換表ファイルを読み取ることができません。

$TUXDIR/udataobj/codepageディレクトリの中にある指定の変換表ファイルに対する読取り権限があることを確認します。

ASCIIからEBCDICに変換するDMCONFIG定義のサンプル

次のリストに、1つのローカル・ドメイン(CIXA)を定義するエントリと、2つのリモート・ドメイン(CISAとIMSA)を定義するエントリを示します。次の例は、ローカル・ドメインがASCIIコード・ページCP-00819を使用し、2つのリモート・ドメインがドイツ語版EBCDICコード・ページCP-00273とフランス語版EBCDICコード・ページCP-00297を使用する場合の例です。

リスト3-3 コード・ページ定義の例

# DMCONFIG

*DM_LOCAL_DOMAINS
CIXA
TYPE=IDOMAIN

*DM_REMOTE_DOMAINS
CISA
TYPE=IDOMAIN
CODEPAGE=00819X00273
IMSA
TYPE=IDOMAIN
CODEPAGE=“00819X00297”

 

マルチバイト文字セット(MBCS)変換の使用

SBCS文字セットの変換に加えて、TCP GWIDOMAINでは、アジア圏の顧客の要件を満たすためにマルチバイト文字セット(MBCS)変換がサポートされています。この変換は、ディレクトリ$TUXDIR/udataobj/codepageにある変換表に依存せず、かわりにICUライブラリを利用します。これは、200種類以上のSBCSおよびMBCS文字セットを含むライブラリです。

この変換を使用するには、次のフォーマットでDMCONFIG DM_REMOTE_DOMAINSのCODEPAGEパラメータを指定します。

CODEPAGE="ASCII_CHAR_SET:EBCDIC_CHAR_SET"

注意:	リモート・ホストが使用するデフォルトの変換は、DMCONFIG DM_LOCAL_DOMAINSのこのCODEPAGEパラメータで指定できます。

ASCII_CHAR_SETがローカル・ドメイン用で、EBCDIC_CHAR_SETがリモート・ドメイン用です。コロン(:)で区切ります。

ASCII_CHAR_SETとEBCDIC_CHAR_SETのどちらも、ICUとして知られる、使用可能の文字セットである必要があります。uconvというユーティリティを使用すると、これらの文字セットに関連する情報を取得できます。

たとえば､ MBCSをリモート・ドメインに変換する場合は、CODEPAGE="utf-8:ibm-1388"と定義します。したがって、発信呼出しの場合、GWIDOMAINはクライアントの入力をUTF-8からibm-1388に変換し、逆に着信呼び出しはibm-1388からUTF-8に変換されます。

詳細は、DM_LOCAL_DOMAINS SectionとDM_REMOTE_DOMAINS Sectionを参照してください。

MBCS変換のDMCONFIG定義の例

次のリストは1つのローカル・ドメイン( CI XA )と2つのリモート・ドメイン( CISAおよびIMSA )を定義するエントリを示しています。次の例では、ローカル・ドメインがUTF-8を使用し、2つのリモート・ドメインがともに簡体字中国語混合のEBCDIC ibm-1388を使用すると想定しています。

リスト3-4 MBCS変換のDMCONFIG定義の例

# DMCONFIG

*DM_LOCAL_DOMAINS

CIXA

TYPE=IDOMAIN

CODEPAGE="UTF-8:ibm-1388"

 

*DM_REMOTE_DOMAINS

CISA

TYPE=IDOMAIN

CODEPAGE="UTF-8:ibm-1388"

IMSA

TYPE=IDOMAIN

CODEPAGE="UTF-8:ibm-1388"