TP1/Client/Jでは，CUP（TP1/Client/Jを使用したJavaアプレット，Javaアプリケーション，またはJavaサーブレット）とrapサーバの間のコネクションを確立したままでメッセージを送受信できます。このようなコネクションを常設コネクションといいます。なお，リモートAPI機能を使用したRPCを実行するとき，連鎖型RPCを使用するとき，およびトランザクション機能を使用するときは，必ず常設コネクションを確立してください。

常設コネクションを確立すると，コネクション確立・解放のための制御用パケットを減らせるため，通信の効率が向上します。

(a)　常設コネクションの確立・解放

TP1/Client/Jが同時に確立できる常設コネクションは，1CUPで1コネクションだけです。TP1/Client/Jの常設コネクションには，管理方式によって次のモードがあります。

非オートコネクトモード

非オートコネクトモードは，CUPで明示的にopenConnectionメソッドを呼び出してTP1/Serverのrapリスナー，rapサーバとのコネクションを確立します。コネクションを解放するには，CUPでcloseConnectionメソッドを明示的に呼び出します。

オートコネクトモード

オートコネクトモードは，TP1/Client/Jでコネクションを管理します。TP1/Client/Jは，最初に呼び出されたときにコネクションが確立されていないと判断すると，自動的にrapリスナー，rapサーバとの間に常設コネクションを確立します。TP1/Client/Jで管理しているコネクションを強制的に解放したい場合は，closeConnectionメソッドを呼び出します。

非オートコネクトモードを使用するか，オートコネクトモードを使用するかは，TP1/Client/J環境定義のdcrapautoconnectオペランドで指定するか，またはsetRpcextendメソッドで指定します。

closeConnectionメソッドを呼び出して常設コネクションを解放するまで，メッセージの送受信には常設コネクションが使用されます。ただし，何らかの障害が発生した場合，常設コネクションは解放されます。

CUPからSPPへのリモートプロシジャコール（RPC）について説明します。

RPCの詳細については，マニュアル「OpenTP1 プログラム作成の手引」を参照してください。

(a)　RPCの形態

TP1/Client/Jで実行できるRPCの形態は，同期応答型RPC，非応答型RPC，および連鎖型RPCです。

●同期応答型RPC

CUPからSPPへ問い合わせメッセージを送信し，応答メッセージを受信する形態です。CUPは，SPPから処理結果が返ってくるまで，次の処理を待ちます。同一サービスを複数回呼び出した場合，サーバプロセスはそのたびにスケジュールされます。

●非応答型RPC

CUPからSPPへ問い合わせメッセージを送信し，応答メッセージを受信しない形態です。CUPは，SPPへ問い合わせメッセージを送信したあと，SPPから処理結果を受け取らないで，すぐに次の処理を実行します。

非応答型RPCでは，何らかの通信障害が発生した場合や呼び出したサービスが誤っていた場合でもエラーを受け取れません。

●連鎖型RPC

TP1/Client/JのリモートAPI機能を使用したCUPからSPPへ問い合わせメッセージを送信し，問い合わせた応答メッセージを受信する形態です。CUPは，SPPから処理結果が返ってくるまで，次の処理を待ちます。同期応答型RPCとの違いは，サーバプロセスを固定できることです。連鎖型RPCの場合，同一サービスに複数回問い合わせメッセージを送信しても，サーバプロセスは再スケジュールされません。なお，TP1アダプタでは，この機能を使用できません。

(b)　スケジュール機能

TP1/Serverのスケジュール機能は，CUPからSPPに対するサービス要求でも有効です。TP1/Serverは，SPPのサービスグループごとにスケジュールキューを作成し，サービス要求をスケジュールします。

(c)　ノード間負荷バランス機能

OpenTP1では，RPCによる要求が特定のノードに集中しないようにノード間で負荷を分散する機能があります。これをノード間負荷バランス機能といいます。

ノード間負荷バランス機能を使用するためには，負荷分散の前提として次の条件を満たしている必要があります。

• 複数のノードに同一のサービスを提供するユーザサーバが起動されていること。
• 各OpenTP1ノードはシステム共通定義のall_nodeオペランドに自分以外のノードを定義して，お互いのOpenTP1ノードで起動されているユーザサーバの情報（ネーム情報）をやり取りしていること。

ここでは，OpenTP1のノード間負荷バランス機能を使用する場合のTP1/Client/J側，TP1/Server側の関連する定義，処理，およびRPCの処理を説明します。なお，TP1/Client/JではTP1/Server側の判断による負荷分散機能だけを提供します。

●TP1/Server側の判断で負荷分散を行う場合

TP1/Serverのスケジュールサービスが，ノードのスケジュール状態に応じて，より効率的に処理できるノードへ負荷を分散させます。

TP1/Client/J側の定義

TP1/Client/J環境定義にdcscddirect=Yを指定します。

これによって，TP1/Client/J側はTP1/Serverのスケジュールサービスに負荷分散を依頼できます。TP1/Client/J側の定義では，どのOpenTP1ノードのスケジュールサービスに判断を依頼するかを指定します。

この場合，スケジュールを依頼するOpenTP1ノードが複数あると，dchostオペランドに指定された順番にスケジュールを依頼します。dchostオペランドに指定された順番ではなく，スケジュールを依頼するTP1/Serverをランダムに選択するには，TP1/Client/J環境定義にdchostselect=Yを指定します。

TP1/Server側の定義

TP1/Server側の定義では，次のどちらかの設定をする必要があります。

• スケジュールサービス定義のオペランドに次の指定をする。
  scd_this_node_first = N （デフォルト）
  scd_announce_server_status = Y （デフォルト）
  
• スケジュールサービス定義を省略する。

(d)　時間監視

同期応答型RPCを行う場合，応答メッセージを受信するまでの時間を監視できます。

監視時間は，TP1/Client/J環境定義のdcwatchtimオペランドで指定します。

(e)　リモートAPI機能を使用したRPC

TP1/Client/Jでは，CUPとTP1/Server間に常設コネクションを確立して，CUPが発行したAPIを，TP1/Server側に転送してTP1/Server側のプロセスで実行できます。このような機能をリモートAPI機能といいます。リモートAPI機能を使うと，ファイアウォールの内側にあるUAPに対しても，サービスを要求できます。なお，リモートAPI機能を使用したRPCは，TP1/Serverのほかに，DCCM3およびTMS-4V/SPを使用できます。

(f)　ネームサービスを使用したRPC

ネームサービスを使用したRPCは，JavaアプリケーションおよびJavaサーブレットから実行できるサービス要求です。Javaアプレットのセキュリティの制約があるため，Javaアプレットからは実行できません。

●ネームサービスを使用したRPCの機能

ネームサービスを使用したRPCの使用時は，ソケット受信型SPPに対してRPCを発行できません。また，TP1/Client/J環境定義のdccltrpcmaxmsgsizeオペランドに2以上を指定した場合，ネームサービスを使用したRPCは，システム共通定義のrpc_max_message_sizeオペランドをサポートするTP1/Server上で稼働しているサービスの情報だけを取得します。サービスの入力パラメタ長が，サービス要求先のシステム共通定義のrpc_max_message_sizeオペランドの値を超える場合もサービス要求は実行されます。システム共通定義のrpc_max_message_sizeオペランドをサポートしないTP1/Server上のSPPに対してはRPCを発行できません。

●RPCごとにサービス要求先スケジューラを分散させる場合の定義

ネームサービスを使用したRPCでは，サービス要求先スケジューラの情報をネームサーバからキャッシュに格納し，キャッシュの情報を参照してRPCごとにサービス要求先スケジューラを分散させることができます。RPCごとにサービス要求先スケジューラを分散させる場合のTP1/Client/J側，TP1/Server側の関連する定義について説明します。

●TP1/Client/J側の定義

RPCごとにサービス要求先スケジューラを分散させる場合は，TP1/Client/J環境定義にdccltloadbalance=Yを指定します。

これによって，TP1/Client/Jは，ネームサーバから複数のサービス要求先スケジューラの情報を取得し，負荷レベルが最も低いサービス要求先スケジューラの情報をキャッシュに格納します。キャッシュに格納されるサービス要求先スケジューラは，1つだけではなく，複数の場合もあります。

キャッシュに格納されたサービス要求先スケジューラが複数ある場合，最初のサービス要求先スケジューラは，ランダムに選択されます。RPCでのサービス要求が2度目以降の場合は，サービス要求先スケジューラの情報を取得するためにキャッシュを参照し，RPCごとにラウンドロビン方式でサービス要求先スケジューラを切り替え，分散させます。

• キャッシュの有効期限の指定
  TP1/Client/J環境定義のdccltcachetimオペランドで，サービス要求先スケジューラの情報を保持する，キャッシュの有効期限を指定できます。
  キャッシュにサービス要求先スケジューラの情報を格納したあとで，キャッシュの有効期限を満了した場合，そのサービス要求先スケジューラの情報を破棄します。その後，サービス要求先スケジューラの情報を再度取得して，その情報をキャッシュに格納することで，キャッシュを更新します。
  TP1/Client/J環境定義のdccltcachetimオペランドは，TP1/Client/J環境定義にdccltloadbalance=Yを指定した場合だけ有効になります。
  

●TP1/Server側の定義

次に示すTP1/Server側の定義のオペランドを指定すると，ネームサーバからサービス要求先スケジューラの情報を取得するときに，スケジューラの負荷情報も同時に取得します。

• スケジュールサービス定義

 
   scd_announce_server_status=Y（デフォルト）
 

このオペランドにNを指定した場合，スケジューラの負荷レベルは常にLEVEL0（負荷が低い状態）となります。負荷レベルが常にLEVEL0のスケジューラが，TP1/Client/Jのサービス要求先スケジューラとなった場合，実際の負荷状態に関係なく，常にサービス要求先スケジューラとして選択されます。

• ユーザサービス定義，またはユーザサービスデフォルト定義

   
   loadcheck_interval
   
   levelup_queue_count
   
   leveldown_queue_count
   

「levelup_queue_count」および「leveldown_queue_count」については，スケジューラの負荷レベルがサービス要求の滞留数で決まる方式とする場合に指定します。

●マルチホームドホスト形態のTP1/Serverに対してRPCを行う場合の定義

ネームサービスを使用したRPCでは，通信先TP1/Serverがマルチホームドホスト形態の場合に通信障害が発生することがあります。これは，CUPが存在するネットワークから，通信先TP1/Serverのシステム共通定義のmy_hostオペランドで指定したホスト名（IPアドレス）に対応するネットワークアダプタに通信できないことが原因です。

これを回避するためには，TP1/Client/J環境定義にdccltnammlthost=Yを指定します。ネットワークの構成例を次の図に2つ示し，それぞれのネットワーク構成でのTP1/Client/J環境定義のdccltnammlthostオペランドの要否を示します。

図A-1　マルチホームドホスト形態のTP1/Serverに対してRPCを行う場合の例

ネットワーク構成例2のCUPがIPアドレス4と通信するには，TP1/Client/J環境定義にdccltnammlthost=Yの指定が必要です。この指定がない場合，CUPとIPアドレス4との間では通信障害が発生します。

通信先TP1/Serverがマルチホームドホスト形態で，かつ同じTP1/Server上にサービス要求先のSPPが存在しているときは，TP1/Client/J環境定義にdccltnammlthost=Yを指定することでRPCが行えるようになります。通信先TP1/Serverのシステム共通定義のall_nodeオペランドに，CUPが接続されていないネットワーク上に存在するTP1/Serverが指定されている場合，このTP1/Server上のSPPに対してRPCを行うと通信障害が発生します。なお，通信先TP1/Serverがマルチホームドホスト形態でない場合，TP1/Client/J環境定義のdccltnammlthostオペランドの指定に関係なくRPCを行えます。

(g)　通信先を指定したRPC

通信先を指定したRPCを使用すると，サービス要求を実行するサーバ（通信先のOpenTP1ノード）を明示的に指定できます。

通信先を指定したRPCを使用した場合，サービス要求を実行するサーバに指定した通信先のOpenTP1ノードでサービス要求が実行されます。指定したOpenTP1ノードが停止，または閉塞しているときでも，他OpenTP1ノードへの転送は行われません。また，ノード間負荷バランス機能は使用できません。

(h)　同期応答型RPCタイムアウト時のサーバ負荷軽減

TP1/Client/JのCUPからサーバを呼び出すと，TP1/Serverではサービス要求を受け付けます。

この要求はSPPの実行待ち時間，実行時間，通信障害などによって，遅れるおそれがあるため，TP1/Client/J側では応答待ち時間に上限を設けることで異常を監視しています。

一方TP1/Server側では，TP1/Client/Jの最大応答待ち時間を認識していないため，TP1/Client/J側でタイムアウトを検出していても，TP1/Server側ではサービスを処理し続けている場合があります。

同期応答型RPCタイムアウト時のサーバ負荷軽減機能を使用すると，TP1/Server側での上記のような不要な処理を軽減できます。同期応答型RPCタイムアウト時のサーバ負荷軽減機能を使用するかどうかは，TP1/Client/J環境定義のdcwatchtimrpcinheritオペランドで指定します。同期応答型RPCタイムアウト時のサーバ負荷軽減機能の処理概要を次の図に示します。

図A-2　同期応答型RPCタイムアウト時のサーバ負荷軽減機能の処理概要

(i)　ServerSocketを使用するRPC

TP1/Client/Jで，スケジューラダイレクト機能を使用したRPC，ネームサービスを使用したRPC，および通信先を指定したRPCを行う場合，ServerSocketを使用します。TP1/Client/Jを使用するクライアントプログラムを動作させるJava VMでセキュリティマネジャを適用する場合，TP1/Client/JのクラスライブラリがServerSocketの機能（connect，listen，およびaccept）を使用できるよう，適切なパーミッションをセキュリティポリシファイルに記述してください。Javaサーブレット，またはEJBの場合，これらコンテナを実装しているアプリケーションサーバ製品で，セキュリティの制約のためデフォルトでセキュリティマネジャを使用していることがあります。使用するアプリケーションサーバの仕様をご確認の上，適切に設定してください。

(j)　マルチスケジューラ機能を使用したRPC

CUPからスケジュールキューを使うSPP（キュー受信型サーバ）にサービスを要求した場合，要求先SPPがあるノードのスケジューラデーモンが，いったんサービス要求メッセージを受信し，該当するSPPのスケジュールキューに格納します。スケジューラデーモンとは，スケジュールサービスを提供するシステムデーモンのことです。

長大なサービス要求メッセージは，一定の長さに分割してスケジューラデーモンに送信します。スケジューラデーモンは，サービス要求メッセージを組み立ててキュー受信型サーバのスケジュールキューに格納します。スケジューラデーモンは，OpenTP1システムごとに1プロセスです。そのため，分割されたサービス要求メッセージの受信処理が完了するまで，スケジューラデーモンはほかのサービス要求メッセージを受信できません。通信速度が遅い回線を使用して，長大なサービス要求メッセージを送信した場合，ほかのサービス要求のスケジューリングが遅延することがあります。また，システムの大規模化，マシンやネットワークの高性能化などに伴って，効率良くスケジューリングできないことがあります。この場合，従来のスケジューラデーモンとは別に，サービス要求受信専用デーモンを複数プロセス起動し，サービス要求メッセージ受信処理を並行動作させることによって，スケジューリング遅延を回避できます。この機能をマルチスケジューラ機能といいます。以降，従来のスケジューラデーモンをマスタスケジューラデーモン，サービス要求受信専用デーモンをマルチスケジューラデーモンと呼びます。

マルチスケジューラ機能の検討が必要なシステム構成については，マニュアル「OpenTP1 プログラム作成の手引」を参照してください。

●マルチスケジューラデーモンをランダムに選択する方法

マルチスケジューラ機能を使用することで，複数起動されているマルチスケジューラデーモンの中から，利用できるマルチスケジューラデーモンをランダムに選択してサービス要求を送信できます。マルチスケジューラデーモンをランダムに選択して，スケジューラダイレクト機能，またはネームサービスを使用したRPCを実行できます。

●スケジューラダイレクト機能を使用したRPC

TP1/Client/J環境定義dcscddirectオペランドにYを指定して，スケジューラダイレクト機能を使用したRPCを行う場合について説明します。

TP1/Client/Jでは，窓口となるTP1/Serverのネームサービスへ問い合わせないで，マルチスケジューラデーモンをランダムに選択できます。これによって通信回数が削減され，ネームサービスの負荷を軽減できます。

マルチスケジューラデーモンをランダムに選択するためには，TP1/Client/J環境定義のdchostオペランド，またはdcscdportオペランドに次のポート番号を指定します。

• スケジュールサービス定義のscd_portオペランドに指定された，スケジュールサービスのポート番号
• スケジュールサービス定義のscdmultiの-pオプションに指定されたポート番号

また，あらかじめTP1/Serverで起動しているマルチスケジューラデーモンのプロセス数を，TP1/Client/J環境定義のdcscdmulticountオペランドに指定しておく必要があります。サービス要求を送信するマルチスケジューラデーモンのポート番号は，次に示す範囲の値からランダムに選択されます。

• 下限値：TP1/Client/J環境定義のdchostオペランド，またはdcscdportオペランドに指定したポート番号の値
• 上限値：下限値 + TP1/Client/J環境定義のdcscdmulticountオペランドに指定したプロセス数 - 1

ただし，TP1/Client/J環境定義のdchostオペランドで指定した窓口となるTP1/Server間で，スケジュールサービス定義のscdmultiで指定した値を統一する必要があります。

●ネームサービスを使用したRPC

マルチスケジューラ機能を使用して，ネームサービスを使用したRPCを行う場合について説明します。サービス情報を一時的に格納する領域に，該当するサービス情報がないときはネームサービスにサービス情報を問い合わせます。サービス情報を基にマルチスケジューラデーモンをランダムに選択してサービス要求を送信します。

●TP1/Client/J環境定義とサービス要求を送信するスケジューラデーモンの関連

マルチスケジューラ機能を使用した場合，サービス要求を送信するスケジューラデーモンはTP1/Client/J環境定義の指定によって異なります。

スケジューラダイレクト機能を使用したRPCの場合の，TP1/Client/J環境定義のオペランドの指定とスケジューラデーモンの関連を次の表に示します。

表A-2　TP1/Client/J環境定義のオペランドの指定とスケジューラデーモンの関連（スケジューラダイレクト機能を使用したRPC）

TP1/Client/J環境定義のオペランドの指定			サービス要求を送信するスケジューラデーモン
dcscddirect	dcscdmulti	dcscdmulticount
Y	Y	○	ランダムに選択したマルチスケジューラデーモン※
		−	TP1/Client/J環境定義のdchostオペランド，またはdcscdportオペランドに指定したポート番号で起動されているスケジューラデーモン
	N	無効	TP1/Client/J環境定義のdchostオペランド，またはdcscdportオペランドに指定したポート番号で起動されているスケジューラデーモン

（凡例）

Y：オペランドの指定値がYです。

N：オペランドの指定値がNです。

○：オペランドに値を指定します。

−：オペランドに値を指定しません。

注※

マルチスケジューラデーモンのポート番号は，次に示す範囲の値から選択されます。

下限値：TP1/Client/J環境定義のdchostオペランド，またはdcscdportオペランドに指定したポート番号の値

上限値：下限値 + TP1/Client/J環境定義のdcscdmulticountオペランドに指定したプロセス数 - 1

　

ネームサービスを使用したRPCの場合の，TP1/Client/J環境定義のオペランドの指定とスケジューラデーモンの関連を次の表に示します。

表A-3　TP1/Client/J環境定義のオペランドの指定とスケジューラデーモンの関連（ネームサービスを使用したRPC）

TP1/Client/J環境定義のオペランドの指定			サービス要求を送信するスケジューラデーモン
dcnamuse	dcscdmulti	dcscdmulticount
Y	Y	無効	サービス情報を基にランダムに選択したマルチスケジューラデーモン※
	N		マスタスケジューラデーモン※

（凡例）

Y：オペランドの指定値がYです。

N：オペランドの指定値がNです。

注※

ネームサービスへの問い合わせが発生します。

この機能は，リモートAPI機能を使用する場合で，要求先TP1/Server Baseのバージョンが05-00以降のときだけ使用できます。

TP1アダプタでは，この機能を使用できません。

TP1/Client/JのTCP/IP通信機能は，CUPがクライアント型かサーバ型かによって通信方法が異なります。CUPがクライアント型の場合は，CUPから定義や引数で指定した通信相手に対してコネクションを確立して通信します。CUPがサーバ型の場合は，定義で指定したポートで通信相手がコネクションを確立してくるのを待って通信します。コネクション確立後は，引数で指定した領域に対してデータの送受信を行います。

TP1アダプタでは，この機能を使用できません。

一方通知受信機能を使用すると，オンライン開始の合図をクライアント側に一斉配布する，従来，メインフレームのOLTPでの端末一斉起動と同様な運用ができるようになります。

TP1アダプタでは，この機能を使用できません。

TP1/Web接続機能は，Javaアプレットとして作成したCUPとTP1/Webを接続して，HTTPプロトコルに基づいた通信サービスをするための機能です。

TP1アダプタでは，この機能を使用できません。

TP1/Client/Jは，TP1/Client/J環境定義をrpcOpenメソッド内で解析し，CUPに一意の情報として格納しています。

動的定義変更機能を使用すると，TP1/Client/J環境定義で定義しなかったオペランドの値を設定したり，TP1/Client/J環境定義で定義したオペランドの値を動的に変更したりできます。

TP1アダプタでは，この機能を使用できません。

TCP/IPコネクションの確立の監視機能では，データ送信時のTCP/IPコネクションの確立処理に対する最大監視時間を指定し，コネクションの確立処理を監視できます。

TP1アダプタでは，この機能を使用できません。

TP1/Client/Jでは，RPCやTCP/IP通信機能を使用して，VOS3やVOS1上のDCCM3と接続できます。

(a)　DCCM3とのRPC

TP1/Client/Jでは，OpenTP1のサーバだけでなく，DCCM3のサーバともRPCを使用した通信ができます。DCCM3とRPCを行うには，DCCM3側に，OpenTP1のRPC要求を解釈する機能が組み込まれていることが前提です。次に示す製品をDCCM3側に組み込むことで，DCCM3ともRPCを使用した通信ができます。

DCCM3側の適用OSがVOS3の場合

DCCM3/Internet

DCCM3側の適用OSがVOS1の場合

DCCM3/SERVER/TP1

相手サーバがDCCM3の場合の特徴は次のとおりです。

• 使用できるRPCの形態は，同期応答型RPCと非応答型RPCです。連鎖型RPCは使用できません。
• トランザクション制御機能は使用できません。
• 常設コネクションを使用してDCCM3論理端末へRPCを行う場合，負荷分散機能を使用できます。詳細については，「●DCCM3論理端末に対してRPCを行う場合の負荷分散」を参照してください。
• DCCM3に対してRPCを行う場合，サービス名がトランザクション名称と評価されます。

●相手サーバの指定方法

DCCM3のサーバとRPCを使用した通信をする場合，相手サーバをサービスグループ名とサービス名で指定します。この指定方法はOpenTP1のサーバに対してRPCを行う場合と同じです。

• サービスグループ名
  サービスグループ名として不正でないダミーの文字列を指定します。1〜31文字の識別子を指定してください。
  
• サービス名
  DCCM3側のトランザクション名称を指定します。使用できる文字は，アルファベット（A〜Z，a〜z）と数字（0〜9）です。文字数の合計が1〜8文字になるように指定してください。
  

●相手サーバのアドレス定義

DCCM3のサーバとRPCを使用した通信をする場合，OpenTP1のネームサービスの管理外にあるサーバを呼び出すため，TP1/Client/J側でサービス名ごとに定義を分けて，サーバのアドレスを定義する必要があります。サーバのアドレスを定義するには，TP1/Client/J環境定義のdchostオペランドに，それぞれRPC受け付け窓口のホスト名およびポート番号を指定します。

●DCCM3論理端末に対してRPCを行う場合の負荷分散

TP1/Client/JとDCCM3論理端末が常設コネクションを使用してRPCを行う場合，コネクション確立時に接続先を複数のDCCM3に振り分けて負荷を分散できます。TP1/Client/Jは，TP1/Client/J環境定義のdchostオペランドに指定された複数のDCCM3論理端末のホスト名およびポート番号の中から，接続先をランダムに選択し，接続を試みます。あるDCCM3論理端末との接続に失敗すると，それ以外のDCCM3論理端末から再びランダムに選択し，接続を試みます。この処理を繰り返し，TP1/Client/J環境定義のdchostオペランドに指定されたすべてのDCCM3論理端末との接続にすべて失敗したときに，初めてエラーを検知します。

●TP1/Client/J環境定義の定義例

次に示す図のように動作する，DCCM3接続時のTP1/Client/J環境定義の定義例を示します。

図A-3　DCCM3のサーバとのRPC

1. TP1/Client/J環境定義で，各トランザクションを処理するサーバのアドレス（RPC受け付け窓口）を，定義ファイルを分けてdchostオペランドに定義します。
2. RPCを行うとき，定義ファイルからRPC受け付け窓口のアドレスを求め，RPCのメッセージを送信します。
3. RPCのメッセージを解釈し，要求されたサービスを実行します。
4. 同期応答型RPCの場合，サーバからの応答メッセージを受信します。

定義ファイル"tran1.ini"の定義例

 
dcrapdirect=Y
dcwatchtim=180
dcrapautoconnect=Y
dchostselect=Y
#"TRAN1"のトランザクションを処理できるサーバのアドレスを定義
dchost=xxx.xxx.xxx.xxx:10020,zzz.zzz.zzz.zzz:10022
 

定義ファイル"tran2.ini"の定義例

 
dcrapdirect=Y
dcwatchtim=180
dcrapautoconnect=Y
dchostselect=Y
#"TRAN2"のトランザクションを処理できるサーバのアドレスを定義
dchost=yyy.yyy.yyy.yyy:10021,zzz.zzz.zzz.zzz:10022
 

●DCCM3論理端末に対してRPCを行う場合の注意事項

• リモートAPI機能を使用したRPCだけ使用できます。
• 連鎖型RPCは使用できません。
• トランザクション制御機能は使用できません。
• TP1/Client/J環境定義のdccltinquiretimeオペランドを指定しても無効になります。CUPからサーバに対する問い合わせ間隔最大時間は，DCCM3の「端末放置監視時間」で指定してください。
• DCCM3側の注意事項については，マニュアル「VOS3 データマネジメントシステム XDM E2系 概説」およびマニュアル「VOS1 データコミュニケーションマネジメントシステム DCCM3 解説」を参照してください。

(b)　DCCM3論理端末への端末識別情報の通知

常設コネクションを使用してDCCM3論理端末と通信する場合，端末識別情報をDCCM3論理端末に通知し，CUPに割り当てられるDCCM3の論理端末を固定することができます。

●DCCM3論理端末でのメッセージ送受信方法

DCCM3論理端末では，通信相手となるTP1/Client/JをIPアドレスとDCCM3論理端末のポート番号で区別する論理端末として定義し，論理端末ごとにメッセージの送受信を行っています。

したがって，複数のCUPを同一マシンから起動した場合，どのCUPからの要求でも，DCCM3論理端末から見るとIPアドレスが同じになってしまいます。複数のCUPから同じDCCM3論理端末のポートにサービスを要求すると，DCCM3の定義では区別が付きません。そのため，該当するDCCM3の論理端末が複数定義されていた場合，DCCM3のどの論理端末にCUPが割り当てられるのかが不定になってしまいます。サービス要求を受け付けるDCCM3の論理端末が異なると，DCCM3側のサーバ処理の順番が保証されなくなるため，業務によっては問題となることがあります。

●端末識別情報の通知

CUPがDCCM3論理端末と常設コネクションを確立するときに，端末識別情報をDCCM3論理端末に通知することで，CUPに割り当てられるDCCM3の論理端末を固定することができます。これを端末識別情報設定機能といいます。この機能を使用することで，CUPを常に同じDCCM3の論理端末に割り当てることができます。なお，DCCM3側では，この機能を端末固定割り当て機能といいます。

端末識別情報設定機能を使用していない場合と使用している場合のCUPとDCCM3論理端末の関係を，次の図にそれぞれ示します。

図A-4　CUPとDCCM3論理端末の関係（端末識別情報設定機能を使用していない場合）

図A-5　CUPとDCCM3論理端末の関係（端末識別情報設定機能を使用している場合）

端末識別情報設定機能は，次の方法で使用できます。

1. TP1/Client/J環境定義のdchostオペランドにDCCM3論理端末のホスト名を指定します。
2. TP1/Client/J環境定義のdchostオペランドまたはdcrapportオペランドにDCCM3論理端末のポート番号を指定します。
3. TP1/Client/J環境定義のdccltconnectinfオペランドに端末識別情報を設定します。
4. 次の方法でDCCM3論理端末との常設コネクションを確立します。
   TP1/Client/J環境定義のdcrapautoconnectオペランドにYを指定します。
   

●DCCM3論理端末に端末識別情報を通知する場合の注意事項

• 端末固定割り当て機能を使用していないDCCM3の論理端末に対して，TP1/Client/Jから端末識別情報を設定して常設コネクションの確立を要求した場合，DCCM3はTP1/Client/Jが設定した端末識別情報の設定内容を無視します。
• TP1/Client/Jから端末識別情報を設定して，TP1/Serverのrapサーバと常設コネクションを確立する場合，rapサーバはTP1/Client/Jが設定した端末識別情報の設定内容を無視します。また，TP1/Client/Jがrapサーバを介してDCCM3へRPCを発行する場合，TP1/Client/Jで設定した端末識別情報はDCCM3に伝達されません。
• 端末識別情報は，リモートAPI機能を使用したRPCの場合だけ有効となります。ネームサービスを使用したRPC，またはスケジューラダイレクト機能を使用したRPCの場合は，端末識別情報を設定しても無視されます。

XAリソースサービス機能を使用する場合，TP1 ConnectorまたはTP1 Connectorが必要です。

TP1アダプタでは，この機能を使用できません。

TP1/Client/Jでは，トラブルシュート機能として，UAPトレース，データトレース，エラートレース，メモリトレース，メソッドトレース，デバッグトレース，性能解析トレース，および性能検証用トレースを取得できます。

詳細については，「付録A.3　TP1/Client/Jの障害対策」を参照してください。

データ圧縮機能を使用すると，RPCによってネットワーク上に送り出されるユーザデータを圧縮できます。これによってネットワーク上に送り出されるパケット数を削減し，ネットワークの混雑を緩和できます。

データ圧縮機能を使用するかどうかは，TP1/Client/J環境定義のdccltdatacompオペランドで指定します。

TP1アダプタでは，この機能を使用できません。

TP1/Client/Jでは，RPCやTCP/IP通信機能でのコネクション確立要求時に，CUPの送信元ホストを指定できます。この機能を，送信元ホスト指定機能といいます。

CUPが動作するホスト上に，複数のネットワークアダプタが接続されている場合，CUPがこれらのコネクション確立要求時に使用する送信元ホストは，TCP/IPの制御で任意に決まります。しかし，送信元ホスト指定機能を使用すると，次のコネクション確立要求時の送信元ホストを固定できます。

• スケジューラダイレクト機能を使用したRPC
• ネームサービスを使用したRPC
• リモートAPI機能を使用したRPC
• 通信先を指定したRPC
• TCP/IP通信機能

CUPの送信元ホストは，TP1/Client/J環境定義のdccltcupsndhostオペランドで指定します。

TP1アダプタでは，この機能を使用できません。

TP1/Client/Jでは，スケジューラダイレクト機能を使用したRPCの受信ポート，およびネームサービスを使用したRPCの受信ポートを固定できます。この機能を，受信ポート固定機能といいます。

この機能は，TP1/ServerからTP1/Client/JへのRPCの応答通信をする場合で，TP1/ServerとTP1/Client/Jとの間に設置したファイアウォールでTP1/Client/Jの受信ポートにだけ通知を許可するようにフィルタリングしたいときに使用します。

この機能を使用する場合は，TP1/Client/J環境定義のdccltcuprcvportオペランドを指定します。

TP1アダプタでは，この機能を使用できません。

サーバダウンなどの理由によって，指定したホストとの通信が一時的に不可となった場合，通信先ホストを1つしか指定していないと，TP1/Client/Jのメソッドはエラーリターンし，通信先ホストの指摘を変更したあと，CPUを再起動する必要があります。

通信先ホストを複数指定しておくと，TP1/Client/Jはホストを切り替えて，別のホストに通信を試みます。これによって，ユーザは通信先ホストの切り替えを意識することなく業務を継続することができます。

なお，障害の内容によっては，ホストを切り替えない場合があります。

TP1アダプタでは，この機能を使用できません。