OpenTP1 Version 7

高速トランザクション処理基盤

TP1/EE/Extended Transaction Controller 使用の手引

解説・手引・文法書

3000-3-F54-20

目　　次

前書き

変更内容

はじめに

1.　概要

1.1　TP1キャッシュ機能とは

1.1.1　高速トランザクション処理を取り巻く環境

1.1.2　トランザクション処理の高速化と高信頼性，高可用性の共存

1.2　システム構成

1.2.1　TP1キャッシュ機能使用時のサーバ構成

1.2.2　ソフトウェア構成

1.3　TP1キャッシュ機能の特長

1.3.1　トランザクション処理の高速化

1.3.2　データに対する高信頼性の確保

1.3.3　フェールオーバ時間の短縮による高可用性の実現

1.3.4　システム運用面での負荷軽減

2.　XTCの機能

2.1　XTCが備えるTP1キャッシュ機能の全体像

2.1.1　高速通信・高速処理を実現する機能

2.1.2　高信頼性を実現する機能

2.1.3　運用性を向上させる機能

2.1.4　永続メッセージと非永続メッセージ

2.2　高速メッセージ送信制御

2.2.1　高速メッセージ送信制御の概要

2.2.2　UDP通信機能によるシステム間通信の流れ

2.2.3　APIからの要求受け付け時の動作

2.2.4　一方送信メッセージの送信

2.2.5　一方送信メッセージの受信

2.2.6　出力キューによるメッセージ管理

2.2.7　送達確認待ちの時間監視

2.2.8　障害処理

2.3　XTCのRPC通信

2.3.1　UDPプロトコルを使用したRPC通信

2.3.2　通信方式

2.3.3　TCPプロトコルを使用したRPC通信との差異

2.3.4　UDPプロトコルを使用したRPC通信で使用できるAPI

2.3.5　注意事項

2.4　UDP通信機能

2.4.1　UDPプロトコルを使用した通信

2.4.2　輻輳制御

2.4.3　複数メッセージの一括送受信機能

2.4.4　W-send機能

2.4.5　UDP通信機能で使用するリソース

2.4.6　ポート構成

2.4.7　UDP通信機能で使用するタイマ

2.4.8　負荷分散機能

2.5　トランザクション制御

2.5.1　TP1キャッシュ機能使用時のCLサーバでのトランザクション

2.5.2　関連するAPI

2.5.3　トランザクショナルRPCの抑止（CLサーバ）

2.5.4　RPC応答の送信タイミング変更機能

2.6　処理キューの制御

2.6.1　TP1キャッシュ機能使用時の処理キューの制御方式

2.6.2　メッセージの同時引き出しの有無

2.6.3　後続メッセージの読み出し

2.6.4　読み出しメッセージの差し戻し

2.6.5　ロールバック時の読み出しメッセージの扱い（ロールバックリトライ）

2.6.6　プロセス終了時の未読み出しメッセージの扱い

2.6.7　サービス先行解放

2.6.8　連鎖モード連携機能

2.7　ステータスファイルレス機能

2.8　メモリの管理

2.8.1　バッファの管理

2.8.2　ワーク領域の管理

2.8.3　バッファ不足時の面数拡張

2.8.4　大量処理用メモリ管理機能

2.9　キューダンプ機能

2.9.1　キューダンプ機能の概要

2.9.2　滞留メッセージのキューダンプファイルへの出力

2.9.3　キューダンプファイルに出力されたメッセージの参照

2.10　UAPのテスト支援機能

2.10.1　CLサーバのシミュレート機能

2.11　CL単独起動機能

3.　XTCが扱うファイルの種類と容量見積もり

3.1　XTCが扱うファイルの種類

3.2　ファイルの容量見積もり

3.2.1　キューダンプファイルの容量見積もり

3.2.2　TASKTMファイルの容量見積もり

3.2.3　回線トレースファイルの容量見積もり

3.2.4　メモリダンプファイルの容量見積もり

4.　環境設定

4.1　環境設定の概要

4.2　TP1/Server Base管理者の設定

4.3　インストール

4.4　システム定義の設定

4.5　OSへの登録，ファイルシステム領域の作成

4.6　ファイルの作成，リソースマネジャの登録

4.7　データベースの準備

4.8　HAモニタの環境設定

4.8.1　CLサーバの場合

4.8.2　HAサーバの場合

5.　システム定義

5.1　システム定義の概要

5.1.1　定義の体系

5.1.2　定義の構成

5.1.3　定義の規則

5.1.4　CLサーバでの注意事項

5.2　TP1/EEサービス定義

5.2.1　TP1キャッシュ機能使用時に指定できないTP1/EEサービス定義

5.2.2　CLサーバで指定できないTP1/EEサービス定義

5.2.3　HAサーバで指定できないTP1/EEサービス定義

5.3　XTCサービス定義

メモリ関連定義

RPC関連定義

ユーザサービス関連定義

ユーザサービス関連定義（コマンド形式）

トラブルシュート関連定義

トランザクション関連定義

ステータスファイル関連定義

サービスグループ情報関連定義（コマンド形式）

高速メッセージ送信関連定義

クラスタ連携関連定義

HAモニタ関連定義

送信先サービス関連定義（コマンド形式）

UDPグループ情報関連定義（コマンド形式）

HAサーバで指定できないXTCサービス定義

6.　運用

6.1　XTCの開始

6.1.1　HAサーバでのXTCの開始

6.1.2　CLサーバでのXTCの開始

6.2　XTCの終了

6.2.1　HAサーバでのXTCの終了

6.2.2　CLサーバでのXTCの終了

6.3　ファイルの運用

6.3.1　回線トレースファイルの運用

6.4　運用コマンド

運用コマンドの一覧

eeactsv（サービスの閉塞解除）

eedctsv（サービスの閉塞）

eehamls（系の状態表示）

eelspce（処理キュー制御用バッファの状態表示およびサービスの最大同時処理限界数の変更）

eelspcenum（処理キュー制御用バッファの状態表示（通番付き））

eemchotqact（出力キューの閉塞解除）

eemchotqdct（出力キューの閉塞）

eemchotqend（出力キューの未送信メッセージの監視終了）

eemchotqls（出力キューの状態表示）

eemchotqskip（出力キューの未送信メッセージのスキップ）

eepcerefer（滞留メッセージのファイル出力）

eepceskip（滞留メッセージのスキップ）

eetrbqueed（キューダンプファイルの編集）

eetrbwtor（メッセージへの応答）

7.　CL連携による系切り替え機能

7.1　CL連携の概要

7.1.1　CL連携による系切り替え

7.1.2　待機系がなくなった場合のXTCの処理

7.1.3　系が切り替わるときの処理の流れ

7.1.4　CL連携時の制限事項

7.1.5　HAモニタ情報ファイル

7.2　自動系切り替えの監視対象となる障害

7.2.1　HAモニタが監視する障害

7.2.2　系切り替えの単位

7.3　系の状態表示

7.4　実行系孤立状態になった場合の対処

7.5　実行系と待機系の間で通信障害が発生した場合の対処

7.5.1　通信障害が発生した場合のXTCの処理と管理者の対処

7.5.2　実行系とすべての待機系との間で通信ができない場合のXTCの処理

7.6　転送処理によるリソースの永続化

7.6.1　待機系に転送されるリソース

7.6.2　入力メッセージの永続化

7.6.3　トランザクションと同期して転送されるリソースの永続化

7.6.4　トランザクションと非同期に転送されるリソースの永続化

7.6.5　UAPからロールバック要求があった場合の転送処理

7.6.6　UAPが異常終了した場合の転送処理

7.7　システム間通信でのメッセージ転送処理

7.7.1　一方送信メッセージの処理の流れ

7.7.2　CL同期メッセージの処理の流れ

7.8　転送処理での時間監視機能

7.8.1　送信メッセージの監視

7.8.2　待機系で仕掛かり中のリソースの監視

7.9　転送処理で障害が発生したときのXTCの処理

7.10　系切り替えが発生したときのXTCの処理

7.11　CLサーバで実行できるHAモニタのコマンド

8.　障害時の運用

8.1　想定される障害

8.1.1　XTCの開始時に発生する障害

8.1.2　XTCの終了時に発生する障害

8.1.3　メッセージの送受信で発生する障害

8.1.4　キュー満杯時に発生する障害

8.1.5　システムダウン時の動作

8.1.6　UAPの障害（SQLでの問題）

8.2　障害に備えて取得する情報

付録

付録A　インストールディレクトリとファイル

付録B　各バージョンの変更内容

付録C　用語解説

索引

[商品名称に関する表示]

All Rights Reserved. Copyright (C) 2008, 2015, Hitachi, Ltd.

前書き

■ 対象製品

P-9W64-9211　 uCosminexus TP1/EE/Extended Transaction Controller　 01-03（適用OS：Red Hat Enterprise Linux 5 (AMD/Intel 64)，Red Hat Enterprise Linux 5 Advanced Platform (AMD/Intel 64)，Red Hat Enterprise Linux Server 6(64-bit x86_64)）
P-8264-9211　 uCosminexus TP1/EE/Extended Transaction Controller　 01-03（適用OS：Red Hat Enterprise Linux Server 6(64-bit x86_64)，Red Hat Enterprise Linux Server 7(64-bit x86_64)）

これらのプログラムプロダクトのほかにも，このマニュアルをご利用になれる場合があります。詳細は「リリースノート」でご確認ください。
これらの製品は，ISO9001およびTickITの認証を受けた品質マネジメントシステムで開発されました。

■ 輸出時の注意

本製品を輸出される場合には、外国為替及び外国貿易法の規制並びに米国輸出管理規則など外国の輸出関連法規をご確認の上、必要な手続きをお取りください。
なお、不明な場合は、弊社担当営業にお問い合わせください。

■ 商標類

HITACHI，HAモニタ，HiRDB，OpenTP1，uCosminexusは，（株）日立製作所の商標または登録商標です。
AMDは，Advanced Micro Devices, Inc.の商標です。
Linuxは，Linus Torvalds氏の日本およびその他の国における登録商標または商標です。
OracleとJavaは，Oracle Corporation 及びその子会社，関連会社の米国及びその他の国における登録商標です。
Red Hatは，米国およびその他の国でRed Hat, Inc. の登録商標もしくは商標です。
UNIXは，The Open Groupの米国ならびに他の国における登録商標です。
その他記載の会社名，製品名は，それぞれの会社の商標もしくは登録商標です。

■ 発行

2015年10月 3000-3-F54-20

■ 著作権

All Rights Reserved. Copyright (C) 2008, 2015, Hitachi, Ltd.

変更内容

変更内容（3000-3-F54-20）　uCosminexus TP1/EE/Extended Transaction Controller　01-03

追加・変更内容
変更個所

RPC応答の送信タイミング変更機能をサポートした。
2.5.4

読み出しできる後続メッセージの条件について，説明を追加した。
2.6.3(1)

次のオペランドの説明を変更した。

メモリ関連定義

mem_uibf_extend_num

mem_obf_extend_num

mem_uobf_extend_num

5.3　XTCサービス定義

メモリ関連定義
mem_uibf_extend_num
mem_obf_extend_num
mem_uobf_extend_num

次のオペランドの説明を変更した。

RPC関連定義

rpc_tcp_communication_use

5.3　XTCサービス定義

RPC関連定義
rpc_tcp_communication_use

次のオペランドのデフォルト値を変更した。

RPC関連定義

rpc_recv_permanence

5.3　XTCサービス定義

RPC関連定義
rpc_recv_permanence

次のオペランドを追加した。

ユーザサービス関連定義

errtrn_serialize

5.3　XTCサービス定義

ユーザサービス関連定義
errtrn_serialize

次のオペランドを追加した。

トランザクション関連定義

trn_cl_rpc_reply_timing

5.3　XTCサービス定義

トランザクション関連定義
trn_cl_rpc_reply_timing

次のオペランドを削除した。

高速メッセージ送信関連定義

mch_send_err_rollback

5.3　XTCサービス定義

高速メッセージ送信関連定義
mch_send_err_rollback

次のオペランドを追加した。

クラスタ連携関連定義

mch_clreq_rcvthd

5.3　XTCサービス定義

クラスタ連携関連定義
mch_clreq_rcvthd

7.7.2

次のオペランドの説明を変更した。

HAモニタ関連定義

ham_stop_msg_interval_time

5.3　XTCサービス定義

HAモニタ関連定義
ham_stop_msg_interval_time

次のオペランドの説明を変更した。

UDPグループ情報関連定義（コマンド形式）

clgrpdef（クラスタグループ情報定義）

5.3　XTCサービス定義

UDPグループ情報関連定義（コマンド形式）
clgrpdef（クラスタグループ情報定義）

eehamlsコマンドの説明を変更した。

6.4　運用コマンド

eehamls（系の状態表示）

系の状態表示の説明を変更した。
7.3

実行系孤立状態になった場合のDB管理者の対処の説明を変更した。
7.4

単なる誤字・脱字などはお断りなく訂正しました。

はじめに

このマニュアルは，次に示すプログラムプロダクトのシステム構築方法および運用方法について説明したものです。

P-9W64-9211 uCosminexus TP1/EE/Extended Transaction Controller

P-8264-9211 uCosminexus TP1/EE/Extended Transaction Controller

以降，このマニュアルでは，「uCosminexus TP1/EE/Extended Transaction Controller」を「XTC」と表記します。

＜はじめにの構成＞

対象読者

マニュアルの構成

関連マニュアル

読書手順

図中で使用する記号

文法の記号

計算式の記号

このマニュアルでの表記

略語一覧

KB（キロバイト）などの単位表記について

対象読者

TP1キャッシュ機能（インメモリデータ処理技術を中心とした高速トランザクション処理機能）を使用したシステムを構築・運用するシステム管理者，システム設計者，プログラマ，およびオペレータの方を対象としています。

なお，このマニュアルは，次に示す知識があることを前提にして説明されています。

Linuxのシステム管理の基礎的な知識

オンラインシステムの基礎的な知識

TP1/Server BaseおよびTP1/Server Base Enterprise Optionの基礎的な知識

HAモニタによる系切り替え機能の基礎的な知識

マニュアルの構成

このマニュアルは，次に示す章と付録から構成されています。

第1章　概要

TP1キャッシュ機能の概要とシステム構成，および特長について説明しています。

第2章　XTCの機能

XTCの機能について説明しています。

第3章　XTCが扱うファイルの種類と容量見積もり

XTCが扱うファイルの種類と容量見積もりについて説明しています。

第4章　環境設定

TP1キャッシュ機能使用時の環境設定とその手順について説明しています。

第5章　システム定義

TP1キャッシュ機能使用時のシステム定義について説明しています。

第6章　運用

XTCの開始・終了方法，および運用コマンドについて説明しています。

第7章　CL連携による系切り替え機能

CL連携による系切り替え機能の仕組みと運用方法について説明しています。

第8章　障害時の運用

障害時の運用について説明しています。

付録A　インストールディレクトリとファイル

XTCのインストールディレクトリの構成とファイルについて説明しています。

付録B　各バージョンの変更内容

各バージョンの変更内容について説明しています。

付録C　用語解説

このマニュアルで使用している用語について説明しています。

関連マニュアル

読書手順

図中で使用する記号

このマニュアルの図中で使用する記号を，次のように定義します。

文法の記号

（1）文法記述記号

システム定義，コマンドのオプションおよび引数の指定方法について説明する記号です。

文法記述記号
意味

〔　　　〕
この記号で囲まれている項目は省略できることを意味しています。

（例）〔-g サービスグループ名〕

この場合，-gオプションの指定を省略できます。

…
この記号で示す直前の項目を繰り返し指定できることを意味しています。

（例）eetrbqueed キューダンプファイル名 〔キューダンプファイル名〕…

この場合，eetrbqueedコマンドにキューダンプファイル名を複数指定できます。

｜
この記号で区切られた項目は選択できることを意味しています。

（例）〔Y｜N〕

この場合，YまたはNのどちらかを指定できます。

｛｛　　　｝｝
この記号で囲まれた複数の項目が一つの繰り返し項目の単位であることを示します。

（例）｛｛eemchsrvdef -g サービスグループ名｝｝

これは，次のように繰り返し指定できることを示します。

eemchsrvdef -g サービスグループ名

eemchsrvdef -g サービスグループ名

｛　　　｝
この記号で囲まれている複数の項目のうち，一つだけ選択できることを意味しています。

（例）｛act｜dct｜all｝

この場合，act，dct，allのうち，どれか一つを指定できます。

＿
（下線）
この記号で示す項目は，該当オペランド，またはオプションを省略した場合に仮定される値を意味しています。

（例）trn_transactional_rpcless_use＝Y｜N

この場合，trn_transactional_rpcless_useオペランドを省略すると，Nが仮定されます。

（2）属性表示記号

システム定義，およびコマンドに指定できる値の範囲を説明する記号です。

属性表示記号 | 意味
～ | この記号のあとに指定値の属性を示します。
《　　》 | 指定を省略したときに仮定される値を示します。
〈　　〉 | 指定値の構文要素を示します。
((　　)) | 指定値の指定範囲を示します。

（3）構文要素記号

システム定義，およびコマンドに指定できる文字または値を説明する記号です。

構文要素記号
意味

〈英字〉
アルファベット（A～Z，a～z）と_（アンダスコア）

〈英数字〉
英字と数字（0～9）

〈符号なし整数〉
数字列（0～9）

〈16進数〉
数字（0～9），A～F，およびa～f

〈識別子〉
先頭がアルファベットの英数字列

〈パス名〉
記号名称，/，および　.（ピリオド）
ただし，パス名は使用するOSに依存します。

〈ホスト名〉
英数字，および!，#，$，%，&，'，(，)，*，+，-，.（ピリオド），/，;，<，=，>，?，@，[，¥，]，^，_（アンダスコア），{，|，}，~，,（コンマ）
ただし，OSによって使用できる文字が異なります。詳細は，使用しているOSのマニュアルを参照してください。

使用上の注意

すべて半角文字を使用してください。

計算式の記号

記号
意味

↑↑
計算結果の値を小数点以下で切り上げます。
（例）　↑34÷3↑
この場合，計算結果は，12となります。

↓↓
計算結果の値を小数点以下で切り捨てます。
（例）　↓34÷3↓
この場合，計算結果は，11となります。

MAX
括弧内の項目のうち，最も大きい値を選びます。

（例）MAX（3，8+2，2×2）

この場合，計算結果は10となります。

MIN
括弧内の項目のうち，最も小さい値を選びます。

（例）MIN（3，8+2，2×2）

この場合，計算結果は3となります。

このマニュアルでの表記

このマニュアルでは，製品の名称を省略して表記しています。製品の名称と，このマニュアルでの表記を次に示します。

製品名称 | このマニュアルでの表記
Linux(R) | Linux
Red Hat Enterprise Linux 5 (AMD/Intel 64)
Red Hat Enterprise Linux 5 (Intel Itanium)
Red Hat Enterprise Linux 5 (x86)
Red Hat Enterprise Linux 5 Advanced Platform (AMD/Intel 64)
Red Hat Enterprise Linux 5 Advanced Platform (Intel Itanium)
Red Hat Enterprise Linux 5 Advanced Platform (x86)
Red Hat Enterprise Linux Server 6(64-bit x86_64)
Red Hat Enterprise Linux Server 7(64-bit x86_64)
uCosminexus TP1/EE/Extended Data Cache | XDB
uCosminexus TP1/EE/Extended Transaction Controller | XTC
uCosminexus TP1/EE/Message Control Extension | MCP
uCosminexus TP1/Server Base | TP1/Server Base
uCosminexus TP1/Server Base Enterprise Option | TP1/EE
uCosminexus TP1/Server Base Enterprise Option(64)

略語一覧

このマニュアルで使用する英略語の一覧を次に示します。

英略語 | 英字での表記
API | Application Programming Interface
ASCII | American Standard Code for Information Interchange
CPU | Central Processing Unit
DB | Database
DNS | Domain Name System
HA | High Availability
I/O | Input/Output
ID | Identifier
IP | Internet Protocol
IT | Information Technology
LAN | Local Area Network
MP | Management Processor
MTU | Maximum Transmission Unit
OS | Operating System
RPC | Remote Procedure Call
SPP | Service Providing Program
TCP | Transmission Control Protocol
TCP/IP | Transmission Control Protocol/Internet Protocol
TTL | Time To Live
UAP | User Application Program
UDP | User Datagram Protocol
UOC | User Own Coding
XA | Extended Architecture

KB（キロバイト）などの単位表記について

1KB（キロバイト），1MB（メガバイト），1GB（ギガバイト），1TB（テラバイト）はそれぞれ1,024バイト，1,024²バイト，1,024³バイト，1,024⁴バイトです。

1.　概要

この章では，TP1キャッシュ機能の概要とシステム構成，および特長について説明します。

＜この章の構成＞

1.1　TP1キャッシュ機能とは

1.2　システム構成

1.3　TP1キャッシュ機能の特長

1.1　TP1キャッシュ機能とは

TP1キャッシュ機能とは，インメモリデータ処理技術を中心とした高速トランザクション処理機能の総称です。インメモリデータ処理技術とは，オンライントランザクション処理システムで処理するデータをすべてメモリ上に配置し，高速に処理するための技術です。

TP1キャッシュ機能は，TP1/Server Base Enterprise Option（TP1/EE）を前提とする機能です。高速メッセージ処理基盤であるuCosminexus TP1/EE/Extended Transaction Controller（XTC）と，高速データ処理基盤であるuCosminexus TP1/EE/Extended Data Cache（XDB）の2製品から構成されます。

TP1キャッシュ機能を使用することで，トランザクション処理の高速化と，高信頼性，高可用性を同時に実現するオンライントランザクション処理システムを構築できます。

ここでは，高速トランザクション処理を取り巻く環境について説明したあと，トランザクション処理の高速化と高信頼性，高可用性の共存について説明します。

＜この節の構成＞

1.1.1　高速トランザクション処理を取り巻く環境

1.1.2　トランザクション処理の高速化と高信頼性，高可用性の共存

1.1.1　高速トランザクション処理を取り巻く環境

近年，IT技術の進歩やインターネットの発展に伴い，オンライントランザクション処理システムで処理されるトランザクション量は増加の一途をたどっています。金融・証券系システムでは，オンライントレードの普及とそれに伴う株取引の小口化やアルゴリズム取引※の浸透によって，今後さらに，トランザクション量の大幅な増加が予想されています。

一方，企業ビジネスでは，ミリ秒レベルといわれる超高速な応答性能を持つシステム基盤が求められています。

このような背景から，高信頼性，高可用性に加えて，大量のデータを高速に処理でき，かつ，将来のトランザクション量の増大にも耐えうる，高速トランザクション処理基盤が必要不可欠なものとなってきています。

TP1キャッシュ機能では，オンラインシステムで処理するデータをすべてメモリ上に配置し，データ操作に伴う磁気ディスク装置に対する入出力処理をなくすことによって，これらの要件を満たす高速トランザクション処理基盤を提供します。

注※

コンピュータシステムが株価や出来高などに応じて，自動的に株式売買注文のタイミングや数量を決めて注文を行う取引のことです。

TP1キャッシュ機能の概要を次の図に示します。

図1-1　TP1キャッシュ機能の概要

TP1キャッシュ機能を適用すると，例えばトランザクション量が増加しても，インメモリ処理によって高速な応答性能を実現できます。また，アプリケーションサーバとDBサーバ間のアクセスがなくなるため，DBサーバの負荷も軽減されます。TP1キャッシュ機能の適用イメージを次の図に示します。

図1-2　TP1キャッシュ機能の適用イメージ

1.1.2　トランザクション処理の高速化と高信頼性，高可用性の共存

メモリの大容量化や，64ビットOSの普及といった背景もあり，操作対象のデータをすべてメモリ上に保持してデータ処理を行うインメモリデータ処理技術は，トランザクション処理を高速化する手段として注目されつつあります。磁気ディスク装置にデータを格納するディスク型DBとは異なり，メモリ上にデータを配置，処理するデータベース（インメモリDB）では，磁気ディスク装置に対する入出力処理が発生しないため，トランザクション処理を高速化できるからです。

一方，インメモリDBには，その特性上，予期しないシステムダウンなどの障害が発生した場合に，データの消失をどのようにして防ぐかという大きな課題があります。特に，ミッションクリティカルなシステムでは，インメモリDBによる高速化に加え，高信頼性と高可用性が必須要件となります。

TP1キャッシュ機能では，システムを多重化してクラスタリングを行うことで，信頼性と可用性を確保します。多重化されたシステムが協調して動作することによって，業務処理を行っているシステム（実行系）に障害が発生してもデータやメッセージを保持したまま，バックアップシステム（待機系）で業務処理を継続できます。TP1キャッシュ機能でのデータ保持の概要を次の図に示します。

図1-3　TP1キャッシュ機能でのデータ保持の概要

TP1キャッシュ機能は，高信頼性，高可用性を兼ね備えた高速データ処理基盤として，ミッションクリティカルなシステムでも使用できます。

1.2　システム構成

ここでは，TP1キャッシュ機能を使用する場合のシステム構成について説明します。

＜この節の構成＞

1.2.1　TP1キャッシュ機能使用時のサーバ構成

1.2.2　ソフトウェア構成

1.2.1　TP1キャッシュ機能使用時のサーバ構成

TP1キャッシュ機能を使用するシステムでは，HAサーバとCLサーバを配置します。HAサーバとCLサーバ間はネットワーク経路を多重化することもできます。

■HAサーバ

HAサーバとは，TP1キャッシュ機能使用時に，メッセージやRPCの送信側となるサーバです。それぞれのサーバにXTCを配置します。

HAサーバは，一般的なクラスタ構成とし，実行系1台，待機系1台の2台で構成します。

共用ディスクなどを使用してデータの永続化を図る場合はHAサーバとします。

■CLサーバ

CLサーバとは，TP1キャッシュ機能使用時に，メッセージやRPCの受信側となって，高速データ処理を行うサーバです。それぞれのサーバにXTCおよびXDBを配置します（XDBを配置したサーバは必ずCLサーバにする必要があります）。

CLサーバは，HAモニタのマルチスタンバイ機能を使用したクラスタ構成として，実行系1台，待機系2台の3台で構成します。

TP1キャッシュ機能を使用すると，CLサーバ間で連携して，実行系のデータベースの更新内容を，待機系のデータベースに逐次反映して整合性を保持します。

インメモリデータ処理を行う場合はCLサーバとします。

TP1キャッシュ機能を使用する場合のシステム構成例を次の図に示します。

図1-4　TP1キャッシュ機能を使用する場合のシステム構成例

1.2.2　ソフトウェア構成

XTCとXDBはTP1/EE下で動作します。TP1/EEとXTC，XDBの関係を次の図に示します。

図1-5　TP1/EEとXTC，XDBの関係

TP1キャッシュ機能でのXTCとXDBの役割について，次に示します。

＜この項の構成＞

(1)　TP1キャッシュ機能でのXTCの役割

(2)　TP1キャッシュ機能でのXDBの役割

(1)　TP1キャッシュ機能でのXTCの役割

XTCは，高速メッセージ処理基盤として，次のような処理を行います。

UDPプロトコルを使用した高速メッセージ制御

マルチキャストによるCLサーバの実行系，待機系への同時送信

実行系と待機系との間の整合性の保証

XDBとのトランザクション連携

(a)　UDPプロトコルを使用した高速メッセージ制御

TP1/EE間でのシステム間通信（RPC）やメッセージの送受信を，UDPプロトコルを使用した独自のインタフェースによって実行できます。これによって，高速にメッセージを送受信することができます。

(b)　マルチキャストによるCLサーバの実行系，待機系への同時送信

HAサーバからの処理要求（メッセージ）を，マルチキャストでCLサーバの実行系，待機系それぞれのサーバに同時に送信できます。処理要求をそれぞれのサーバで保証することによって，CLサーバの実行系で障害が発生しても，待機系で処理を継続できます。マルチキャストによるCLサーバの実行系，待機系への同時送信の概要を次の図に示します。

図1-6　マルチキャストによるCLサーバの実行系，待機系への同時送信

(c)　実行系と待機系との間の整合性の保証

データの保全を行うため，CLサーバの実行系のデータを待機系に転送します。その際，データの送信順序を保証することによって，CLサーバの実行系と待機系との間でデータの整合性を保証します。

保全の対象となるデータには，入出力メッセージ，XDBの更新ログ，タイマトランザクションメッセージなどがあります。

CLサーバの実行系と待機系の整合性の保証とデータの保全を次の図に示します。

図1-7　CLサーバの実行系と待機系の整合性の保証とデータの保全

(d)　XDBとのトランザクション連携

インメモリデータ処理を実現するXDBと連携したトランザクション制御を行うことによって，高速なトランザクション処理を実現します。

(2)　TP1キャッシュ機能でのXDBの役割

XDBは，高速データ処理基盤として次のような処理を行います。

インメモリデータ処理の制御

更新ログによる待機系のデータベースの更新

XDBの詳細については，マニュアル「TP1/EE/Extended Data Cache 使用の手引」を参照してください。

(a)　インメモリデータ処理の制御

インメモリデータ処理では，すべてのデータをメモリ上に展開します。これによって，トランザクション実行時間の大半を占めていたディスクアクセスに掛かる時間が大幅に削減され，トランザクションの処理性能が大きく向上します。

メモリ上へのデータベースの展開は，CLサーバの実行系の正常開始時に自動的に行われます（XDBが行います）。CLサーバの待機系の起動時には，実行系のデータベースの内容がコピーされて展開されます。

XDBの正常終了時には，メモリ上に展開されていたデータベースの内容が指定されたファイルに自動的に取得されます。次回のオンライン起動時には，ここで取得した内容をメモリ上に展開することができます。

(b)　更新ログによる待機系のデータベースの更新

CLサーバの実行系と待機系の整合性を保証するため，XDBでは実行系のデータベースの更新内容を，待機系のデータベースに逐次反映します。

1.3　TP1キャッシュ機能の特長

ここでは，TP1キャッシュ機能の特長について次の観点から説明します。

トランザクション処理の高速化

データに対する高信頼性の確保

フェールオーバ時間の短縮による高可用性の実現

システム運用面での負荷軽減

TP1キャッシュ機能の特長を次の図に示します。

図1-8　TP1キャッシュ機能の特長

＜この節の構成＞

1.3.1　トランザクション処理の高速化

1.3.2　データに対する高信頼性の確保

1.3.3　フェールオーバ時間の短縮による高可用性の実現

1.3.4　システム運用面での負荷軽減

1.3.1　トランザクション処理の高速化

TP1キャッシュ機能では，トランザクション処理でのスループットの向上とレイテンシの低減を図るため，次のような特長があります。

高速メッセージ制御

インメモリデータ処理の採用

TP1/EEと同一プロセス内にデータを展開

＜この項の構成＞

(1)　高速メッセージ制御

(2)　インメモリデータ処理の採用

(3)　TP1/EEと同一プロセス内にデータを展開

(1)　高速メッセージ制御

UDPプロトコルを使用することによって，メッセージやRPCの送受信を高速化しています。その際，UDPプロトコルの欠点である，送信順序や送達確認をXTCが保証します。

(2)　インメモリデータ処理の採用

インメモリデータ処理によって，磁気ディスク装置の入出力に掛かるオーバヘッドをなくし，トランザクションの処理性能を大きく向上させます。

(3)　TP1/EEと同一プロセス内にデータを展開

TP1/EEと同一のプロセス内にデータを展開することによって，データアクセス時に他プロセスとの通信を発生させません。これによって，OpenTP1とDBMS（リソースマネジャ）の間で発生する通信オーバヘッドを削減しています。

1.3.2　データに対する高信頼性の確保

TP1キャッシュ機能では，データに対する高信頼性を確保するため，次のような特長があります。

待機系の複数配置

待機系への更新内容の逐次反映，および待機系によるデータの保全

実行系孤立時のデータ保全

＜この項の構成＞

(1)　待機系の複数配置

(2)　待機系への更新内容の逐次反映，および待機系によるデータの保全

(3)　実行系孤立時のデータ保全

(1)　待機系の複数配置

インメモリデータ処理の課題である障害発生時のデータの消失を防ぐため，CLサーバとして複数の待機系を配置します。CLサーバの実行系と待機系が連携して動作することによって，データベースの冗長化を図り，高い信頼性を確保します。

(2)　待機系への更新内容の逐次反映，および待機系によるデータの保全

CLサーバの実行系のデータベースの更新内容（更新ログ）は，XTCによって逐次，待機系に転送されます。待機系では更新ログを基にデータベースの追い付き処理が行われます。

更新ログを転送する際，XTCは転送順序（待機系のデータベースの更新順序）を保証します。これによって，実行系と待機系の間の整合性が保証されます。

CLサーバの実行系と待機系の間の整合性が保証されることによって，待機系がバックアップの位置づけになります（待機系でデータが保全されます）。これによって，実行系で障害が発生しても，メモリ上のデータの消失を防ぐことができます。

(3)　実行系孤立時のデータ保全

障害などによって系切り替えが発生した結果，待機系がなくなり，実行系だけとなった場合（実行系が孤立した場合），XTCはデータの保全を最優先して，メモリ上のダンプ情報をファイルに出力します。

1.3.3　フェールオーバ時間の短縮による高可用性の実現

TP1キャッシュ機能では，CLサーバの実行系で障害が発生した際のフェールオーバ（系切り替え）に掛かる時間を大幅に短縮しています。高可用性を実現する上で次のような特長があります。

HAモニタとの連携による高速系切り替え

TP1/EEのプロセス単位での系切り替え

メモリリソース情報の取得

＜この項の構成＞

(1)　HAモニタとの連携による高速系切り替え

(2)　TP1/EEのプロセス単位での系切り替え

(3)　メモリリソース情報の取得

(1)　HAモニタとの連携による高速系切り替え

TP1キャッシュ機能では，XTCがHAモニタと独自のインタフェースで連携し，障害発生時の系の切り替えを高速で行います。CLサーバの実行系と待機系の整合性が保証されているため，待機系で再開始処理（実行系への追い付き処理）を実行することなく，高速で系切り替えを実行できます。

(2)　TP1/EEのプロセス単位での系切り替え

TP1キャッシュ機能では，マシン単位ではなく，TP1/EEのプロセス単位に系切り替えを行います。これによって，高速な切り替えを実現し，オンライン停止時間を極小化します。

(3)　メモリリソース情報の取得

CLサーバが2台構成時に，実行系で障害が発生して残り1台になると，自動的にオンライン処理を停止します。その際，データを保持するためにメモリリソース情報（データベースの情報，キューの情報など）を取得します。

1.3.4　システム運用面での負荷軽減

TP1キャッシュ機能を使用する場合，次に示すようなシステム運用面での負荷や，システム環境構築時のコストを軽減できます。

システム環境構築時のコストの軽減

負荷の少ないデータベース運用

トラブルシュート情報や統計情報の一元管理

既存ユーザの移行負荷の軽減

＜この項の構成＞

(1)　システム環境構築時のコストの軽減

(2)　負荷の少ないデータベース運用

(3)　トラブルシュート情報や統計情報の一元管理

(4)　既存ユーザの移行負荷の軽減

(1)　システム環境構築時のコストの軽減

インメモリデータ処理によって，磁気ディスク装置の使用を抑えることができます。磁気ディスク装置は冗長化されていることも多いため，使用を抑えることでシステム環境構築時のコストを軽減できます。

(2)　負荷の少ないデータベース運用

インメモリデータ処理では，データベースの更新履歴（ログ）の管理や，バックアップの取得などの運用が必要ありません。また，バッファプールやチェックポイントなどのチューニングも必要ありません。そのため，データベースの運用に掛かる負荷を少なくすることができます。

(3)　トラブルシュート情報や統計情報の一元管理

XDBに関するトラブルシュート情報や統計情報を，TP1/EEのトラブルシュート，統計情報として一元管理できます。これによって，OpenTP1のインタフェースでリソースマネジャに関する情報を管理できます。

(4)　既存ユーザの移行負荷の軽減

TP1/EEの機能を使用できることから，すでにTP1/EEを使用しているユーザがTP1キャッシュ機能を適用する際，アプリケーションや運用手順などの変更を抑えることができます。これによって，システム移行時の作業負荷やコストを軽減できます。

2.　XTCの機能

この章では，XTCの機能について説明します。

＜この章の構成＞

2.1　XTCが備えるTP1キャッシュ機能の全体像

2.2　高速メッセージ送信制御

2.3　XTCのRPC通信

2.4　UDP通信機能

2.5　トランザクション制御

2.6　処理キューの制御

2.7　ステータスファイルレス機能

2.8　メモリの管理

2.9　キューダンプ機能

2.10　UAPのテスト支援機能

2.11　CL単独起動機能

2.1　XTCが備えるTP1キャッシュ機能の全体像

XTCには，次の機能があります。

高速通信・高速処理を実現する機能

高信頼性を実現する機能

運用性を向上させる機能

ここでは，それぞれの機能の概要と，TP1キャッシュ機能使用時の位置づけを説明します。

また，永続メッセージと非永続メッセージの違いについても説明します。

＜この節の構成＞

2.1.1　高速通信・高速処理を実現する機能

2.1.2　高信頼性を実現する機能

2.1.3　運用性を向上させる機能

2.1.4　永続メッセージと非永続メッセージ

2.1.1　高速通信・高速処理を実現する機能

高速通信・高速処理を実現する機能として，次の図に示す機能があります。

図2-1　高速通信・高速処理を実現する機能

■UDPプロトコルによるRPC通信

RPC通信をUDPプロトコルによって行うことができます。

詳細については，「2.3　XTCのRPC通信」を参照してください。

■UDPプロトコルによるシステム間通信（高速メッセージ送信制御）

システム間通信をUDPプロトコルによって行うことで，高速にメッセージを送受信できます。

詳細については，「2.2　高速メッセージ送信制御」を参照してください。

2.1.2　高信頼性を実現する機能

高信頼性を実現する機能として，次の図に示す機能があります。

図2-2　高信頼性を実現する機能

■再送制御

UDPプロトコルによって送受信するデータの整合性を保証するために，メッセージがロストした場合でも，再送制御によってメッセージを保証します。

詳細については，「2.4　UDP通信機能」を参照してください。

■キューダンプ機能

オンライン終了時にキューに滞留したメッセージをファイル出力することで，次回オンライン開始時の整合性を保ちます。

詳細については，「2.9　キューダンプ機能」を参照してください。

■ネットワーク経路の二重化（W-send機能）

ネットワーク経路を二重化した構成にすることで，ネットワークの信頼性を高めることができます。

詳細については，「2.4　UDP通信機能」を参照してください。

■マルチキャスト送受信（高速メッセージ送信制御）

メッセージをマルチキャストで送受信することによって，系切り替え時のフェールオーバ時間を短縮できます。

■3台構成のCLサーバ

CLサーバを3台構成にすることで，データの高信頼性を確保します。

詳細については，「7.　CL連携による系切り替え機能」を参照してください。

2.1.3　運用性を向上させる機能

運用性を向上させる機能として，次の機能があります。

■トラブルシュート情報の取得とステータスファイルレス機能

トラブルシュート情報はTP1/EEで取得することで，一元管理します。また，ステータスファイルレス機能によって，TP1キャッシュ機能時に取得する情報を限定します。

詳細については，「2.7　ステータスファイルレス機能」を参照してください。

■CLサーバのシミュレート機能

HAモニタ環境，および待機系の環境を構築する前に，TP1キャッシュ機能使用時の動作をシミュレートすることができます。

詳細については，「2.10.1　CLサーバのシミュレート機能」を参照してください。

2.1.4　永続メッセージと非永続メッセージ

CLサーバに対するメッセージの送信では，送信するメッセージを待機系で保証するかどうかを選択できます。このとき，保証するメッセージを永続メッセージ，保証しないメッセージを非永続メッセージといいます。

永続メッセージが有効となる通信を次に示します。

HAサーバからCLサーバへの，マルチキャストでのメッセージ送信要求

CLサーバからのメッセージ送信要求

永続メッセージは送信先の待機系で破棄されませんが，非永続メッセージは破棄されます。

永続メッセージの送信が完了（トランザクション同期点完了）していると，送信先の実行系の障害発生によって待機系に切り替わってもメッセージは保証され，継続してトランザクション処理が実行できます。非永続メッセージでは，待機系に切り替わると継続したトランザクション処理が実行できません。

2.2　高速メッセージ送信制御

ここでは，高速メッセージ送信制御について説明します。

＜この節の構成＞

2.2.1　高速メッセージ送信制御の概要

2.2.2　UDP通信機能によるシステム間通信の流れ

2.2.3　APIからの要求受け付け時の動作

2.2.4　一方送信メッセージの送信

2.2.5　一方送信メッセージの受信

2.2.6　出力キューによるメッセージ管理

2.2.7　送達確認待ちの時間監視

2.2.8　障害処理

2.2.1　高速メッセージ送信制御の概要

TP1キャッシュ機能使用時，高速にメッセージを送受信するために，TP1/EE間でのシステム間通信をUDPプロトコルによって行います。これを，高速メッセージ送信制御といいます。

一般に，UDPプロトコルはコネクションを確立することなくメッセージの送受信ができる反面，メッセージが保証されないという問題があります。そのため，高速メッセージ送信制御では次のことを行ってメッセージを保証しています。

メッセージの送達確認

メッセージの欠落，重複，および到着順序のチェックやフロー制御

＜この項の構成＞

(1)　送受信できるメッセージ

(2)　APIの引数と定義の関連

(3)　メッセージの通信形態

(1)　送受信できるメッセージ

高速メッセージ送信制御では，次に示すメッセージを送受信できます。

トランザクション同期の一方送信メッセージ

トランザクション非同期の一方送信メッセージ

なお，これらのメッセージを総称してMCHメッセージといいます。

(a)　トランザクション同期の一方送信メッセージ

トランザクション同期の一方送信メッセージとは，送信要求元トランザクションのコミット確定時に有効となり，トランザクションの延長で，同期点処理中（UAPリターン後）に送信するメッセージです。

クライアントUAPで，サービス要求に必要な項目をee_mch_cmtsend_sync関数に指定することで，サーバUAPにサービスを要求します。サーバUAPは複数のサービスを実行できます。

トランザクション同期の一方送信メッセージの特徴を次に示します。

CLサーバ（実行系）からの送信要求はできません。

メッセージは，同一トランザクション処理からの送信要求順に送信します。

メッセージ送信失敗時はエラートランザクション（ERRTRNSまたはERRTRNR）を起動し，メッセージを破棄します。

(b)　トランザクション非同期の一方送信メッセージ

トランザクション非同期の一方送信メッセージとは，送信要求元トランザクションのコミット確定後，トランザクション処理とは別のスレッド（送信スレッド）で送信するメッセージです。

クライアントUAPで，サービス要求に必要な項目をee_mch_cmtsend関数に指定することで，サーバUAPにサービスを要求します。サーバUAPは複数のサービスを実行できます。

トランザクション非同期の一方送信メッセージの特徴を次に示します。

メッセージはコミット確定時に出力キュー（OTQ）に登録され，その際に通番を採番します。これによって，未送信のメッセージから通番順に送信できるようになり，送信順序が保証されます。

メッセージ送信失敗時はエラートランザクション（ERRTRNS）を起動し，メッセージを保持（別タイミングで再送）します。

(2)　APIの引数と定義の関連

高速メッセージ送信制御で使用するAPIの引数と定義には関連があります。APIと定義の指定には整合性を持たせてください。

APIの引数と定義の関連の例を次の図に示します。

図2-3　高速メッセージ送信で使用するAPIの引数と定義の関連の例

各定義の詳細については，「5.3　XTCサービス定義」を参照してください。

APIの詳細については，マニュアル「TP1/Server Base Enterprise Option プログラム作成の手引」を参照してください。

(3)　メッセージの通信形態

高速メッセージ送信制御では，UDPプロトコルを使用したクライアント／サーバ形態で通信します。

(a)　クライアント側（送信形態）

マルチキャストまたはユニキャストによってメッセージを送信できます。

(b)　サーバ側（受信形態）

マルチキャストまたはユニキャストによって送信されたメッセージを受信できます。メッセージはTP1/EE内の受信スレッドが受信して，処理キューに登録します。

2.2.2　UDP通信機能によるシステム間通信の流れ

高速メッセージ送信制御は，UDP通信機能によって実現しています。

UDP通信機能では，メッセージの整合性を保証するために送達確認を行います。UDP通信機能によるシステム間通信の流れを次の図に示します。

図2-4　UDP通信機能によるシステム間通信の流れ

説明

送信側のUAPから，一方送信メッセージの送信要求を行います。

UDP通信機能によって，一方送信メッセージを送信します。

受信側では，一方送信メッセージに対する肯定応答（ACK）を送信します。

送達確認用の処理キューを登録し，送信スレッドから肯定応答不要で送達確認メッセージを送信します。

送信側は，受信要求を行って，一方送信メッセージに対する送達確認メッセージを受信します。

UDP通信機能の詳細については，「2.4　UDP通信機能」を参照してください。

2.2.3　APIからの要求受け付け時の動作

高速メッセージ送信制御では，受信側サーバの構成や送信形態によって，APIからの要求受け付け時の動作が異なります。

APIからの要求受け付け時の動作を次の表に示します。

表2-1　APIからの要求受け付け時の動作

項番
受信側サーバ
送信形態
動作

1
HAサーバ
ユニキャスト
－

2
マルチキャスト
受信側では，送達確認エラーを送信します。
送信側では，エラートランザクションを起動します。

3
自プロセスあて
－

4
CLサーバ
ユニキャスト
受信側では，送達確認エラーを送信します。※
送信側では，エラートランザクションを起動します。※

5
マルチキャスト
非永続メッセージの場合，待機系では受信メッセージを破棄します。

6
自プロセスあて
－

（凡例）

－：正常に動作します。

注※

CL単独起動機能を使用している場合，ここに示す動作はしません。正常に動作します。

2.2.4　一方送信メッセージの送信

ここでは，一方送信メッセージを送信するときの流れ，および一方送信メッセージの一括送信について説明します。

＜この項の構成＞

(1)　一方送信メッセージを送信するときの流れ

(2)　一方送信メッセージの一括送信

(1)　一方送信メッセージを送信するときの流れ

トランザクション同期の場合と，トランザクション非同期の場合に分けて説明します。

(a)　トランザクション同期の場合

ユニキャストまたはマルチキャストによる送信

トランザクション同期の一方送信メッセージの送信で，ユニキャストまたはマルチキャストによる送信の流れを次の図に示します。

図2-5　ユニキャストまたはマルチキャストによる送信の流れ（トランザクション同期）

説明

クライアントUAPから，ユニキャストまたはマルチキャストによる一方送信メッセージの送信要求を行います。

TP1/EEは，出力キュー（OTQ）が閉塞状態でなければメッセージをUDP用送信バッファ（UOBF）に格納し，UAPにリターンします。

UAPリターン後，TP1/EEはコミットが確定すると，指定された送信先にメッセージを送信します。

送達確認メッセージを受信することで，送信処理を完了します。

自プロセスあての送信

自プロセスあての送信の流れを次の図に示します。

図2-6　自プロセスあての送信の流れ

説明

クライアントUAPから，自プロセスあての一方送信メッセージの送信要求を行います。

TP1/EEは，出力キューが閉塞状態でなければメッセージをUDP用送信バッファに格納し，UAPにリターンします。

UAPリターン後，TP1/EEは同期点処理でのコミット確定後に，メッセージを入力キュー（ITQ）に登録します。

入力キューに登録されたメッセージは処理スレッドによって引き出されます。

処理スレッドがトランザクションを開始して，UAPにメッセージを引き渡します。

(b)　トランザクション非同期の場合

ユニキャストまたはマルチキャストによる送信

トランザクション非同期の一方送信メッセージの送信で，ユニキャストまたはマルチキャストによる送信の流れを次の図に示します。

図2-7　ユニキャストまたはマルチキャストによる送信の流れ（トランザクション非同期）

説明

クライアントUAPから，ユニキャストまたはマルチキャストによる一方送信メッセージの送信要求を行います。

TP1/EEは，出力キューが閉塞状態でなければメッセージをUDP用送信バッファに格納し，UAPにリターンします。

UAPリターン後，TP1/EEは同期点処理でのコミット確定後にメッセージを出力キューに登録し，その際に通番を採番します。

送信スレッドに対して，メッセージ送信指示を行います。

送信スレッドは，未送信のメッセージを読み出し，指定された送信先にメッセージを送信します。

送達確認メッセージを受信すると，出力キューからメッセージを削除します。読み出していないメッセージがある場合，メッセージ読み出し要求を行います。

自プロセスあての送信

トランザクション非同期の場合，自プロセスあての送信の流れは，基本的には「ユニキャストまたはマルチキャストによる送信」と同様です。

ただし，自プロセスあての送信であるため，送信スレッドからのメッセージの送信先は，「(1)(a)　トランザクション同期の場合」の「自プロセスあての送信」と同様，自プロセスのUAPとなります。

(2)　一方送信メッセージの一括送信

同一出力キュー（OTQ）上にある他プロセスあてのトランザクション非同期の一方送信メッセージを，最大1024件を一括で送信できます。一括で送信できるメッセージの数は，高速メッセージ送信関連定義のmch_send_lump_countオペランドで指定します。

一括送信できるのは，属性が同じメッセージだけです。次の属性ごとにまとめて一括送信します。

メッセージ送信先で登録された処理キューの中で優先的に起動するかどうか
（ee_mch_cmtsend関数のpriority引数にEEMCH_HIまたはEEMCH_LOWを指定しているか）

通信方式がユニキャストかマルチキャストか
（ee_mch_cmtsend関数のflags引数にEENOFLAGSまたはEEMCH_MULTI_CLを指定しているか）

メッセージが永続か非永続か
（ee_mch_cmtsend関数のflags引数にEEMCH_PERMANENCEを指定しているか）

なお，異なる属性のメッセージが出現した場合は，それまでにまとめたメッセージだけで一括送信します。

メッセージの一括送信は，出力キュー（OTQ）ごとの一方送信メッセージ数が多く，属性が同じ場合に活用できます。

(a)　一方送信メッセージを一括送信するときの流れ

一方送信メッセージを一括送信するときの流れについて説明します。ここでは，クライアントUAPからサーバへ非同期の一方送信メッセージを一括送信するときの流れを例に示します。この例では，高速メッセージ送信関連定義のmch_send_lump_countオペランドの指定値は16です。

図2-8　一方送信メッセージを一括送信するときの流れ

説明

同一出力キュー（OTQ）に登録されている未送信メッセージを，16件読み出してまとめます。未送信メッセージが16件よりも少ない場合は，すべての未送信メッセージをまとめます。

指定された送信先に，まとめたメッセージを一括送信します。

送達確認メッセージを受信すると，出力キューからメッセージを削除します。読み出していないメッセージがある場合，メッセージ読み出し要求を行います。

(b)　一括送信時の注意事項

一方送信メッセージを一括で送信する場合，クライアント側とサーバ側のXTCのバージョンが一致している必要があります。

注意

製品バージョンの変更は，すべてのシステムを停止してから実施してください。バージョンが01-02以降のクライアントが稼働中に送信先のバージョンを変更する場合，次のことに注意してください。

送信先のバージョンを01-01以前から01-02以降に変更する場合

メッセージを一括送信できるようになります。サービスグループレベルの出力キュー（OTQ）閉塞中に変更することをお勧めします。

送信先のバージョンを01-02以降から01-01以前に変更する場合

一方送信メッセージの欠落が発生するおそれがあるため変更しないでください。

2.2.5　一方送信メッセージの受信

ここでは，クライアント側から一方送信メッセージを受信するときの流れを説明します。

図2-9　一方送信メッセージの受信の流れ

説明

一方送信メッセージを受信すると，送達確認用の処理キューを登録します。処理キューはサービスごとにシリアライズされます。

送信スレッドで処理キューが引き出され，クライアントからの一方送信メッセージを入力キュー（ITQ）に登録し，送達確認メッセージを送信します。
一括送信されたメッセージを受信した場合は，処理キューが引き出されてメッセージを入力キュー（ITQ）に登録する処理が，受信したメッセージの数だけ繰り返されます。

処理キューに登録したサービスは，処理スレッドによって引き出され，トランザクションを開始してUAPにメッセージを引き渡します。

2.2.6　出力キューによるメッセージ管理

UAPから一方送信メッセージの送信要求があったときに，指定されたサービスごとに出力キュー（OTQ）の閉塞状態の管理ができるよう，出力キューは送信先サービスグループのサービス単位に管理されます。

なお，出力キューはメモリ上で管理されるため，サーバダウンによる再開始時は閉塞状態を引き継げません。ただし，CLサーバについては，出力キューの閉塞状態を実行系から待機系に転送することで，閉塞状態を保証（永続化）します。出力キューの閉塞状態の永続化については，「7.6.4　トランザクションと非同期に転送されるリソースの永続化」を参照してください。

＜この項の構成＞

(1)　出力キューの定義

(2)　出力キューの閉塞

(3)　出力キューの閉塞状態の監視と閉塞解除

(4)　XTC終了処理の待ち合わせ

(1)　出力キューの定義

出力キューは，送信元となるXTCの送信先サービス関連定義のeemchsrvdef定義コマンドで定義します。送信先となるXTCのサービスグループごとに，サービスグループ名とサービス名を定義します。

(2)　出力キューの閉塞

出力キューが閉塞すると，次のような状態になります。

UAPからの一方送信メッセージの送信要求が受け付けられない

出力キュー上の一方送信メッセージを送信しない

出力キューが閉塞する要因を次に示します。

オンライン開始時に出力キューを自動閉塞するように定義されている場合

APIまたはコマンドによる指示があった場合

自動閉塞の対象となる障害が発生した場合
自動閉塞の対象となる障害を次の表に示します。

表2-2　出力キューの自動閉塞の対象となる障害

項番 | 自動閉塞の対象となる障害 | システムの処理
1 | 一方送信メッセージの送信障害※ | 送信先サービスグループ下の全サービスに対応する出力キューを閉塞（サービスグループレベルの自動閉塞）
2 | 一方送信メッセージの送信障害（パケットサイズの不正）
3 | 一方送信メッセージの送達確認待ちタイムアウト※
4 | 送達確認エラーメッセージ受信（CL同期エラー）※
5 | 送達確認エラーメッセージ受信（送信先サービスグループ名の不正）
6 | 送達確認エラーメッセージ受信（送信先サービスの閉塞）※ | 送信先サービスに対応する出力キューを閉塞（サービスレベルの自動閉塞）
7 | 送達確認エラーメッセージ受信（送信先サービス名の不正，メッセージ送信形態・オプションの不正）

注※

自動閉塞するのは，送信先サービス関連定義のeemchsrvdef定義コマンドで出力キューの自動閉塞を定義した場合だけです。

一方送信メッセージの送信障害時の出力キューの自動閉塞を次の図に示します。

図2-10　一方送信メッセージの送信障害時の出力キューの自動閉塞

説明

一方送信メッセージの送信障害が発生すると，出力キューを自動閉塞します。その後，出力キューの閉塞を示すメッセージを出力して，エラートランザクションを起動します。

(3)　出力キューの閉塞状態の監視と閉塞解除

XTCは，出力キューの閉塞状態を監視します。監視時間の間隔は，高速メッセージ送信関連定義のmch_send_otqwatch_time_intervalオペランドで定義します。

また，出力キューの閉塞解除は，APIまたはコマンドによる指示があったときにだけ行います。

出力キューの閉塞監視と閉塞解除の流れを次の図に示します。

図2-11　出力キューの閉塞監視と閉塞解除の流れ

説明

メッセージ送信障害発生時，サービスグループ下の全サービスに対応する出力キューを自動閉塞し，送信先サービスグループの状態監視を依頼します。

監視スレッドでは，送信先サービスグループに対して一定間隔で受付確認要求メッセージを送信します。

受付確認要求メッセージを受信した受信側は，一方送信メッセージを受信できるかどうか判断し，受信可能であれば，受付確認応答（受付可）メッセージを送信します。受信できない場合は，受付確認応答（受付不可）メッセージを送信します。

受付確認応答（受付可）メッセージを受信した送信側は，イベント通知トランザクション起動要求を行い，UAPに通信できることを通知します。受付確認応答（受付不可）メッセージを受信した場合は，2.に戻って処理を継続します。なお，イベント通知トランザクションは，一度起動すると，新たにサービスグループレベルの自動閉塞が発生しないかぎり起動しません。

出力キュー閉塞解除要求時，閉塞解除対象の送信先サービスグループに対し，受付確認要求メッセージを送信します。

受付確認要求メッセージを受信した受信側は，一方送信メッセージが受信できるかどうかを判断し，受付確認応答（受付可）メッセージまたは受付確認応答（受付不可）メッセージを送信します。

受付確認応答（受付可）メッセージを受信した場合は，出力キューの閉塞を解除します。出力キューの閉塞解除によって，出力キュー上の一方送信メッセージの送信を再開します。

(4)　XTC終了処理の待ち合わせ

XTCの終了処理時，出力キューに未送信メッセージが残っている間は，終了処理の待ち合わせを行います。終了処理の待ち合わせを行うのは，XTCの終了形態が正常終了または計画停止Aの場合です。計画停止B，強制終了，またはプロセスダウンの場合，待ち合わせは行いません。

待ち合わせ方法は次の3とおりです。

出力キューの閉塞状態に関係なく，未送信メッセージがある間はXTCを終了しません。

出力キューが閉塞している場合を除いて，未送信メッセージがある間はXTCを終了しません。

mch_send_end_otqwatch_timeオペランドで指定した時間が経過するまで，XTCを終了しません。指定時間が経過すると，未送信メッセージが残っていてもXTCを終了します。

待ち合わせ中であっても，eemchotqendコマンドを入力することでXTCを終了できます。

なお，待ち合わせ方法は高速メッセージ送信関連定義のmch_send_end_otqwatchオペランドで指定します。

2.2.7　送達確認待ちの時間監視

高速メッセージ送信制御では，クライアント側から一方送信メッセージを送信してからサーバ側で送達確認メッセージを受信するまでの時間（送達確認待ちの時間）を監視できます。送達確認待ちの時間を過ぎても応答がない場合は，定義に従ってメッセージを再送します。送達確認待ちの時間や再送のリトライ回数などは，高速メッセージ送信関連定義で指定します。

なお，メッセージを分割する場合は，最終パケットを送信してから監視を開始します。パケットレベルでの時間監視については，「2.4.1　UDPプロトコルを使用した通信」を参照してください。

2.2.8　障害処理

ここでは，高速メッセージ送信制御での主な障害発生時の流れと，障害発生時のシステムの処理について説明します。

＜この項の構成＞

(1)　障害発生時の処理の流れ

(2)　一方送信メッセージでの障害要因とシステムの処理

(3)　一方送信メッセージの送信に失敗したとき，または送信前にロールバック決着となったときに参照できる情報

(4)　トランザクション非同期の一方送信メッセージ送信障害後の再送

(5)　注意事項

(1)　障害発生時の処理の流れ

高速メッセージ送信制御では，主に次のような障害の発生が考えられます。

メッセージ送信処理の障害

メッセージ送信先サーバのリソース不足による障害

メッセージ送信先のサービス閉塞による障害

メッセージ送信先のサービスグループ名またはサービス名の不正による障害

(a)　メッセージ送信処理の障害

メッセージ送信処理での障害時の流れを次の図に示します。

図2-12　メッセージ送信処理での障害時の流れ

説明

メッセージ送信時の障害を検知すると，高速メッセージ送信関連定義に従ってメッセージを再送します。

リトライ回数が定義値を超えた場合は，エラーメッセージを出力し，エラートランザクションを起動します。

(b)　メッセージ送信先サーバのリソース不足による障害

メッセージ送信先サーバのリソース不足による障害時の流れを次に示します。

サーバ側で，メッセージ受信時に処理キュー制御用バッファ（PCE）が不足している場合，送達確認エラーメッセージ（リソース不足）を応答し，受信メッセージを破棄します。

クライアント側で送達確認エラーメッセージ（リソース不足）を受信すると，高速メッセージ送信関連定義に従ってメッセージを再送します。

リトライ回数が定義値を超えた場合は，エラーメッセージを出力し，エラートランザクションを起動します。

(c)　メッセージ送信先のサービス閉塞による障害

メッセージ送信先のサービス閉塞による障害時の流れを次に示します。

サーバ側で，メッセージ受信時に該当するサービスが閉塞中の場合，送達確認エラーメッセージ（サービス閉塞中）を応答し，受信メッセージを破棄します。

クライアント側で送達確認エラーメッセージ（サービス閉塞中）を受信すると，エラーメッセージを出力し，エラートランザクションを起動します（再送はしません）。

(d)　メッセージ送信先のサービスグループ名またはサービス名の不正による障害

メッセージ送信先のサービスグループ名またはサービス名の不正による障害時の流れを次に示します。

サーバ側で，メッセージ受信時に受信メッセージ中のサービスグループ名またはサービス名が不正だった場合，送達確認エラーメッセージ（サービスグループ名不正またはサービス名不正）を応答し，受信メッセージを破棄します。

クライアント側で，送達確認エラーメッセージ（サービスグループ名不正またはサービス名不正）を受信すると，エラーメッセージを出力し，エラートランザクションを起動します（再送はしません）。

(2)　一方送信メッセージでの障害要因とシステムの処理

一方送信メッセージの送信で発生する障害の要因と，システムの処理を次の表に示します。

表2-3　一方送信メッセージでの障害要因とシステムの処理

項番
障害要因
システムの処理

1
送信前に起きた，XDBの障害などによるロールバック決着
ロールバック決着でERRTRNRを起動

2
送信障害（パケットサイズの不正などの，RPC関連定義の不正）

ERRTRNSを起動

サービスグループレベルの出力キューの自動閉塞

ほかの未送信メッセージの送信処理を継続※1

3
送信障害※2

送信エラーとなったメッセージの送信リトライ実施※3

送信リトライ失敗時，ERRTRNSを起動

サービスグループレベルの出力キューの自動閉塞※4

ほかの未送信メッセージの送信処理を継続※1

4
送達確認待ちタイムアウト※2

5
送達確認エラーメッセージ受信（CL同期エラー）

6
送達確認エラーメッセージ受信（リソース不足（PCE，IBF））

送信エラーとなったメッセージの送信リトライ実施※3

送信リトライ失敗時，ERRTRNSを起動

ほかの未送信メッセージの送信処理を継続※1

7

送達確認エラーメッセージ受信（送信先サービスの閉塞）

自プロセスあてのサービス閉塞

ERRTRNSを起動

サービスレベルの出力キューの自動閉塞※4

ほかの未送信メッセージの送信処理を継続※1

8
送達確認エラーメッセージ受信（送信先サービスグループ名の不正）

ERRTRNSを起動

サービスグループレベルの出力キューの自動閉塞

ほかの未送信メッセージの送信処理を継続※1

9
送達確認エラーメッセージ受信（送信先サービス名の不正）

ERRTRNSを起動

サービスレベルの出力キューの自動閉塞

ほかの未送信メッセージの送信処理を継続※1

10
送達確認エラーメッセージ受信（メッセージ送信形態，オプションの不正）

（凡例）

PCE：処理キュー制御用バッファ

IBF：受信バッファ

注※1

トランザクション同期の一方送信メッセージの場合の動作です。トランザクション非同期の場合は該当しません。

注※2

メッセージが送信先に届いている場合があるため，UAPで送達確認を行う必要があります。

注※3

高速メッセージ送信関連定義で，送信リトライ回数および送信リトライ間隔を指定している場合にだけ実施します。

注※4

送信先サービス関連定義のeemchsrvdef定義コマンドで，出力キューの自動閉塞を指定している場合にだけ実施します。

(3)　一方送信メッセージの送信に失敗したとき，または送信前にロールバック決着となったときに参照できる情報

一方送信メッセージの送信に失敗したとき，または送信前にロールバック決着となったときに参照できる情報を次の表に示します。

表2-4　一方送信メッセージの送信に失敗したとき，または送信前にロールバック決着となったときに参照できる情報

項番
発生した障害
参照するエラートランザクション
参照できる情報

1
トランザクション同期の一方送信メッセージの送信失敗
ERRTRNS

送信先サービスグループ名

送信先サービス名

送信エラー要因（障害要因）

出力キューの自動閉塞の有無

送信メッセージ

2
ERRTRNR

入力メッセージ

送信先サービスグループ名※1

送信先サービス名※1

送信エラー要因（障害要因）※1

出力キューの自動閉塞の有無※1

送信メッセージ※1

3
トランザクション非同期の一方送信メッセージの送信失敗
ERRTRNS

送信先サービスグループ名

送信先サービス名

送信エラー要因（障害要因）

出力キューの自動閉塞の有無

出力キュー通番

送信メッセージ※2

4
メッセージ送信前のXDB障害などによるロールバック決着
項番2と同様です。

注※1

ee_mch_cmtsend_get関数によって一方送信メッセージ情報を取得することで，同一トランザクション内で一方送信メッセージ送信要求を行ったメッセージ情報を参照できます。

注※2

一括送信したメッセージの場合，参照できるのは送信に失敗した先頭メッセージだけです。

(4)　トランザクション非同期の一方送信メッセージ送信障害後の再送

トランザクション非同期の一方送信メッセージの送信で障害が発生すると，メッセージの送信を中断して，出力キューで未送信メッセージとして管理します。

未送信メッセージを再送するタイミングは，次のとおりです。

■出力キューが閉塞した場合

出力キューの閉塞解除後に再送します。

■出力キューが閉塞していない場合

高速メッセージ送信関連定義のmch_send_otqschedule_intervalオペランドで指定した間隔で送信を待ち合わせ，その後，再送します。障害要因が送信先サービス閉塞のときはサービス単位で，その他の障害要因のときはサービスグループ単位での待ち合わせとなります。待ち合わせ中に新たな送信要求があっても送信しません。

また，出力キュー閉塞解除要求を行った場合にも再送します。

なお，一括送信したメッセージが未送信メッセージとして管理された場合は，1メッセージずつ再送します。

(5)　注意事項

サーバ側では，一方送信メッセージの受信時に同一メッセージを受信しても同一トランザクションを起動しないように，メッセージをチェックします。ただし，次の場合についてはチェックの対象外となります。

HAサーバがダウンして再起動した場合

クライアントが永続指定でない一方送信メッセージを送信している間に，CLサーバ（実行系）がダウンして系切り替えが発生した場合

2.3　XTCのRPC通信

ここでは，XTCのRPC通信について説明します。

＜この節の構成＞

2.3.1　UDPプロトコルを使用したRPC通信

2.3.2　通信方式

2.3.3　TCPプロトコルを使用したRPC通信との差異

2.3.4　UDPプロトコルを使用したRPC通信で使用できるAPI

2.3.5　注意事項

2.3.1　UDPプロトコルを使用したRPC通信

OpenTP1の通常のRPC通信では，クライアントとサーバの間の通信を，TCPプロトコルを使用したコネクション経由で行います。XTCでは，UDPプロトコルを使用したRPC通信ができます。UDPプロトコルを使用したRPC通信を行うと，クライアントとサーバの間をコネクションレスで通信できます。

＜この項の構成＞

(1)　UDPプロトコルを使用したRPC通信を行うための条件

(2)　定義との関連

(1)　UDPプロトコルを使用したRPC通信を行うための条件

UDPプロトコルを使用したRPC通信を行う場合は，ee_rpc_call関数のflags引数にEERPC_UDPを指定します。

また，クライアントおよびサーバがTP1/EE（07-60以降）であり，かつTP1/EEサービス定義のプロセス関連定義のxtc_useオペランドにYを指定していなければなりません。

(2)　定義との関連

UDPプロトコルを使用したRPC通信（サービスグループ情報関連定義のeesvgdef定義コマンド）とUDP通信機能（UDPグループ情報関連定義のeeudpdef定義コマンド）との関係を次の表に示します。

表2-5　RPC通信（サービスグループ情報関連定義）とUDP通信機能（UDPグループ情報関連定義）との関係

サービスグループ情報関連定義
UDPグループ情報関連定義
内容

eesvgdef
-g サービスグループ名
-u あて先UDPグループ名
-t UDP

eeudpdef
-g あて先UDPグループ名
-a ホスト名
-p ポート番号[,ポート番号]…
-c UC | MC

サービス要求先のあて先UDPグループを指定します。
サービス要求先ごとに定義する必要があります。

なお，eesvgdef定義コマンドの-tオプションにUDPを指定した通信と，-tオプションにRPCを指定した通信を同時に行う場合，それぞれのeesvgdef定義コマンドには同じサービスグループ名を指定できます。

同期応答型RPCで通信する場合を例に，APIおよび定義の関連を次の図に示します。

図2-13　同期応答型RPCで通信する場合のAPIおよび定義の関連

2.3.2　通信方式

UDPプロトコルを使用したRPC通信では，ユニキャストおよびマルチキャストによる通信ができます。

RPCサービス要求メッセージは，クライアントからサーバに対して，マルチキャスト，またはユニキャストで送信します。一方，RPCサービス応答メッセージは，サーバからクライアントに対してユニキャストで送信します。

サービス要求先の構成によって，サービスが実行できる通信方式が異なります。RPCサービス要求メッセージの通信方式は，UDPグループ情報関連定義のeeudpdef定義コマンドの-cオプションで指定します。通信方式とサービスの実行可否の組み合わせを次の表に示します。

表2-6　通信方式とサービスの実行可否

項番 | 通信方式 | サービス要求先 | 実行系／待機系 | サービスの実行 | 備考
1 | ユニキャスト | HAサーバ | － | できる | －
2 | CLサーバ | 実行系 | できる | －
3 | 待機系 | できない | サービス要求先でメッセージを破棄します。
4 | マルチキャスト | HAサーバ | － | できる | －
5 | CLサーバ | 実行系 | できる | －
6 | 待機系 | できない※ | サービス要求先でメッセージを破棄します。

（凡例）

－：該当しません。

注※

実行系のサーバでサービスが実行されます。

＜この項の構成＞

(1)　ユニキャストでの通信

(2)　マルチキャストでの通信

(1)　ユニキャストでの通信

サーバに対して，ユニキャストで直接RPC要求メッセージを送信します。RPC要求メッセージを受信したサーバは，サービスを実行します。

RPC要求メッセージを受信したサーバがCLサーバ（待機系）の場合は，受信したメッセージを破棄します。

同期応答型RPCによってユニキャストでサービスを要求する場合の処理の流れを次の図に示します。

図2-14　同期応答型RPCによってユニキャストでサービスを要求する場合の処理の流れ

説明

クライアントUAPによってee_rpc_call関数が呼び出されます。

要求メッセージは，ユニキャストでサーバに送信されます。

サーバで受信した要求メッセージは，処理キューに登録されます。処理キューは，処理スレッドによって引き出されます。

UAPによって応答メッセージが作成され，処理スレッドにリターンします。

処理スレッドは，応答メッセージをユニキャストでクライアントに送信します。

受信スレッドで受信した応答メッセージは，処理スレッドのee_rpc_call関数に引き渡されます。

(2)　マルチキャストでの通信

複数のサーバに対してマルチキャストでRPC要求メッセージを送信します。

RPC要求メッセージを受信したサーバが実行系の場合は，サービスを実行します。一方，待機系がRPC要求メッセージを受信した場合は，メッセージを破棄します。

同期応答型RPCによってマルチキャストでサービスを要求する場合の処理の流れを次の図に示します。

図2-15　同期応答型RPCによってマルチキャストでサービスを要求する場合の処理の流れ

説明

クライアントUAPによってee_rpc_call関数が呼び出されます。

要求メッセージは，マルチキャストでCLサーバに送信されます。このとき，待機系のCLサーバでは，受信したメッセージを破棄します。

サーバで受信した要求メッセージは，処理キューに登録されます。処理キューは，サーバの処理スレッドによって引き出されます。

UAPによって応答メッセージが作成され，処理スレッドにリターンします。

処理スレッドは，応答メッセージをユニキャストでクライアントに送信します。

受信スレッドで受信した応答メッセージは，処理スレッドのee_rpc_call関数に引き渡されます。

2.3.3　TCPプロトコルを使用したRPC通信との差異

TCPプロトコルを使用したRPC通信と比較して，UDPプロトコルを使用したRPC通信では，次に示す差異があります。

＜この項の構成＞

(1)　RPC通信機能の差異

(2)　使用するリソースの差異

(1)　RPC通信機能の差異

UDPプロトコルを使用したRPC通信を行う場合は，次に示す機能を使用できません。

表2-7　UDPプロトコルを使用したRPC通信を行う場合のRPC通信機能の差異

項番
差異
影響するシステム

1
トランザクショナルRPCは使用できません。
ee_rpc_call関数のflags引数にEERPC_UDPを指定し，かつ論理和でEERPC_TPNOTRANを指定しなかった場合，ee_rpc_call関数はEERPCER_PARAM_FLAGSでエラーになります。
クライアント側

2
RPC応答のトランザクションまたがり送信機能は使用できません。
使用した場合，ee_rpc_reply_suspend関数がEERPCER_PROTOでエラーになります。ただし，通常のRPC通信で起動されたサービス上でRPC応答メッセージの送信を抑止（ee_rpc_reply_suspend関数を発行）し，この機能によって起動されたサービス上で抑止解除（ee_rpc_reply_send関数を発行）することはできます。
サーバ側

3
ERRTRNRによるRPC応答メッセージ送信機能は使用できません。
ERRTRNRによるRPC応答メッセージ送信機能を使用し（rpc_reply_errtrnrオペランドにYを指定），かつ起動されたサービスからERRTRNRが起動されたとしても，RPC応答メッセージはトランザクション決着時に送信されます。
サーバ側

4
サービス要求先の決定方法として，ネームサービスからの検索は使用できません。
ee_rpc_call関数のflags引数にEERPC_UDPを指定した場合，RPC関連定義のrpc_destination_modeオペランドの設定値は無視され，eesvgdef定義コマンド指定値だけがサービス要求先になります。
クライアント側

5
次に示すノード間負荷バランス機能は使用できません。

サービス要求時のノード間負荷バランス機能（クライアント側）

サービス要求受付時のノード間負荷バランス機能（サーバ側）
rpc_loadbalanceオペランドの指定値は無視されます。

他サービスグループあてのサービス要求受付時の転送（サーバ側）
rpc_transfer_othersvgオペランドの指定値は無視されます。

クライアント側およびサーバ側

(2)　使用するリソースの差異

UDPプロトコルを使用したRPC通信を行う場合は，TCPプロトコルを使用したRPC通信と比較して，使用するリソースに，次に示す差異があります。次に示すリソース以外については，TCPプロトコルを使用したRPC通信を行う場合と共有します。

表2-8　UDPプロトコルを使用したRPC通信を行う場合の使用するリソースの差異

項番 | リソース | 差異
1 | ファイルディスクリプタ | UDP通信機能のファイルディスクリプタを使用するため，RPC通信用としてファイルディスクリプタを使用しません。
2 | ポート | UDP通信機能のポートを使用するため，RPC通信用のポートを使用しません。
3 | ソケット送受信バッファサイズ | UDP通信機能の定義で指定したUDPソケット送受信バッファサイズになります。
4 | フラグメントメッセージ用バッファ | UDP通信機能のリソースを使用するため，RPC通信用としてフラグメントメッセージ用バッファを使用しません。

2.3.4　UDPプロトコルを使用したRPC通信で使用できるAPI

UDPプロトコルを使用したRPC通信で使用できるAPIを次の表に示します。

表2-9　UDPプロトコルを使用したRPC通信で使用できるAPI

項番 | API | 内容 | 使用可否
1 | ee_rpc_call | 遠隔サービスの要求 | ○※
2 | ee_rpc_cmtsend | トランザクションと同期して送信する非応答型RPC要求 | ×
3 | ee_rpc_poll_any_replies | 非同期応答型RPCの応答受信 | ○
4 | ee_rpc_discard_further_replies | すべての非同期応答型RPCの応答受信拒否 | ○
5 | ee_rpc_discard_specific_reply | 特定の非同期応答型RPCの応答受信拒否 | ○
6 | ee_rpc_get_error_descriptor | エラーが発生した非同期応答型RPCの識別子取得 | ○
7 | ee_rpc_set_watch_time | サービスの同期応答型RPCの応答待ち時間の更新 | ○
8 | ee_rpc_get_watch_time | サービスの同期応答型RPCの応答待ち時間の参照 | ○
9 | ee_rpc_reply_suspend | RPC応答メッセージ送信の抑止 | UDPプロトコルを使用する場合は，抑止できません（APIエラーとなります）。
10 | ee_rpc_reply_send | 抑止していたRPC応答メッセージの送信 | ×

（凡例）

○：使用できます。

×：使用できません。

注※

この機能を使用する場合，ee_rpc_call関数のflags引数にEERPC_UDPを指定します。

2.3.5　注意事項

UDP通信機能の仕様上，ee_rpc_call関数がEERPCER_NET_DOWNエラーとなった場合でも，サーバ側でサービスが実行されている可能性があります。問題がある場合は，UAPでサービス実行の有無を確認してください。

2.4　UDP通信機能

ここでは，UDP通信機能について説明します。

UDP通信機能を使用する通信は，次に示すとおりです。UDP通信機能の設定を変更する場合は，次に示した通信との整合性が保たれているかどうか確認してください。

トランザクション同期の一方送信要求（ee_mch_cmtsend_sync関数）またはトランザクション非同期の一方送信要求（ee_mch_cmtsend関数）によって通信する場合

同一のクラスタグループ内で，サーバ間通信する場合

UDPプロトコルを使用したRPC通信を行う場合

＜この節の構成＞

2.4.1　UDPプロトコルを使用した通信

2.4.2　輻輳制御

2.4.3　複数メッセージの一括送受信機能

2.4.4　W-send機能

2.4.5　UDP通信機能で使用するリソース

2.4.6　ポート構成

2.4.7　UDP通信機能で使用するタイマ

2.4.8　負荷分散機能

2.4.1　UDPプロトコルを使用した通信

UDP通信機能を使用すると，UDPプロトコルを使用した高速通信ができます。

UDPプロトコルを使用した通信では，メッセージをパケット単位で管理し，1パケットを1UDPデータグラムとして送受信します。パケットのサイズは，RPC関連定義のrpc_udp_packet_sizeオペランドで指定できます。

メッセージがrpc_udp_packet_sizeオペランドに指定したパケットサイズを超えている場合は，メッセージを複数のパケットに分割して送信します。受信側は，パケットを受信すると，分割された複数のパケットを元のメッセージに組み立てます。

UDPプロトコルを使用した通信では，パケット（分割されたメッセージ）の送信に対して，肯定応答（ACK），否定応答（NACK），およびタイマ監視を行います。これによって，回線障害，回線ビジーなどでメッセージがロストした場合でも，再送制御によってメッセージを保証します。

送信側は，最後のパケットを送信したあと，再送タイマを設定します。再送制御は，ここで設定した再送タイマを使用して行います。再送タイマは，UDPグループ情報関連定義のeeudpdef，clgrpdef，またはmyudpsnddef定義コマンドの-wオプション（輻輳制御時は，-Wオプション）によって指定します。

通信処理の流れを次に示すケースに分けて説明します。

正常ケース

正常ケース（受信側パケットロスでの再送発生）

正常ケース（再送タイマでの再送発生）

正常ケース（UDP用受信バッファ（UIBF）の不足）

異常ケース（タイムアウト上限超過）

＜この項の構成＞

(1)　正常ケース

(2)　正常ケース（受信側パケットロスでの再送発生）

(3)　正常ケース（再送タイマでの再送発生）

(4)　正常ケース（UDP用受信バッファ（UIBF）の不足）

(5)　異常ケース（タイムアウト上限超過）

(1)　正常ケース

正常ケースでの通信の流れを次の図に示します。

図2-16　正常ケースでの通信の流れ

説明

送信側は，パケットを送信したあと，再送タイマを設定します。

受信側は，すべてのパケットを受信したあとに肯定応答を返信します。

送信側は，肯定応答の受信によってメッセージの送達確認を行います。

(2)　正常ケース（受信側パケットロスでの再送発生）

正常ケース（受信側パケットロスでの再送発生）での通信の流れを次の図に示します。

図2-17　正常ケース（受信側パケットロスでの再送発生）での通信の流れ

説明

送信側は，パケットを送信したあと，再送タイマを設定します。

受信側は，パケットのロストを検出した場合，否定応答を返信します。

送信側は，否定応答で指示されたパケットを再送します。

受信側は，送信側からの再送によってすべてのパケットを受信したあと，肯定応答を返信します。

送信側は，肯定応答の受信によってメッセージの送達確認を行います。

(3)　正常ケース（再送タイマでの再送発生）

正常ケース（再送タイマでの再送発生）での通信の流れを次の図に示します。

図2-18　正常ケース（再送タイマでの再送発生）での通信の流れ

説明

送信側は，パケットを送信したあと，再送タイマを設定します。

最後に送信したパケットがロストした場合（または送信先からの送達確認がロストした場合），送信側は，再送タイマで設定した時間まで待ったあとタイムアウトします。このとき，送信側は，最後に送信したパケットを再送して，再び再送タイマを設定します。

受信側は，パケットのロストを検出した場合，否定応答を返信します。

送信側は，否定応答で指示されたパケットを再送します。

受信側は，送信側からの再送によってすべてのパケットを受信したあと，肯定応答を返信します。

送信側は，肯定応答の受信によってメッセージの送達確認を行います。

(4)　正常ケース（UDP用受信バッファ（UIBF）の不足）

正常ケース（UDP用受信バッファ（UIBF）の不足）での通信の流れを次の図に示します。

図2-19　正常ケース（UDP用受信バッファ（UIBF）の不足）での通信の流れ

説明

送信側は，パケットを送信したあと，再送タイマを設定します。

受信側は，UDP用受信バッファ不足によって受信できなかったパケットがあった場合，否定応答を返信します。

送信側は，否定応答を受信してもすぐには再送しないで，再送タイマのタイムアウト時に否定応答で指示されたパケットを再送します。

受信側は，送信側からの再送によってすべてのパケットを受信したあと，肯定応答を返信します。

送信側は，肯定応答の受信によってメッセージの送達確認を行います。

(5)　異常ケース（タイムアウト上限超過）

異常ケース（タイムアウト上限超過）での通信の流れを次の図に示します。

図2-20　異常ケース（タイムアウト上限超過）での通信の流れ

説明

送信側は，パケットを送信したあと，再送タイマを設定します。

最終パケットがロストした場合，または受信側からの肯定応答，否定応答がロストした場合，再送タイマがタイムアウトします。この場合，最終パケットの再送後，再度，タイマを設定します。

タイムアウト回数がタイムアウト上限に達した場合は送達確認失敗となり，送信エラーになります。

2.4.2　輻輳制御

通信回線上で輻輳が発生した場合は，ネットワーク機器のどれかのバッファがオーバフローを起こすため，受信側のバッファに格納されるはずのUDPパケットが破棄されます。

輻輳が頻繁に起こる場合は，受信側から見ると連続してパケットロスが発生するため，再送要求の回数が増えます。また，送信側がこの再送要求どおりに再送を行うと，ネットワークのトラフィックをさらに増加させるため，輻輳が解消できません。

そのため，XTCでは送信側が輻輳制御を行うことで輻輳を解消します。なお，輻輳制御は，送信元スレッド単位に行われます。

＜この項の構成＞

(1)　輻輳制御の開始と終了

(2)　輻輳制御の方法

(1)　輻輳制御の開始と終了

輻輳制御の開始と終了について説明します。

■輻輳制御の開始

監視対象の範囲内（RPC関連定義のrpc_udp_congestion_packet_countオペランドの指定値）に送信したパケットについて，再送パケットの比率がパケットロス上限（UDPグループ情報関連定義のmyudpsnddef定義コマンドの-Lオプションの指定値）以上になった場合に輻輳制御を開始します。

■輻輳制御の終了

監視対象の範囲内（RPC関連定義のrpc_udp_congestion_packet_countオペランドの指定値）に送信したパケットについて，再送パケットの比率がパケットロス下限（UDPグループ情報関連定義のmyudpsnddef定義コマンドの-lオプションの指定値）以下になった場合に輻輳制御を終了します。

再送パケット比率が0%→100%→0%と遷移し，かつ，パケットロス上限に70，パケットロス下限に30が指定された場合の輻輳状態の遷移例を次の図に示します。

図2-21　輻輳状態の遷移例

(2)　輻輳制御の方法

輻輳を検知した直後に輻輳制御を開始します。輻輳制御を開始した時点で仕掛かり中のメッセージについても輻輳制御によって再送します。輻輳制御では，次に示す方法によって，トラフィックを軽減します。

■肯定応答が未受信で連続送信できるパケット数の縮小

通常状態では，メッセージの最終パケットを送信した時点で再送タイマを設定します。しかし，輻輳状態では，最終パケットだけではなく，中間パケットを送信した時点でも再送タイマを設定します。

肯定応答待ちは，再送パケット比率を基に自動的に決定したパケット数のパケット送信ごとに行うようにします。肯定応答待ちを行うパケット数の最低値はUDPグループ情報関連定義のmyudpsnddef定義コマンドの-Uオプションで指定します。この制御によって，連続送信によるトラフィック増加を回避できます。

■否定応答の受信時の再送契機

通常状態では，否定応答を受信した場合，すぐに再送パケットを送信します。

輻輳状態では，否定応答を受信した場合，再送タイマのタイムアウト時に再送パケットを送信します。

■再送タイマの変更

通常状態の場合，再送タイマのタイマ値には，UDPグループ情報関連定義のeeudpdef，clgrpdef，またはmyudpsnddef定義コマンドの-wオプションの指定値を使用します。

輻輳状態の場合，再送タイマのタイマ値には，eeudpdef，clgrpdef，またはmyudpsnddef定義コマンドの-Wオプション指定値を使用します。ただし，-Wオプションを指定していない場合は，タイマ値を変更しません。

それぞれの定義コマンドに異なる値を指定した場合の優先順位は次のとおりです。

同一のクラスタグループ内で通信する場合
clgrpdef定義コマンドの指定値＞myudpsnddef定義コマンドの指定値

同一のクラスタグループ外と通信する場合
eeudpdef定義コマンドの指定値＞myudpsnddef定義コマンドの指定値

2.4.3　複数メッセージの一括送受信機能

複数のメッセージを結合し，一つの論理メッセージとすることで，論理メッセージ単位での送達確認を行います。これを，複数メッセージの一括送受信機能といいます。複数のメッセージを一括して送受信することで，送達確認の頻度が減るため，通信時間を短縮できます。

通常のメッセージ送受信時の送達確認と，複数メッセージの一括送受信機能を使用した場合の送達確認との比較を次の図に示します。

図2-22　通常のメッセージ送受信時の送達確認

図2-23　複数メッセージの一括送受信機能を使用した場合の送達確認

なお，一つの論理メッセージの最大サイズは，最大で9メガバイトです。メッセージの合計サイズが9メガバイトを超える場合は，複数の論理メッセージになります。一つのメッセージが複数の論理メッセージに分割されることはありません。

この機能は，次のときに使用できます。

一方送信メッセージの送受信時
一方送信メッセージについては，「2.2　高速メッセージ送信制御」を参照してください。

CLサーバでのCL同期メッセージの送受信時
CL同期メッセージについては，「7.7.2　CL同期メッセージの処理の流れ」を参照してください。

＜この項の構成＞

(1)　論理メッセージの送達確認範囲

(2)　単メッセージの送達確認範囲の変更機能

(1)　論理メッセージの送達確認範囲

論理メッセージの送達確認は，一定の範囲ごとに行われます。ここでは，送達確認範囲およびその見積もり方法について説明します。

論理メッセージの送達確認は，送達確認パケット数ごとに行われます。ただし，送達確認後の残りパケット数が，送達確認パケット数の20%未満となる場合は，残りのすべてのパケットに対して送達確認を行います。論理メッセージのパケット数が，送達確認パケット数以下の場合は，すべてのパケットに対して一度の送達確認を行います。

送達確認パケット数は，RPC関連定義のrpc_udp_lmsg_deliverychk_sizeオペランドの指定値（省略時解釈値：512キロバイト）をrpc_udp_packet_sizeオペランドの指定値（省略時解釈値：1472バイト）で除算した値です。

送達確認が完了した時点で，送達確認範囲で完成（最終パケットのパケット送信完了）しているメッセージは，送受信完了となります。輻輳状態となった場合は，送達確認範囲単位に輻輳制御を行います。

送達確認範囲が小さい場合は，送達確認が多発するため，通信遅延の原因となります。一方，送達確認範囲が大きい場合は，パケットロスなどによる通信障害時に，再送による通信量が増加します。そのため，送信側のUDPグループ情報関連定義のmyudpsnddef定義コマンドの-bオプションの指定値と，受信側のmyudprcvdefまたはclgrpdef定義コマンドの-Bオプションの指定値のうち，小さい方の値以下に指定することをお勧めします。

論理メッセージサイズが送達確認サイズを超過している場合の送達確認範囲を次の図に示します。

図2-24　論理メッセージサイズが送達確認サイズを超過している場合

この図では，論理メッセージを構成するパケットを送達確認パケット数で区切った場合に，1パケット（D15）が余ります。しかし，送達確認の最小パケット数は2であるため，D15は送達確認範囲2に含めます。

次に，論理メッセージサイズが送達確認サイズ以下の場合の送達確認範囲を次の図に示します。

図2-25　論理メッセージサイズが送達確認サイズ以下の場合

この図では，論理メッセージが送達確認パケット数以下であるため，一度に送達確認できます。

(2)　単メッセージの送達確認範囲の変更機能

単メッセージとは，一つのメッセージから成る論理メッセージです。

通常，送達確認はパケットの送信後に行われます。しかし，メッセージサイズより送信先のソケット受信バッファサイズが小さい場合，送信先のUDPソケット受信バッファ不足が発生し，パケットロスするおそれがあります。ロストしたパケットは，再送処理によって保証されます。しかし，送信するパケット数が増加するため，通信遅延が発生したり，CPUやネットワークの負荷が増大したりします。そのため，XTCでは，単メッセージの場合の送達確認範囲を変更できます。

送達確認範囲を変更する場合，RPC関連定義のrpc_udp_msg_deliverychk_sizeオペランドの指定値（省略時解釈値：2メガバイト）をRPC関連定義のrpc_udp_packet_sizeオペランドの指定値（省略時解釈値：1472バイト）で除算した値を送達確認パケット数として，送達確認パケット数ごとに送達確認を行います。ただし，送達確認後の残パケット数が，送達確認パケット数の20%未満となる場合は，残りのすべてのパケットに対して送達確認を行います。メッセージのパケット数が，送達確認パケット数以下の場合は，すべてのパケットに対して一度に送達確認を行います。これによって，連続送信するパケット数が減少し，パケットのロスト頻度も減少します。輻輳状態となった場合は，送達確認範囲単位に輻輳制御を行います。

送達確認範囲が小さい場合は，送達確認が多発するため通信遅延の原因となります。一方，送達確認範囲が大きい場合は，パケットロスなどによる通信障害時に，再送による通信量が増加します。そのため，送信元のUDPグループ情報関連定義のmyudpsnddef定義コマンドの-bオプションの指定値，および送信先のmyudprcvdef定義コマンド，またはclgrpdef定義コマンドの-Bオプションの指定値のうち，小さい方の値以下に指定することをお勧めします。

メッセージサイズが送達確認サイズを超過している場合の送達確認範囲を次の図に示します。

図2-26　メッセージサイズが送達確認サイズを超過している場合

この図では，メッセージを構成するパケットを送達確認パケット数で区切った場合に，1パケット（D15）が余ります。しかし，送達確認の最小パケット数は2であるため，D15は送達確認範囲2に含めます。

次に，メッセージサイズが送達確認サイズ以下の場合の送達確認範囲を次の図に示します。

図2-27　メッセージサイズが送達確認サイズ以下の場合

この図では，メッセージが送達確認サイズ以下であるため，一度に送達確認できます。

2.4.4　W-send機能

XTCでは，ネットワーク経路を二重化した構成でhbondingドライバ（HA Network Driver Mirroring Edition for Linux）を適用し，二つの経路から同一のパケットを送受信できます。これをW-send機能といいます。W-send機能を使用するためには，hbondingドライバのバージョンが02-01以降であり，hbondingドライバの動作モードにbroadcastモードを選択する必要があります。

W-send機能を使用した場合のメリットは次のとおりです。

ネットワーク切り替え時間の短縮

UDPパケットロスの補償

W-send機能を使用した場合，受信側では，二つの経路から同一のパケットを重複して受信します。このとき，重複して受信したパケット（重複受信パケット）は，hbondingドライバまたはXTCによって破棄されます。

hbondingドライバで重複受信パケットを破棄する場合は，hbondingドライバの重複受信パケットフィルタリング機能を使用します。XTCで受信パケットを破棄する場合と比較して次のメリットがあるため，hbondingドライバで重複受信パケットを破棄することをお勧めします。

CPU負荷の軽減

UDPソケット受信バッファの使用量の削減

hbondingドライバの重複受信パケットフィルタリング機能を使用しない場合，または重複受信パケットフィルタリング機能で破棄できなかった場合は，XTCによって重複受信パケットが破棄されます。

2.4.5　UDP通信機能で使用するリソース

UDP通信機能で使用するリソースについて説明します。

＜この項の構成＞

(1)　ポート

(2)　UDP用送受信バッファ

(3)　UDPソケット送受信バッファ

(1)　ポート

UDP通信機能で使用するポートは，目的に応じて送信用ポート，または受信用ポートと呼ばれます。

ポートごとに異なるソケット属性を指定する場合（例えば，UDPを使用したRPC通信と高速メッセージ送信制御でポート番号を切り替えたい場合など）は，UDPグループを複数定義して，異なる属性を指定します。

ポート種別による定義の違いを次の表に示します。

表2-10　ポート種別による定義の違い

項番 | ポート種別 | 内容
1 | 送信用ポート | メッセージの送信に使用し，送信UDPグループとして管理します。UDPグループ情報関連定義のmyudpsnddef定義コマンドで定義します。
2 | 受信用ポート | メッセージの受信，ならびに肯定応答および否定応答の送受信に使用し，受信UDPグループとして管理します。UDPグループ情報関連定義のmyudprcvdef定義コマンドまたはclgrpdef定義コマンドで定義します。

(2)　UDP用送受信バッファ

■UDP用送信バッファ

UDP通信機能が使用するUDP用送信バッファのサイズと面数は，メモリ関連定義のudp_send_message_buf_sizeオペランドおよびudp_send_message_buf_cntオペランドで指定します。

■UDP用受信バッファ

UDP通信機能が使用するUDP用受信バッファのサイズと面数は，メモリ関連定義のudp_recv_message_buf_sizeオペランドおよびudp_recv_message_buf_cntオペランドで指定します。

(3)　UDPソケット送受信バッファ

■UDPソケット送信バッファ

送信UDPデータグラムを一時的に格納するOSのバッファです。送信パケットサイズ（RPC関連定義のrpc_udp_packet_sizeオペランド指定値 + 28）以上を指定します。また，次の計算式を満たすサイズに指定することをお勧めします。

UDPソケット送信バッファ ≧ RPC関連定義のrpc_udp_lmsg_deliverychk_sizeオペランド，またはrpc_udp_msg_deliverychk_sizeオペランドの指定値

■UDPソケット受信バッファ

受信UDPデータグラムを一時的に格納するOSのバッファです。受信パケットサイズ（RPC関連定義のrpc_udp_packet_sizeオペランド指定値 + 28）以上を指定します。また，次の計算式を満たすサイズに指定することをお勧めします。

UDPソケット受信バッファ ≧ 送信するユーザデータのサイズ※¹ × 1.1 × 送信元スレッド数※²

注※1

CL同期メッセージの送受信だけで使用するソケットの場合に，ユーザデータのサイズがRPC関連定義のrpc_udp_lmsg_deliverychk_sizeオペランドの指定値以上になるときは，オペランド指定値はユーザデータのサイズになります。

上記以外のメッセージの場合に，ユーザデータのサイズがRPC関連定義のrpc_udp_msg_deliverychk_sizeオペランドの指定値以上になるときは，オペランド指定値はユーザデータのサイズになります。

注※2

UDPソケットに対して，同時送信を行う送信元のスレッド数です。

輻輳によるパケットロスを減らすには，UDPソケット受信バッファを大きく設定する必要があります。各送信元スレッドからのメッセージ一つ分を格納するソケット受信バッファを設定することをお勧めします。

なお，W-send機能を使用している場合にhbondingドライバで重複受信パケットを破棄しないときは，UDPソケット受信バッファを上記の計算式で算出されるサイズの2倍に設定することをお勧めします。

2.4.6　ポート構成

通信相手が同一のクラスタグループ内のサーバであるかどうかによって，ポート構成が異なります。ここでは，同一のクラスタグループ内のサーバと通信する場合，および同一のクラスタグループ外のサーバと通信する場合について，ポート構成例を説明します。

＜この項の構成＞

(1)　同一のクラスタグループ内のサーバと通信する場合の構成

(2)　同一のクラスタグループ外のサーバと通信する場合の構成

(3)　マルチキャストループバック受信（同一のクラスタグループ内での自マシンに対するマルチキャスト送信）有無

(1)　同一のクラスタグループ内のサーバと通信する場合の構成

クラスタグループ内の各サーバには，クラスタグループ定義のclgrpdef定義コマンドを定義する必要があります。クラスタグループ定義では，同一のクラスタグループ内での通信で使用するポート番号，マルチキャストアドレス，送信UDPグループなどを指定します。各サーバのクラスタグループ定義は，次の項目を除いて同じ値を指定します。

送信UDPグループ

LANアダプタのホスト名

同一のクラスタグループ内で通信する場合の定義例を次の図に示します。

図2-28　同一のクラスタグループ内で通信する場合の定義例

説明

送信側プロセスでは，次のように定義します。

UDPグループ情報関連定義のmyudpsnddef定義コマンドに，送信UDPグループAとして扱うポート番号，10001，10002，および10003を指定します。

UDPグループ情報関連定義のclgrpdef定義コマンドの送信UDPグループ名に，送信UDPグループAを指定します。また，受信用ポートのポート番号として10004を指定します。

受信側プロセスでは，次のように定義します。

clgrpdef定義コマンドで受信用のポート番号として10004を指定します。

(2)　同一のクラスタグループ外のサーバと通信する場合の構成

同一のクラスタグループ外のサーバと通信する場合（例えば，HAサーバとCLサーバ間，CLサーバと別のCLサーバ間での通信）は，通信先情報をあて先UDPグループ（受信側プロセスにとっての受信UDPグループ）として，eeudpdef定義コマンドで定義します。

あて先UDPグループを定義する場合，該当するあて先グループへのメッセージ送信に使用する送信UDPグループ，および該当するあて先グループからの送達確認受信で使用する受信UDPグループを定義します。省略した場合は，デフォルトの送信UDPグループ，および受信UDPグループが使用されます。

同一のクラスタグループ外のサーバと通信する場合の定義の組み合わせ例を，次の表および図に示します。

表2-11　同一のクラスタグループ外のサーバと通信する場合の定義の組み合わせ例

組み合わせ | あて先UDPグループ名 | 送信UDPグループ名 | 受信UDPグループ名
1 | あて先UDPグループA | 送信UDPグループA | 受信UDPグループA
2 | あて先UDPグループB | 送信UDPグループA | 受信UDPグループB

図2-29　同一のクラスタグループ外のサーバと通信する場合の定義の組み合わせ例

説明

送信側プロセスでは，次のように定義します。

UDPグループ情報関連定義のmyudpsnddef定義コマンドに，送信UDPグループAとして扱うポート番号10001，10002，および10003を指定します。

UDPグループ情報関連定義のmyudprcvdef定義コマンドを二つ定義し，それぞれの定義に受信UDPグループAとしてポート番号10004，受信UDPグループBとしてポート番号10005，および10006を指定します。

UDPグループ情報関連定義のeeudpdef定義コマンドを二つ定義し，それぞれの定義のあて先UDPグループ名に，あて先UDPグループA，およびあて先UDPグループBを指定します。また，それぞれのあて先UDPグループに対して，送受信に利用する送信UDPグループおよび受信UDPグループを指定します。

受信側プロセスでは，次のように定義します。

eeudpdef定義コマンドで受信用のポート番号として10007および10008を指定します。

(3)　マルチキャストループバック受信（同一のクラスタグループ内での自マシンに対するマルチキャスト送信）有無

マルチキャストループバック受信とは，マルチキャストでメッセージを送信する場合に，自マシンを送信対象とすることで，自マシンから送信したメッセージを自マシンで受信することをいいます。マルチキャストループバック受信を行うかどうかは，UDPグループ情報関連定義のmyudpsnddef定義コマンドで選択できます。

■マルチキャストループバック受信をありに設定する場合

マルチキャストによるサービス要求時に，該当するサービスを処理するXTCが同一マシン上に存在する場合は，ループバック受信をあり（-kオプションを指定）に設定してください。

■マルチキャストループバック受信をなしに設定する場合

CLサーバの場合，ループバック受信をありに設定すると，自マシンから送信したメッセージを自マシンで受信し，破棄するという不要な受信処理が発生します。そのため，ループバック受信をなし（-kオプションを省略）に設定することをお勧めします。

上記の二つの条件が重なった場合，次のどちらかの対策をする必要があります。

ループバック受信ありの送信UDPグループを一つ定義し，サービス要求送信用およびCLサーバ間での通信用の定義として共有する。

ループバック受信ありとループバック受信なしの送信UDPグループを二つ以上定義し，ループバック受信ありはサービス要求送信用，ループバック受信なしはCLサーバ間での通信用というように用途ごとに割り当てる。

2.4.7　UDP通信機能で使用するタイマ

UDP通信機能で使用するタイマを，次の表に示します。

表2-12　UDP通信機能で使用するタイマ

項番 | タイマ種別 | タイマ設定側 | 内容
1 | 再送タイマ | 送信側 | メッセージを構成するすべてのパケットを送信してから送達確認を受信するまでのタイマです。タイムアウト時は再送制御を行います。タイムアウト回数が定義した値を超過した場合はエラーとなります。

2.4.8　負荷分散機能

XTCには，送信用ポート，受信用ポート，および通信回線に対する負荷を分散するための負荷分散機能があります。ここでは，XTCの負荷分散機能について説明します。

＜この項の構成＞

(1)　送信用ポートの共有と占有

(2)　受信用ポート（あて先ポート）の分散

(1)　送信用ポートの共有と占有

送信用ポート数が少ない場合，送信用ポートをスレッド間で共有します。送信用ポートを共有した場合に，スレッド間で送信処理が競合したときは，送信用ポートの空き待ちを行います。そのため，競合するスレッド数が増えるほど，空き待ち時間が長くなります。

一方，送信用ポート数が多い場合は，送信用ポートをスレッドが占有します。この場合，スレッド間での待ち時間は発生しません。

送信用ポートの共有または占有は，次の表に示す規則で決定します。なお，送信UDPグループごとに，このルールが適用されます。そのため，例えば，送信UDPグループAは共有，送信UDPグループBは占有という構成も考えられます。

表2-13　送信用ポートの共有または占有を決定するためのルール

項番 | 条件 | 結果
1 | 送信用ポート数 ≧ メインスレッドを除いたスレッド数 | すべてのスレッドは占有
2 | 送信用ポート数 ＞ 処理スレッド数+送信スレッド数 | 処理スレッド，および送信スレッドは占有，それ以外のスレッドは共有
3 | 項番1および項番2以外の場合 | すべてのスレッドは共有

(2)　受信用ポート（あて先ポート）の分散

受信UDPグループに複数のポート番号を指定した場合，複数のUDP受信スレッドが同時に受信処理を行うことで，負荷分散を行います。

あて先UDPグループにポート番号が複数指定されている場合，送信元プロセスは，あて先ポート番号をランダムに選択します。

2.5　トランザクション制御

ここでは，TP1キャッシュ機能使用時のCLサーバでのトランザクション制御について説明します。

＜この節の構成＞

2.5.1　TP1キャッシュ機能使用時のCLサーバでのトランザクション

2.5.2　関連するAPI

2.5.3　トランザクショナルRPCの抑止（CLサーバ）

2.5.4　RPC応答の送信タイミング変更機能

2.5.1　TP1キャッシュ機能使用時のCLサーバでのトランザクション

TP1キャッシュ機能使用時のCLサーバでのトランザクションは，ルートブランチだけで構成されます。

TP1キャッシュ機能使用時にトランザクション連携できるリソースマネジャは，CLサーバのXDBだけです。TP1キャッシュ機能使用時のXDBの呼び出しタイミングを次の表に示します。

表2-14　TP1キャッシュ機能使用時のXDBの呼び出しタイミング

項番
タイミング
実施内容

1
トランザクション開始時

XTCからXDBに対して，トランザクションIDを通知（中央処理通番）

XDBからXTCに対して，コネクトコンテキストを通知

2
トランザクションコミット時

XTCからXDBに対して，トランザクションIDを通知（中央処理通番）

XDBが更新ログ作成

DB更新

3
更新ログサイズ取得時
XTCからXDBに対し，更新ログサイズを問い合わせ

4
トランザクションロールバック時

XTCからトランザクションIDを通知（中央処理通番）

更新データを更新する前に戻す

5
待機系での更新ログ反映時
XDBが更新ログ反映

また，XDBとのインタフェースにはXAインタフェースを使用しないで，独自のインタフェースによって連携します。HAサーバでは，データベースとしてHiRDBを使用できますが，TP1キャッシュ機能とのトランザクション連携はできません。

TP1キャッシュ機能を使用する場合とTP1キャッシュ機能を使用しない場合でのトランザクション制御の違いを，次の表に示します。

表2-15　TP1キャッシュ機能を使用する場合と使用しない場合でのトランザクション制御の違い

項番 | 項目 | TP1キャッシュ機能を使用しない場合 | TP1キャッシュ機能を使用する場合
HAサーバ | CLサーバ
1 | トランザクション構成 | 複数のトランザクションブランチで構成 | 複数のトランザクションブランチで構成 | ルートトランザクションブランチだけで構成
2 | トランザクショナルRPC | サポート | サポート | 未サポート
3 | 連携リソースマネジャ | HiRDB，Oracle（XAインタフェースに準拠したリソースマネジャ） | HiRDB，Oracle（XAインタフェースに準拠したリソースマネジャ） | XDB（独自のインタフェース）
4 | コミット | 二相コミット | 二相コミット | 一相コミット

2.5.2　関連するAPI

TP1キャッシュ機能使用時に使用できる同期点取得に関連するAPIを，次の表に示します。

表2-16　TP1キャッシュ機能使用時の同期点取得に関連するAPI

項番 | API項目
C言語関数名 | thkindの指定値
1 | ee_trn_chained_rollback | EETRN_PRCS
EETRN_KILL
EETRN_ABRT
EETRN_KEEP
2 | ee_trn_rollback_mark | なし

2.5.3　トランザクショナルRPCの抑止（CLサーバ）

TP1キャッシュ機能使用時，CLサーバでは，トランザクショナルRPCを抑止する必要があります。そのため，CLサーバでは，トランザクション連携定義のtrn_transactional_rpcless_useオペランドにYを指定し，トランザクショナルRPCの抑止を有効にしてください。

2.5.4　RPC応答の送信タイミング変更機能

TP1キャッシュでCL連携による系切り替え機能使用時，コミットと同期して行うRPC応答メッセージの送信処理のタイミングをCL連携の転送処理の結果と同期するための機能です。

TP1キャッシュのCLサーバで，RPC応答と転送処理のタイミングを変更するものです。

この機能の使用有無は，トランザクション関連定義のtrn_cl_rpc_reply_timingオペランドで指定できます。

この機能を使用するときに変更できる処理を次に示します。

送信タイミングの変更

永続化しない（RPC関連定義のrpc_recv_permanenceオペランドにY指定なし）同期応答型RPC/非同期応答型RPCの応答送信を，永続化する（RPC関連定義のrpc_recv_permanenceオペランドにY指定）ときの応答送信と同様に，転送処理によってリソースの永続化が完了したあとに行います。

実行系孤立状態を検知したときの動作の変更

転送失敗によって実行系孤立状態を検知した場合，RPC応答メッセージの送信はロールバックしたときと同様の動作をするように変更します。ただし，ERRTRNRは起動しません。

次の条件をすべて満たした場合，トランザクション結果に加え，転送処理の結果をRPC応答メッセージに反映できます。

rpc_reply_tp1modeオペランドにNを指定

rpc_reply_errtrnrオペランドを省略，またはNを指定

RPC応答メッセージの内容を，次の表に示します。

表2-17　RPC応答メッセージの内容

トランザクション結果
転送処理の結果
RPC応答メッセージ

コミット
正常
RPC正常応答

転送失敗(孤立検知)※
RPCエラー応答
（EERPCER_TRNCHK_EXTEND）

ロールバック
－
RPCエラー応答
（EERPCER_TRNCHK_EXTEND）

注※

系切り替えが発生すると，転送結果が反映されている可能性があります。

＜この項の構成＞

(1)　RPC要求受信時の処理シーケンス

(2)　実行系孤立状態の実行系／待機系のメモリDB

(3)　実行系孤立状態になった場合の対処

(1)　RPC要求受信時の処理シーケンス

(a)　RPC永続化指定なし（RPC関連定義rpc_recv_permanenceにY指定なし）の場合

永続化しないRPC要求メッセージを受信した場合について，次のケースのそれぞれの処理シーケンスを示します。

RPC応答の送信タイミング変更機能を使用するケース（trn_cl_rpc_reply_timing=Y）

機能未使用のケース

図2-30　RPC応答の送信タイミング変更機能使用時（trn_cl_rpc_reply_timing=Y）の処理シーケンス

図2-31　この機能を使用しないときの処理シーケンス

(b)　RPC永続化指定あり（RPC関連定義rpc_recv_permanenceにY指定）の場合

永続化するRPC要求メッセージを受信した場合について，次のケースの処理シーケンスを示します。

RPC応答の送信タイミング変更機能を使用するケース（trn_cl_rpc_reply_timing=Y）

機能未使用のケース

なお，RPC永続指定ありの場合は，各ケースで処理シーケンスに変更はありません。

図2-32　RPC応答の送信タイミング変更機能使用時（trn_cl_rpc_reply_timing=Y）の処理シーケンス，およびこの機能を使用しないときの処理シーケンス

(2)　実行系孤立状態の実行系／待機系のメモリDB

この機能使用時，転送処理失敗により実行系孤立状態を検知した場合には，クライアントからのRPC要求はエラー応答となり，待機系に転送処理が反映されているか不明となります。このため，TP1キャッシュのメモリDBは実行系と待機系で不一致となることがあります。

RPC要求をリトライする場合，2重実行されても問題ないようなUAPを作成する必要があります。

メモリDBの不一致となるケースの例を次に記します。

(a)　すべての待機系が転送失敗となった場合の流れ

図2-33　すべての待機系が転送失敗となった場合の流れ

(b)　1台ずつ転送失敗となった場合の流れ

図2-34　1台ずつ転送失敗となった場合の流れ

(3)　実行系孤立状態になった場合の対処

実行系孤立時のeetrbwtorコマンド待ち

孤立モードBを選択してください。孤立モードAを選択した場合，メモリダンプファイル出力後に受け付け済みサービスが動作するため，実行系孤立後のメモリDB更新の内容はメモリダンプファイルへ出力されません。また，クライアントへのRPC応答は失敗します。

2.6　処理キューの制御

処理キューの制御はTP1/EEによって行われますが，TP1キャッシュ機能使用時は，使用するキューや実現できる機能に一部異なる点があります。ここでは，TP1キャッシュ機能使用時の処理キューの制御方式について説明します。

＜この節の構成＞

2.6.1　TP1キャッシュ機能使用時の処理キューの制御方式

2.6.2　メッセージの同時引き出しの有無

2.6.3　後続メッセージの読み出し

2.6.4　読み出しメッセージの差し戻し

2.6.5　ロールバック時の読み出しメッセージの扱い（ロールバックリトライ）

2.6.6　プロセス終了時の未読み出しメッセージの扱い

2.6.7　サービス先行解放

2.6.8　連鎖モード連携機能

2.6.1　TP1キャッシュ機能使用時の処理キューの制御方式

TP1/EEでは，処理キューの制御に処理キュー制御用バッファ（PCE）および入力バッファ（IBF）を使用します。TP1キャッシュ機能使用時はそれに加え，入力キュー（ITQ）を使用して処理キューを制御します。

TP1キャッシュ機能を使用する場合とTP1キャッシュ機能を使用しない場合での処理キューの制御方式の違いを，次の表に示します。

表2-18　TP1キャッシュ機能を使用する場合と使用しない場合での処理キューの制御方式の違い

項目 | 制御方式の違い
TP1キャッシュ機能を使用しない場合 | TP1キャッシュ機能を使用する場合
メッセージの流れ | メッセージ受信時に入力バッファに格納し，UAP起動時に入力メッセージ引き渡しエリア（IMA）にコピーしてから，入力バッファを解放します。 | メッセージ受信時に入力バッファに格納し，処理キュー登録時にそのまま入力キューに登録します。
処理キュー制御用バッファおよび入力バッファの解放 | トランザクション起動時にすべて解放します。 | トランザクション終了まで保持します。

TP1キャッシュ機能使用時の処理キューの制御方式を，メッセージの受信からUAP起動までの流れを例にして，次の図に示します。

図2-35　処理キューの制御方式

説明

相手システム（送信元）から受信した入力メッセージを，処理キューへ登録要求します。

処理キューに登録された入力メッセージおよび処理キュー制御用バッファ情報を，入力キューに書き込みます。優先キューと通常キューのどちらに書き込むかは送信元の指示に従います。優先キューに書き込まれたメッセージは，優先して処理されます。通常キューに書き込まれたメッセージは，優先キューのメッセージをすべて処理したあとで，処理されます。

入力メッセージの読み出しを処理スレッドで処理させるために，処理スレッドを起動します。

起動した処理スレッドは，該当するサービスから処理キューの引き出し要求をします。

入力メッセージ引き渡しエリアにメッセージをコピーします。

UAPを起動して，メッセージを引き渡します。

2.6.2　メッセージの同時引き出しの有無

メッセージは，該当するサービスに接続されている入力キューの先頭から毎回読み出されることでスケジュールされます。

このとき，入力キューのメッセージを読み出すトランザクションを一つずつ起動する（メッセージの同時引き出しなし）か，複数のトランザクションを起動する（メッセージの同時引き出しあり）かをservice_attr定義コマンドの-eオプションで指定できます。

なお，メッセージの同時引き出しなしを指定した場合に，起動中のトランザクションがあったときは，そのトランザクションが終了してから次のトランザクションを起動します。

メッセージの同時引き出しの有無によって，次に示す差異があります。

表2-19　メッセージの同時引き出しの有無よる差異

項番 | 項目 | メッセージの同時引き出し
なし | あり
1 | メッセージの同時引き出し限界数 | 1 | 1～255※1
2 | メッセージの同時引き出し限界数の変更 | 変更できない | eelspceコマンドで変更できる
3 | 複数メッセージの読み出し | 使用できる※2 | 使用できない
4 | 読み出しメッセージの差し戻し | 使用できる※2 | 使用できない
5 | ロールバック時の読み出しメッセージの扱い | リトライする※3 | 破棄する

注※1

同時引き出し限界数は，TP1/EEサービス定義のユーザサービス関連定義のserviceオペランドで指定します。

注※2

連鎖モード連携機能による再起動トランザクションでは使用できません。連鎖モード連携機能については，「2.6.8　連鎖モード連携機能」を参照してください。

注※3

次に示すメッセージ，およびトランザクションの場合は破棄します。

・応答型RPC

・トランザクショナルRPC

・RAPメッセージ

・エラートランザクション

・MCP後処理トランザクション（RL）

・イベント通知トランザクション（MV）

2.6.3　後続メッセージの読み出し

TP1キャッシュ機能使用時は，トランザクション実行中（UAP処理中）に，該当するサービスに滞留している後続メッセージを読み出せます。後続メッセージを読み出すには，ee_scd_msg_receive関数を発行します。なお，この関数を発行できるのは，ユーザサービス関連定義のserviceオペランドの同時処理限界数に1が指定されたサービスだけです。

同時処理限界数に1を指定した場合は，一つのトランザクションで複数のメッセージを読み出せます。読み出せるメッセージは，トランザクション起動時に入力キューに滞留しているメッセージです。トランザクション実行中に新たに書き込まれたメッセージは，次のトランザクションから読み出せます。

一つのトランザクションで読み出せるのは，優先キューと通常キューのどちらか一方に滞留しているメッセージです。サービストランザクション起動時に読み出したキューと，同じ（優先または通常）キューに滞留しているメッセージを読み出せます。

後続メッセージの読み出し例を次の図に示します。

図2-36　後続メッセージの読み出し例

説明

処理キュー引き出し後のメッセージ読み出しで，入力メッセージ1を読み出し，UAPを起動します。

ee_scd_msg_receive関数によって，入力メッセージ2を読み出します。

ee_scd_msg_receive関数によって，入力メッセージ3を読み出します。

＜この項の構成＞

(1)　読み出しできる後続メッセージの条件

(2)　読み出しできる後続メッセージの上限

(3)　後続メッセージ読み出し時の格納領域の上書き

(4)　コミット決着失敗通知（ERRTRNR）時およびUAP異常終了通知（ERRTRN3）時の動作

(1)　読み出しできる後続メッセージの条件

ee_scd_msg_receive関数で，読み出すメッセージの種別をAPI引数で指定できます。ee_scd_msg_receive発行時に，後続メッセージの読み出し方法を「メッセージ種別を指定しない方式」および「メッセージ種別を指定する方式」から選択できます。

(a)　メッセージ種別を指定しない方式

ee_scd_msg_receive関数で読み出せる後続メッセージ種別は，トランザクション起動時と同じメッセージ種別で，RPCメッセージ，MCPメッセージ，タイマメッセージ，およびMCHメッセージです。

ただし，RPCメッセージの場合，応答型RPC，トランザクショナルRPC，およびRAPは読み出せません。また，タイマメッセージの場合，永続か非永続かによって異なるメッセージ種別として扱います。

(b)　メッセージ種別を指定する方式

メッセージ種別を指定する方式は，トランザクション起動時と異なるメッセージ種別の読み出しができます。次のメッセージ種別を指定できます。

端末入力（MCP）

RPC（非応答型RPCの場合だけ読み出しができます。トランザクショナルRPCは読み出しができません）

タイマ（永続／非永続タイマは別メッセージ種別として扱います）

指定したメッセージ種別だけの読み出しができ，起動時のメッセージ種別も指定しない場合は，読み出しはできません。例えば，MCPメッセージでトラザクション起動した場合，MCPのメッセージ種別を指定しなければMCPメッセージの読出しはできません。

起動時に読み出したメッセージ種別と後続メッセージで読み出しできるメッセージ種別の組み合わせを示します。

表2-20　起動時のメッセージ種別と後続メッセージの組み合わせ

後続メッセージ
起動時のメッセージ

MCP
mach
RPC
タイマ
（永続）
タイマ
（非永続）
左記以外

MCP
○
×
○
○
○
×

mach
×
×
×
×
×
×

RPC
○
×
○
○
○
×

タイマ（永続）
○
×
○
○
○
×

タイマ（非永続）
○
×
○
○
○
×

上記以外
×
×
×
×
×
×

（凡例）

○：メッセージ種別指定時，読み出しができます。

×：読み出しができません。

(2)　読み出しできる後続メッセージの上限

ee_scd_msg_receive関数は，トランザクション起動時に登録済みのメッセージ数以上の回数を発行できません。上限を超えてee_scd_msg_receive関数を発行した場合は，「読み出し上限を超えた」としてエラーになります。

(3)　後続メッセージ読み出し時の格納領域の上書き

後続メッセージは，トランザクション起動時と同様，入力メッセージ引き渡しエリア（IMA）にコピーされます。このため，ee_scd_msg_receive関数を発行すると，前に読み込んだメッセージやトランザクション起動時のインタフェース情報は上書きされます。受信側のUAPから見ると，ee_scd_msg_receive関数を発行することで新しいトランザクションを起動することになります。

後続メッセージを読み出すときの格納領域の上書きを次の図に示します。

図2-37　後続メッセージを読み出すときの格納領域の上書き

ee_scd_msg_receive関数を発行すると直前のメッセージを参照できなくなるため，必要に応じて事前に退避してください。

(4)　コミット決着失敗通知（ERRTRNR）時およびUAP異常終了通知（ERRTRN3）時の動作

コミット決着に失敗するとエラートランザクションのERRTRNRが起動します。また，UAPが異常終了すると，エラートランザクションのERRTRN3が起動します。

通常は，トランザクション起動時にUAPに引き渡した入力メッセージを，ERRTRNRまたはERRTRN3の入力メッセージとして引き渡します。しかし，ee_scd_msg_receive関数を使用して後続メッセージを読み出している場合は，最後に発行したee_scd_msg_receive関数で読み出した入力メッセージをERRTRNRまたはERRTRN3の入力メッセージとして引き渡します。

UAP異常終了通知（ERRTRN3）時の動作を次の図に示します。

図2-38　UAP異常終了通知（ERRTRN3）時の動作

UAPが異常終了すると，メッセージをロールバックして，入力キューを未読み出しの状態にします。そのため，ERRTRN3で引き渡された入力メッセージは，ERRTRN3終了後に，通常のトランザクションまたはERRTRN2で再度UAPに引き渡されます。

2.6.4　読み出しメッセージの差し戻し

メッセージの同時引き出しをなしに指定した場合，ee_scd_msg_receive関数によって読み出したメッセージは，ee_scd_msg_rollback関数によって差し戻すことができます。ee_scd_msg_rollback関数を発行すると，トランザクションの終了状態に関係なく，読み出し済みのメッセージをロールバックして，メッセージを未読み出しの状態にします。

読み出しメッセージの差し戻し例を次の図に示します。

図2-39　読み出しメッセージの差し戻し例

説明

入力メッセージ1を読み出します。

ee_scd_msg_receive関数によって，入力メッセージ2を読み出します。

ee_scd_msg_receive関数によって，入力メッセージ3を読み出します。

ee_scd_msg_rollback関数によって，入力メッセージ2以降を差し戻します。

UAPを終了します（リターンします）。

入力メッセージ2，3が未読み出しの状態に戻ります。

トランザクション起動時に読み出したメッセージは，ee_scd_msg_rollback関数では差し戻せません。トランザクション起動時に読み出したメッセージを差し戻したい場合は，トランザクションをロールバックさせる必要があります。

＜この項の構成＞

(1)　読み出しメッセージの差し戻しが有効となるタイミング

(1)　読み出しメッセージの差し戻しが有効となるタイミング

ee_scd_msg_rollback関数によってメッセージが未読み出しの状態となるのは，ee_scd_msg_rollback関数を発行してUAPがリターン（コミット）したタイミングです。

ee_scd_msg_receive関数発行後，ee_scd_msg_rollback関数を発行し，再度ee_scd_msg_receive関数を発行した場合は，次のメッセージを読み出します。

読み出しメッセージの差し戻しが有効となるタイミングを，次の図に示します。

図2-40　読み出しメッセージの差し戻しが有効となるタイミング

説明

入力メッセージ1を読み出します。

ee_scd_msg_receive関数によって，入力メッセージ2を読み出します。

ee_scd_msg_receive関数によって，入力メッセージ3を読み出します。

ee_scd_msg_rollback関数によって，入力メッセージ2以降を差し戻します。

ee_scd_msg_receive関数によって，入力メッセージ4を読み出します。

UAP処理を終了します（リターンします）。

入力メッセージ2，3，4が未読み出しの状態に戻ります（ee_scd_msg_rollback関数の発行後に読み出した入力メッセージ4も，未読み出しの状態に戻ります）。

なお，ee_scd_msg_rollback関数を複数回発行した場合は，最後にee_scd_msg_rollback関数で指定したメッセージ通番が有効となります。

2.6.5　ロールバック時の読み出しメッセージの扱い（ロールバックリトライ）

トランザクションがロールバックで決着して終了したときは，読み出したメッセージをすべてキューに戻し，再度同じメッセージを読み出すトランザクションを起動します。これをロールバックリトライといいます。ロールバックリトライは，メッセージの同時引き出しをなしに指定した場合だけできます。ロールバックリトライ時の処理の流れを次の図に示します。

図2-41　ロールバックリトライ時の処理の流れ

説明

メッセージ1を読み出します。

メッセージ1のトランザクションがロールバックで決着して終了したため，メッセージ1は入力キューに差し戻されます。

メッセージ1が再度読み出され，トランザクションを開始します。トランザクションがコミットで決着するまで処理が繰り返されます。ただし，処理が繰り返されるのは，ロールバックリトライ回数の上限までです。

＜この項の構成＞

(1)　ロールバック回数のカウント

(2)　ロールバックリトライの監視

(1)　ロールバック回数のカウント

ロールバック回数は，入力キューごとにカウントします。優先キューと通常キューはそれぞれ別にカウントされます。

ロールバック回数のカウント対象になるのは，UAPが明示的にロールバックを指示した場合と，同期点処理の通信障害などでTP1/EEが暗黙的にロールバックした場合です。

ロールバック回数は，次の場合にクリアされ，0になります。

トランザクションのコミット決着時

メッセージ差し戻し指示のコミット決着時

ee_scd_clear_rollback_cnt関数の発行時

また，TP1/EEでは，ロールバック回数をUAPに通知します。

(2)　ロールバックリトライの監視

ロールバックリトライの監視は，TP1/EEで行うか，UAPで行うか選択できます。

TP1/EEでロールバックリトライを監視する場合は，ロールバックリトライ回数の上限をサービス属性定義のservice_attr定義コマンドの-fオプションで定義します。また，ロールバックリトライ回数が上限を超えたときに，該当するサービスを閉塞するか，プロセスダウンするかをユーザサービス関連定義のscd_rollback_retry_modeオペランドで定義します。

UAPで監視する場合は，ロールバック回数が一定の回数を超えたときに，次に示すような対応をします。

業務処理を行わない意味のないコミットとする

サービス閉塞要求とする

2.6.6　プロセス終了時の未読み出しメッセージの扱い

サービスが閉塞している場合，サービス定義のforbid_draw_serviceオペランドにYを指定していると，該当するサービスの入力キュー（ITQ）に未読み出しメッセージが滞留することがあります。

プロセス終了時，サービス閉塞によって入力キューに未読み出しメッセージが滞留していると，プロセスを終了できません。そのため，プロセス終了時に未読み出しメッセージがある場合は，1分おきに警告のメッセージログを出力します。未読み出しメッセージの監視は，未読み出しメッセージがなくなるまで続きます。

プロセスを終了させたい場合は，次のどちらかの方法を用いてください。

eelspcenumコマンドで未読み出しメッセージが滞留しているサービスを確認し，eepceskipコマンドで滞留メッセージを破棄する

eeactsvコマンドでサービスの閉塞を解除して，メッセージを読み出せる状態にする

2.6.7　サービス先行解放

サービス先行解放とは，同期点でのメッセージ送信処理前にサービスを解放し，次のトランザクション（未読み出しメッセージ）の処理を先行して行えるようにすることです。UAPの処理（受信メッセージ処理）を早めるために，サービス先行解放を実行します。

サービス先行解放を実行するための条件を次に示します。

TP1/EEプロセスがCLサーバである（クラスタ連携関連定義のcluster_modeオペランドにYを指定）

トランザクションがサービストランザクション（MN）またはタイマトランザクション（TM）である

サービス先行解放のタイミングを次の図に示します。

図2-42　サービス先行解放のタイミング

説明

メッセージ1を読み出して，トランザクションを起動します。

同期点でのメッセージの送信前に，サービスを解放します。

メッセージ2を読み出して，トランザクションを起動します。

同期点でのメッセージの送信前に，サービスを解放します。

＜この項の構成＞

(1)　タイマトランザクションのスケジュール

(1)　タイマトランザクションのスケジュール

ee_tim_execap関数でタイマトランザクションを即時起動する場合（actionにEETIM_JUSTを指定）などに，タイマ登録を行ったトランザクションが終了してからトランザクションを起動したいときは，flagsオプションにEETIM_SCDL_HOLDを指定します。

EETIM_SCDL_HOLDの指定によるメッセージ読み出しタイミングの違いを次の図に示します。

図2-43　EETIM_SCDL_HOLDの指定によるメッセージ読み出しタイミングの違い

説明

EETIM_SCDL_HOLDを指定しない場合は，サービス解放のタイミングでメッセージ2を読み出します。

EETIM_SCDL_HOLDを指定した場合は，トランザクションが終了してからメッセージ2を読み出します。

EETIM_SCDL_HOLDを指定したタイマをキャンセルすると，EETIM_SCDL_HOLDを指定しなかったものとして，サービス解放時に次のメッセージをスケジュールします。

また，EETIM_SCDL_HOLDを指定した複数のタイマを登録した場合に，EETIM_SCDL_HOLDを指定したタイマをキャンセルすると，EETIM_SCDL_HOLDを指定したタイマが一つでもあれば，トランザクション終了時に次のメッセージをスケジュールします。

なお，EETIM_SCDL_HOLDを指定したタイマを登録したトランザクション（サービス）の同時実行数が複数かどうかに関係なく処理を行います。

2.6.8　連鎖モード連携機能

トランザクション処理の同期点取得には，一つのトランザクションの終了後，同期点を取得して次のトランザクションを続けて起動する連鎖モードのコミット，ロールバックと，トランザクションの終了で同期点を取得したあと，新たなトランザクションを起動しない非連鎖モードのコミット，ロールバックがあります。

連鎖モード連携機能とは，読み出したメッセージを連鎖モードのコミット，ロールバックと連携して決着するか，または連携しないでUAP終了で決着するかを指定する機能です。サービス属性定義のservice_attrオペランドの-gオプションによって指定できます。

＜この項の構成＞

(1)　連鎖モード連携する場合

(2)　連鎖モード連携しない場合

(1)　連鎖モード連携する場合

連鎖モード連携機能を使用すると，連鎖モードのコミット，ロールバックと連携して読み出したメッセージを決着させます。

■連鎖モードのコミットで決着した場合

トランザクションが連鎖モードのコミットによって決着すると，読み出したメッセージは読み出し済みになります。

■連鎖モードのロールバックで決着した場合

トランザクションが連鎖モードのロールバックによって決着すると，メッセージはリトライまたは破棄となります。

トランザクションがロールバックしたときの再起動トランザクションは，読み出したメッセージとは関係のないトランザクションとなります。再起動トランザクションでは，メッセージの読み出し，およびメッセージの差し戻しはできません。また，再起動トランザクションで連鎖モードのコミットまたはロールバックによってトランザクションが決着しても，メッセージには影響しません。

■連鎖モードのコミット，ロールバックを要求しなかった場合

連鎖モードのコミット，ロールバックを要求しなかった場合は，UAPがリターンした時点のトランザクションの決着によって，メッセージは読み出し済み，リトライ，または破棄となります。

連鎖モード連携する場合の処理の流れを次の図に示します。

図2-44　連鎖モード連携する場合の処理の流れ

説明

メッセージ1のトランザクションが開始されたあとも，トランザクションが決着するまでの間，メッセージの読み出しおよび差し戻しができます。

メッセージ1のトランザクションが，連鎖モードのロールバックによって決着し，リトライが決定したため，残りの処理をメッセージ1とは関係のない再起動トランザクションとします。

連鎖モードのロールバックによる再起動トランザクションでは，メッセージの読み出しおよび差し戻しはできません。また，再起動トランザクションが決着した時点では，メッセージ1は読み出し済みになりません。

2.でリトライが決定したため，メッセージ1が再度読み出されます。トランザクションがコミットで決着すると，メッセージ1は読み出し済みになります。

(2)　連鎖モード連携しない場合

連鎖モード連携しない場合，つまり，連鎖モードのコミットまたはロールバックによるトランザクションの決着でメッセージを決着しない場合は，UAPがリターンした時点のトランザクションの決着で，メッセージを決着します（読み出し済み，リトライ，または破棄とします）。

連鎖モード連携しない場合は，再起動トランザクションでメッセージの読み出し，およびメッセージの差し戻しができます。連鎖モード連携しない場合の処理の流れを次の図に示します。

図2-45　連鎖モード連携をしない場合の処理の流れ

説明

連鎖モード連携しないため，トランザクションがロールバックで決着したあとの再起動トランザクションでもメッセージの読み出し要求，および差し戻し要求ができます。

メッセージ1は，再起動トランザクションの決着によって読み出し済みになります。

メッセージ1が読み出し済みになったため，メッセージ2が読み出され，トランザクションが開始されます。

2.7　ステータスファイルレス機能

TP1/EEで取得するステータスファイルには，TP1キャッシュ機能使用時は必要のないシステム制御情報があります。そのため，ステータスファイルレス機能によって，ステータスファイルに取得するシステム制御情報を限定します。

ステータスファイルレス機能には，全体レスと部分レスのオプションがあります。オプションによる違いを次の表に示します。

表2-21　ステータスファイルレス機能での全体レスと部分レスの違い

項番 | 項目 | 全体レス | 部分レス
1 | 指定するシステム構成 | CLサーバ（必須） | HAサーバ（任意）
2 | 取得するシステム制御情報 | すべてのシステム制御情報を取得しません。 | トランザクションに関連するシステム制御情報を取得しません。
3 | ステータスファイルの使用 | 使用しません。 | 使用します。

取得するシステム制御情報の詳細を次の表に示します。

表2-22　取得するシステム制御情報の詳細

項番 | システム制御情報 | 全体レス | 部分レス
1 | サービスの閉塞情報※ | × | ○
2 | システムの終了状態 | × | ○
3 | ランID，システムステータス | × | ○
4 | 処理キューの最大同時処理限界数の変更情報※ | × | ○
5 | システム定義情報 | × | ○
6 | オンラインEEのプロセス定義情報 | × | ×
7 | トランザクション情報 | × | ×
8 | ロールバックアボート時のRPC情報 | × | ×
9 | RPC応答メッセージ送信抑止機能使用時のRPC情報 | × | ×
10 | UAP共用ライブラリ入れ替え情報 | × | ○
11 | ERRTRNRによるRPC応答メッセージ送信情報 | × | ×

（凡例）

○：システム制御情報を取得します。

×：システム制御情報を取得しません。

注※

CLサーバの場合，実行系から待機系へシステム制御情報を転送することによって永続化されます。そのため，実行系がプロセスダウンしても，待機系でシステム制御情報を引き継ぐことができます。

ステータスファイルレス機能の使用は，ステータスファイル関連定義のsts_fileless_useオペランドで指定します。また，全体レスとするか部分レスとするかは，sts_fileless_levelオペランドで指定します。

2.8　メモリの管理

TP1キャッシュ機能使用時のメモリの管理方法は，TP1/EEだけを使用する場合と同様です。

ここでは，TP1キャッシュ機能使用時にだけ使用するバッファおよびワーク領域，ならびにバッファ不足時の面数拡張について説明します。また，大量処理用メモリ管理機能についても説明します。

＜この節の構成＞

2.8.1　バッファの管理

2.8.2　ワーク領域の管理

2.8.3　バッファ不足時の面数拡張

2.8.4　大量処理用メモリ管理機能

2.8.1　バッファの管理

ここでのバッファとは，特定の用途に使用することを目的とした，固定サイズの領域です。

TP1キャッシュ機能使用時は，TP1/EEのバッファに加えて次の表に示すバッファを使用します。

表2-23　TP1キャッシュ機能使用時に使用するバッファ

項番
名称
用途
定義

1
UDP用受信バッファ（UIBF）
UDPプロトコルを使用した通信でのメッセージ受信時に，受信データを格納するバッファです。
メモリ関連定義

udp_recv_message_buf_cntオペランド

udp_recv_message_buf_sizeオペランド

2
UDP用送信バッファ（UOBF）
UDPプロトコルを使用した通信でのメッセージ送信時に，送信データを格納するバッファです。
メモリ関連定義

udp_send_message_buf_cntオペランド

udp_send_message_buf_sizeオペランド

各バッファは，プロセス初期化時にTP1/EEが一括して確保したメモリ領域内に作成されます。

なお，プロセス初期化時に作成されたバッファ面数が不足した場合，XTC用のワーク領域として確保したメモリ領域を不足分のバッファに割り当てます。詳細については，「2.8.2　ワーク領域の管理」および「2.8.3　バッファ不足時の面数拡張」を参照してください。

2.8.2　ワーク領域の管理

ワーク領域とは，TP1/EEプロセスで使用するメモリ領域のうち，システムが一時的に使用するセグメントです。一定の領域をワーク領域として管理し，オンライン中に一時的なメモリが必要になった時点で，ワーク領域から必要なサイズのセグメントを切り出して使用します。なお，使用済みとなったセグメントは，次回利用時に備えてワーク領域に返還します。

TP1キャッシュ機能使用時は，TP1/EEが使用するワーク領域に加えて次の表に示すワーク領域を使用します。

表2-24　TP1キャッシュ機能使用時のワーク領域

項番
名称
用途
定義

1
XTC用ワーク領域（XTCPOOL）
XTCが利用するワーク領域です。
メモリ関連定義

memory_xtc_area_sizeオペランド

memory_xtc_limit_sizeオペランド

2
XDB用ワーク領域（XDBPOOL）
XDBが利用するワーク領域です。
メモリ関連定義

memory_xdb_area_sizeオペランド

memory_xdb_limit_sizeオペランド

ワーク領域は，プロセス初期化時にTP1/EEが一括して確保したメモリ領域内に作成されます。

なお，TP1/EEのワーク領域と異なり，TP1キャッシュ機能使用時のワーク領域は，拡張できるサイズの上限を設定できます。この定義は，メモリ関連定義のmemory_xdb_limit_sizeオペランドおよびmemory_xtc_limit_sizeオペランドで行います。

オンライン中にワーク領域が不足した場合，設定された拡張サイズでワーク領域を拡張（malloc関数の発行）します。一度拡張したワーク領域はオンライン終了まで解放（free関数の発行）しません。

2.8.3　バッファ不足時の面数拡張

TP1キャッシュ機能使用時にバッファ面数が不足すると，XTC用ワーク領域（XTCPOOL）からバッファを割り当てて，バッファ面数を拡張します。

ただし，各バッファの面数は不足しないように，余裕を持って確保してください。

面数拡張の対象となるTP1/EEおよびXTCのバッファと，拡張する面数を次の表に示します。

表2-25　面数拡張の対象となるTP1/EEおよびXTCのバッファと拡張する面数

項番 | 製品 | バッファ種別 | 拡張する面数
1 | TP1/EE | 処理キュー制御用バッファ（PCE） | pce_noオペランドの指定値
2 | タイマサービス制御用バッファ（ICB） | icb_noオペランドの指定値
3 | タイマトランザクション用バッファ（TTBF） | time_message_noオペランドの指定値
4 | 受信バッファ（IBF） | recv_message_buf_cntオペランドの指定値
5 | 送信バッファ（OBF） | send_message_buf_cntオペランドの指定値
6 | DBキュー用受信バッファ（QIBF） | dbq_recv_message_buf_cntオペランドの指定値
7 | DBキュー用送信バッファ（QOBF） | dbq_send_message_buf_cntオペランドの指定値
8 | DBキュー用最大バッファ（QWBF） | dbq_use_buf_cntオペランドの指定値
9 | システムバッファ | システム固定
10 | XTC | UDP用受信バッファ（UIBF） | udp_recv_message_buf_cntオペランドの指定値
11 | UDP用送信バッファ（UOBF） | udp_send_message_buf_cntオペランドの指定値

なお，面数の拡張で割り当てたバッファが使用済みになると，XTC用ワーク領域へ返還します。割り当て先のバッファに，面数の拡張で割り当てたバッファがストックされることはありません。

2.8.4　大量処理用メモリ管理機能

一時的に大量のメモリを消費するトランザクションが発生すると，通常のオンライン中には使用しないメモリをTP1/EEが大量に確保し続けるおそれがあります。そのため，このようなトランザクションが発生する場合は，大量処理用メモリ管理機能を使用します。

大量処理用メモリ管理機能を使用すると，該当するトランザクションの処理中に要求されたメモリを，初期確保する領域からではなく別のメモリ領域から割り当てます。大量処理用メモリ管理機能で割り当てられた領域は，該当するトランザクションが終了したあとで，OSに解放されます。

＜この項の構成＞

(1)　使用する領域の種類と定義

(2)　機能の使用開始と終了

(3)　留意事項

(1)　使用する領域の種類と定義

大量処理用メモリ管理機能で使用する領域を次の表に示します。

表2-26　大量処理用メモリ管理機能で使用する領域

項番
名称
TP1/EEが管理するメモリリソースとの対応
定義

1
大量処理用システム領域（MPSPOOL）

すべてのバッファ

システム用ワーク領域

XTC用ワーク領域（XTCPOOL）

XDB用ワーク領域（XDBPOOL）

メモリ関連定義のmemory_mdpsys_area_sizeオペランド

2
大量処理用ユーザ領域（MPUPOOL）
ユーザ用ワーク領域
メモリ関連定義のmemory_mdpusr_area_sizeオペランド

なお，大量処理用システム領域と大量処理用ユーザ領域は，どちらか一方だけを使用することもできます。

(2)　機能の使用開始と終了

UAPでee_mem_mdpstart関数を発行すると，大量処理用メモリ管理機能の使用を開始します。また，該当するUAPがリターンしてトランザクションが終了するときに，大量処理用メモリ管理機能も終了し，使用中のセグメントが存在しない領域をOSに解放します。なお，使用中のセグメントが存在する場合は，使用中のセグメントがすべて返還されてから，領域ごとにOSに解放します。

複数のUAPで並行して大量処理用メモリ管理機能を使用する場合，大量処理用システム領域および大量処理用ユーザ領域はそれぞれのUAPで共有します。この場合，領域の解放は，並行して動作するUAPのうち，最後のUAPがリターンしてトランザクションが終了してから行われます。

(3)　留意事項

大量処理用メモリ管理機能を使用する際の留意事項を次に示します。

■スレッドダウン時の動作

大量処理用メモリ管理機能を使用中のスレッドでスレッドダウンが発生した場合，該当するスレッドで使用された未返還のTASK属性のセグメントを強制解放するときに，大量処理用メモリ管理機能を終了します。

■XTC用ワーク領域およびXDB用ワーク領域の動作

CLサーバ（クラスタ連携関連定義のcluster_modeオペランドにYを指定）の場合，XTCワーク領域およびXDBワーク領域の動作が次のとおりになります。

追加確保した領域については，使用中のセグメントが存在しなくなった時点で，オンライン中に該当する領域をOSに解放（free関数を発行）します。

待機系では，メモリ関連定義のmemory_xtc_limit_sizeオペランドおよびmemory_xdb_limit_sizeオペランドの設定値が無効になります。なお，設定値を超えるセグメント要求があった場合，設定値を無視して領域を追加確保（malloc関数を発行）します。

なお，ee_mem_mdpstart関数を発行したかどうかに関係なく，オンライン中は常にこの動作となります。

2.9　キューダンプ機能

ここでは，キューダンプ機能について説明します。

＜この節の構成＞

2.9.1　キューダンプ機能の概要

2.9.2　滞留メッセージのキューダンプファイルへの出力

2.9.3　キューダンプファイルに出力されたメッセージの参照

2.9.1　キューダンプ機能の概要

TP1キャッシュ機能を使用すると，オンライン終了時にキューにメッセージが滞留する場合があります（このメッセージを滞留メッセージといいます）。

この場合，キューダンプ機能によって，滞留メッセージのキューダンプファイルへの出力，編集が行えます。

キューダンプ機能の概要を次の図に示します。

図2-46　キューダンプ機能の概要

説明

滞留メッセージをキューダンプファイルに出力します。
詳細については，「2.9.2　滞留メッセージのキューダンプファイルへの出力」を参照してください。

キューダンプファイルを編集して，参照します。
詳細については，「2.9.3　キューダンプファイルに出力されたメッセージの参照」を参照してください。

2.9.2　滞留メッセージのキューダンプファイルへの出力

＜この項の構成＞

(1)　キューダンプファイルへの出力タイミング

(2)　キューダンプファイルの作成と削除

(3)　出力対象となるメッセージ

(4)　キューダンプファイル作成時の障害

(1)　キューダンプファイルへの出力タイミング

滞留メッセージは，次のタイミングでキューダンプファイルに出力されます。

XTC終了時
正常終了，計画停止A，または計画停止Bの場合に出力されます。また，CLサーバの待機系の場合は，待機系が単独で終了するときにだけ出力されます。

実行系孤立状態になったとき

参考

次の場合，滞留メッセージはキューダンプファイルに出力されません。

出力対象となるメッセージがない場合

XTCの終了モードが強制停止またはプロセスダウンの場合

待機系が実行系と連動して終了する場合

(2)　キューダンプファイルの作成と削除

キューダンプファイルは，TP1/EEによってTP1/EEプロセス（サービスグループ）ごとに専用のファイルが作成されます。キューダンプファイルの容量見積もりは，「3.2.1　キューダンプファイルの容量見積もり」を参照してください。

(a)　XTC終了時

XTC終了時に作成されるキューダンプファイルは，次のディレクトリに格納されます。

$DCDIR/spool/dceeinf/quedump/

ファイル名は次のとおりです。

gg....ggquedump

変数の説明

gg....gg：サービスグループ名（最大31バイト）

quedump：キューダンプファイルを示す文字列（7バイト固定）

なお，古いキューダンプファイルがある場合は新しいファイルに上書きされるため，必要に応じて古いファイルのバックアップを取得してください。

(b)　実行系孤立状態になったとき

実行系孤立状態になったときに作成されるキューダンプファイルは，次のディレクトリに格納されます。

$DCDIR/spool/dceeinf/hamdump/

ファイル名は次のとおりです。

gg....gg_nnnn_rrrrrrrr_cc....cc_xtc

変数の説明

gg....gg：サービスグループ名（最大31バイト）

nnnn：ノード識別子（4バイト）

rrrrrrrr：ランID（8バイト）※1

cc....cc：CL通番（16バイト）※2

xtc：キューダンプファイルを示す文字列（3バイト固定）

注※1

ランIDは，16進数の通算秒です。

注※2

CL通番は，実行系でトランザクションを起動するたびに加算される16進数の通番です。待機系から実行系に切り替わった場合も，プロセスダウン前の実行系のCL通番を引き継ぐため，CLサーバでのトランザクションを一意に決定できます。

実行系孤立状態になったときに作成されるキューダンプファイルは，自動的には削除されません。必要に応じてバックアップを取得するか，または削除してください。

複数のキューダンプファイルから最新のファイルを探すには，サービスグループ名とノード識別子からファイルを絞り込み，その中で「ランID」＋「CL通番」が最も大きいファイルを特定します。

(3)　出力対象となるメッセージ

キューダンプファイルに出力される対象となるメッセージを次の表に示します。

表2-27　キューダンプファイルへの出力対象メッセージ

項番
システム構成（系）
キュー種別
メッセージ種別
出力対象

1
CLサーバ
（実行系）
ITQ
RPCメッセージ
（非永続）
×

2
RPCメッセージ
（永続）
○

3
MCPメッセージ
（非永続）
×

4
MCPメッセージ
（永続）
○

5
タイマメッセージ
（非永続）
×

6
タイマメッセージ
（永続）※1
×

7
MCHメッセージ
（非永続）
×

8
MCHメッセージ
（永続）
○

9
OTQ
MCHメッセージ
（非永続）
×

10
MCHメッセージ
（永続）
○

11
CLサーバ
（待機系）
ITQ（仮登録）※2
RPCメッセージ
（永続）
○

12
MCPメッセージ
（永続）
○

13
タイマメッセージ
（永続）
×

14
MCHメッセージ
（永続）
○

15
OTQ
MCHメッセージ
（永続）
○

16
HAサーバ
ITQ
RPCメッセージ
×

17
MCPメッセージ
×

18
タイマメッセージ
×

19
MCHメッセージ
×

20
OTQ
MCHメッセージ
（非永続）
×

21
MCHメッセージ
（永続）
×

（凡例）

ITQ：入力キューを示します。

OTQ：出力キューを示します。

○：出力対象になります。

×：出力対象になりません。

注※1

タイマトランザクションの起動時刻前で，入力キュー（ITQ）に登録待ちとなっているメッセージを含みます。

注※2

処理キュー仮登録のメッセージに対応するXDBの更新ログ，およびee_mch_cmtsend関数またはee_mch_cmtsend_sync関数による一方送信メッセージを含みます。

(4)　キューダンプファイル作成時の障害

キューダンプファイル作成時にファイルのI/Oで障害が発生した場合，エラーメッセージが出力されて，キューダンプファイルの作成は中止されます。また，オンラインは終了処理を中断してコマンド入力待ちとなります。TP1/EE管理者は，障害要因を取り除いたあとにeetrbwtorコマンドで応答してください。eetrbwtorコマンドのオプションによって，キューダンプファイルの作成をリトライするか，キューダンプファイルを作成しないでオンラインを終了するか選択できます。

2.9.3　キューダンプファイルに出力されたメッセージの参照

キューダンプファイルに出力されたメッセージを参照するには，キューダンプファイルを編集します。キューダンプファイルの編集にはeetrbqueedコマンドを使用します。

2.10　UAPのテスト支援機能

UAPの動作確認テストを支援する機能として，CLサーバのシミュレート機能があります。

＜この節の構成＞

2.10.1　CLサーバのシミュレート機能

2.10.1　CLサーバのシミュレート機能

通常，CLサーバを実現するには，HAモニタ環境を構築し，3台構成とする必要があります。しかし，CLサーバのシミュレート機能を使用することで，HAモニタ環境，および待機系2台の環境を構築しなくても，実行系1台だけでUAPの動作を確認できます。ただし，実行系で使用するTP1/Server Baseの環境構築は必要です。

CLサーバのシミュレート機能を使用するには，クラスタ連携関連定義のcluster_test_modeオペランドにYを指定します。また，クラスタ構成に関する定義を記述します。

CLサーバのシミュレート機能を使用すると，次の図に示す項目をシミュレートします。

図2-47　CLサーバのシミュレート機能

それぞれの項目について，CLサーバのシミュレート機能使用時の処理を次の表に示します。

表2-28　CLサーバのシミュレート機能使用時の処理

項番
項目
処理内容

1
HAモニタとの連携
HAモニタと連携する機能は，すべて実行しません。HAモニタから正常にリターンしたものとして処理します。
なお，eehamlsコマンドでは，実行系だけとして表示します。

2
実行系と待機系の起動待ち合わせ
実行系と待機系の起動待ち合わせをしません。実行系の初期化処理が完了した際，待機系が起動したものとして処理します。

3
CL同期通信などの待機系との通信
待機系に対する通信が成功したものとして処理します。

2.11　CL単独起動機能

通常，CLサーバを実現するには，HAモニタ環境を構築し，XTCを配置した実行系1台，待機系2台が必要です。しかし，CL単独起動機能を使用することで，XTCを配置した実行系1台で，TP1キャッシュ機能を実現できます。実行系のHAモニタ環境，およびXTCの待機系は不要になります。

CL単独起動機能を使用しない場合と使用する場合の構成を次の図に示します。

図2-48　CL単独起動機能を使用しない場合と使用する場合の構成

CL単独起動機能には，次の特徴があります。

実行系だけの構成で，XDBのインメモリDBを使用できます。

CLサーバで待機系との通信が行われないため，CL単独起動機能を使用しない場合と比べて性能が向上します。
ただし，プロセスダウンした場合，永続メッセージ，およびインメモリDBを保証しません。

正常終了，計画停止A，および計画停止Bで，キューダンプを出力します。

＜この節の構成＞

(1)　CL単独起動機能を使用する場合と使用しない場合の相違点

(2)　CL単独起動機能に関する定義

(3)　CL単独起動機能使用時の注意事項

(1)　CL単独起動機能を使用する場合と使用しない場合の相違点

CL単独起動機能を使用する場合，使用しない場合と比べて次の点が異なります。

HAモニタと連携しません。このため，HAモニタが前提プログラムではありません。

クラスタ構成による系切り替えをしません。

プロセスダウンしても待機系でキューダンプを出力しません。

待機系でのメッセージの永続化ができません。

XTCの開始・終了時に，待機系に関連した処理を行いません。XTCの開始・終了時の待機系の処理については，「6.1.2　CLサーバでのXTCの開始」，および「6.2.2　CLサーバでのXTCの終了」を参照してください。

(2)　CL単独起動機能に関する定義

CL単独起動機能を使用する場合，次のように定義してください。

クラスタ連携関連定義のcluster_modeオペランドにYを指定

UDPグループ情報関連定義のclgrpdef定義コマンドの指定を省略

(3)　CL単独起動機能使用時の注意事項

CL単独起動機能を使用する場合，次のことに注意してください。

eehamlsコマンドを実行した場合，実行系だけが表示されます。

CL単独起動機能では，HAモニタ構成とCL同期をシミュレートする必要がありません。このため，CLサーバのシミュレート機能は使用できません。

3.　XTCが扱うファイルの種類と容量見積もり

この章では，XTCが扱うファイルの種類と容量見積もりについて説明します。

＜この章の構成＞

3.1　XTCが扱うファイルの種類

3.2　ファイルの容量見積もり

3.1　XTCが扱うファイルの種類

XTCでは，TP1/EEが扱うファイル以外に，次の表に示すファイルを扱います。

表3-1　XTCが扱うファイル

項番 | ファイル名称 | 内容 | ファイル形式
1 | キューダンプファイル | キューダンプを取得するファイルです。 | UNIXファイル

TP1/EEが扱うファイルについては，マニュアル「TP1/Server Base Enterprise Option 使用の手引」を参照してください。

3.2　ファイルの容量見積もり

ファイルの容量見積もりについては，マニュアル「TP1/Server Base Enterprise Option 使用の手引」を参照してください。

ここでは，XTCが独自に扱うファイル，および見積もり方法に変更のあるファイルについて説明します。

＜この節の構成＞

3.2.1　キューダンプファイルの容量見積もり

3.2.2　TASKTMファイルの容量見積もり

3.2.3　回線トレースファイルの容量見積もり

3.2.4　メモリダンプファイルの容量見積もり

3.2.1　キューダンプファイルの容量見積もり

キューダンプファイルの容量は，次の計算式で求めます。

全体のキューダンプファイルサイズ（T）＝
　　↑（416＋（516＋（1044＋M）×↑（L÷M）↑）×I
　　＋（（1044＋N）×↑（L÷N）↑）×Q）×1.2（安全率）↑

（凡例）

L：平均メッセージ長

M：udp_recv_message_buf_sizeオペランドの指定値

N：udp_send_message_buf_sizeオペランドの指定値

I：入力キュー（ITQ）の滞留メッセージ数

Q：出力キュー（OTQ）の滞留メッセージ数

3.2.2　TASKTMファイルの容量見積もり

TASKTMファイルのサイズの見積もりに必要な情報を次に示します。ここで求める値を，TP1/EEの見積もりサイズに加算してください。

トランザクション単位のバイト数：512

1ブロック単位に付加する情報のバイト数：96

1ファイル単位に付加する情報のバイト数：128＋34×（サービス数）＋256

全体のTASKTMファイルのサイズは次の計算式で求めます。

全体のTASKTMファイルのサイズ（T）＝（512×x）
　　　　　　　　　　　　　　　　　　＋（↑（（512×x）÷b）↑×96）
　　　　　　　　　　　　　　　　　　＋（128＋34×s＋256）

（凡例）

b：trb_tasktm_buffer_sizeオペランドで指定する値

s：サービス数

x：トランザクション数

また，トランザクション数を見積もる場合の参考値は，システム構成によって異なります。なお，次に示す計算式は参考値です。実際には余裕を持って見積もってください。

■HAサーバの場合

トランザクション数＝受信メッセージ数（MCH）×2
　　　　　　　　　　＋受信メッセージ数（RPC，MCP）
　　　　　　　　　　＋ee_tim_execap関数のAPI発行回数
　　　　　　　　　　＋ee_mch_cmtsend関数のAPI発行回数

■CLサーバの場合

トランザクション数＝受信メッセージ数（MCH）×2※¹
　　　　　　　　　　＋受信メッセージ数（RPC）※²
　　　　　　　　　　＋受信メッセージ数（MCP）※³
　　　　　　　　　　＋ee_mch_cmtsend関数のAPI発行回数×2
　　　　　　　　　　＋ee_tim_execap関数のAPI発行回数×3
　　　　　　　　　　＋転送対象コマンド発行回数※⁴
　　　　　　　　　　＋転送対象API発行回数※⁴

注※1

受信メッセージを永続化している場合は，さらに2倍します。

注※2

RPC関連定義で受信メッセージを永続化する指定（rpc_recv_permanenceオペランドにYを指定）の場合は，4倍します。

注※3

MCP構成定義で受信メッセージを永続化する指定（eemcpfunc定義コマンドの-mオプションのrecvpermanenceオペランドにyesを指定）の場合は，4倍します。

注※4

転送対象コマンドおよび転送対象APIとは，次のコマンドおよびAPIです。

スレッドダウンによるサービス自動閉塞

eedctsvコマンド，eeactsvコマンド，またはee_thd_abdctl関数によるサービス閉塞状態の変更

一方送信メッセージ障害による出力キュー（OTQ）の自動閉塞

eemchotqactコマンド，eemchotqdctコマンド，またはee_mch_otqbkctl関数による出力キュー閉塞状態の変更

eelspceコマンドによるサービスの最大同時処理限界数の変更

eemchotqskipコマンドまたはee_mch_otqskip関数による出力キューメッセージのスキップ

eepceskipコマンドまたはee_scd_msg_skip関数による滞留メッセージのスキップ

3.2.3　回線トレースファイルの容量見積もり

＜この項の構成＞

(1)　HAサーバの場合

(2)　CLサーバの場合

(1)　HAサーバの場合

HAサーバの場合に，回線トレースファイルのサイズの見積もりに必要な情報を次に示します。ここで求める値を，TP1/EEの見積もりサイズに加算してください。

トランザクション単位のバイト数：328

メッセージ受信単位のバイト数：600

1ブロック単位に付加する情報のバイト数：96

1ファイル単位に付加する情報のバイト数：128＋34×（サービス数）＋256

パケット数：（↑メッセージ長÷（パケットサイズ※1）↑＋1）※2

注※1

パケットサイズは次の計算式で求めます。

rpc_udp_packet_sizeオペランドの指定値－96

注※2

W-send機能使用時は2倍にしてください。

全体の回線トレースファイルのサイズは次の計算式で求めます。

全体の回線トレースファイルのサイズ（T）＝
　　　　　　　　（328×x）＋（600×y1）＋（600×y2）＋（600×p×z）
　　　　　　　　＋（↑（（（328×x）＋（600×y1）＋（600×p×y2）
　　　　　　　　＋（600×p×z））÷b）↑×96）
　　　　　　　　＋（128＋34×（s）＋256）

（凡例）

b：バッファサイズ※

p：パケット数

s：サービス数

x：トランザクション数

y1：受信メッセージ数（RPCメッセージ）

y2：受信メッセージ数（MCHメッセージ）

z：送信メッセージ数

注※

バッファサイズには次に示す値を指定します。

トラブルシュート関連定義のtrb_extend_functionオペランドに00000001を論理和で指定した場合
trb_line_trace_buffer_sizeオペランドでの指定値とtrb_line_cmtrace_buffer_sizeオペランドでの指定値の小さい方

トラブルシュート関連定義のtrb_extend_functionオペランドを省略するか，または00000000を論理和で指定した場合
trb_line_trace_buffer_sizeオペランドでの指定値

(2)　CLサーバの場合

CLサーバの場合に，回線トレースファイルのサイズの見積もりに必要な情報を次に示します。ここで求める値を，TP1/EEの見積もりサイズに加算してください。

トランザクション単位のバイト数：328

メッセージ受信単位のバイト数：600

メッセージ送信単位のバイト数：600

送達確認メッセージ送信単位のバイト数：1800

1ブロック単位に付加する情報のバイト数：96

1ファイル単位に付加する情報のバイト数：128＋34×（サービス数）

パケット数：（↑メッセージ長÷（パケットサイズ※1）↑＋1）※2

注※1

パケットサイズは次の計算式で求めます。

rpc_udp_packet_sizeオペランドの指定値－96

注※2

W-send機能使用時は2倍にしてください。

XDBの更新ログのバイト数：D

（凡例）

Ni：挿入（INSERT）した行の数

Nu：更新（UPDATE）した行の数

Nd：削除（DELETE）した行の数

Lk：k番目に挿入（INSERT）した行の行長

Mk：k番目に更新（UPDATE）した行の行長

全体の回線トレースファイルのサイズは次の計算式で求めます。

全体の回線トレースファイルのサイズ（T）＝
　　　　　　　　（328×x1）＋（600×p×y）＋（600×p×z）
　　　　　　　　＋（600×p×t）＋（600×↑D÷8388608​↑×x2）
　　　　　　　　＋1644×（x1＋x2＋y＋z＋t）
　　　　　　　　＋（↑（（（328×x1）＋（600×p×y）＋（600×p×z）
　　　　　　　　＋（600×p×t）＋（600×↑D÷8388608​↑×x2）
　　　　　　　　＋1644×（x1＋x2＋y＋z＋t））÷b）↑×96）
　　　　　　　　＋（128＋34×（s））

（凡例）

D：XDBの更新ログのバイト数

b：バッファサイズ※

p：パケット数

s：サービス数

t：ee_tim_execap関数（永続指定）を発行した回数

x1：トランザクション数（SQL発行なし）

x2：トランザクション数（SQL発行あり）

y：受信メッセージ数

z：送信メッセージ数

注※

バッファサイズには次に示す値を指定します。

トラブルシュート関連定義のtrb_extend_functionオペランドに00000001を論理和で指定した場合
trb_line_trace_buffer_sizeオペランドでの指定値とtrb_line_cmtrace_buffer_sizeオペランドでの指定値の小さい方

トラブルシュート関連定義のtrb_extend_functionオペランドを省略するか，または00000000を論理和で指定した場合
trb_line_trace_buffer_sizeオペランドでの指定値

3.2.4　メモリダンプファイルの容量見積もり

メモリダンプファイルの見積もり方法は，TP1/EEサービス定義のトラブルシュート関連定義のtrb_dump_area_kindオペランド（メモリダンプファイル出力領域種別）の指定によって異なります。

■trb_dump_area_kind=13の場合

次の計算式で求めます。

（max_mem_sizeオペランドまたはmax_mem_size_mbオペランドの指定値
　　－user_work_sizeオペランドの指定値
　　－368×pce_noオペランドの指定値
　　－144×（10＋icb_noオペランドの指定値）
　　－time_message_sizeオペランドの指定値×time_message_noオペランドの指定値
　　－（recv_message_buf_sizeオペランドの指定値＋1040）
　　　　　　　　　　×recv_message_buf_cntオペランドの指定値
　　－（send_message_buf_sizeオペランドの指定値＋1040）
　　　　　　　　　　×send_message_buf_cntオペランドの指定値
　　－（udp_recv_message_buf_sizeオペランドの指定値＋1040）
　　　　　　　　　　×udp_recv_message_buf_cntオペランドの指定値
　　－（udp_send_message_buf_sizeオペランドの指定値＋1040）
　　　　　　　　　　×udp_send_message_buf_cntオペランドの指定値
　　－（max_message_sizeオペランドの指定値＋2264）
　　　　　　　　　　×（thread_noオペランドの指定値＋reserve_thread_noオペランドの指定値＋1）
）

■trb_dump_area_kind=9の場合

次の計算式で求めます。

（max_mem_sizeオペランドまたはmax_mem_size_mbオペランドの指定値
　　－user_work_sizeオペランドの指定値
　　－system_work_sizeオペランドの指定値
　　－memory_cobol_area_sizeオペランドの指定値
　　－memory_xtc_area_sizeオペランドの指定値
　　－memory_xdb_area_sizeオペランドの指定値
　　－368×pce_noオペランドの指定値
　　－144×（10＋icb_noオペランドの指定値）
　　－time_message_sizeオペランドの指定値×time_message_noオペランドの指定値
　　－（recv_message_buf_sizeオペランドの指定値＋1040）
　　　　　　　　　　×recv_message_buf_cntオペランドの指定値
　　－（send_message_buf_sizeオペランドの指定値＋1040）
　　　　　　　　　　×send_message_buf_cntオペランドの指定値
　　－（udp_recv_message_buf_sizeオペランドの指定値＋1040）
　　　　　　　　　　×udp_recv_message_buf_cntオペランドの指定値
　　－（udp_send_message_buf_sizeオペランドの指定値＋1040）
　　　　　　　　　　×udp_send_message_buf_cntオペランドの指定値
　　－（max_message_sizeオペランドの指定値＋2264）
　　　　　　　　　　×（thread_noオペランドの指定値＋reserve_thread_noオペランドの指定値＋1）
）

■注意事項

大量処理用メモリ管理機能を使用している場合，計算式で求めたメモリダンプファイルのサイズに，大量処理用メモリ管理機能で確保した大量処理用メモリ領域のサイズを加算してください。

大量処理用メモリ領域のサイズは，メモリダンプ出力時にeememlsコマンドで表示される「大量処理用システム領域（MDP system area）」と「大量処理用ユーザ領域（MDP user area）」の領域確保サイズを合算した値です。

4.　環境設定

この章では，TP1キャッシュ機能使用時の環境設定とその手順について説明します。

＜この章の構成＞

4.1　環境設定の概要

4.2　TP1/Server Base管理者の設定

4.3　インストール

4.4　システム定義の設定

4.5　OSへの登録，ファイルシステム領域の作成

4.6　ファイルの作成，リソースマネジャの登録

4.7　データベースの準備

4.8　HAモニタの環境設定

4.1　環境設定の概要

TP1キャッシュ機能使用時の環境設定は，CLサーバの場合とHAサーバの場合とで異なります。手順を次の図に示します。

図4-1　TP1キャッシュ機能使用時の環境設定の手順

各項目の作業については，次節以降で説明します。

CLサーバの場合は，CLサーバを構成する全マシンに対して同じ手順で環境設定を行ってください。

HAサーバの場合は，HAサーバを構成する全マシンに対して同じ手順で環境設定を行ってください。

4.2　TP1/Server Base管理者の設定

TP1/Server Base管理者の設定手順を次の図に示します。CLサーバの場合もHAサーバの場合も，設定手順は同じです。

図4-2　TP1/Server Base管理者の設定手順

詳細については，マニュアル「OpenTP1 運用と操作」を参照してください。

4.3　インストール

インストール手順を次の図に示します。

図4-3　インストール手順

TP1/Server Baseのインストールについては，マニュアル「OpenTP1 運用と操作」を参照してください。

TP1/EEのインストールについては，マニュアル「TP1/Server Base Enterprise Option 使用の手引」を参照してください。

それ以外については，各製品のリリースノートを参照してください。

4.4　システム定義の設定

システム定義の設定手順を次の図に示します。

図4-4　システム定義の設定手順

TP1/Server Baseのシステム定義の作成については，マニュアル「OpenTP1 システム定義」およびマニュアル「TP1/Server Base Enterprise Option 使用の手引」を参照してください。

TP1/EEサービス定義の作成については，マニュアル「TP1/Server Base Enterprise Option 使用の手引」を参照してください。

XTCサービス定義の作成については，「5.　システム定義」を参照してください。

MCP構成定義の作成については，マニュアル「TP1/EE/Message Control Extension 使用の手引」を参照してください。

XDBサービス定義の作成については，マニュアル「TP1/EE/Extended Data Cache 使用の手引」を参照してください。

4.5　OSへの登録，ファイルシステム領域の作成

OSへの登録，およびファイルシステム領域の作成手順を次の図に示します。

図4-5　OSへの登録，およびファイルシステム領域の作成手順

詳細については，マニュアル「OpenTP1 運用と操作」およびマニュアル「TP1/Server Base Enterprise Option 使用の手引」を参照してください。

4.6　ファイルの作成，リソースマネジャの登録

ファイルの作成，およびリソースマネジャの登録手順を次の図に示します。

図4-6　ファイルの作成，およびリソースマネジャの登録手順

詳細については，マニュアル「OpenTP1 運用と操作」およびマニュアル「TP1/Server Base Enterprise Option 使用の手引」を参照してください。

4.7　データベースの準備

CLサーバではデータベースの準備が必要になります。データベースの準備については，マニュアル「TP1/EE/Extended Data Cache 使用の手引」の「環境設定」を参照してください。

4.8　HAモニタの環境設定

CLサーバとHAサーバでは，HAモニタの環境設定方法が異なります。ここでは，サーバごとのHAモニタの環境設定方法について説明します。

＜この節の構成＞

4.8.1　CLサーバの場合

4.8.2　HAサーバの場合

4.8.1　CLサーバの場合

CLサーバでは，HAモニタのマルチスタンバイ機能を使用して，クラスタ型系切り替え構成を構築します。マルチスタンバイ機能を使用したときのHAモニタの環境設定については，マニュアル「高信頼化システム監視機能 HAモニタ Linux(R)編」を参照してください。

ここでは，環境設定時の注意点を説明します。

＜この項の構成＞

(1)　環境設定時の注意点

(2)　TP1/Server Baseのシステムサービス定義を作成するときの注意点

(3)　HAモニタの定義ファイルを作成するときの注意点

(1)　環境設定時の注意点

実行系と待機系の実行環境を同じにしてください。例えば，次に示すことを一致させてください。一致していないと，系が正常に切り替わりません。

システム定義の内容

UAPの実行形式プログラム

トランザクションサービス制御用実行形式プログラム（trnlnkrmコマンドで再作成した場合）

TP1/EEおよび関連製品のバージョン

TP1/EE管理者の環境（ユーザID，グループID，環境変数など）

TP1/EEディレクトリの絶対パス名

(2)　TP1/Server Baseのシステムサービス定義を作成するときの注意点

TP1/Server Baseのシステムサービス定義を作成するときの注意点を次に示します。

システムサービス構成定義のha_confオペランドにNを指定し，TP1/Server Baseに対して系切り替え機能を適用しないようにしてください。
CLサーバでは，TP1/EEプロセスをHAモニタが直接監視します。そのため，TP1/Server BaseをHAモニタの監視対象から外す必要があります。

ユーザサービス定義のholdオペランドにYを指定し，TP1/EEプロセスが異常終了した場合，サービスグループまたはサービスを閉塞するようにしてください。

(3)　HAモニタの定義ファイルを作成するときの注意点

HAモニタの定義ファイルを作成するときの注意点を次に示します。

次に示すオペランドに指定するホスト名を一致させてください。

UDPグループ情報関連定義のclgrpdef定義コマンドの-nオプションに指定するホスト名

HAモニタのenvironment定義文のnameオペランドに指定するホスト名

次に示すオペランドに指定するクラスタ識別子を一致させてください。

UDPグループ情報関連定義のclgrpdef定義コマンドの-cオプションに指定するクラスタ識別子

HAモニタのserver定義文のnameオペランドに指定するクラスタ識別子

TP1/EEプロセスを直接監視するため，HAモニタのserver定義文のserver_typeオペランドにBを指定してください。

HAモニタのマルチスタンバイ機能を使用するため，HAモニタのfunction定義文のmultistandbyオペランドにuseを指定してください。

HAモニタの定義ファイルの指定例を次に示します。

■実行系の定義例

OpenTP1およびXTCの定義例

set node_id = ap01
  :
clgrpdef -p 10001 -m path01 -n ap01:host01,ap02:host02,ap03:host03 -c cl01
                                     [1]                               [2]

HAモニタの定義例

environment    name host01,  ...[1]
  :
function
              multistandby    use,  ...[3]
  :
server    name cl01,         ...[2]
         alias server01,
         acttype server,
         server_type B,     ...[4]
         initial online,    ...[5]
  :

説明

同じホスト名を指定します。

同じクラスタ識別子を指定します。

マルチスタンバイ機能を使用するため，useを指定します。

TP1/EEプロセスを直接監視するため，Bを指定します。

CLサーバの開始時にこのサーバを実行系にするため，onlineを指定します。

■待機系1の定義例

OpenTP1およびXTCの定義例

set node_id = ap02
  :
clgrpdef -p 10001 -m path01 -n ap01:host01,ap02:host02,ap03:host03 -c cl01
                                                  [1]                 [2]

HAモニタの定義例

environment    name host02,  ...[1]
  :
function
              multistandby    use,  ...[3]
  :
server    name cl01,         ...[2]
         alias server01,
         acttype server,
         server_type B,     ...[4]
         standbypri 1,      ...[5]
         initial standby,   ...[6]
  :

説明

同じホスト名を指定します。

同じクラスタ識別子を指定します。

マルチスタンバイ機能を使用するため，useを指定します。

TP1/EEプロセスを直接監視するため，Bを指定します。

待機系の優先度を指定します。1を指定しているため，最初の系切り替えが発生した場合，このサーバが実行系になります。

CLサーバの開始時にこのサーバを待機系にするため，standbyを指定します。

■待機系2の定義例

OpenTP1およびXTCの定義例

set node_id = ap03
  :
clgrpdef -p 10001 -m path01 -n ap01:host01,ap02:host02,ap03:host03 -c cl01
                                                             [1]       [2]

HAモニタの定義例

environment    name host03,  ...[1]
  :
function
              multistandby    use,  ...[3]
  :
server    name cl01,         ...[2]
         alias server01,
         acttype server,
         server_type B,     ...[4]
         standbypri 2,      ...[5]
         initial standby,   ...[6]
  :

説明

同じホスト名を指定します。

同じクラスタ識別子を指定します。

マルチスタンバイ機能を使用するため，useを指定します。

TP1/EEプロセスを直接監視するため，Bを指定します。

待機系の優先度を指定します。2を指定しているため，最初の系切り替えが発生した場合，このサーバは待機系のままです。

CLサーバの開始時にこのサーバを待機系にするため，standbyを指定します。

4.8.2　HAサーバの場合

HAサーバの場合，TP1/EEが直接HAモニタと連携することはありません。系切り替え時のTP1/EEの動作は，TP1/Server Baseの設定に依存します。

HAモニタの環境設定については，マニュアル「高信頼化システム監視機能 HAモニタ Linux(R)編」およびマニュアル「TP1/Server Base Enterprise Option 使用の手引」を参照してください。

5.　システム定義

この章では，TP1キャッシュ機能使用時のシステム定義について説明します。

＜この章の構成＞

5.1　システム定義の概要

5.2　TP1/EEサービス定義

5.3　XTCサービス定義

5.1　システム定義の概要

ここでは，TP1キャッシュ機能使用時のシステム定義の体系，定義の構成，定義の規則，および注意事項について説明します。

＜この節の構成＞

5.1.1　定義の体系

5.1.2　定義の構成

5.1.3　定義の規則

5.1.4　CLサーバでの注意事項

5.1.1　定義の体系

TP1キャッシュ機能使用時の定義は，次に示す定義で構成されます。

TP1/Server Baseのシステムサービス定義

TP1/EEサービス定義

XTCサービス定義（XTCの定義）

MCP構成定義（MCPの定義）

XDBサービス定義（XDBの定義）

TP1キャッシュ機能使用時の定義体系を次の図に示します。TP1/Server Baseのシステムサービス定義，およびTP1/EEサービス定義の体系の詳細については，マニュアル「OpenTP1システム定義」およびマニュアル「TP1/Server Base Enterprise Option 使用の手引」を参照してください。

図5-1　TP1キャッシュ機能使用時の定義体系

MCP構成定義については，マニュアル「TP1/EE/Message Control Extension 使用の手引」を参照してください。

XDBサービス定義については，マニュアル「TP1/EE/Extended Data Cache 使用の手引」を参照してください。

5.1.2　定義の構成

XTCサービス定義は，一つのファイルに定義します。TP1/EEシステムの動作する環境をTP1/EE（SPP）ごとに定義します。

XTCサービス定義の概要を次の表に示します。

表5-1　XTCサービス定義の概要

項番 | 定義名 | 内容
1 | メモリ関連定義 | 使用するメモリの関連情報を定義します。
2 | RPC関連定義 | RPC関連情報を定義します。
3 | ユーザサービス関連定義 | UAP関連情報を定義します。
4 | トラブルシュート関連定義 | トラブルシュートおよびトレース関連情報を定義します。
5 | トランザクション関連定義 | トランザクション関連情報を定義します。
6 | ステータスファイル関連定義 | ステータスファイル関連情報を定義します。
7 | サービスグループ情報関連定義 | サービスグループ関連情報を定義します。
8 | 高速メッセージ送信関連定義 | 高速メッセージ送信制御の関連情報を定義します。
9 | クラスタ連携関連定義 | CLサーバでの，クラスタ連携の関連情報を定義します。
10 | HAモニタ関連定義 | CLサーバでの，HAモニタの関連情報を定義します。
11 | 送信先サービス関連定義 | 送信先サービスの関連情報を定義します。
12 | UDPグループ情報関連定義 | UDPグループの関連情報を定義します。

5.1.3　定義の規則

XTCサービス定義を作成する場合は，テキストエディタを使用して定義ファイルを作成します。TP1/EEサービス定義と同じ定義ファイルの中に定義します。

また，XTCサービス定義の規則はTP1/EEサービス定義の規則に準じます。詳細については，マニュアル「TP1/Server Base Enterprise Option 使用の手引」を参照してください。

5.1.4　CLサーバでの注意事項

CLサーバを構成する各TP1/EEの定義は，記述順序も含めて，基本的には同じにしてください。ただし，サーバごとに異なる値の設定が必要な定義（自ホスト名など，ネットワークに関連する定義）は除きます。

また，CLサーバでは，構成するすべてのTP1/EEで異なる値を指定しなければならないオペランドがあります。詳細を次の表に示します。

表5-2　CLサーバを構成するすべてのTP1/EEで異なる値を指定しなければならないオペランド

項番 | 定義 | 異なる値を指定しなければならないオペランド
1 | TP1/EEサービス定義 | RPC関連定義 | node_idオペランド

また，CLサーバでは指定できないオペランドを次の表に示します。これらを指定すると，定義エラーとなります。

表5-3　CLサーバでは指定できないオペランド

項番
定義
指定できないオペランド

1
TP1/EEサービス定義
トランザクション関連定義
trnstringオペランド

2
XTCサービス定義
トランザクション関連定義

trn_transactional_rpcless_useオペランドにNを指定

trn_transactional_rpcless_useオペランドを省略

3
ステータスファイル関連定義

sts_fileless_useオペランドにNを指定

sts_fileless_useオペランドを省略

4
sts_fileless_levelオペランドに2を指定

5.2　TP1/EEサービス定義

TP1キャッシュ機能を使用する場合，TP1/EEサービス定義の中で指定できないオペランドや定義コマンドがあります。ここでは，TP1キャッシュ機能使用時に指定できないオペランドおよび定義コマンドについて説明します。

TP1/EEサービス定義の各オペランドおよび定義コマンドの内容については，マニュアル「TP1/Server Base Enterprise Option 使用の手引」を参照してください。

＜この節の構成＞

5.2.1　TP1キャッシュ機能使用時に指定できないTP1/EEサービス定義

5.2.2　CLサーバで指定できないTP1/EEサービス定義

5.2.3　HAサーバで指定できないTP1/EEサービス定義

5.2.1　TP1キャッシュ機能使用時に指定できないTP1/EEサービス定義

TP1キャッシュ機能使用時に指定できないTP1/EEサービス定義の一覧を次の表に示します。

表5-4　TP1キャッシュ機能使用時に指定できないTP1/EEサービス定義

項番
定義
指定できないオペランドおよび定義コマンド

1
プロセス関連定義

dbq_use

dbq_obs_use

process_kind

online_process_cnt

master_svgname

2
メモリ関連定義

dbq_recv_message_buf_cnt

dbq_send_message_buf_cnt

dbq_max_message_size

dbq_use_buf_cnt

3
RPC関連定義

ipc_sendbuf_size_dbq

ipc_recvbuf_size_dbq

ipc_backlog_count_dbq

ipc_tcpnodelay_dbq

rpc_first_connect_errmsg_dbq

rpc_firstmsg_recv_timer_dbq

rpc_nam_server_list

rpc_tcpsend_con_cnt

rpc_tcpsend_con_max_cnt

rpc_tcpsend_proc_max_cnt

4
ユーザサービス関連定義

dbq_service

dbq_obs_service

5
DBキュー機能関連定義

dbq_reqbuf_retry_timer

dbq_readcheckmsg_interval

dbq_endcheckmsg_interval

dbq_rollback_retry_count

dbqdef定義コマンド

dbqgrpdef定義コマンド

dbqsrvdef定義コマンド

dbqsvgdef定義コマンド

dbqprcdef定義コマンド

6
オンラインバッチ機能関連定義

dbq_obs_lot_no

dbq_obs_endcheckmsg_interval

dbq_obs_trn_end_api

dbqobssrvdef定義コマンド

dbqobsdef定義コマンド

dbqobslotdef定義コマンド

5.2.2　CLサーバで指定できないTP1/EEサービス定義

CLサーバで指定できないTP1/EEサービス定義の一覧を次の表に示します。

表5-5　CLサーバで指定できないTP1/EEサービス定義の一覧

項番
定義
指定できないオペランドおよび定義コマンド

1
プロセス関連定義

service_hold_watch_procdown

fil_filesystem_no

sys_dba_waittime

2
RPC関連定義

rpc_reply_suspend_recover

rpc_reply_suspend_autosend

3
トランザクション関連定義

trn_max_subordinate_count

trn_optimum_item

trn_watch_time

trn_wait_rm_open

trn_retry_interval_rm_open

trn_retry_count_rm_open

trn_retry_interval_rm_open_mime

trn_retry_count_rm_open_mime

trn_delayed_allrecover

trn_endrerun_msg_interval

trn_thd_down_count

trn_thd_down_interval

trn_unknown_rm_tran_down

trn_max_commit_count

trn_max_commit_downmode

trn_communication_tp1ee0101

trn_undelayed_recover_thread

trn_rm_open_close_scope

trnstring定義コマンド

4
ステータスファイル関連定義

sts_initial_error_switch

sts_single_operation_switch

sts_buffer_count

sts_control_buffer_length

sts_signal_buffer_length

stsflgrp定義コマンド

stsflnam定義コマンド

5
ファイルサービス関連定義

fil_watch_time

fil_watch_timeout

5.2.3　HAサーバで指定できないTP1/EEサービス定義

HAサーバで指定できないTP1/EEサービス定義の一覧を次の表に示します。

表5-6　HAサーバで指定できないTP1/EEサービス定義の一覧

項番
定義
指定できないオペランド

1
プロセス関連定義

xdb_use

5.3　XTCサービス定義

ここでは，XTCサービス定義を説明します。

＜この節の構成＞

メモリ関連定義

RPC関連定義

ユーザサービス関連定義

ユーザサービス関連定義（コマンド形式）

トラブルシュート関連定義

トランザクション関連定義

ステータスファイル関連定義

サービスグループ情報関連定義（コマンド形式）

高速メッセージ送信関連定義

クラスタ連携関連定義

HAモニタ関連定義

送信先サービス関連定義（コマンド形式）

UDPグループ情報関連定義（コマンド形式）

HAサーバで指定できないXTCサービス定義

メモリ関連定義

ここでは，メモリ関連定義の各オペランドについて説明します。

なお，メモリ関連定義のオペランドには，HAサーバで指定できないオペランドがあります。HAサーバで指定できないオペランドについては，「HAサーバで指定できないXTCサービス定義」を参照してください。

形式

〔set udp_recv_message_buf_size＝UDP用受信バッファサイズ〕
〔set udp_recv_message_buf_cnt＝UDP用受信バッファ面数〕
〔set udp_send_message_buf_size＝UDP用送信バッファサイズ〕
〔set udp_send_message_buf_cnt＝UDP用送信バッファ面数〕
　set memory_xdb_area_size＝初期化確保時のXDB用ワーク領域サイズ,追加確保時のXDB用ワーク領域サイズ
　set memory_xdb_limit_size＝確保するXDB用ワーク領域の最大サイズ
　set memory_xtc_area_size＝初期化確保時のXTC用ワーク領域サイズ,追加確保時のXTC用ワーク領域サイズ
　set memory_xtc_limit_size＝確保するXTC用ワーク領域の最大サイズ
〔set memory_mdpsys_area_size＝初期化確保時の大量処理用システム領域サイズ,追加確保時の大量処理用システム領域サイズ〕
〔set memory_mdpusr_area_size＝初期化確保時の大量処理用ユーザ領域サイズ,追加確保時の大量処理用ユーザ領域サイズ〕
〔set mem_ibf_extend_num＝受信バッファの最大拡張数〕
〔set mem_uibf_extend_num＝UDP用受信バッファの最大拡張数〕
〔set mem_obf_extend_num＝送信バッファの最大拡張数〕
〔set mem_uobf_extend_num＝UDP用送信バッファの最大拡張数〕

オペランドの説明

●udp_recv_message_buf_size＝UDP用受信バッファサイズ

　　～〈符号なし整数〉((2000～66000))《33000》（単位：バイト）

UDP用受信バッファ（UIBF）のサイズをバイト単位で指定します。

UDP用受信バッファサイズには，クライアントのUDP用送信バッファサイズ以上の値を指定することをお勧めします。

参考

UDP用受信バッファは，UDPプロトコルを使用する通信で使用します。UDPプロトコルを使用する通信を次に示します。

トランザクション同期の一方送信メッセージの受信

トランザクション非同期の一方送信メッセージの受信

CLサーバ間の通信
・定義情報の受信
・CL同期メッセージの受信（XDBの更新ログ情報を含む）
・CL同期済み通知メッセージの受信
・実行系ダウン時のリソース回復用メッセージの受信

RPCサービス要求の受信

●udp_recv_message_buf_cnt＝UDP用受信バッファ面数

　　～〈符号なし整数〉((1～2000000))《128》

UDP用受信バッファの面数を指定します。

UDP用受信バッファは，クライアントからメッセージを受信してからUAP実行前までメッセージ単位（フラグメント時は分割単位）に使用します。処理キュー登録数（メモリ関連定義のpce_noオペランドの指定値）やフラグメント発生有無を考慮して設定してください。

UDP用受信バッファ面数に最小の値を設定する場合は，次に示す計算式の値を指定してください。

処理スレッド分＋（UDP受信スレッド分×6）

（凡例）

処理スレッド分：thread_noオペランドの指定値＋reserve_thread_noオペランドの指定値＋1

UDP受信スレッド分：myudprcvdef定義コマンドとclgrpdef定義コマンドの-pオプションに設定したポート番号数

●udp_send_message_buf_size＝UDP用送信バッファサイズ

　　～〈符号なし整数〉((2000～66000))《33000》（単位：バイト）

UDP用送信バッファ（UOBF）のサイズをバイト単位で指定します。

送信メッセージサイズが送信バッファサイズより大きい場合は，分割（フラグメント）してメッセージを送信します。

参考

UDP用送信バッファは，UDPプロトコルを使用する通信で使用します。UDPプロトコルを使用する通信を次に示します。

トランザクション同期の一方送信メッセージの送信

トランザクション非同期の一方送信メッセージの送信

タイマトランザクション起動要求のメッセージ（CLサーバで，永続指定の場合だけ）

CLサーバ間の通信
・定義情報の送信
・CL同期メッセージの送信（XDB更新ログ情報を含む）
・CL同期済み通知メッセージの送信
・実行系ダウン時のリソース回復用メッセージの送信

●udp_send_message_buf_cnt＝UDP用送信バッファ面数

　　～〈符号なし整数〉((1～2000000))《128》

UDP用送信バッファの面数を指定します。

分割（フラグメント）が発生した場合は，分割した数の送信バッファを使用します。そのため，分割が発生する数を考慮して面数を設定してください。

分割が発生しない場合は，次の計算式で見積もってください。

（システム内で同時に発行する，UDPプロトコルを使用する通信の要求数
　＋システム内で同時に起動するトランザクションブランチ数）
　×1.5（安全率）

システム内で同時に起動するトランザクションブランチ数は，RPC関連定義のrpc_replymsg_saveオペランドにYを指定する場合に必要です。

●memory_xdb_area_size＝初期化確保時のXDB用ワーク領域サイズ,追加確保時のXDB用ワーク領域サイズ

　　～〈符号なし整数〉((1～1048576))（単位：キロバイト）

XDB用ワーク領域（XDBPOOL）の初期化確保時および追加確保時のサイズをキロバイト単位で指定します。

オペランドの第1指定値には，初期化時に確保するXDB用ワーク領域のサイズを指定します。第2指定値には，追加確保時に確保するXDB用ワーク領域のサイズを指定します。

注意

CLサーバ（クラスタ連携関連定義のcluster_modeオペランドにYを指定）の場合，次に示すオペランドのどちらか一方でも指定していると，このオペランドで指定して追加確保したXDB用ワーク領域のうち未使用になった領域を解放します。

memory_mdpsys_area_sizeオペランド

memory_mdpusr_area_sizeオペランド

なお，プールサイズが小さいと，XDB用ワーク領域が解放されないおそれがあります（OSの仕様）。そのため，memory_xdb_area_sizeオペランドの第2指定値には，MMAP_THRESHOLDの値以上を設定してください。

実際のメモリ要求などで追加確保されるワーク領域のサイズは，指定値と一致しないことがあります。

xdb_useオペランドにYを指定した場合は，このオペランドは省略できません。必ず，オペランドの第1指定値と第2指定値の両方を指定してください。

XDB用ワーク領域を求める計算式については，マニュアル「TP1/EE/Extended Data Cache 使用の手引」を参照してください。

●memory_xdb_limit_size＝確保するXDB用ワーク領域の最大サイズ

　　～〈符号なし整数〉((1～104857600))（単位：キロバイト）

memory_xdb_area_sizeオペランドの指定によって確保するXDB用ワーク領域の最大サイズを指定します。

memory_xdb_area_sizeオペランドの第1指定値（初期化確保時のXDB用ワーク領域サイズ）より小さな値を指定した場合，追加確保は行いません。

xdb_useオペランドにYを指定した場合は，このオペランドは省略できません。必ず指定してください。

●memory_xtc_area_size＝初期化確保時のXTC用ワーク領域サイズ,追加確保時のXTC用ワーク領域サイズ

　　～〈符号なし整数〉((1～1048576))（単位：キロバイト）

XTC用ワーク領域（XTCPOOL）の初期化確保時および追加確保時のサイズをキロバイト単位で指定します。

オペランドの第1指定値には，初期化時に確保するXTC用ワーク領域のサイズを指定します。第2指定値には，追加確保時に確保するXTC用ワーク領域のサイズを指定します。

注意

CLサーバ（クラスタ連携関連定義のcluster_modeオペランドにYを指定）の場合，次に示すオペランドのどちらか一方でも指定していると，このオペランドで指定して追加確保したXTC用ワーク領域のうち未使用になった領域を解放します。

memory_mdpsys_area_sizeオペランド

memory_mdpusr_area_sizeオペランド

なお，プールサイズが小さいと，XTC用ワーク領域が解放されないおそれがあります（OSの仕様）。そのため，memory_xtc_area_sizeオペランドの第2指定値には，MMAP_THRESHOLDの値以上を設定してください。

実際のメモリ要求などで追加確保されるワーク領域のサイズは，指定値と一致しないことがあります。

XTC用ワーク領域は，次のオペランドで指定するバッファおよびシステム用バッファの予備領域としても使用します。

pce_noオペランド

icb_noオペランド

time_message_noオペランド

recv_message_buf_cntオペランド

send_message_buf_cntオペランド

dbq_recv_message_buf_cntオペランド

dbq_send_message_buf_cntオペランド

dbq_use_buf_cntオペランド

udp_recv_message_buf_cntオペランド

udp_send_message_buf_cntオペランド

このオペランドは省略できません。必ず，オペランドの第1指定値と第2指定値の両方を指定してください。

XTC用ワーク領域を求める計算式については，リリースノートを参照してください。

●memory_xtc_limit_size＝確保するXTC用ワーク領域の最大サイズ

　　～〈符号なし整数〉((1～104857600))（単位：キロバイト）

memory_xtc_area_sizeオペランドの指定によって確保するXTC用ワーク領域の最大サイズを指定します。

memory_xtc_area_sizeオペランドの第1指定値（初期化確保時のXTC用ワーク領域サイズ）より小さな値を指定した場合，追加確保は行いません。

このオペランドは省略できません。必ず指定してください。

●memory_mdpsys_area_size＝初期化確保時の大量処理用システム領域サイズ,追加確保時の大量処理用システム領域サイズ

　　～〈符号なし整数〉((1～1048576))（単位：キロバイト）

大量処理用システム領域（MPSPOOL）を使用する場合，初期化確保時および追加確保時のサイズをキロバイト単位で指定します。

オペランドの第1指定値には，初期化時に確保する大量処理用システム領域のサイズを指定します。第2指定値には，追加確保時に確保する大量処理用システム領域のサイズを指定します。このオペランドを指定する場合は，第1指定値と第2指定値の両方を指定してください。

このオペランドを指定すると，XTCワーク領域およびXDBワーク領域の動作が次のとおり変更になります。

追加確保した領域については，使用中のセグメントが存在しなくなった時点で，オンライン中に該当する領域をOSに解放（free関数を発行）します。

CLサーバ（クラスタ連携関連定義のcluster_modeオペランドにYを指定）の場合，待機系ではmemory_xtc_limit_sizeオペランドおよびmemory_xdb_limit_sizeオペランドの設定値が無効になります。なお，設定値を超えるセグメント要求があった場合，設定値を無視して領域を追加確保（malloc関数を発行）します。

注意

プールサイズが小さいと，大量処理用システム領域が解放されないおそれがあります（OSの仕様）。第1指定値と第2指定値にはMMAP_THRESHOLDの値以上を設定してください。

実際のメモリ要求などで追加確保される大量処理用システム領域のサイズは，指定値と一致しないことがあります。

このオペランドを省略すると，大量処理用システム領域を使用しません。

●memory_mdpusr_area_size＝初期化確保時の大量処理用ユーザ領域サイズ,追加確保時の大量処理用ユーザ領域サイズ

　　～〈符号なし整数〉((1～1048576))（単位：キロバイト）

大量処理用ユーザ領域（MPUPOOL）を使用する場合，初期化確保時および追加確保時のサイズをキロバイト単位で指定します。

オペランドの第1指定値には，初期化時に確保する大量処理用ユーザ領域のサイズを指定します。第2指定値には，追加確保時に確保する大量処理用ユーザ領域のサイズを指定します。このオペランドを指定する場合は，第1指定値と第2指定値の両方を指定してください。

このオペランドを指定すると，XTCワーク領域およびXDBワーク領域の動作が次のとおり変更になります。

追加確保した領域については，使用中のセグメントが存在しなくなった時点で，オンライン中に該当する領域をOSに解放（free関数を発行）します。

CLサーバ（クラスタ連携関連定義のcluster_modeオペランドにYを指定）の場合，待機系ではmemory_xtc_limit_sizeオペランドおよびmemory_xdb_limit_sizeオペランドの設定値が無効になります。なお，設定値を超えるセグメント要求があった場合，設定値を無視して領域を追加確保（malloc関数を発行）します。

注意

プールサイズが小さいと，大量処理用ユーザ領域が解放されないおそれがあります（OSの仕様）。第1指定値と第2指定値にはMMAP_THRESHOLDの値以上を設定してください。

実際のメモリ要求などで追加確保される大量処理用ユーザ領域のサイズは，指定値と一致しないことがあります。

このオペランドを省略すると，大量処理用ユーザ領域を使用しません。

●mem_ibf_extend_num＝受信バッファの最大拡張数

　　～〈符号なし整数〉((0～2147483647))《2147483647》

受信バッファ（IBF）が不足した場合に拡張する面数の上限を指定します。

このオペランドを指定した場合に利用できるバッファの最大数を次に示します。

recv_message_buf_cntオペランドで指定した初期確保数
＋mem_ibf_extend_numの指定値

ただし，この値が2147483647を超えても，バッファの最大数の上限は2147483647です。0を指定した場合はバッファを拡張しません。

なお，このオペランドで指定した面数を超えなくても，XTC用ワーク領域の最大サイズを超えたときは拡張できません。

●mem_uibf_extend_num＝UDP用受信バッファの最大拡張数

　　～〈符号なし整数〉((0～2147483647))《2147483647》

UDP用受信バッファ（UIBF）が不足した場合に拡張する面数の上限を指定します。

このオペランドを指定した場合に利用できるバッファの最大数を次に示します。

udp_recv_message_buf_cntオペランドで指定した初期確保数
＋mem_uibf_extend_numの指定値

ただし，この値が2147483647を超えても，バッファの最大数の上限は2147483647です。0を指定した場合はバッファを拡張しません。

なお，このオペランドで指定した面数を超えなくても，XTC用ワーク領域の最大サイズを超えたときは拡張できません。

●mem_obf_extend_num＝送信バッファの最大拡張数

　　～〈符号なし整数〉((0～2147483647))《2147483647》

送信バッファ（OBF）が不足した場合に拡張する面数の上限を指定します。

このオペランドを指定した場合に利用できるバッファの最大数を次に示します。

send_message_buf_cntオペランドで指定した初期確保数
＋mem_obf_extend_numの指定値

ただし，この値が2147483647を超えても，バッファの最大数の上限は2147483647です。0を指定した場合はバッファを拡張しません。

なお，このオペランドで指定した面数を超えなくても，XTC用ワーク領域の最大サイズを超えたときは拡張できません。

●mem_uobf_extend_num＝UDP用送信バッファの最大拡張数

　　～〈符号なし整数〉((0～2147483647))《2147483647》

UDP用送信バッファ（UOBF）が不足した場合に拡張する面数の上限を指定します。

このオペランドを指定した場合に利用できるバッファの最大数を次に示します。

udp_send_message_buf_cntオペランドで指定した初期確保数
＋mem_uobf_extend_numの指定値

ただし，この値が2147483647を超えても，バッファの最大数の上限は2147483647です。0を指定した場合はバッファを拡張しません。

なお，このオペランドで指定した面数を超えなくても，XTC用ワーク領域の最大サイズを超えたときは拡張できません。

RPC関連定義

ここでは，RPC関連定義の各オペランドについて説明します。

形式

〔set rpc_udp_packet_size＝パケットサイズ〕
〔set rpc_udp_congestion_packet_count＝パケット数〕
〔set rpc_udp_departure_limit＝UDP通信を行うスレッド数の合計〕
〔set rpc_udp_linetrace＝回線トレース情報の取得量の変更〕
〔set rpc_tcp_communication_use＝｛Y｜N｝〕
〔set rpc_udp_lmsg_deliverychk_size＝複数メッセージの一括送受信機能を使用した場合の送達確認サイズ〕
〔set rpc_udp_msg_deliverychk_size＝送達確認サイズ〕
〔set rpc_recv_permanence＝｛Y｜N｝〕

オペランドの説明

●rpc_udp_packet_size＝パケットサイズ

　　～〈符号なし整数〉((1452～16000))《1472》（単位：バイト）

UDP通信機能の通信単位であるパケットのサイズをバイト単位で指定します。このオペランドの指定値は，UDP通信を行うXTC間で同じ値を指定します。一致しない場合は，通信に失敗します。

このオペランドの指定値には，次に示す値を指定することお勧めします。次に示す値以外を指定した場合は，IP層でのフラグメント化の多発によるパケット数増加によって，性能が低下するおそれがあります。

MTUサイズ－28

UDP通信を行うXTC間でMTUサイズが異なる場合は，最も小さいMTUサイズに合わせます。MTUサイズの取得方法はOSによって異なります。詳細については，OSのマニュアルを参照してください。

なお，ジャンボフレームを使用できる環境では，ジャンボフレームの使用をお勧めします。ジャンボフレームを使用した場合，パケットサイズの拡張によって通信量が減少し，通信性能が向上します。

ただし，hbondingドライバによってW-send機能を使用する場合は，hbondingドライバの仕様上，推奨値を超える値は指定しないでください。指定した場合の動作は保証しません。

なお，UDP受信バッファ（UIBF）のサイズを超える値を指定した場合，XTCの起動に失敗します。

●rpc_udp_congestion_packet_count＝パケット数

　　～〈符号なし整数〉((0，100～16000))《1000》

輻輳制御の開始，終了の判断に使用するための監視対象パケット数を指定します。このオペランドに0を指定した場合は監視しません。

パケット送信時には，監視対象パケット数分の送信履歴を残します。再送パケット比率は，監視対象パケット数と再送パケット数を基に算出します。この再送パケット比率と，パケットロス上限およびパケットロス下限を比較することで，輻輳制御の開始，終了を判断します。パケットロス上限およびパケットロス下限については，UDPグループ情報関連定義のmyudpsnddef定義コマンドで指定します。

監視対象パケット数が少ない場合は，輻輳の検出が速くなります。しかし，瞬間的なパケットロスを輻輳として判断する場合があります。また，監視対象パケット数が多い場合は輻輳の検出が遅くなります。

輻輳制御の詳細については，「2.4.2　輻輳制御」を参照してください。

●rpc_udp_departure_limit＝UDP通信を行うスレッド数の合計

　　～〈符号なし整数〉((100～10000))《200》

自XTCとUDP通信を行う，すべての相手プロセスのスレッド数の合計値を指定します。

自プロセスに対して送信を行う場合は，自プロセスのスレッド数も加算する必要があります。ただし，ee_mch_cmtsend関数，またはee_mch_cmtsend_sync関数のメッセージ送信形態にEEMCH_MYPROCを指定して送信する場合は，自プロセスのスレッド数を加算する必要はありません。

すべての相手プロセスのスレッド数が，このオペランドの指定値を超えた場合は，通信が失敗します。

●rpc_udp_linetrace＝回線トレース情報の取得量の変更

　　～〈16進数〉((00000000～00000007｜00000020～00000023))《00000000》

UDP通信機能の回線トレース情報の取得量を変更する場合，変更する項目を論理和で指定します。指定値の組み合わせについては，「6.3.1(1)(c)　rpc_udp_linetraceオペランドの指定値の組み合わせ」を参照してください。

00000000：

すべての回線トレース情報を取得します。

00000001：

W-send機能や再送などによって重複して受信したパケットについて，回線トレース情報を取得しません。

00000002：

次のすべての条件を満たす場合に，回線トレース情報を取得しません。

myudpsnddef定義コマンドの-kオプションを指定している

クラスタ内でのマルチキャストによって自TP1/EEが送信したメッセージを，自TP1/EEで受信した

00000004：

メッセージが複数のパケットに分割されている場合，先頭パケットはUDP通信制御ヘッダおよびデータ部分を最大374バイト取得します。残りのパケットはUDP通信制御ヘッダだけを取得します。

00000020：

送受信が正常に行われた場合は，送受信データの先頭にある製品ヘッダを回線トレース情報として取得します。送受信データが複数のパケットに分割されている場合は，先頭パケットだけが製品ヘッダを取得します。残りのパケットは，製品ヘッダのうちUDP通信制御ヘッダだけを取得します。

●rpc_tcp_communication_use＝｛Y｜N｝

　　～《Y》

RPC通信で，TCP/IPプロトコルを使用するかどうかを指定します。

Y：

RPC通信で，TCP/IPプロトコルを使用します。

N：

RPC通信で，TCP/IPプロトコルを使用しません。

次の条件をすべて満たしている場合にだけ，このオペランドにNを指定できます。

xtc_use＝Y

name_use＝N

trn_transactional_rpcless_use＝Y

このオペランドにNを指定した場合でも，ee_rpc_call関数とee_rpc_cmtsend関数の自プロセス送信（通信レス）によるRPC要求はできます。ただし，RPC要求先のサービスで，RPC応答のトランザクションまたがり送信機能，およびERRTRNRによるRPC応答メッセージ送信機能を使用することはできません。

このオペランドにNを指定した場合は，次の表に示す定義コマンドおよびオペランドの省略時解釈値または指定値が変更されます。

サービスグループ情報関連定義のmysvgdef定義コマンドおよびmyreplydef定義コマンドは省略できません。しかし，このオペランドにNを指定した場合は省略できます。

表5-7　rpc_tcp_communication_useオペランドにNを指定した場合の省略時解釈値または指定値の変化

定義コマンド名，またはオペランド名 | Y指定時の省略時解釈値 | N指定時の省略時解釈値 | 指定値
mysvgdef | なし | なし | 無視されます。
myreplydef | なし | なし
rpc_reply_con_cnt | 2 | 0
rpc_reply_con_max_cnt | 256 | 0
rpc_reply_proc_max_cnt | 128 | 0
rpc_reply_suspend_cnt | 128 | 0
rpc_reply_suspend_time | 180 | 0
rpc_reply_suspend_recover | Y | N
rpc_reply_suspend_autosend | N | N
rpc_reply_errtrnr | N | N
rpc_reply_errtrnr_cnt | 128 | 0
rpc_reply_port_auto | N | N

●rpc_udp_lmsg_deliverychk_size＝複数メッセージの一括送受信機能を使用した場合の送達確認サイズ

　　～〈符号なし整数〉((1452～9437184))《524288》（単位：バイト）

複数メッセージの一括送受信機能を使用する場合に，送達確認を行うサイズをバイト単位で指定します。

複数メッセージの一括送受信機能については，「2.4.3　複数メッセージの一括送受信機能」を参照してください。

このオペランドの指定値が小さい場合，送達確認が多発し，通信遅延の原因になります。このオペランドの指定値が大きい場合，パケットロスなどによる通信障害時に，再送による通信量が増加します。そのため，パケットロス頻度が高い（ネットワーク性能やマシン性能が低い）構成では，このオペランドの指定値を小さくし，パケットロス頻度の低い（ネットワーク性能やマシン性能が高い）構成では，このオペランドの指定値を大きくすることをお勧めします。

複数メッセージの一括送受信は，次の場合に行います。

CLサーバでCL同期メッセージの送受信をする場合

高速メッセージ送信関連定義のmch_send_lump_countオペランドに2以上を指定し，一方送信メッセージを送受信する場合

なお，CL同期メッセージの送受信だけで使用するソケットの場合に，ユーザデータのサイズがこのオペランドの指定値以上になるときは，このオペランドの指定値はユーザデータのサイズになります。

●rpc_udp_msg_deliverychk_size＝送達確認サイズ

　　～〈符号なし整数〉((1452～9437184))《2097152》（単位：バイト）

メッセージ送受信時の，送達確認を行うサイズをバイト単位で指定します。

このオペランドの指定値が小さい場合，送達確認が多発し，通信遅延の原因になります。このオペランドの指定値が大きい場合，パケットロスなどによる通信障害時に，再送による通信量が増加します。そのため，パケットロス頻度が高い（ネットワーク性能やマシン性能が低い）構成では，このオペランドの指定値を小さくし，パケットロス頻度の低い（ネットワーク性能やマシン性能が高い）構成では，このオペランドの指定値を大きくすることをお勧めします。

なお，複数メッセージの一括送受信時には，rpc_udp_lmsg_deliverychk_sizeオペランドで指定した値が使用されます。また，CL同期メッセージ以外の送受信に使用するソケットの場合に，ユーザデータのサイズがこのオペランドの指定値以上になるときは，このオペランド指定値はユーザデータのサイズになります。

●rpc_recv_permanence＝｛Y｜N｝

　　～《N》

クラスタを構成する実行系と待機系の間で，RPC要求の受信メッセージを永続化するかどうかを指定します。

このオペランドは，クラスタ連携関連定義のcluster_modeオペランドにYを指定している場合だけ有効です。

Y：

RPC要求の受信メッセージを永続化します。

N：

RPC要求の受信メッセージを永続化しません。

ユーザサービス関連定義

ここでは，ユーザサービス関連定義の各オペランドについて説明します。

なお，ユーザサービス関連定義のオペランドには，HAサーバで指定できないオペランドがあります。HAサーバで指定できないオペランドについては，「HAサーバで指定できないXTCサービス定義」を参照してください。

形式

〔set event_trn＝サービス名〕
〔set system_start_ui＝実行系連絡トランザクションを起動するエントリポインタ名〕
〔set scd_rollback_retry_mode＝｛H｜P｝〕
〔set errtrn_serialize＝｛Y｜N｝〕

オペランドの説明

●event_trn＝サービス名

　　～〈1～31文字の識別子〉

イベント通知トランザクション（MV）を起動するサービス名を指定します。ユーザサービス関連定義のserviceオペランドで指定したサービス名を指定してください。

イベント通知トランザクションはserviceオペランドに指定したサービスに登録しますが，該当するサービスが閉塞中であってもserviceオペランドに指定したエントリポインタを起動します。イベント通知トランザクションのエラートランザクションは起動しません。なお，サービス閉塞による処理キュー引き出し禁止となっている場合（ユーザサービス関連定義のforbid_draw_serviceオペランドにYを指定している場合）は，引き出し禁止が解除されるまでイベント通知トランザクションを起動しません。

なお，このオペランドを省略した場合は，イベント通知トランザクションを起動しません。

●system_start_ui＝実行系連絡トランザクションを起動するエントリポインタ名

　　～〈1～31文字の識別子〉

実行系連絡トランザクション（UI）を起動するエントリポインタ名を指定します。

このオペランドで指定したエントリポインタ名は，ほかのオペランドで指定したエントリポインタ名と同じものでもかまいません。ユーザサービス関連定義のserviceオペランドで指定したエントリポインタ名を指定してください。

なお，このオペランドを省略した場合は，実行系連絡トランザクションを起動しません。

●scd_rollback_retry_mode＝｛H｜P｝

　　～《H》

ユーザサービス関連定義のservice_attr定義コマンドの-fオプションに指定した，連続ロールバック監視回数を超えた場合の動作を指定します。

H：

サービス閉塞します。

P：

プロセスダウンします。

●errtrn_serialize＝｛Y｜N｝

　　～《Y》

ERRTRNR，ERRTRN3を起動する障害発生時の端末キュー，処理キューから次のメッセージを引き出す契機を，ERRTRN3/ERRTRNR終了後か，ERRTRN3/ERRTRNRの終了とは非同期かを指定します。

Y：

ERRTRNR，ERRTRN3が終了してから端末キュー，処理キューから次のメッセージを引き出します。

N：

ERRTRNR，ERRTRN3の終了とは非同期に，障害が発生したトランザクション決着時に端末キュー，処理キューから次のメッセージを引き出します。

このオペランドには，省略，またはYを指定することを推奨します。

このオペランドを指定できるのは，TP1/EEのバージョンが次の場合です。

07-7xの場合，07-73以降

07-8xの場合，07-81以降

TP1/EEのバージョンがこのオペランドを指定できないバージョンの場合は，このオペランドにNを指定した場合の動作をします。

ユーザサービス関連定義（コマンド形式）

ここでは，ユーザサービス関連定義（コマンド形式）の各定義コマンドについて説明します。

service_attr（サービス属性定義）

TP1/EEの定義コマンドです。

ここでは，TP1キャッシュ機能使用時に使用できるオプションを示します。そのほかのオプションについては，マニュアル「TP1/Server Base Enterprise Option 使用の手引」を参照してください。

機能

set形式のユーザサービス関連定義で定義した各サービスの付加情報を定義します。

TP1キャッシュ機能使用時の各オプションに対応した機能の詳細は，「2.6　処理キューの制御」を参照してください。

コマンドの形式

｛｛service_attr 〔-e ｛parallel｜serial｝〕
                〔-f 連続ロールバックリトライ監視回数〕
                〔-g ｛Y｜N｝〕
｝｝

オプションの説明

●-e ｛parallel｜serial｝

～《parallel》

メッセージの同時引き出しの可否を指定します。

parallel：

同時引き出しできます。

serial：

同時引き出しできません。

serialを指定した場合は，ユーザサービス関連定義のserviceオペランドの同時処理限界数に1を指定するか，または同時処理限界数を指定しないでください。

-eオプションは，-vオプションを指定した場合に指定できます。-xオプションを指定した場合は指定できません。

●-f 連続ロールバックリトライ監視回数

～〈符号なし整数〉((0～10))《5》

サービスの同時引き出しができないサービスで，同じメッセージを読み出すトランザクションがロールバックリトライする回数の上限を指定します。監視回数を超えてロールバックリトライした場合，ユーザサービス関連定義のscd_rollback_retry_modeオペランドの指定に従って処理します。0を指定した場合は，ロールバックリトライ回数を監視しません。

-fオプションは，-eオプションにserialを指定した場合にだけ指定できます。

●-g ｛Y｜N｝

～《Y》

入力キュー（ITQ）の連鎖モード連携機能を使用するかを指定します。

Y：

連鎖モード連携機能を使用します。

ee_trn_chained_commit関数，またはee_trn_chained_rollback関数（thkindにEETRN_KEEPを設定）による同期点取得時に読み出したメッセージを読み出し済みにするか，またはロールバックリトライします。これらの関数が実行されなかった場合は，サービス関数実行終了時にメッセージを読み出し済みにするか，またはロールバックリトライします。

N：

連鎖モード連携機能を使用しません。

サービス関数実行終了時にメッセージを読み出し済みにするか，またはロールバックリトライします。

-gオプションは，-vオプションを指定した場合に指定できます。-xオプションを指定した場合は指定できません。

uoc_func（ユーザオウンコーディング定義）

機能

ユーザオウンコーディングのエントリポインタ名を指定します。

コマンドの形式

〔uoc_func -s オンライン開始UOCエントリポインタ名〕

オプションの説明

●-s オンライン開始UOCエントリポインタ名

～〈1～31文字の識別子〉

オンライン開始UOCのエントリポインタ名を指定します。

省略した場合，オンライン開始UOCを呼び出しません。

トラブルシュート関連定義

ここでは，トラブルシュート関連定義の各オペランドについて説明します。

なお，トラブルシュート関連定義のオペランドには，HAサーバで指定できないオペランドがあります。HAサーバで指定できないオペランドについては，「HAサーバで指定できないXTCサービス定義」を参照してください。

形式

〔set trb_quedump_wtor_interval_time＝eetrbwtorコマンド実行待ちメッセージ出力間隔〕
〔set trb_quedump_io_watch_time＝キューダンプファイルのI/O処理監視時間〕
〔set trb_quedump_io_watch_msg_time＝キューダンプファイルのI/O処理監視メッセージ出力最小間隔〕
〔set trb_pcerefer_output_time＝eepcereferコマンドのファイル出力監視時間〕

オペランドの説明

●trb_quedump_wtor_interval_time＝eetrbwtorコマンド実行待ちメッセージ出力間隔

　　～〈符号なし整数〉((0～60))《5》（単位：分）

キューダンプファイルの出力障害によってeetrbwtorコマンドの実行待ちとなっている間に，KFSB85802-Qメッセージを出力する間隔を分単位で指定します。

0を指定した場合，キューダンプファイルの出力障害発生時に一度だけKFSB85802-Qメッセージを出力します。

●trb_quedump_io_watch_time＝キューダンプファイルのI/O処理監視時間

　　～〈符号なし整数〉((0～3600))《10》（単位：秒）

キューダンプファイルのI/O処理1回当たりの監視時間を秒単位で指定します。

0以外を指定した場合は，キューダンプファイルのI/O処理1回当たりの時間が指定値を超えたときにKFSB55412-Eメッセージを出力します。トランザクションタイマの監視時間には，キューダンプファイルのI/O処理時間を含みません。

0を指定した場合は，キューダンプファイルのI/O処理を監視しません。

●trb_quedump_io_watch_msg_time＝キューダンプファイルのI/O処理監視メッセージ出力最小間隔

　　～〈符号なし整数〉((10～36000))《trb_quedump_io_watch_time×10》（単位：秒）

I/O処理1回当たりの時間がtrb_quedump_io_watch_timeオペランドの指定値を超えた場合に，KFSB55412-Eメッセージを出力する最小間隔を秒単位で指定します。最後にKFSB55412-Eメッセージを出力した時刻からこのオペランドの指定値を経過していない場合は，KFSB55412-Eメッセージを出力しません。

●trb_pcerefer_output_time＝eepcereferコマンドのファイル出力監視時間

　　～〈符号なし整数〉((0～65535))《60》（単位：秒）

eepcereferコマンドの出力処理の監視時間を秒単位で指定します。指定時間を超えた場合は，TP1/EEプロセスは異常終了します。0を指定した場合は監視しません。

トランザクション関連定義

ここでは，トランザクション関連定義の各オペランドについて説明します。

なお，トランザクション関連定義のオペランドには，HAサーバで指定できないオペランドがあります。HAサーバで指定できないオペランドについては，「HAサーバで指定できないXTCサービス定義」を参照してください。

形式

〔set trn_transactional_rpcless_use＝｛Y｜N｝〕
〔set trn_expiration_time_ui＝実行系連絡トランザクション（UI）処理監視時間〕
〔set trn_expiration_time_mv＝イベント通知トランザクション（MV）処理監視時間〕
〔set trn_cl_rpc_reply_timing＝｛Y｜N｝〕

オペランドの説明

●trn_transactional_rpcless_use＝｛Y｜N｝

　　～《N》

トランザクショナルRPCの実行を抑止するかどうかを指定します。トランザクショナルRPCの抑止については，「2.5.3　トランザクショナルRPCの抑止（CLサーバ）」を参照してください。

Y：

トランザクショナルRPCの実行を抑止します。

N：

トランザクショナルRPCの実行を抑止しません。

●trn_expiration_time_ui＝実行系連絡トランザクション（UI）処理監視時間

　　～〈符号なし整数〉((0～65535))《trn_expiration_timeオペランドの指定値》（単位：秒）

実行系連絡トランザクション（UI）でのトランザクション処理の監視時間を秒単位で指定します。

監視時間が指定値を超えた場合は，プロセス関連定義のuapabend_downmodeオペランドの指定に従って異常終了します。

このオペランドに0を指定した場合は，時間監視しません。

このオペランドを省略した場合は，トランザクション関連定義のtrn_expiration_timeオペランドの指定値を省略時解釈値とします。

●trn_expiration_time_mv＝イベント通知トランザクション（MV）処理監視時間

　　～〈符号なし整数〉((0～65535))《trn_expiration_timeオペランドの指定値》（単位：秒）

イベント通知トランザクション（MV）でのトランザクション処理の監視時間を秒単位で指定します。

監視時間が指定値を超えた場合は，プロセス関連定義のuapabend_downmodeオペランドの指定に従って異常終了します。

このオペランドに0を指定した場合は，時間監視しません。

このオペランドを省略した場合は，トランザクション関連定義のtrn_expiration_timeオペランドの指定値を省略時解釈値とします。

●trn_cl_rpc_reply_timing＝｛Y｜N｝

　　～《N》

TP1/EE/XTCのCLサーバで，RPC応答の送信タイミング変更機能を使用するかどうかを指定します。

この機能を使用した場合，RPCのレスポンスタイムが落ちます。RPC応答メッセージに転送処理の結果を反映したいときだけ使用してください。

このオペランドは，次の条件を満たした場合だけ有効です。

cluster_modeオペランドにYを指定している

clgrpdef定義コマンドでクラスタグループ内のノード情報を2個以上指定している

cluster_test_modeオペランドにYを指定していない

Y：

RPC応答の送信タイミング変更機能を使用します。

RPC応答の送信は，転送処理によってリソースの永続化が完了したあとに行います。

転送処理によるリソースの永続化に失敗したときは，RPCエラー応答を送信します。

N：

RPC応答の送信タイミング変更機能を使用しません。

ステータスファイル関連定義

ここでは，ステータスファイル関連定義の各オペランドについて説明します。

形式

〔set sts_fileless_use＝｛Y｜N｝〕
〔set sts_fileless_level＝｛1｜2｝〕

オペランドの説明

●sts_fileless_use＝｛Y｜N｝

　　～《N》

ステータスファイルレス機能を使用するかどうかを指定します。ステータスファイルレス機能については，「2.7　ステータスファイルレス機能」を参照してください。

Y：

ステータスファイルレス機能を使用します。

N：

ステータスファイルレス機能を使用しません。

XAインタフェースによるトランザクションを実行する場合，またはトランザクショナルRPCを使用する場合，Yは指定できません。

●sts_fileless_level＝｛1｜2｝

　　～《1》

ステータスファイルレス機能使用時，システム制御情報の取得レベルを指定します。sts_fileless_levelオペランドは，sts_fileless_useオペランドにYを指定している場合にだけ有効です。

1：

全体レスとなります（すべてのシステム制御情報を取得しません）。CLサーバの場合に，必ず指定してください。

1を指定した場合，ステータスファイル自体を使用しません。ほかのステータスファイル関連定義を指定しても無効になります。

2：

部分レスとなります（トランザクションに関連するシステム制御情報を取得しません）。HAサーバの場合に，任意で指定してください。

2を指定した場合，ステータスファイルは使用します。ステータスファイル関連定義の必須定義は指定してください。

サービスグループ情報関連定義（コマンド形式）

ここでは，サービスグループ情報関連定義（コマンド形式）の各定義コマンドについて説明します。

eesvgdef（相手サービスグループ情報定義）

機能

通信相手となるサービスグループの情報，および通信方法を指定します。

コマンドの形式

通信方法によって，指定できるオプションが異なります。通信方法の指定を次に示します。

通信方法がRPC，DBQ，またはRAPの場合

｛｛eesvgdef -g サービスグループ名
            -h ホスト名:ポート番号〔,ホスト名:ポート番号〕…
          〔-s ソケット数〕
          〔-a〕
          〔-t ｛RPC｜DBQ｜RAP｝〕
｝｝

通信方法がUDPの場合

｛｛eesvgdef -g サービスグループ名
            -u あて先UDPグループ名
            -t UDP
｝｝

オプションの説明

●-g サービスグループ名

～〈1～31文字の識別子〉

サービス要求を行うサービスグループ名を指定します。

●-h ホスト名：ポート番号

-tオプションにUDP以外を指定した場合，サービス要求先のホスト名およびポート番号を指定します。

ホスト名
～〈1～255文字のホスト名〉
サービス要求を行うホスト名を指定します。-tオプションにRAPを指定した場合は，リモートAPI機能によるサービスの受信口となるホスト名を指定してください。
ホスト名は，/etc/hostsファイルまたはDNSなどで，IPアドレスとのマッピングができなければなりません。

ポート番号
～〈符号なし整数〉((1～65535))
サービス要求を行うホストのポート番号を指定します。相手ホストがTP1/Server Baseの場合は，スケジュールサービスのポート番号を指定してください。-tオプションにRAPを指定した場合は，リモートAPI機能によるサービスの受信口となるポート番号を指定してください。

TP1/EEからTP1/Server Base管理下のSPPのサービスを利用する場合，そのSPPのサービスグループ名とそのSPPが存在するノードのホスト名，およびスケジュールサービス定義のscd_portオペランドに指定したポート番号を指定します。リモートAPI機能を使用して通信する場合（-tオプションにRAPを指定する場合）は，リモートAPI機能によるサービスの受信口のホスト名とポート番号を指定します。

TP1/EEからTP1/EEのサービスを利用する場合，自サービスグループ情報定義のmysvgdef定義コマンドで指定したホスト名とポート番号を指定します。

-hオプションには，複数のホスト名およびポート番号を指定することもできます。ただし，リモートAPI機能を使用して通信する場合（-tオプションにRAPを指定する場合）は，複数のホスト名およびポート番号は指定できません。

●-u あて先UDPグループ名

～〈1～31文字の識別子〉

-tオプションにUDPを指定した場合に，サービス要求先のあて先UDPグループ名を指定します。

UDPプロトコルを使用して通信する場合（-tオプションにUDPを指定する場合）は，サービス要求先を定義しているeeudpdef定義コマンドのあて先UDPグループ名を指定します。

●-s ソケット数

～〈符号なし整数〉((1～32))《1》

接続する最大ソケット数をホスト単位に指定します。複数スレッドから同一サービスグループ名で送信要求を行う場合，サービスグループ下のソケット数の合計は，処理スレッド数＋1より大きくなるように指定することをお勧めします。

TP1/Server Baseに対するサービス要求を行う場合は，TP1/Server Baseのスケジュールサービス定義のmax_socket_descriptorsオペランドで指定するソケット数を追加してください。

ネームサービス機能を使用して，-tオプションにRPCを指定するか，または指定を省略した場合，このオプションは無視されます。

また，-tオプションにRAPまたはUDPを指定した場合も，このオプションは無視されます。

●-a

TP1/EEプロセス起動時に，相手ホストとコネクションを自動確立するときに指定します。相手ホストがTP1/Server Base管理下のSPPの場合，または相手ホストがコネクションを確立してから最初のメッセージを受信するまで時間監視している場合は，このオプションを指定しないでください。ネームサービス機能を使用して，-tオプションにRPCを指定するか，または指定を省略した場合，このオプションは無視されます。

また，-tオプションにRAPまたはUDPを指定した場合も，このオプションは無視されます。

●-t ｛RPC｜DBQ｜RAP｜UDP｝

～《RPC》

該当するホストで使用する通信方法を指定します。

RPC：

RPC通信を使用します。DBキュー機能で使用するホストの場合，DBキューを使用したシステム間通信をRPC通信によって行います。また，DBキュー機能で使用するホストの場合，RPC関連定義のname_useオペランドの指定に関係なく，ネームサービス機能は使用しません。

DBQ：

DBキューを使用したシステム間通信をTCP/IPプロトコルによって行います。

DBQを指定する場合は，UDPグループ情報関連定義のmysvgdef定義コマンドの-tオプションでDBQを指定して，DBキューのイベント通知用のポートとホスト名の組み合わせを最低一つ指定する必要があります。ただし，接続先がTP1/EE 01-01の場合は，-tオプションを設定しないでください。

RAP：

リモートAPI機能を使用して通信します。このオプションを指定すると，-hオプションで指定した値は，リモートAPI機能によるサービスの受信口の情報となります。

UDP：

高速メッセージ送信制御によって通信します。次の機能を使用して通信します。

トランザクション同期の一方送信要求（ee_mch_cmtsend_sync関数）

トランザクション非同期の一方送信要求（ee_mch_cmtsend関数）

UDPプロトコルによるRPC通信（ee_rpc_call関数（EERPC_UDP指定））

注意事項

複数のeesvgdef定義コマンドに同じサービスグループ名を指定し，かつ，それぞれの-tオプションにRAPとRPC（またはUDP）を指定していた場合は，定義ファイル中で先に記述されているeesvgdef定義コマンドの指定が有効になります。定義コマンドの指定内容および指定順に注意してください。

複数のeesvgdef定義コマンドに同じサービスグループ名を指定し，それぞれの-tオプションにRPCとUDPを指定できます。ee_rpc_call関数発行時のflags引数としてEERPC_UDPを指定しない場合はRPCのeesvgdef定義コマンド，指定した場合はUDPのeesvgdef定義コマンドが使用されます。

TP1/EEは，UAPから呼び出されるee_rpc_call関数，ee_rpc_cmtsend関数について，第1引数に指定されたサービスグループ名を，この定義に指定されたサービスグループ名の中から検索します。サービスグループ名が一致する定義が見つかった場合，その定義に指定されているホストとポート番号へサービス要求を送信します。

同一サービスグループ下に複数のホスト名を指定した場合，TP1/EEはランダムにホストを選択してサービス要求を送信します。ネームサービス機能を使用した場合は，前回送信したホストを選択してサービス要求を送信し，送信に失敗した場合は残りのホストから順次選択します。該当するホストでサービス要求できるコネクションがない場合は，残りのホストから順次選択します。すべてのホストでサービス要求ができない場合，ee_rpc_call関数はエラーとなります。ee_rpc_call関数またはee_rpc_cmtsend関数によって自プロセスあてにサービス要求を行う場合は，自ホストの情報を定義する必要があります。

リモートAPI機能を使用して通信するサービスグループに対して，トランザクションとしてサービスを要求しても，非トランザクションモードとして処理します。

リモートAPI機能を使用して通信する場合は，-hオプションに自プロセスのホスト名とポート番号（RPC関連定義のrap_listen_portオペランドの指定値）は指定しないでください。指定してサービス要求した場合の動作は保証しません。

高速メッセージ送信関連定義

ここでは，高速メッセージ送信関連定義の各オペランドについて説明します。

形式

〔set mch_send_ack_timer＝送達確認待ち監視時間〕
〔set mch_send_retry_count＝メッセージ送信エラー時の送信リトライ回数〕
〔set mch_send_retry_interval＝送信リトライ開始間隔T1，送信リトライ最大間隔T2〕
〔set mch_send_rs_retry_interval＝送信リトライ開始間隔T1，送信リトライ最大間隔T2〕
〔set mch_send_max_count＝メッセージ送信最大数〕
〔set mch_send_ack_retry_count＝送達確認メッセージ送信エラー時の送信リトライ回数〕
〔set mch_send_ack_retry_interval＝送達確認メッセージの送信リトライ間隔〕
〔set mch_send_otqwatch_time_interval＝出力キュー閉塞監視インターバル時間〕
〔set mch_send_end_otqwatch＝｛continue｜dct_continue｜timer｝〕
〔set mch_send_end_otqwatch_time＝終了時の未送信メッセージ監視時間〕
〔set mch_receive_limit＝一方送信メッセージの送信元合計数〕
〔set mch_send_otqschedule_interval＝一方送信メッセージの再送信スケジュール間隔〕
〔set mch_send_lump_count＝一括送信するメッセージ数〕

オペランドの説明

●mch_send_ack_timer＝送達確認待ち監視時間

　　～〈符号なし整数〉((1～65535))《1》（単位：10ミリ秒）

ee_mch_cmtsend関数またはee_mch_cmtsend_sync関数による一方送信メッセージを送信してから，送達確認メッセージを受信するまでの待ち時間の最大値を指定します。

指定時間を過ぎても応答がない場合は，高速メッセージ送信関連定義のmch_send_retry_countオペランドに従って再送します。

永続指定の一方送信メッセージの送信先にCLサーバが含まれる場合，送信先のCLサーバの実行系では，一方送信メッセージと待機系からの送達確認メッセージの待ち合わせを行います。このとき，最大で，クラスタ連携関連定義のmch_clsend_ack_timerオペランドで指定した時間を待ち合わせします。

そのため，永続指定の一方送信メッセージの送信先にCLサーバが含まれる場合，このオペランドに，送信先CLサーバのmch_clsend_ack_timerオペランドの指定値よりも大きい値を指定することをお勧めします。このオペランドの指定値が送信先CLサーバのmch_clsend_ack_timerオペランドの指定値以下の場合，送信先CLサーバでの待ち合わせが完了できないため，送信先CLサーバからの送達確認メッセージを受信できないことがあります。

●mch_send_retry_count＝メッセージ送信エラー時の送信リトライ回数

　　～〈符号なし整数〉((0～65535))《10》

ee_mch_cmtsend関数またはee_mch_cmtsend_sync関数による一方送信メッセージの送信時にエラーが発生した場合の，送信リトライ回数を指定します。

0を指定した場合は，送信リトライを行いません。

●mch_send_retry_interval＝送信リトライ開始間隔T1，送信リトライ最大間隔T2

　　～送信リトライ開始間隔T1：〈符号なし整数〉((1～1000))《10》（単位：ミリ秒）

　　～送信リトライ最大間隔T2：〈符号なし整数〉((10～65536))《1000》（単位：ミリ秒）

ee_mch_cmtsend関数またはee_mch_cmtsend_sync関数による一方送信メッセージの送信時にエラーが発生した場合の，送信リトライ間隔を指定します。

送信リトライ開始間隔T1：

送信リトライ開始時の間隔を指定します。

送信リトライ最大間隔T2：

送信リトライ時の最大間隔を指定します。「送信リトライ開始間隔T1」以上の値を指定してください。

送信リトライ間隔は，次に示す計算式によって決まります。ただし，送信リトライ間隔が「送信リトライ最大間隔T2」より大きくなったときは，以降のリトライ間隔は「送信リトライ最大間隔T2」の指定値に従います。

送信リトライ間隔＝送信リトライ開始間隔T1×2n－¹

n：

送信リトライ回数

オペランドの指定によるリトライ間隔の例を次に示します。

（例1）mch_send_retry_interval=1,100　mch_send_retry_count=10と指定した場合の，送信エラーによるリトライ間隔（単位：ミリ秒）

1，2，4，8，16，32，64，100，100，100

（例2）mch_send_retry_interval=10,10　mch_send_retry_count=10と指定した場合の，送信エラーによるリトライ間隔（単位：ミリ秒）

10，10，10，10，10，10，10，10，10，10

●mch_send_rs_retry_interval＝送信リトライ開始間隔T1，送信リトライ最大間隔T2

　　～送信リトライ開始間隔T1：〈符号なし整数〉((1～1000))《10》（単位：ミリ秒）

　　～送信リトライ最大間隔T2：〈符号なし整数〉((10～65536))《1000》（単位：ミリ秒）

ee_mch_cmtsend関数またはee_mch_cmtsend_sync関数による一方送信メッセージの送信時に，リソース不足のエラーが発生した場合の，送信リトライ間隔を指定します。

送信リトライ開始間隔T1：

送信リトライ開始時の間隔を指定します。

送信リトライ最大間隔T2：

送信リトライ時の最大間隔を指定します。「送信リトライ開始間隔T1」以上の値を設定してください。

送信リトライ間隔の仕様は，mch_send_retry_intervalオペランドと同じです。詳細については，mch_send_retry_intervalオペランドの説明を参照してください。

●mch_send_max_count＝メッセージ送信最大数

　　～〈符号なし整数〉((1～1024))《16》

送信スレッドで，1トランザクション内でee_mch_cmtsend関数による一方送信メッセージを送信できる最大数を指定します。

1トランザクション内でのメッセージ送信は，同一サービスグループ下の同一サービスあてのメッセージだけです。

メッセージ送信に失敗した場合は，この指定値に関係なくメッセージ送信を中断します。

●mch_send_ack_retry_count＝送達確認メッセージ送信エラー時の送信リトライ回数

　　～〈符号なし整数〉((0～255))《3》

ee_mch_cmtsend関数またはee_mch_cmtsend_sync関数による一方送信メッセージの受信によって送達確認メッセージを送信した際にエラーが発生した場合の，送信リトライ回数を指定します。

0を指定した場合は，送信リトライを行いません。

●mch_send_ack_retry_interval＝送達確認メッセージの送信リトライ間隔

　　～〈符号なし整数〉((0～1000))《0》（単位：ミリ秒）

ee_mch_cmtsend関数またはee_mch_cmtsend_sync関数による一方送信メッセージの受信によって送達確認メッセージを送信した際にエラーが発生した場合の，送信リトライ間隔を指定します。

0を指定した場合は，すぐに送信リトライを行います。

●mch_send_otqwatch_time_interval＝出力キュー閉塞監視インターバル時間

　　～〈符号なし整数〉((1～65535))《3》（単位：秒）

通信障害などによってサービスグループレベルで出力キュー（OTQ）が自動閉塞となった場合に，送信先サービスグループとの間で通信を行い，出力キュー閉塞解除できるかどうかの確認をする最小時間間隔を指定します。

●mch_send_end_otqwatch＝｛continue｜dct_continue｜timer｝

　　～《continue》

XTC終了処理時，出力キューに未送信メッセージが残っている場合の処理を指定します。

continue：

すべての未送信メッセージがなくなるまで，XTCを終了しません。

dct_continue：

閉塞中の出力キュー以外に残っているすべての未送信メッセージがなくなるまで，XTCを終了しません。

timer：

mch_send_end_otqwatch_timeオペランドで指定した時間が経過した場合，未送信メッセージが残っていてもXTCを終了します。

●mch_send_end_otqwatch_time＝終了時の未送信メッセージ監視時間

　　～〈符号なし整数〉((1～65535))《180》（単位：秒）

mch_send_end_otqwatchオペランドでtimerを指定した場合，XTC終了処理時に出力キューに未送信メッセージがなくなるまでの最大監視時間を指定します。

●mch_receive_limit＝一方送信メッセージの送信元合計数

　　～〈符号なし整数〉((100～100000000))《256》

トランザクション非同期の一方送信メッセージとトランザクション同期の一方送信メッセージの送信元の合計数を指定します。この指定値を超えて一方送信メッセージを受信したときは，送信元に送達確認エラーメッセージを応答します。

一方送信メッセージの送信元合計数は，次の計算式を基に算出します。

一方送信メッセージの送信元合計数　≧
　送信元プロセス数×（自XTCのサービス数＋送信元プロセスの処理スレッド数）

●mch_send_otqschedule_interval＝一方送信メッセージの再送信スケジュール間隔

　　～〈符号なし整数〉((1～65535))《3》（単位：秒）

ee_mch_cmtsend関数による一方送信メッセージ送信時にエラーが発生し，出力キュー閉塞とならなかった場合の，出力キューからの再送信スケジュール間隔を指定します。

この指定値は，出力キュー閉塞または出力キュー閉塞解除を行った場合に無効となります。

●mch_send_lump_count＝一括送信するメッセージ数

　　～〈符号なし整数〉((1～1024))《1》

一方送信メッセージをee_mch_cmtsend関数で一括送信する場合に，一括送信できるメッセージの最大数を指定します。

mch_send_max_countオペランドの指定値以下の値を指定してください。それよりも大きい値を指定した場合は，mch_send_max_countオペランドの指定値を一括送信できるメッセージの最大数とします。

このオペランドを省略または1を指定した場合，メッセージを一括送信できません。

クラスタ連携関連定義

ここでは，クラスタ連携関連定義の各オペランドについて説明します。

なお，クラスタ連携関連定義のオペランドには，HAサーバで指定できないオペランドがあります。HAサーバで指定できないオペランドについては，「HAサーバで指定できないXTCサービス定義」を参照してください。

形式

〔set cluster_mode＝｛Y｜N｝〕
〔set cluster_test_mode＝｛Y｜N｝〕
 set standby_start_watch_time＝待機系の起動完了の最大待ち時間
〔set standby_start_error_switch＝｛stop｜continue｝〕
〔set mch_clsend_ack_timer＝CL同期待ち監視時間〕
〔set mch_clsend_next_timer＝CL同期後続待ち監視時間〕
〔set mch_clsend_retry_count＝CL間同期メッセージの送信エラー時の送信リトライ回数〕
〔set mch_clsend_retry_interval＝送信リトライ開始間隔T1，送信リトライ最大間隔T2〕
〔set mch_clsend_rs_retry_interval＝送信リトライ開始間隔T1，送信リトライ最大間隔T2〕
〔set mch_clsend_ack_retry_count＝送達確認メッセージの送信エラー時の送信リトライ回数〕
〔set mch_clsend_ack_retry_interval＝送達確認メッセージの送信リトライ間隔〕
〔set mch_clsend_sta_timer＝開始および終了時のCL同期待ち監視時間〕
〔set mch_clsend_rrn_timer＝系切り替え時のCL同期待ち監視時間〕
〔set mch_commit_wait_msg_interval＝仕掛かり中のリソースを知らせるメッセージの出力間隔〕
〔set mch_commit_wait_msg_level＝仕掛かり中のリソースの監視レベル〕
〔set mch_xdb_buf_pool_count＝XDBの更新ログ転送用のUDP用送信バッファ確保数〕
〔set send_thread_no＝送信スレッド数〕
〔set mch_clreq_rcvthd＝｛Y｜N｝〕

オペランドの説明

●cluster_mode＝｛Y｜N｝

　　～《Y》

CL連携による系切り替えを行うかどうかを指定します。

Y：

CL連携による系切り替えを行います。

N：

CL連携による系切り替えを行いません。

●cluster_test_mode＝｛Y｜N｝

　　～《N》

CLサーバのシミュレート機能を使用するかどうかを指定します。CLサーバのシミュレート機能については，「2.10.1　CLサーバのシミュレート機能」を参照してください。

Y：

CLサーバのシミュレート機能を使用します。

CL単独起動機能を使用する場合は，Yを指定できません。

N：

CLサーバのシミュレート機能を使用しません。

●standby_start_watch_time＝待機系の起動完了の最大待ち時間

　　～〈符号なし整数〉((0～3600))（単位：秒）

実行系の起動時，すべての待機系の起動が完了するまでの待ち時間の上限を秒単位で指定します。このオペランドは必ず指定してください。

このオペランドに指定した時間を過ぎても，すべての待機系の起動が完了しない場合，standby_start_error_switchオペランドの指定に従った処理が行われます。

0を指定した場合は，すべての待機系の起動が完了するまで待ち続けます。この場合，すべての待機系の起動が完了しないかぎり実行系は起動しません。

なお，このオペランドの指定は，待機系では無視されます。

また，cluster_test_modeオペランドにYを指定，またはCL単独起動機能を使用した場合，このオペランドの指定は無視されます。

●standby_start_error_switch＝｛stop｜continue｝

　　～《stop》

実行系の起動時，standby_start_watch_timeオペランドで指定した時間を過ぎてもすべての待機系の起動が完了しない場合の処理を指定します。

stop：

実行系の起動処理を中止します。

continue：

起動が完了している待機系がある場合は，実行系を起動します。

ただし，起動が完了している待機系がない場合は，実行系の起動処理を中止します。

●mch_clsend_ack_timer＝CL同期待ち監視時間

　　～〈符号なし整数〉((1～65535))《1》（単位：10ミリ秒）

実行系と待機系の同期合わせ処理の通信待ち時間の上限を10ミリ秒単位で指定します。このオペランドに指定した時間を過ぎても応答がない場合は，mch_clsend_retry_countオペランドに従って再送します。

実行系が，複数の待機系からの応答メッセージを受信する場合，最初に受信した応答メッセージまでの時間が，このオペランドで指定する監視時間になります。以降の待機系からの応答メッセージの監視時間は，mch_clsend_next_timerオペランドで指定します。

●mch_clsend_next_timer＝CL同期後続待ち監視時間

　　～〈符号なし整数〉((2～128))《2》（単位：ミリ秒）

実行系と待機系の同期合わせ処理の通信待ち時間の上限をミリ秒単位で指定します。このオペランドに指定した時間を過ぎても応答がない場合は，mch_clsend_retry_countオペランドに従って再送します。

実行系が，待機系から応答メッセージを受信してから，次の応答メッセージを受信するまでの時間が，このオペランドで指定する監視時間になります。

mch_clsend_ack_timerオペランドとmch_clsend_next_timerオペランドの関係を次の図に示します。

図5-2　mch_clsend_ack_timerオペランドとmch_clsend_next_timerオペランドの関係

●mch_clsend_retry_count＝CL間同期メッセージの送信エラー時の送信リトライ回数

　　～〈符号なし整数〉((0～65535))《10》

実行系と待機系間での同期合わせのためのメッセージ（CL同期メッセージなど）を送信した場合に，エラーが発生したときの送信リトライ回数の上限を指定します。

実行系の場合，送信リトライ回数がこのオペランドの値を超えた場合，以後，送信エラーとなった待機系に対してはメッセージを送信しません。

0を指定した場合は，送信リトライを行いません。

●mch_clsend_retry_interval＝送信リトライ開始間隔T1，送信リトライ最大間隔T2

　　～送信リトライ開始間隔T1：〈符号なし整数〉((1～1000))《1》（単位：ミリ秒）

　　～送信リトライ最大間隔T2：〈符号なし整数〉((10～65536))《100》（単位：ミリ秒）

実行系と待機系間での同期合わせのためのメッセージ（CL同期メッセージなど）を送信した場合に，エラーが発生したときの送信リトライ間隔をミリ秒単位で指定します。

送信リトライ開始間隔T1：

最初の送信リトライを開始するまでの間隔を指定します。

送信リトライ最大間隔T2：

送信リトライの最大間隔を指定します。「送信リトライ開始間隔T1」以上の値を指定してください。

送信リトライ間隔は，次に示す計算式によって決まります。ただし，送信リトライ間隔が「送信リトライ最大間隔T2」より大きくなったときは，以降のリトライ間隔は「送信リトライ最大間隔T2」の指定値に従います。

送信リトライ間隔＝送信リトライ開始間隔T1×2n－¹

n：

送信リトライ回数

オペランドの指定によるリトライ間隔の例を次に示します。

（例1）mch_clsend_retry_interval=1,100　mch_clsend_retry_count=10と指定した場合の，送信エラーによるリトライ間隔（単位：ミリ秒）

1，2，4，8，16，32，64，100，100，100

（例2）mch_clsend_retry_interval=10,10　mch_clsend_retry_count=10と指定した場合の，送信エラーによるリトライ間隔（単位：ミリ秒）

10，10，10，10，10，10，10，10，10，10

●mch_clsend_rs_retry_interval＝送信リトライ開始間隔T1，送信リトライ最大間隔T2

　　～送信リトライ開始間隔T1：〈符号なし整数〉((1～1000))《1》（単位：ミリ秒）

　　～送信リトライ最大間隔T2：〈符号なし整数〉((10～65536))《100》（単位：ミリ秒）

実行系と待機系間での同期合わせのためのメッセージ（CL同期メッセージなど）を送信した場合に，リソース不足のエラーが発生したときの送信リトライ間隔をミリ秒単位で指定します。

送信リトライ開始間隔T1：

最初の送信リトライを開始するまでの間隔を指定します。

送信リトライ最大間隔T2：

送信リトライの最大間隔を指定します。「送信リトライ開始間隔T1」以上の値を指定してください。

送信リトライ間隔の仕様は，mch_clsend_retry_intervalオペランドと同じです。詳細については，mch_clsend_retry_intervalオペランドの説明を参照してください。

●mch_clsend_ack_retry_count＝送達確認メッセージの送信エラー時の送信リトライ回数

　　～〈符号なし整数〉((0～255))《3》

送達確認メッセージを待機系から実行系に送信する場合にエラーが発生したときの送信リトライ回数の上限を指定します。

0を指定した場合は，送信リトライを行いません。

●mch_clsend_ack_retry_interval＝送達確認メッセージの送信リトライ間隔

　　～〈符号なし整数〉((0～1000))《0》（単位：ミリ秒）

送達確認メッセージを待機系から実行系に送信する場合にエラーが発生したときの送信リトライ間隔をミリ秒単位で指定します。

0を指定した場合は，すぐに送信リトライを行います。

●mch_clsend_sta_timer＝開始および終了時のCL同期待ち監視時間

　　～〈符号なし整数〉((1～65535))《10》（単位：100ミリ秒）

XTCの開始および終了時，実行系と待機系の同期合わせ処理が行われます。このオペランドには，同期合わせ処理の通信待ち時間の上限を100ミリ秒単位で指定します。このオペランドに指定した時間を過ぎても応答がない場合は，mch_clsend_retry_countオペランドの指定に従ってメッセージの再送を行います。

●mch_clsend_rrn_timer＝系切り替え時のCL同期待ち監視時間

　　～〈符号なし整数〉((1～65535))《1》（単位：100ミリ秒）

系切り替え時，実行系と待機系の同期合わせ処理が行われます。このオペランドには，同期合わせ処理の通信待ち時間の上限を100ミリ秒単位で指定します。このオペランドに指定した時間を過ぎても応答がない場合は，mch_clsend_retry_countオペランドの指定に従ってメッセージの再送を行います。

●mch_commit_wait_msg_interval＝仕掛かり中のリソースを知らせるメッセージの出力間隔

　　～〈符号なし整数〉((0～65535))《300》（単位：100ミリ秒）

実行系から転送されたリソースが待機系に反映されていない場合，仕掛かり中のリソースを知らせるメッセージが出力されます。このメッセージの出力間隔を100ミリ秒単位で指定します。

0を指定した場合は，仕掛かり中のリソースを知らせるメッセージは出力されません。

●mch_commit_wait_msg_level＝仕掛かり中のリソースの監視レベル

　　～〈符号なし整数〉((1～2))《1》

仕掛かり中のリソースの監視レベルを指定します。

1：

トランザクション決着後のCL同期メッセージの受信から，CL同期済み通知メッセージの受信による処理キュー登録までの時間を監視対象とします。

2：

CL同期済み通知メッセージの受信から，CL同期済み通知メッセージの受信による処理キュー登録までの時間を監視対象とします。

●mch_xdb_buf_pool_count＝XDBの更新ログ転送用のUDP用送信バッファ確保数

　　～〈符号なし整数〉((1～1000))《1》

XDBの更新ログを実行系から待機系に転送する場合，UDP用送信バッファ（UOBF）を確保します。このオペランドには，処理スレッドごとに確保するUDP用送信バッファの最大数を指定します。

なお，このオペランドの指定によって確保されるUDP用送信バッファ数が，メモリ関連定義のudp_send_message_buf_cntオペランドの値以上にならないように注意してください。

UDP用送信バッファが不足した場合，不足した分のUDP用送信バッファを新たに確保します。

また，転送に必要なUDP用送信バッファ数が，このオペランドで指定した数の2倍以上で，かつ10面以上になる場合は，XTC用ワーク領域（XTCPOOL）を使用して更新ログを転送します。

●send_thread_no＝送信スレッド数

　　～〈符号なし整数〉((1～50))《3》

プロセス内で使用する送信スレッド数を指定します。送信スレッド数は3以上を指定することをお勧めします。

送信スレッドは次に示す用途で使用します。

ee_rpc_cmtsend関数の再送

ee_mch_cmtsend関数による一方送信メッセージの送信

一方送信メッセージの受信による送達確認メッセージの送信

実行系と待機系の同期合わせ

●mch_clreq_rcvthd＝｛Y｜N｝

　　～《N》

待機系で，CL同期メッセージを受信してから送達確認メッセージを送信するまでの処理をすべてUDP受信スレッドで行うかどうかを指定します。

Y：

UDP受信スレッドだけで処理を行います。

ただし，トランザクションと非同期で転送するリソースのときは，送信スレッドでも処理を行います。

N：

UDP受信スレッドと送信スレッドで処理を行います。

この定義は，CLサーバだけ指定できます。HAサーバでは指定できません。

HAモニタ関連定義

ここでは，HAモニタ関連定義の各オペランドについて説明します。HAモニタ関連定義は，CLサーバの各サーバで指定する必要があります。HAサーバの各サーバでは指定する必要はありません。

形式

〔set ham_wait_interval_time＝HAモニタ応答待ちメッセージの出力間隔〕
〔set ham_onl_interval_time＝実行系の系監視スレッドのイベント監視時間〕
〔set ham_sby_interval_time＝待機系の系監視スレッドのイベント監視時間〕
〔set ham_stop_msg_interval_time＝TP1/EE停止待ちメッセージの出力間隔〕
〔set ham_isolate_wtor_interval_time＝eetrbwtorコマンドの入力待ちメッセージの出力間隔〕

オペランドの説明

●ham_wait_interval_time＝HAモニタ応答待ちメッセージの出力間隔

　　～〈符号なし整数〉((0～60))《5》（単位：分）

HAモニタからの応答を待っている間，KFSB55901-Eメッセージが出力されます。このメッセージの出力間隔を分単位で指定します。

0を指定した場合，KFSB55901-Eメッセージは出力されません。

●ham_onl_interval_time＝実行系の系監視スレッドのイベント監視時間

　　～〈符号なし整数〉｛100｜250｜500｜1000｝《1000》（単位：ミリ秒）

実行系の系監視スレッドが，終了などのイベントを監視する間隔をミリ秒単位で指定します。

このオペランドの値を大きくすると，イベント監視処理によるオーバヘッドは小さくなりますが，イベント発生からイベント検出までの時間が長くなります。

このオペランドの値を小さくすると，イベント発生からイベント検出までの時間は短くなりますが，イベント監視処理によるオーバヘッドが大きくなります。

●ham_sby_interval_time＝待機系の系監視スレッドのイベント監視時間

　　～〈符号なし整数〉｛100｜250｜500｜1000｝《100》（単位：ミリ秒）

待機系の系監視スレッドが，系切り替えや，終了などのイベントを監視する間隔をミリ秒単位で指定します。

このオペランドの値を大きくすると，イベント監視処理によるオーバヘッドは小さくなりますが，イベント発生からイベント検出までの時間が長くなります。

このオペランドの値を小さくすると，イベント発生からイベント検出までの時間は短くなりますが，イベント監視処理によるオーバヘッドが大きくなります。

系切り替えの発生をなるべく早く検知したい場合は，このオペランドの値を小さくしてださい。

●ham_stop_msg_interval_time＝TP1/EE停止待ちメッセージの出力間隔

　　～〈符号なし整数〉((1～60))《5》（単位：分）

系監視スレッドからのeesvstopコマンドの実行後から，TP1/EEが停止するまでの間，KFSB55902-Eメッセージが出力されます。このメッセージの出力間隔を分単位で指定します。

系監視スレッドでeesvstopコマンドを実行するのは，次のケースです。

実行系のTP1/EEが孤立した場合の，eetrbwtor実行時

実行系のTP1/EEがeesvstopで正常終了する場合の，待機系のTP1/EEの終了時

●ham_isolate_wtor_interval_time＝eetrbwtorコマンドの入力待ちメッセージの出力間隔

　　～〈符号なし整数〉((0～60))《5》（単位：分）

実行系孤立状態が発生した場合，eetrbwtorコマンドの入力を促すKFSB85801-Qメッセージが出力されます。このメッセージの出力間隔を分単位で指定します。

0を指定した場合，KFSB85801-Qメッセージは1回だけしか出力されません。

送信先サービス関連定義（コマンド形式）

ここでは，送信先サービス関連定義（コマンド形式）の各定義コマンドについて説明します。

eemchsrvdef（出力キュー情報定義）

機能

高速メッセージ送信制御による一方送信メッセージ送信先のサービスグループ名とサービス名を指定します。指定されたサービスグループ名とサービス名の組み合わせごとに出力キュー（OTQ）を作成し，出力キュー状態を管理します。

サービスグループ名は，最大1024個を定義できます。

同じサービスグループ名を複数のeemchsrvdef定義コマンドで定義した場合，-aオプションと-bオプションは最初に定義した値が有効となります。

コマンドの形式

｛｛eemchsrvdef -g サービスグループ名
               -v サービス名〔,サービス名…〕
             〔-a〕
             〔-b〕
｝｝

オプションの説明

●-g サービスグループ名

～〈1～31文字の識別子〉

一方送信メッセージの送信要求を行うサービスグループ名を指定します。

サービスグループ名は，サービスグループ情報関連定義のeesvgdef定義コマンドで定義しておく必要があります。

●-v サービス名

～〈1～31文字の識別子〉

一方送信メッセージの送信要求を行うサービス名を指定します。

同一サービスグループ下に，最大32000個のサービス名を指定できます。

●-a

オンライン開始時に出力キューの自動閉塞を行う場合に指定します。

●-b

一方送信メッセージの送信失敗時に，エラー要因に応じて出力キューの自動閉塞を行う場合に指定します。出力キューが自動閉塞する要因については，「2.2.6　出力キューによるメッセージ管理」を参照してください。

UDPグループ情報関連定義（コマンド形式）

ここでは，UDPグループ情報関連定義（コマンド形式）の各定義コマンドについて説明します。

なお，UDPグループ情報関連定義（コマンド形式）の定義コマンドには，HAサーバで指定できない定義コマンドがあります。HAサーバで指定できない定義コマンドについては，「HAサーバで指定できないXTCサービス定義」を参照してください。

eeudpdef（あて先UDPグループ情報定義）

機能

UDP通信機能を使用して他プロセスにサービス要求する場合，要求先プロセスごとに，通信種別，ホスト名，ポート番号，通信パラメタなどを指定します。

この定義コマンドは，次の通信をする場合に必要になります。

トランザクション同期の一方送信要求（ee_mch_cmtsend_sync関数）

トランザクション非同期の一方送信要求（ee_mch_cmtsend関数）

UDPプロトコルを使用したRPC通信（ee_rpc_call関数にEERPC_UDPオプションを指定）

この定義コマンドの指定値と，サービス要求先の定義との関連を次の表に示します。

表5-8　eeudpdef定義コマンドの指定値とサービス要求先の定義との関連

項番
eeudpdef定義
コマンドの指定値
サービス要求先

ユニキャストによる
メッセージ送信
マルチキャストによる
メッセージ送信

1
ホスト名
要求先プロセスのLANアダプタのホスト名
要求先プロセスのUDPグループ情報関連定義のmyudprcvdef定義コマンドまたはclgrpdef定義コマンドの-aオプションの指定値

2
ポート番号
要求先プロセスのUDPグループ情報関連定義のmyudprcvdef定義コマンドまたはclgrpdef定義コマンドの-pオプションの指定値
要求先プロセスのUDPグループ情報関連定義のmyudprcvdef定義コマンドまたはclgrpdef定義コマンドの-pオプションの指定値

複数のeeudpdef定義コマンドで，同じあて先UDPグループ名を指定した場合は，あて先UDPグループが同じになります。送信先のポート番号は，あて先UDPグループのポートの中からランダムで選択します。

eeudpdef定義コマンドごとに，LANアダプタの異なる送信UDPグループを指定した場合は，該当するあて先UDPグループに対する送信時に，複数のLANアダプタを使用した負荷分散通信ができます。ただし，同じあて先UDPグループ名を指定する場合は，eeudpdef定義コマンドの-cオプションの指定値を一致させる必要があります。不一致の場合は，XTCの起動に失敗します。

負荷分散通信の詳細については，「2.4.8　負荷分散機能」を参照してください。

コマンドの形式

｛｛eeudpdef -g あて先UDPグループ名
            -c ｛UC｜MC｝
            -a ホスト名
            -p ポート番号〔,ポート番号〕…
          〔-s 送信UDPグループ名〕
          〔-r 受信UDPグループ名〕
          〔-w 再送タイマ値〕
          〔-W 輻輳時の再送タイマ値〕
          〔-R 再送タイマのタイムアウト上限回数〕
｝｝

オプションの説明

●-g あて先UDPグループ名

～〈1～31文字の識別子〉

あて先UDPグループを識別するためのあて先UDPグループ名を指定します。ただし，「CL」はクラスタグループを表す予約語であるため指定できません。「CL」を指定した場合は，XTCの起動に失敗します。

複数のUDPグループ情報関連定義のeeudpdef定義コマンドで同じあて先UDPグループ名を指定した場合は，あて先UDPグループは同じになります。送信先のポート番号は，あて先UDPグループのポートの中からランダムで選択します。

●-c ｛UC｜MC｝

あて先UDPグループに対する通信方式を指定します。

UC：

ユニキャストでメッセージを送信します。

MC：

マルチキャストでメッセージを送信します。

●-a ホスト名

～〈1～255文字のホスト名〉

送信先のホスト名を指定します。指定するホスト名は，通信方式によって異なります。

通信方式がユニキャスト（-cオプションにUCを指定）の場合は，LANアダプタのホスト名を指定します。通信方式がマルチキャスト（-cオプションにMCを指定）の場合は，ホストグループのホスト名を指定します。

ホスト名は，/etc/hostsファイル，DNSなどで，IPアドレスとのマッピングができなければなりません。

●-p ポート番号

～〈符号なし整数〉((5001～65535))

送信先のポート番号を指定します。ポート番号を複数指定した場合は，送信のたびにランダムで送信先ポートを選択します。ポート番号は，128個まで指定できます。

●-s 送信UDPグループ名

～〈1～31文字の識別子〉

該当するあて先UDPグループに対するサービス要求時に，メッセージ送信で使用する送信UDPグループ名を指定します。省略した場合，XTCの定義ファイル内で最初に定義している送信UDPグループを使用します。

●-r 受信UDPグループ名

～〈1～31文字の識別子〉

該当するあて先UDPグループに対するサービス要求時に，肯定応答（ACK）または否定応答（NACK）の受信で使用する受信UDPグループ名を指定します。受信UDPグループ名として「CL」を指定した場合は，クラスタグループ（UDPグループ情報関連定義のclgrpdef定義コマンドで指定）を使用します。

省略した場合は，XTCの定義ファイル内で最初に定義している受信UDPグループ（clgrpdef定義コマンドで指定している受信UDPグループを含む）を使用します。

●-w 再送タイマ値

～〈符号なし整数〉((1～65535))《送信UDPグループの再送タイマ》（単位：ミリ秒）

メッセージ送信から肯定応答または否定応答を受信するまでの待ち時間をミリ秒単位で指定します。待ち時間が指定値を超えてタイムアウトした場合は，再送処理を行います。

●-W 輻輳時の再送タイマ値

～〈符号なし整数〉((1～65535))《-wオプションの指定値》（単位：ミリ秒）

輻輳状態での，メッセージ送信から肯定応答または否定応答を受信するまでの待ち時間をミリ秒単位で指定します。待ち時間が指定値を超えてタイムアウトした場合は，再送処理を行います。

●-R 再送タイマのタイムアウト上限回数

～〈符号なし整数〉((0～65535))《送信UDPグループの再送タイマのタイムアウト上限回数》

再送タイマのタイムアウト発生時の再送処理回数を指定します。タイムアウト回数がこのオプションの指定値を超えた場合は，送信失敗となります。

このオプションに0を指定した場合は，タイムアウト時の再送処理を行いません。

注意事項

指定した送信先XTCと通信できない場合，次のことを確認してください。

-cオプションの指定値がUCの場合，-aオプションで指定したホスト上でXTCが起動されているかどうか。

-cオプションの指定値がMCの場合，次の条件が満たされているかどうか。

送信先XTCが起動されている。

-aオプションで指定したホスト名が，送信先XTCのUDPグループ情報関連定義のmyudprcvdef定義コマンドの-aオプション，またはclgrpdef定義コマンドの-mオプションもしくは-aオプションの指定値と同じである。

-pオプションで指定したポート番号が，送信先XTCのUDPグループ情報関連定義のmyudprcvdef定義コマンドまたはclgrpdef定義コマンドの-pオプションの指定値が同じかどうか。

送信先ホストが自ホストの場合に，UDPグループ情報関連定義のmyudpsnddef定義コマンドの-kオプションを指定しているかどうか。

myudpsnddef（送信UDPグループ情報定義）

機能

UDP通信機能を使用して他プロセスと通信する場合，送信用ポート，通信パラメタなどを指定します。この定義コマンドは，必ず一つ以上定義します。

送信用ポートのポート数とスレッド数を基に，次の表に示す規則に従い，送信用ポートの占有または共有を決定します。処理スレッドと送信スレッドは，送信用ポートの使用頻度が高いため，項番2の条件を満たすことをお勧めします。

表5-9　送信用ポートの占有，共有を決定する規則

項番 | 条件 | 占有／共有
1 | 送信用ポート数≧メインスレッドを除いた全スレッド数 | すべてのスレッドが占有※になります。
2 | 送信用ポート数＞処理スレッド数＋送信スレッド数 | 処理スレッドおよび送信スレッドは占有，それ以外のスレッドは共有になります。
3 | 上記以外 | すべてのスレッドが共有になります。

注※

送信用ポート数が全スレッド数を超過している場合，送信用ポートは，全スレッドの数分作成します。

コマンドの形式

｛｛myudpsnddef -g 送信UDPグループ名
             ｛-p ポート番号〔,ポート番号〕…｜-P ポート数｝
             〔-a LANアダプタのホスト名〕
             〔-b システムのUDPソケット送信バッファのサイズ〕
             〔-T マルチキャスト時のTTL〕
             〔-w 再送タイマ値〕
             〔-W 輻輳時の再送タイマ値〕
             〔-R 再送タイマのタイムアウト上限回数〕
             〔-L パケットロス上限〕
             〔-l パケットロス下限〕
             〔-U 連続送信パケット数下限〕
             〔-k〕
｝｝

オプションの説明

●-g 送信UDPグループ名

～〈1～31文字の識別子〉

送信UDPグループを識別するための送信UDPグループ名を指定します。

同一の送信UDPグループ名がすでに定義されている場合は，XTCの起動に失敗します。

●-p ポート番号

～〈符号なし整数〉((5001～65535))

送信用ポートのポート番号を明示的に指定する場合，このオペランドでポート番号を指定します。ポート番号は，128個まで指定できます。

指定されたポート番号がすでに使用されていた場合は，XTCの起動に失敗します。

-pオプションまたは-Pオプションのどちらか一方だけを指定する必要があります。-pオプションおよび-Pオプションの両方を指定，または両方を省略した場合は，XTCプロセスの起動に失敗します。

●-P ポート数

～〈符号なし整数〉((1～128))

送信用ポートのポート番号をOSによる自動割り当てにする場合は，このオペランドでポート数を指定します。指定値分のポートを作成できなかった場合は，XTCの起動に失敗します。

-pオプションまたは-Pオプションのどちらか一方だけを指定する必要があります。-pオプションおよび-Pオプションの両方を指定，または両方を省略した場合は，XTCの起動に失敗します。

●-a LANアダプタのホスト名

～〈1～255文字のホスト名〉

複数のLANアダプタを持つ構成にした場合に，送信に使用するLANアダプタのホスト名を指定します。省略した場合は，送信に使用するLANアダプタをOSが自動的に決定します。

ホスト名は，/etc/hostsファイル，DNSなどで，IPアドレスとのマッピングができなければなりません。

●-b システムのUDPソケット送信バッファのサイズ

～〈符号なし整数〉((2048～2147483647))《2097152》（単位：バイト）

システムのUDPソケット送信バッファのサイズをバイト単位で指定します。

指定できる範囲はOSに依存します。詳細については，OSのマニュアルを参照してください。

●-T マルチキャスト時のTTL

～〈符号なし整数〉((0～255))

マルチキャストメッセージ送信時のマルチキャストパケットの生存期間（TTL）を指定します。省略した場合は，OSのデフォルト値となります。

●-w 再送タイマ値

～〈符号なし整数〉((1～65535))《10》（単位：ミリ秒）

メッセージ送信から肯定応答または否定応答を受信するまでの待ち時間をミリ秒単位で指定します。待ち時間が指定値を超えてタイムアウトした場合は，再送処理を行います。

メッセージ送信時に，UDPソケット送信バッファが送信できる状態になるまでの，待ち時間としても使用します。

●-W 輻輳時の再送タイマ値

～〈符号なし整数〉((1～65535))《20》（単位：ミリ秒）

輻輳状態での，メッセージ送信から肯定応答または否定応答を受信するまでの待ち時間をミリ秒単位で指定します。待ち時間が指定値を超えてタイムアウトした場合は，再送処理を行います。

輻輳状態でのメッセージ送信時に，UDPソケット送信バッファが送信できる状態になるまでの，待ち時間としても使用します。

●-R 再送タイマのタイムアウト上限回数

～〈符号なし整数〉((0～65535))《10》

再送タイマのタイムアウト発生時の再送処理回数を指定します。タイムアウト回数がこのオプションの指定値を超えた場合は，送信失敗となります。

このオプションに0を指定した場合は，タイムアウト時の再送処理を行いません。

●-L パケットロス上限

～〈符号なし整数〉((1～100))《30》（単位：%）

監視対象範囲内（rpc_udp_congestion_packet_countオペランドで指定）での再送パケット比率が，このオプションの指定値以上になった場合に輻輳制御を開始します。

パケットロス上限は，パケットロス下限より大きくなるように設定してください。パケットロス上限がパケットロス下限以下の場合は，XTCの起動に失敗します。

●-l パケットロス下限

～〈符号なし整数〉((0～99))《20》（単位：%）

監視対象範囲内（rpc_udp_congestion_packet_countオペランドで指定）での再送パケット比率が，このオプションの指定値以下になった場合に輻輳制御を終了します。

パケットロス下限は，パケットロス上限より小さくなるように設定してください。パケットロス下限がパケットロス上限以上の場合は，XTCの起動に失敗します。

●-U 連続送信パケット数下限

～〈符号なし整数〉((1～65536))《5》

輻輳時の連続送信パケット数の最低値を指定します。

輻輳時は，連続送信パケット数を自動計算します。自動計算した連続送信パケット数が少ない場合，ネットワークの負荷は軽減されます。しかし，通信時間が増加することがあります。このオプションによって連続送信パケット数の下限値を設定することで，通信時間の増加を回避できます。

●-k

自マシンをマルチキャストメッセージの送信対象にする場合に指定します。省略した場合は，自マシンはマルチキャストメッセージの送信対象外になります。

CLサーバ同士でのマルチキャストによる通信時にこのオプションを指定した場合は，受信負荷が増加します。そのため，CLサーバ同士の通信に限定して使用する場合は，このオプションを省略することをお勧めします。

myudprcvdef（受信UDPグループ情報定義）

機能

UDP通信機能を使用して他プロセスと通信する場合に，受信用ポート，システムのUDPの受信バッファサイズなどを指定します。指定した受信用ポートごとに，UDP受信スレッドを作成します。

HAサーバの場合，必ず一つ以上定義します。CLサーバの場合，クラスタグループで代用できるため省略できます。ただし，クラスタ構成のサーバでCL単独起動機能を使用する場合は，必ず一つ以上定義してください。

コマンドの形式

｛｛myudprcvdef -g 受信UDPグループ名
               -p ポート番号〔,ポート番号〕…
             〔-a ホストグループのホスト名〔:LANアダプタのホスト名〕
             〔,ホストグループのホスト名〔:LANアダプタのホスト名〕〕…〕
             〔-B UDPの受信バッファサイズ〕
｝｝

オプションの説明

●-g 受信UDPグループ名

～〈1～31文字の識別子〉

受信UDPグループを識別するための受信UDPグループ名を指定します。ただし，「CL」はクラスタグループを表す予約語であるため指定できません。同一の受信UDPグループ名がすでに定義されている場合，または「CL」を指定した場合は，XTCプロセスの起動に失敗します。

●-p ポート番号

～〈符号なし整数〉((5001～65535))

受信用ポートのポート番号を指定します。ポート番号は，128個まで指定できます。指定されたポート番号がすでに使用されていた場合は，XTCプロセスの起動に失敗します。

●-a ホストグループのホスト名：LANアダプタのホスト名

ホストグループのホスト名～〈1～255文字のホスト名〉

LANアダプタのホスト名～〈1～255文字のホスト名〉

所属するホストグループのホスト名を指定します。また，複数のLANアダプタを持つ構成の場合，マルチキャストメッセージの受信に使用するLANアダプタのホスト名も指定します。LANアダプタのホスト名を省略した場合は，OSが自動的にLANアダプタを決定します。

ホスト名は，/etc/hostsファイル，DNSなどで，IPアドレスとのマッピングができなければなりません。

このオプションを省略した場合，該当する受信用ポートは，ユニキャストメッセージだけを受信します。

●-B UDPの受信バッファサイズ

～〈符号なし整数〉((2048～2147483647))《3145728》（単位：バイト）

システムのUDPの受信バッファサイズをバイト単位で指定します。

指定できる範囲はOSに依存します。詳細については，OSのマニュアルを参照してください。

clgrpdef（クラスタグループ情報定義）

機能

CLサーバの場合，クラスタ情報，受信用ポート，通信パラメタなどを指定します。指定した受信用ポートごとに，UDP受信スレッドを作成します。

HAサーバの場合は，この定義コマンドを指定しないでください。

この定義コマンドを省略すると，CL単独起動機能が有効になります。

この定義コマンドは，受信UDPグループ情報定義として使用することもできます。その場合は，受信UDPグループ名は「CL」となります。

この定義コマンドを複数指定した場合，送信先のポート番号は，すべてのclgrpdef定義コマンドのポートの中からランダムで選択されます。

clgrpdef定義コマンドごとに，LANアダプタが異なる送信UDPグループを指定した場合に，CLサーバ同士の送信をするときは，複数のLANアダプタを使用した負荷分散通信ができます。負荷分散通信の詳細については，「2.4.8　負荷分散機能」を参照してください。

なお，この定義コマンドを複数指定する場合は，次のオプションの指定値を一致させる必要があります。

-c

-p

-m

-n

-a

-B

コマンドの形式

｛｛clgrpdef -c クラスタ識別子
            -p ポート番号〔,ポート番号〕…
            -m ホストグループのホスト名〔:LANアダプタのホスト名〕
            -n ノード識別子:HAモニタのホスト名〔:LANアダプタのホスト名〕〔,ノード識別子:HAモニタのホスト名〔:LANアダプタのホスト名〕〕…
          〔-a ホストグループのホスト名〔:LANアダプタのホスト名〕〔,ホストグループのホスト名〔:LANアダプタのホスト名〕〕…〕
          〔-s 送信UDPグループ名〕
          〔-w 再送タイマ値〕
          〔-W 輻輳時の再送タイマ値〕
          〔-R 再送タイマのタイムアウト上限回数〕
          〔-B UDPの受信バッファサイズ〕
｝｝

オプションの説明

●-c クラスタ識別子

～〈4文字の識別子〉

CLサーバを一意に識別するためのクラスタ識別子を指定します。

クラスタグループを構成する全サーバ間で，同一のクラスタ識別子を指定します。異なる識別子を指定した場合は，XTCの起動に失敗します。

複数のクラスタグループが存在する場合は，各クラスタグループ間で異なる識別子を指定します。同一の識別子を指定した場合は，ee_mch_cmtsend_sync関数またはee_mch_cmtsend関数のメッセージが破棄されるおそれがあります。

●-p ポート番号

～〈符号なし整数〉((5001～65535))

受信用ポートのポート番号を指定します。ポート番号は，128個まで指定できます。指定されたポート番号がすでに使用されていた場合は，XTCプロセスの起動に失敗します。

送信時は，送信先ポート番号として使用します。

●-m ホストグループのホスト名：LANアダプタのホスト名

ホストグループのホスト名～〈1～255文字のホスト名〉

LANアダプタのホスト名～〈1～255文字のホスト名〉

CLサーバ同士でのマルチキャストメッセージによる通信時に使用するホストグループのホスト名を指定します。また，複数のLANアダプタを持つ構成の場合，マルチキャストメッセージの受信に使用するLANアダプタのホスト名も指定します。LANアダプタのホスト名を省略した場合は，OSが自動的にLANアダプタを決定します。

ホスト名は，/etc/hostsファイル，DNSなどで，IPアドレスとのマッピングができなければなりません。

●-n ノード識別子：HAモニタのホスト名：LANアダプタのホスト名

クラスタグループ内の全サーバのノード情報を指定します。ノード情報は，最大で3つ指定できます。4つ以上を指定した場合は，XTCの起動に失敗します。

自ノード情報は必ず指定しなければなりません。自ノード情報を指定していない場合は，XTCの起動に失敗します。

すべてのノード情報で，ノード識別子，HAモニタのホスト名，およびLANアダプタのホスト名に異なる値を指定する必要があります。同一の値を指定していた場合は，XTCの起動に失敗します。

また，このオプションに指定する値は実行系と待機系で同じ順番で指定してください。実行系と待機系で異なる順番で指定した場合は，XTCの起動に失敗します。

ノード識別子
～〈4文字の識別子〉
該当するサーバのTP1/EEサービス定義で指定したRPC関連定義のノード識別子（node_idオペランドの指定値）を指定します。

HAモニタのホスト名
～〈1～255文字のホスト名〉
該当するサーバのHAモニタの環境設定（sysdefファイル）のnameオペランドで指定したホスト名を指定します。

LANアダプタのホスト名
～〈1～255文字のホスト名〉
該当するサーバのLANアダプタのホスト名を指定します。省略時は，HAモニタのホスト名をLANアダプタのホスト名として使用します。

●-a ホストグループのホスト名：LANアダプタのホスト名

ホストグループのホスト名～〈1～255文字のホスト名〉

LANアダプタのホスト名～〈1～255文字のホスト名〉

該当する受信用ポートを使用して，他プロセスからのサービス要求を受け付ける場合，参加するホストグループのホスト名を指定します。また，複数のLANアダプタを持つ構成の場合，マルチキャストメッセージの受信に使用するLANアダプタのホスト名も指定します。LANアダプタのホスト名を省略した場合は，OSが自動的にLANアダプタを決定します。

このオプションを省略した場合，該当する受信用ポートに対するサービス要求は，ユニキャストメッセージだけでできるようになります。

ホスト名は，/etc/hostsファイル，DNSなどで，IPアドレスとのマッピングができなければなりません。

●-s 送信UDPグループ名

～〈1～31文字の識別子〉

該当するあて先UDPグループに対するサービス要求時に，メッセージ送信で使用する送信UDPグループ名を指定します。省略した場合は，XTCの定義ファイル内で，最初に定義している送信UDPグループを使用します。

●-w 再送タイマ値

～〈符号なし整数〉((1～65535))《送信UDPグループの再送タイマ》（単位：ミリ秒）

メッセージ送信から肯定応答または否定応答を受信するまでの待ち時間をミリ秒単位で指定します。待ち時間が指定値を超えてタイムアウトした場合は，再送処理を行います。

●-W 輻輳時の再送タイマ値

～〈符号なし整数〉((1～65535))《-wオプションの指定値》（単位：ミリ秒）

輻輳状態での，メッセージ送信から肯定応答または否定応答を受信するまでの待ち時間をミリ秒単位で指定します。待ち時間が指定値を超えてタイムアウトした場合は，再送処理を行います。

●-R 再送タイマのタイムアウト上限回数

～〈符号なし整数〉((0～65535))《送信UDPグループの再送タイマのタイムアウト上限回数》

再送タイマのタイムアウト発生時の再送処理回数を指定します。タイムアウト回数がこのオプションの指定値を超えた場合は，送信失敗となります。

なお，0～2を指定した場合でも，タイムアウト上限回数は3となります。

実行系から待機系にリソース情報を送信するときに，再送に対する肯定応答（ACK），または否定応答（NACK）を再送処理の間に一度も受信しなかった場合，待機系をメッセージ送信の対象外とします。

●-B UDPの受信バッファサイズ

～〈符号なし整数〉((2048～2147483647))《3145728》（単位：バイト）

システムのUDPの受信バッファサイズをバイト単位で指定します。

指定できる範囲はOSに依存します。詳細については，OSのマニュアルを参照してください。

HAサーバで指定できないXTCサービス定義

ここでは，HAサーバで指定できないXTCサービス定義について説明します。

HAサーバで指定できないXTCサービス定義

HAサーバで指定できないXTCサービス定義の一覧を次の表に示します。

表5-10　HAサーバで指定できないXTCサービス定義の一覧

項番
定義
指定できないオペランドおよび定義コマンド

1
メモリ関連定義

memory_xdb_area_size

memory_xdb_limit_size

2
RPC関連定義

rpc_recv_permanence

3
ユーザサービス関連定義

system_start_ui

4
トラブルシュート関連定義

trb_quedump_io_watch_time

trb_quedump_io_watch_msg_time

5
トランザクション関連定義

trn_expiration_time_ui

6
クラスタ連携関連定義

cluster_test_mode

standby_start_watch_time

standby_start_error_switch

mch_clsend_ack_timer

mch_clsend_next_timer

mch_clsend_retry_count

mch_clsend_retry_interval

mch_clsend_rs_retry_interval

mch_clsend_ack_retry_count

mch_clsend_ack_retry_interval

mch_commit_wait_msg_interval

mch_commit_wait_msg_level

mch_xdb_buf_pool_count

mch_clsend_sta_timer

mch_clsend_rrn_timer

7
HAモニタ関連定義
すべてのオペランドが指定できません。

8
UDPグループ情報関連定義（コマンド形式）

clgrpdef定義コマンド

6.　運用

この章では，XTCの開始・終了方法，および運用コマンドについて説明します。

＜この章の構成＞

6.1　XTCの開始

6.2　XTCの終了

6.3　ファイルの運用

6.4　運用コマンド

6.1　XTCの開始

ここでは，XTCの開始方法，開始モード，および開始時のシステムの処理について説明します。

＜この節の構成＞

6.1.1　HAサーバでのXTCの開始

6.1.2　CLサーバでのXTCの開始

6.1.1　HAサーバでのXTCの開始

HAサーバの場合，開始方法と開始モードはTP1キャッシュ機能を使用しないときと同様です。詳細については，マニュアル「TP1/Server Base Enterprise Option 使用の手引」を参照してください。

システムの処理を次の図に示します。

図6-1　HAサーバでのXTCの開始

説明

定義解析
TP1/EEの定義解析を実行します。定義解析では，定義の形式および値の妥当性をチェックします。この処理によって，サーバの構成が決定します。

ライブラリのローディング
ライブラリをローディングします。次の表に，使用する機能とロードするライブラリの対応を示します。ライブラリのローディングでエラーが発生した場合は，プロセスダウンします。

表6-1　使用する機能とロードするライブラリの対応

項番 | 使用する機能 | ロードするライブラリ
1 | XTC | XTC用のライブラリ
2 | XDB | XDB用のライブラリ
3 | MCP | MCP用のライブラリ

MCPのオブジェクトファイルのローディング
MCPを使用する場合は，MCP定義オブジェクト生成ユティリティで生成したオブジェクトファイルをローディングします。オブジェクトファイルのローディングで障害が発生した場合は，プロセスダウンします。

オンライン開始UOCの発行
オンライン開始UOCを発行します。オンライン開始UOCについては，マニュアル「TP1/Server Base Enterprise Option プログラム作成の手引」を参照してください。
オンライン開始UOCのリターン後の動作を次の表に示します。

表6-2　オンライン開始UOCリターン後の動作

項番 | リターン値 | 動作
1 | EEMCH_UOC_OK | 開始処理続行
2 | EEMCH_UOC_NG | プロセスダウン

dc_rpc_open関数の発行
dc_rpc_open関数を発行します。

初期化トランザクション（MI）の起動
初期化トランザクション（MI）を起動します。

6.1.2　CLサーバでのXTCの開始

CLサーバの場合，次のどちらかの方法でXTCを開始します。

TP1/EEに対してeesvstartコマンドを実行する。

TP1/Server Baseに対してdcstartコマンドを実行する。

コマンドは，実行系と待機系の両方で実行してください。

開始モードは，前回オンラインの終了状態に関係なく，常に正常開始となります。また，XTCを開始するとその延長でXDBも開始されます。

システムの処理を次の図に示します。

図6-2　CLサーバでのXTCの開始

実行系の処理の説明

定義解析～dc_rpc_open関数の発行
HAサーバの場合と同様です。

CLサーバの初期化
HAモニタやCLサーバに関する初期化処理を実行します。この処理によって，自TP1/EEの系が決定します。

XDBの初期化
XDBを初期化します。XDBの開始の詳細については，マニュアル「TP1/EE/Extended Data Cache 使用の手引」を参照してください。

待機系の起動完了待ち
待機系の起動完了を待ちます。
CL連携する場合（クラスタ連携関連定義のcluster_modeオペランドにYを指定した場合）は，次のどちらかの条件を満たすまで，すべての待機系からの起動完了通知の受信を待ちます。
・すべての待機系から起動完了通知を受信した。
・起動完了通知の受信タイムアウト（クラスタ連携関連定義のstandby_start_watch_timeオペランドで指定）となった。
起動完了通知の受信タイムアウト時の動作を次の表に示します。

表6-3　起動完了通知の受信タイムアウト時の動作

項番
standby_start_error_switchオペランドの指定値
動作

1
continue
起動が完了している待機系がある場合は，実行系を起動します。
起動が完了している待機系がない場合は，実行系の起動処理を中止します。

2
stop
実行系の起動処理を中止します。

CL連携しない場合（クラスタ連携関連定義のcluster_modeオペランドにNを指定した場合），およびCLサーバのシミュレート機能を使用する場合（クラスタ連携関連定義のcluster_test_modeオペランドにYを指定した場合）は，何も行いません。

初期化トランザクション（MI）の起動
初期化トランザクション（MI）を起動します。このとき，実行系での起動であることをユーザに通知するため，トランザクションインタフェース情報の系情報にEERPC_SYSTEM_ONLINE（実行系を意味する値）を設定して起動します。

HAモニタ起動完了通知
HAモニタに対して起動完了通知を行います。以降，自TP1/EEに障害が発生した場合，系切り替えが発生します。

待機系の処理の説明

定義解析～dc_rpc_open発行
HAサーバの場合と同様です。

CLサーバの初期化
実行系の場合と同様です。
なお，この処理の間に実行系との通信が行われます。そのため，以降の処理は実行系が起動していることが前提となります。

実行系の状態取得
実行系と通信を行い，現時点での実行系の状態を取得します。

開始可否チェック
実行系の状態が，待機系の起動完了待ちよりも先に進んでいる場合は，プロセスダウンします。

実行系と待機系の定義チェック
実行系と通信を行い，実行系の定義内容に対して自TP1/EEの定義内容が妥当であるかどうかをチェックします。自TP1/EEの定義内容が妥当ではない場合，プロセスダウンします。

XDBの初期化
実行系と通信を行い，実行系の状態を取得します。取得した内容を基に，XDBのデータベースを作成します。

初期化トランザクション（MI）の起動
初期化トランザクション（MI）を起動します。このとき，待機系での起動であることをユーザに通知するため，トランザクションインタフェース情報の系情報にEERPC_SYSTEM_STANDBY（待機系を意味する値）を設定して起動します。

起動完了通知送信
起動が完了したことを実行系に通知します。

HAモニタ待機状態通知
HAモニタに対して待機状態通知を行います。以降，自TP1/EEは系切り替え対象となります。

開始処理後の処理
開始処理後の処理として，待機系としてのオンライン処理を行います。

参考

実行系が起動していない状態で待機系が起動すると，HAモニタ関連定義のham_wait_interval_timeオペランドに従って，実行系が起動するまでKFSB55901-Eメッセージが出力されます。

CLサーバでのXTCの開始時に発生する障害については，「8.1.1　XTCの開始時に発生する障害」を参照してください。

6.2　XTCの終了

ここでは，XTCの終了方法，終了モード，および終了時のシステムの処理について説明します。

＜この節の構成＞

6.2.1　HAサーバでのXTCの終了

6.2.2　CLサーバでのXTCの終了

6.2.1　HAサーバでのXTCの終了

HAサーバの場合，終了方法，終了モード，および終了時のシステムの処理はTP1キャッシュ機能を使用しない場合と同様です。詳細については，マニュアル「TP1/Server Base Enterprise Option 使用の手引」を参照してください。

6.2.2　CLサーバでのXTCの終了

CLサーバの場合の終了方法，終了モード，および終了時のシステムの処理について説明します。なお，XTCを終了すると，その延長でXDBも終了されます。

＜この項の構成＞

(1)　終了方法

(2)　終了モード

(3)　終了時のシステムの処理

(1)　終了方法

CLサーバの場合，次のどちらかの方法でXTCを終了します。

実行系のTP1/EEに対してeesvstopコマンドを実行する。

実行系が起動しているTP1/Server Baseに対してdcstopコマンドを実行する。

実行系を終了させることで，すべての待機系を連動して終了させます。

系切り替え中に終了コマンドを実行すると，系切り替え後に終了処理を開始します。ただし，終了モードに強制停止を指定した場合は，系切り替え中であっても終了します。

なお，通信障害などによってTP1/EEが待機系を切り離した場合，HAモニタは切り離しを検知しません。この場合，切り離された待機系を次のどちらかの方法で終了させてください。

待機系のTP1/EEに対してeesvstopコマンドを実行する。

待機系が起動しているTP1/Server Baseに対してdcstopコマンドを実行する。

切り離されていない待機系だけを終了する場合，系切り替えのタイミングによっては，実行系，およびすべての待機系が終了するおそれがあります。

(2)　終了モード

XTCの終了モードには次の四つがあります。

正常終了

計画停止A

計画停止B

強制停止

各終了モードの意味については，マニュアル「OpenTP1 運用と操作」を参照してください。ここでは，TP1キャッシュ機能使用時の処理について説明します。

(a)　eesvstopコマンドで終了する場合

終了モードは，eesvstopコマンドのオプションの指定で決定します。ただし，強制停止（eesvstopコマンドに-fオプションを指定）はできません。

(b)　dcstopコマンドで終了する場合

終了モードは，dcstopコマンドのオプションの指定で決定します。

強制停止の場合，実行中のサービス要求の完了を待たないで終了します。処理キュー上の受け付け済みのサービス要求はすべて破棄します。また，XDBの内容は永続化されません。

(3)　終了時のシステムの処理

終了時のシステムの処理を次の図に示します。

図6-3　CLサーバでのXTCの終了

実行系の処理の説明

サービスの受け付け禁止
新たなサービスの受け付けを禁止します。

終了トランザクション（ME）の起動
終了トランザクション（ME）を起動します。このとき，実行系での起動であることをユーザに通知するため，トランザクションインタフェース情報の系情報にEERPC_SYSTEM_ONLINE（実行系を意味する値）を設定して起動します。

XDBの終了
XDBの終了処理を行います。

CLサーバの終了
HAモニタやCLサーバに関する終了処理を行います。この処理以降は，系切り替えが発生しません。

待機系の処理の説明

実行系の終了検知
HAモニタ経由で，実行系が終了したことを検知します。

CLサーバの終了
HAモニタやCLサーバに関する終了処理を行います。この処理以降は，系切り替えが発生しません。

サービスの受け付け禁止
新たなサービスの受け付けを禁止します。

プロセス終了監視トランザクション（SE）の起動
プロセス終了監視トランザクション（SE）を起動します。

終了トランザクション（ME）の起動
終了トランザクション（ME）を起動します。このとき，待機系での起動であることをユーザに通知するため，トランザクションインタフェース情報の系情報にEERPC_SYSTEM_STANDBY（待機系を意味する値）を設定して起動します。

XDBの終了
XDBの終了処理を行います。

参考

待機系に対して終了コマンドを実行する場合も，処理の流れは同様です。

XTCの終了時にCLサーバで発生する障害については，「8.1.2　XTCの終了時に発生する障害」を参照してください。

6.3　ファイルの運用

ここでは，XTC固有のファイルの運用について説明します。

ここに記載のないファイルの運用については，マニュアル「TP1/Server Base Enterprise Option 使用の手引」のファイルの運用の説明を参照してください。

＜この節の構成＞

6.3.1　回線トレースファイルの運用

6.3.1　回線トレースファイルの運用

ここでは，回線トレースファイルの運用で，XTC固有の部分についてだけ説明します。

＜この項の構成＞

(1)　回線トレース情報の取得量の変更

(1)　回線トレース情報の取得量の変更

送受信データごとに回線トレース情報を取得する場合，I/O処理の増加によって性能が低下したり，重要な回線トレース情報が欠落したりすることがあります。これを防止するために，RPC関連定義のrpc_udp_linetraceオペランドを指定することで，送受信時の回線トレース情報の取得内容を変更できます。

ここでは，rpc_udp_linetraceオペランドの指定値別の取得内容，取得サイズの差異，およびオペランドの指定値の組み合わせについて説明します。

(a)　取得内容

メッセージ送受信が正常終了した場合の取得内容を，rpc_udp_linetraceオペランドの指定値によって変更することができます。オペランドの指定値別に，回線トレース情報の取得内容について説明します。

00000000（デフォルト）

すべての回線トレース情報を，送信側と受信側で取得します。

送受信処理が正常に完了した場合は，最大374バイト取得します。

00000001

W-send機能や再送などによって重複して受信したパケットについて，回線トレース情報を取得しません。

回線トレース情報は，受信側で取得します。

00000002

次のすべての条件を満たす場合に，回線トレース情報を取得しません。

myudpsnddef定義コマンドの-kオプションを指定している

クラスタ内でのマルチキャストによって自TP1/EEが送信したメッセージを，自TP1/EEで受信した

回線トレース情報は，受信側で取得します。

00000004

メッセージが複数のパケットに分割されている場合，先頭パケットはUDP通信制御ヘッダおよびデータ部分を最大374バイト取得します。残りのパケットはUDP通信制御ヘッダだけを取得します。

回線トレース情報は送信側と受信側の両方で取得します。

00000020

送受信データの先頭にある製品ヘッダを回線トレース情報として送信側と受信側で取得します。

取得する製品ヘッダはメッセージ種別によって異なります。それぞれの場合について，次に示します。

メッセージ種別がACKの場合

UDP通信制御ヘッダだけを取得します。

メッセージ種別がACK以外の場合

UDP通信制御ヘッダおよびデータ部分を最大374バイト取得します。

メッセージ種別がACK以外のメッセージが複数のパケットに分割されている場合

先頭パケットはUDP通信制御ヘッダおよびデータ部分を最大374バイト取得し，残りのパケットはUDP通信制御ヘッダだけを取得します。

(b)　取得サイズの差異

回線トレース情報の取得サイズの差異について，次の図に示します。この例では，UDP通信機能を使用したRPCのメッセージを2回に分けて受信したため，メッセージが二つ（1472バイトと328バイト）に分割されています。

図6-4　回線トレース情報の取得サイズの差異

(c)　rpc_udp_linetraceオペランドの指定値の組み合わせ

rpc_udp_linetraceオペランドの指定値は，論理和を使用して複数選択できます。複数選択する場合に可能な組み合わせを次の表に示します。

表6-4　rpc_udp_linetraceオペランドの指定値の組み合わせ

指定値 | 組み合わせる指定値
00000000​ | 00000001​ | 00000002​ | 00000004​ | 00000020​
00000000​ | － | ◎ | ◎ | － | －
00000001​ | ○ | － | ◎ | ○ | ○
00000002​ | ○ | ◎ | － | ○ | ○
00000004​ | － | ◎ | ◎ | － | －
00000020​ | － | ◎ | ◎ | － | －

（凡例）

◎：組み合わせて指定できます。

○：どれか一つを組み合わせて指定できます。

－：組み合わせて指定できません。

6.4　運用コマンド

ここでは，XTCで使用する運用コマンドについて説明します。運用コマンドの入力方法や記述形式などは，マニュアル「TP1/Server Base Enterprise Option 使用の手引」を参照してください。

＜この節の構成＞

運用コマンドの一覧

eeactsv（サービスの閉塞解除）

eedctsv（サービスの閉塞）

eehamls（系の状態表示）

eelspce（処理キュー制御用バッファの状態表示およびサービスの最大同時処理限界数の変更）

eelspcenum（処理キュー制御用バッファの状態表示（通番付き））

eemchotqact（出力キューの閉塞解除）

eemchotqdct（出力キューの閉塞）

eemchotqend（出力キューの未送信メッセージの監視終了）

eemchotqls（出力キューの状態表示）

eemchotqskip（出力キューの未送信メッセージのスキップ）

eepcerefer（滞留メッセージのファイル出力）

eepceskip（滞留メッセージのスキップ）

eetrbqueed（キューダンプファイルの編集）

eetrbwtor（メッセージへの応答）

運用コマンドの一覧

XTCの運用コマンドの一覧を次の表に示します。

表6-5　XTCの運用コマンド一覧

項番 | 機能 | コマンド | オフライン | オンライン | API | 実行系 | 待機系
1 | システム制御 | サービスの閉塞 | eedctsv※ | × | ○ | ○ | ○ | ×
2 | サービスの閉塞解除 | eeactsv※ | × | ○ | ○ | ○ | ×
3 | 処理キュー制御用バッファの状態表示およびサービスの最大同時処理限界数の変更 | eelspce※ | × | ○ | ○ | ○ | ×
4 | 高速メッセージ送信制御 | 出力キューの閉塞 | eemchotqdct | × | ○ | ○ | ○ | ×
5 | 出力キューの閉塞解除 | eemchotqact | × | ○ | ○ | ○ | ×
6 | 出力キューの未送信メッセージのスキップ | eemchotqskip | × | ○ | ○ | ○ | ×
7 | 出力キューの状態表示 | eemchotqls | × | ○ | ○ | ○ | ○
8 | 出力キューの未送信メッセージの監視終了 | eemchotqend | × | ○ | × | ○ | ×
9 | 入力キュー（ITQ）制御 | 滞留メッセージのファイル出力 | eepcerefer | × | ○ | × | ○ | ×
10 | 処理キュー制御用バッファの状態表示（通番付き） | eelspcenum | × | ○ | ○ | ○ | ×
11 | 滞留メッセージのスキップ | eepceskip | × | ○ | ○ | ○ | ×
12 | キューダンプ制御 | キューダンプファイルの編集 | eetrbqueed | ○ | ○ | ○ | ○ | ○
13 | 系切り替え | 系の状態表示 | eehamls | × | ○ | ○ | ○ | ○
14 | トラブルシュート | メッセージへの応答 | eetrbwtor※ | × | ○ | ○ | ○ | ○

（凡例）

オフライン：TP1/EEが起動していない状態での実行を示します。

オンライン：TP1/EEが起動している状態での実行を示します。

API：ee_adm_call_command関数での実行を示します。

実行系：CLサーバの実行系での実行を示します。

待機系：CLサーバの待機系での実行を示します。

○：実行できます。

×：実行できません。

注※

TP1/EEの運用コマンドです。このマニュアルでは，TP1キャッシュ機能使用時の差分だけを説明します。マニュアル「TP1/Server Base Enterprise Option 使用の手引」もあわせて参照してください。

eeactsv（サービスの閉塞解除）

TP1/EEの運用コマンドです。

TP1キャッシュ機能を使用する場合，注意事項が追加になります。

機能

サービスの閉塞を解除します。

注意事項

ユーザサービス関連定義のforbid_draw_serviceオペランドにYを指定した場合は，該当するサービスの処理キューの引き出し禁止を解除します。

eedctsv（サービスの閉塞）

TP1/EEの運用コマンドです。

TP1キャッシュ機能を使用する場合，注意事項が追加になります。

機能

サービスを閉塞します。

注意事項

ユーザサービス関連定義のforbid_draw_serviceオペランドにYを指定した場合は，該当するサービスの処理キューが引き出し禁止となります。

eehamls（系の状態表示）

機能

CLサーバの実行系および待機系の状態を表示します。

系切り替えできる状態かを確認できます。

コマンドの形式

eehamls -g サービスグループ名

オプションの説明

●-g サービスグループ名

　　～〈1～31文字の識別子〉

TP1/EEプロセスのサービスグループ名を指定します。

出力形式

eehamlsコマンドの出力形式を次の図に示します。

ONLの系が1つ，SBYの系が2つ表示された場合は，系切り替えできる状態です。

図6-5　eehamlsコマンドの出力形式

変数の説明

変数
意味

a
コマンドを実行した系に*が表示されます。ほかの系には何も表示されません。

bb....bb
ホスト名
HAモニタのenvironment定義文のnameオペランドで指定した名称が表示されます。

ccc.ccc.ccc.ccc
IPアドレス

dddd
ノード識別子

ee....ee
系の状態

ONL：実行系として稼働中

SBY：待機系として稼働中

(ONL)：実行系として起動処理中

(SBY)：待機系として起動処理中

***：クラスタグループから切り離されている状態

ONLY：CL単独起動機能を使用中

出力メッセージ

メッセージID | 内容 | 出力先
KFSB95900-E | メモリを確保できません。 | 標準エラー出力
KFSB95901-E | コマンドの形式が不正です。 | 標準エラー出力
KFSB95902-E | オプションが不正です。 | 標準エラー出力
KFSB95921-I | ヘルプメッセージ | 標準出力
KFSB95950-E | コマンドが失敗しました（TP1/EEプロセスでエラーを検知しました）。 | 標準エラー出力
KFSB95951-E | コマンドが失敗しました（コマンドプロセスでエラーを検知しました）。 | 標準エラー出力

注意事項

eehamlsコマンドに関する注意事項を次に示します。

実行系と待機系の間で通信障害が発生した場合，待機系はクラスタグループから切り離されます。この状態の場合，実行系のeehamlsコマンドと，HAモニタのmonshowコマンドでは表示結果が異なります。
実行系のeehamlsコマンドでは，切り離された系は"***"が表示されます。
HAモニタのmonshowコマンドでは"SBY"が表示されます。

待機系でこのコマンドを実行しても最新の状態が表示されません。そのため，このコマンドは，実行系で実行してください。

CL単独機能を使用する場合，ホスト名は「*」が32個，IPアドレスは「0.0.0.0」が表示されます。

eelspce（処理キュー制御用バッファの状態表示およびサービスの最大同時処理限界数の変更）

TP1/EEの運用コマンドです。

TP1キャッシュ機能を使用する場合，注意事項が追加になります。

機能

処理キュー制御用バッファ（PCE）の滞留状態や処理状態を表示したり，サービスの最大同時処理限界数を変更したりします。

注意事項

最大同時処理限界数の変更は，ユーザサービス関連定義のservice_attr定義コマンドで，-eオプションにparallelを指定するか，または-eオプションを省略したサービスに対してだけ実行できます。

eelspcenum（処理キュー制御用バッファの状態表示（通番付き））

機能

処理キュー制御用バッファ（PCE）の滞留状態，処理状態，およびメッセージ通番を表示します。

コマンドの形式

eelspcenum -g サービスグループ名
        〔-v サービス名〕

オプションの説明

●-g サービスグループ名

　　～〈1～31文字の識別子〉

TP1/EEプロセスのサービスグループ名を指定します。

●-v サービス名

　　～〈1～31文字の識別子〉

滞留状態を表示するサービス名を指定します。

指定を省略した場合，すべてのサービスの滞留状態を表示します。

出力形式

eelspcenumコマンドの出力形式を次の図に示します。

図6-6　eelspcenumコマンドの出力形式

変数の説明

変数
意味

a
キューの種別

p：優先キュー

n：通常キュー

bb....bb
滞留メッセージ数（最大10けた）

ccc
同時に処理できる処理キューの最大数（最大3けた）

ddd
処理中の処理キューの数（最大3けた）

ee....ee
書き込み通番（最大10けた）

ff....ff
読み出し通番（最大10けた）

vv....vv
サービス名（最大31文字）

出力メッセージ

メッセージID | 内容 | 出力先
KFSB95301-E | コマンドの形式が不正です。 | 標準エラー出力
KFSB95302-E | フラグ引数が不正です。 | 標準エラー出力
KFSB95304-E | オプションの組み合わせが不正です。 | 標準エラー出力
KFSB95305-E | コマンドが失敗しました。 | 標準エラー出力
KFSB95306-E | 領域の確保に失敗しました。 | 標準エラー出力
KFSB95307-E | 内部矛盾が発生しました。 | 標準エラー出力
KFSB95372-I | ヘルプメッセージ | 標準出力

注意事項

このコマンドを頻繁に使用すると，スループットが悪化するおそれがあります。

eemchotqact（出力キューの閉塞解除）

機能

出力キュー（OTQ）の閉塞を解除します。オプションによって次の指定ができます。

システムレベルでの出力キューの閉塞解除
すべての出力キューの閉塞を解除します。

サービスグループレベルでの出力キューの閉塞解除
指定したサービスグループ下の全サービスについて，出力キューの閉塞を解除します。

サービスレベルでの出力キューの閉塞解除
指定したサービスグループ下のサービスについて，出力キューの閉塞を解除します。

サービスグループレベルでの出力キューの閉塞解除の場合，閉塞解除対象のサービスグループと通信して，閉塞解除ができるかどうかをチェックしたあとで出力キューの閉塞を解除します。

コマンドの形式

eemchotqact -g サービスグループ名
      〔｛ -m サービスグループ名 -v サービス名｜-m サービスグループ名｝〕

オプションの説明

●-g サービスグループ名

　　～〈1～31文字の識別子〉

TP1/EEプロセスのサービスグループ名を指定します。

●-m サービスグループ名

　　～〈1～31文字の識別子〉

閉塞解除の対象とするサービスグループ名を指定します。

サービスグループ名を省略すると，システムレベルでの出力キューの閉塞解除となります。

●-v サービス名

　　～〈1～31文字の識別子〉

閉塞解除の対象とするサービス名を指定します。

サービス名を指定すると，サービスレベルでの出力キューの閉塞解除となります。

サービス名を省略すると，サービスグループレベルでの出力キューの閉塞解除となります。

出力メッセージ

メッセージID | 内容 | 出力先
KFSB98001-E | コマンドの形式が不正です。 | 標準エラー出力
KFSB98002-E | フラグ引数が不正です。 | 標準エラー出力
KFSB98004-E | オプションの組み合わせが不正です。 | 標準エラー出力
KFSB98005-E | コマンドが失敗しました。 | 標準エラー出力
KFSB98006-E | 領域の確保に失敗しました。 | 標準エラー出力
KFSB98023-I | システムレベルで出力キューの閉塞を解除しました。 | 標準出力
KFSB98024-I | サービスグループレベルで出力キューの閉塞を解除しました。 | 標準出力
KFSB98025-I | サービスレベルで出力キューの閉塞を解除しました。 | 標準出力
KFSB98032-E | 出力キューの閉塞解除に失敗しました。 | 標準エラー出力
KFSB98033-E | 一部のサービスグループで出力キューの閉塞解除に失敗しました。 | 標準エラー出力
KFSB98051-I | ヘルプメッセージ | 標準出力
KFSB98099-E | 内部矛盾が発生しました。 | 標準エラー出力

注意事項

eemchotqactコマンドに関する注意事項を次に示します。

サービスグループレベルで出力キューが閉塞中（出力キューの自動閉塞中を含む）の場合，サービスレベルでの出力キュー閉塞解除はできません。

サービスグループレベルでの出力キューの自動閉塞中に，サービスグループレベルでの出力キューの閉塞解除要求を行った場合，出力キューの閉塞監視を終了します。

CLサーバの実行系で，システムレベルでの出力キューの閉塞解除要求を行った場合，KFSB98033-Eメッセージが表示されると，実行系と待機系で結果が異なっています。eemchotqlsコマンドで実行系と待機系の出力キューの状態を確認してから，eemchotqdctコマンドを待機系で実行して，実行系の出力キューの状態と一致させてください。

eemchotqdct（出力キューの閉塞）

機能

出力キュー（OTQ）を閉塞します。オプションによって次の指定ができます。

システムレベルでの出力キューの閉塞
すべての出力キューを閉塞します。

サービスグループレベルでの出力キューの閉塞
指定したサービスグループ下の全サービスについて，出力キューを閉塞します。

サービスレベルでの出力キューの閉塞
指定したサービスグループ下のサービスについて，出力キューを閉塞します。

コマンドの形式

eemchotqdct -g サービスグループ名
      〔｛ -m サービスグループ名 -v サービス名｜-m サービスグループ名｝〕

オプションの説明

●-g サービスグループ名

　　～〈1～31文字の識別子〉

TP1/EEプロセスのサービスグループ名を指定します。

●-m サービスグループ名

　　～〈1～31文字の識別子〉

閉塞の対象とするサービスグループ名を指定します。

サービスグループ名を省略した場合，システムレベルでの出力キューの閉塞となります。

●-v サービス名

　　～〈1～31文字の識別子〉

閉塞の対象とするサービス名を指定します。

サービス名を指定すると，サービスレベルでの出力キューの閉塞となります。

サービス名を省略すると，サービスグループレベルでの出力キューの閉塞となります。

出力メッセージ

メッセージID | 内容 | 出力先
KFSB98001-E | コマンドの形式が不正です。 | 標準エラー出力
KFSB98002-E | フラグ引数が不正です。 | 標準エラー出力
KFSB98004-E | オプションの組み合わせが不正です。 | 標準エラー出力
KFSB98005-E | コマンドが失敗しました。 | 標準エラー出力
KFSB98006-E | 領域の確保に失敗しました。 | 標準エラー出力
KFSB98020-I | システムレベルで出力キューを閉塞しました。 | 標準出力
KFSB98021-I | サービスグループレベルで出力キューを閉塞しました。 | 標準出力
KFSB98022-I | サービスレベルで出力キューを閉塞しました。 | 標準出力
KFSB98030-E | 出力キューの閉塞に失敗しました。 | 標準エラー出力
KFSB98050-I | ヘルプメッセージ | 標準出力
KFSB98099-E | 内部矛盾が発生しました。 | 標準エラー出力

注意事項

サービスグループレベルでの出力キューの自動閉塞中に，サービスグループレベルでの出力キューの閉塞要求を行った場合，出力キューの閉塞監視を終了します。サービスレベルでの出力キューの閉塞要求を行った場合は，出力キューの閉塞監視は続行します。

eemchotqend（出力キューの未送信メッセージの監視終了）

機能

出力キュー（OTQ）の未送信メッセージの監視を終了します。出力キューに残った未送信メッセージは，キューダンプファイルに出力して終了します。

このコマンドは，出力キューに未送信メッセージが残っていて，オンライン終了ができない場合に使用します。

コマンドの形式

eemchotqend -g サービスグループ名

オプションの説明

●-g サービスグループ名

　　～〈1～31文字の識別子〉

TP1/EEプロセスのサービスグループ名を指定します。

出力メッセージ

メッセージID | 内容 | 出力先
KFSB98001-E | コマンドの形式が不正です。 | 標準エラー出力
KFSB98002-E | フラグ引数が不正です。 | 標準エラー出力
KFSB98005-E | コマンドが失敗しました。 | 標準エラー出力
KFSB98006-E | 領域の確保に失敗しました。 | 標準エラー出力
KFSB98054-I | ヘルプメッセージ | 標準出力
KFSB98099-E | 内部矛盾が発生しました。 | 標準エラー出力

eemchotqls（出力キューの状態表示）

機能

出力キュー（OTQ）の状態を表示します。

コマンドの形式

eemchotqls -g サービスグループ名
        〔-m サービスグループ名〕
          -s ｛act｜dct｜all｝

オプションの説明

●-g サービスグループ名

　　～〈1～31文字の識別子〉

TP1/EEプロセスのサービスグループ名を指定します。

●-m サービスグループ名

　　～〈1～31文字の識別子〉

出力キューの状態を表示するサービスグループ名を指定します。

このオプションを省略した場合，すべてのサービスグループが対象となります。

●-s ｛act｜dct｜all｝

表示する出力キューの状態を指定します。

act：

閉塞していないサービス名をすべて表示します。

dct：

閉塞しているサービス名をすべて表示します。

all：

すべてのサービス名を表示します。

出力形式

eemchotqlsコマンドの出力形式を次の図に示します。

図6-7　eemchotqlsコマンドの出力形式

変数の説明

変数
意味

aa....aa
サービスグループ名

bb....bb
サービス名

cc....cc
メッセージ送信要求済み出力キューの通番（10進数）
メッセージ送信要求がない場合は0が表示されます。

dd....dd
メッセージ送信済み出力キューの通番（10進数）
メッセージ送信要求がない場合は0が表示されます。

ee....ee
未送信メッセージ数（10進数）

xxx
出力キューの状態

ACT：閉塞解除状態

DCT：自動閉塞中

DCC：コマンドによる閉塞中

DCA：API関数による閉塞中

y
閉塞レベル

G：サービスグループレベル

S：サービスレベル

*：閉塞解除状態

出力対象のサービス名がない場合は，「対象のサービスはありません。」が表示されます。

出力メッセージ

メッセージID | 内容 | 出力先
KFSB98001-E | コマンドの形式が不正です。 | 標準エラー出力
KFSB98002-E | フラグ引数が不正です。 | 標準エラー出力
KFSB98004-E | オプションの組み合わせが不正です。 | 標準エラー出力
KFSB98005-E | コマンドが失敗しました。 | 標準エラー出力
KFSB98006-E | 領域の確保に失敗しました。 | 標準エラー出力
KFSB98053-I | ヘルプメッセージ | 標準出力
KFSB98099-E | 内部矛盾が発生しました。 | 標準エラー出力

注意事項

CLサーバの場合，待機系では実行系よりも遅れて出力キューの状態が更新されます。

eemchotqskip（出力キューの未送信メッセージのスキップ）

機能

指定したサービスグループ下のサービス名に対応する出力キューの未送信のメッセージ（送信に失敗したメッセージを含む）をスキップして，送信済みにします。

eemchotqskipコマンドは，該当する出力キューが閉塞中の場合にだけ実行できます。

コマンドの形式

eemchotqskip -g サービスグループ名
            -m サービスグループ名
            -v サービス名
            -s ｛all｜one｜num｝
          〔-n 出力キュー通番〕

オプションの説明

●-g サービスグループ名

　　～〈1～31文字の識別子〉

TP1/EEプロセスのサービスグループ名を指定します。

●-m サービスグループ名

　　～〈1～31文字の識別子〉

スキップ対象とする出力キューのサービスグループ名を指定します。

●-v サービス名

　　～〈1～31文字の識別子〉

スキップ対象とする出力キューのサービス名を指定します。

●-s ｛all｜one｜num｝

送信済みにするメッセージを指定します。

all：

未送信メッセージをすべてスキップし，送信済みにします。

one：

未送信の先頭1メッセージをスキップし，送信済みにします。

num：

-nオプションで指定された出力キュー通番までの未送信メッセージをスキップし，送信済みにします。

●-n 出力キュー通番

　　～((1～4294967295))

送信済みにする出力キューの出力キュー通番を指定します。

指定した出力キュー通番と一致する未送信メッセージがある場合は，指定した通番までのメッセージをスキップし，送信済みにします。指定した出力キュー通番と一致する未送信メッセージがない場合は，メッセージをスキップしないで正常終了します。

このオプションは，-sオプションでnumを指定した場合だけ指定できます。

出力メッセージ

メッセージID | 内容 | 出力先
KFSB98001-E | コマンドの形式が不正です。 | 標準エラー出力
KFSB98002-E | フラグ引数が不正です。 | 標準エラー出力
KFSB98004-E | オプションの組み合わせが不正です。 | 標準エラー出力
KFSB98005-E | コマンドが失敗しました。 | 標準エラー出力
KFSB98006-E | 領域の確保に失敗しました。 | 標準エラー出力
KFSB98026-I | 未送信メッセージをスキップしました。 | 標準出力
KFSB98034-E | 未送信メッセージのスキップに失敗しました。 | 標準エラー出力
KFSB98052-I | ヘルプメッセージ | 標準出力
KFSB98099-E | 内部矛盾が発生しました。 | 標準エラー出力

注意事項

eemchotqskipコマンドに関する注意事項を次に示します。

CLサーバの待機系では，このコマンドは実行できません。

送信スキップ対象のメッセージがない場合は，正常終了します。

eepcerefer（滞留メッセージのファイル出力）

機能

引き出し禁止状態のサービスの入力キュー（ITQ）に滞留しているメッセージを，指定したファイルに出力して参照できるようにします。

出力対象となるのは，一つのサービスの通常キューまたは優先キューのどちらかのキューに滞留しているすべてのメッセージです。

ファイルへの出力は，TP1/EEプロセスで行います。eepcereferコマンドは，TP1/EEプロセスが出力要求を受け付けた時点で終了します。TP1/EEプロセスは，ファイル出力終了時にKFSB85407-Iメッセージを出力します。

コマンドの形式

eepcerefer -g サービスグループ名
          -v サービス名
          -p ｛p｜n｝
          -o 出力ファイル名
        〔-r〕

オプションの説明

●-g サービスグループ名

　　～〈1～31文字の識別子〉

TP1/EEプロセスのサービスグループ名を指定します。

●-v サービス名

　　～〈1～31文字の識別子〉

滞留メッセージを出力するサービス名を指定します。

●-p ｛p｜n｝

優先キュー，通常キューのどちらの滞留メッセージを出力するかを指定します。

p：

優先キュー

n：

通常キュー

●-o 出力ファイル名

　　～〈510文字以内のパス名〉

滞留しているメッセージを出力するファイル名を絶対パス名で指定します。ファイルの容量は，次に示す計算式で見積もってください。

滞留メッセージ数×（メッセージ長×5＋200）＋2000（単位：バイト）

●-r

このオプションを指定すると，-oオプションで指定したファイルがすでにある場合にファイルを上書きします。上書きした場合，元のファイルの内容は失われます。このオプションを指定する場合は，必要に応じて手動でバックアップを取得してください。

このオプションを省略すると，-oオプションで指定したファイルがすでにある場合は，ファイル出力を中止します。

出力形式

eepcereferコマンドの出力形式を次の図に示します。

図6-8　eepcereferコマンドの出力形式

注※

滞留メッセージの数だけ繰り返します。

変数の説明

変数
意味

aa-aa-aa
コマンドを実行したTP1/EEのバージョン

bb-bb-bb
コマンドを実行したXTCのバージョン

cc....cc
サービスグループ名（最大31文字）

dddddddd
TP1/EEのランID（16進数，8けた）

ee....ee
サービス名（最大31文字）

f
キューの種別（1文字）

p：優先キュー

n：通常キュー

gg....gg
メッセージ通番（10進数，最大10けた）

hhh
メッセージ種別

RPC：RPCメッセージ

MCH：MCHメッセージ

MCP：MCPメッセージ

TIM：タイマトランザクション

RLn：MCP後処理トランザクション
RLO：コネクション確立
RLC：コネクション解放
RLF：論理端末閉塞解除
RLH：論理端末閉塞

MV：イベントトランザクション

ll....ll
メッセージ長（10進数，最大10けた）
メッセージ長が0の場合は，以降の項目は出力しません。

xxxxxxxx
メッセージの先頭からのロケーション（16進数，8けた）

yyyyyyyy
メッセージの内容（16進数，最大8けた）
1行前に出力した行と同一の場合，次の文字列を出力します。

TO NEXT LINE LOCATION SAME AS ABOVE

複数行同一の場合，次の文字列を一度だけ出力します。

TO NEXT LINE LOCATION SAME AS ABOVE

ただし，最終行の2行が同一の場合は，「TO NEXT LINE LOCATION SAME AS ABOVE」を出力しません。

zzzzzzzzzzzzzzzz
メッセージの内容（ASCII文字で最大16文字）
表示できないASCII文字の場合は「.」を出力します。

出力メッセージ

メッセージID | 内容 | 出力先
KFSB95301-E | コマンドの形式が不正です。 | 標準エラー出力
KFSB95302-E | フラグ引数が不正です。 | 標準エラー出力
KFSB95304-E | オプションの組み合わせが不正です。 | 標準エラー出力
KFSB95305-E | コマンドが失敗しました。 | 標準エラー出力
KFSB95306-E | 領域の確保に失敗しました。 | 標準エラー出力
KFSB95307-E | 内部矛盾が発生しました。 | 標準エラー出力
KFSB95378-I | ヘルプメッセージ | 標準出力
KFSB95379-I | コマンドを受け付けました。 | 標準出力
KFSB95380-E | コマンドを受け付けませんでした。 | 標準エラー出力

注意事項

eepcereferコマンドに関する注意事項を次に示します。

このコマンドを頻繁に使用すると，スループットが悪化するおそれがあります。

引き出し禁止状態ではないサービスの滞留メッセージは出力できません。

滞留メッセージのファイル出力中に引き出し禁止状態を解除した場合は，出力途中のメッセージのファイル出力が終了した時点で，ファイル出力を終了します。後続の滞留メッセージはファイルに出力されません。

滞留メッセージのファイル出力中にeepceskipコマンドを実行した場合は，出力途中のメッセージのファイル出力が終了した時点で，ファイル出力を終了します。後続の滞留メッセージはファイルに出力されません。

滞留メッセージのファイル出力中は，出力するメッセージのサイズによって1キロバイト～8メガバイトのワーク領域，またはXTC用ワーク領域（XTCPOOL）を使用します。

eepceskip（滞留メッセージのスキップ）

機能

入力キュー（ITQ）の滞留メッセージを読み出し済みにして，入力キューから破棄します。

指定したサービス名に対応する入力キューのメッセージを読み出し済みにします。スキップ要求を受け付けるのは，該当するサービスの処理キューが引き出し禁止状態であり，かつ該当するサービスのトランザクションが動作していない場合だけです。

コマンドの形式

eepceskip -g サービスグループ名
         -v サービス名

オプションの説明

●-g サービスグループ名

　　～〈1～31文字の識別子〉

TP1/EEプロセスのサービスグループ名を指定します。

●-v サービス名

　　～〈1～31文字の識別子〉

滞留メッセージをスキップするサービス名を指定します。

出力メッセージ

メッセージID | 内容 | 出力先
KFSB95301-E | コマンドの形式が不正です。 | 標準エラー出力
KFSB95302-E | フラグ引数が不正です。 | 標準エラー出力
KFSB95304-E | オプションの組み合わせが不正です。 | 標準エラー出力
KFSB95305-E | コマンドが失敗しました。 | 標準エラー出力
KFSB95306-E | 領域の確保に失敗しました。 | 標準エラー出力
KFSB95307-E | 内部矛盾が発生しました。 | 標準エラー出力
KFSB95375-I | ヘルプメッセージ | 標準出力
KFSB95376-I | 滞留メッセージのスキップが成功しました。 | 標準出力
KFSB95377-E | 滞留メッセージのスキップが失敗しました。 | 標準エラー出力

注意事項

スキップ対象のメッセージがない場合は，正常終了します。

eetrbqueed（キューダンプファイルの編集）

機能

キューダンプファイルの内容を編集して出力します。

コマンドの形式

eetrbqueed 〔-e ｛m｜f｝〕
          〔-q ｛i｜o｝〕
          〔-g サービスグループ名〕
          〔-v サービス名〕
          〔-o 編集結果出力ファイル名〕
            キューダンプファイル名 〔キューダンプファイル名〕…

オプションの説明

●-e ｛m｜f｝

　　～《f》

編集種別を指定します。

m：

メッセージの内容を出力します。

f：

キューダンプファイルの一覧を出力します。

●-q ｛i｜o｝

キュー種別を指定します。

このオプションを省略した場合は，入力キュー（ITQ）および出力キュー（OTQ）の両方のメッセージを出力します。

i：

入力キューのメッセージだけ出力します。

o：

出力キューのメッセージだけ出力します。

●-g サービスグループ名

　　～〈1～31文字の識別子〉

表示対象とする出力キューのサービスグループ名を指定します。

このオプションを省略した場合は，すべてのサービスグループを対象として表示します。

このオプションは，-qオプションにoを指定した場合にだけ指定できます。

●-v サービス名

　　～〈1～31文字の識別子〉

表示対象とする入力キューまたは出力キューのサービス名を指定します。

このオプションを省略した場合は，すべてのサービスを対象として表示します。

このオプションは，-qオプションを指定した場合にだけ指定できます。

●-o 編集結果出力ファイル名

　　～〈パス名〉

編集結果を出力するファイル名を相対パス名で指定します。-eオプションにmを指定した場合は，必ずこのオプションを指定してください。-eオプションにfを指定した場合は指定できません。

●キューダンプファイル名 〔キューダンプファイル名〕…

　　～〈パス名〉

編集するキューダンプファイル名を相対パス名で指定します。-eオプションにfを指定した場合は，キューダンプファイル名を複数指定できます。その場合，キューダンプファイル名は最大1024個指定できます。

出力形式

-eオプションにmを指定した場合

eetrbqueedコマンドの出力形式（-eオプションにmを指定した場合）を次の図に示します。

図6-9　eetrbqueedコマンドの出力形式（-eオプションにmを指定した場合）

注※1

入力キューの滞留メッセージ数分繰り返し出力します。

注※2

入力キュー仮登録の滞留メッセージ数分繰り返し出力します。

注※3

入力キュー仮登録の滞留メッセージに対応する送信メッセージ数分繰り返し出力します。

注※4

出力キューの送信メッセージ数分繰り返し出力します。

変数の説明

変数
意味

aa-aa-aa
コマンドを実行したTP1/EEのバージョン

bb-bb-bb
コマンドを実行したXTCのバージョン

cc....cc
編集コマンドの引数

dd....dd
キューダンプファイル名

eeee/ee/ee ee:ee:ee eee.eee
ファイルに出力を開始した日付
年号/月/日 時間：分：秒 ミリ秒．マイクロ秒

ff-ff-ff
ファイルを作成したTP1/EEのバージョン

gg-gg-gg
ファイルを作成したXTCのバージョン

g1-g1-g1
ファイルを作成したMCPのバージョン
MCPの受信メッセージを永続化している場合にだけ出力します。

hh....hh
サービスグループ名（最大31文字）

iiiiiiii
TP1/EEのランID（16進数，8けた）

jj....jj
サービス名（最大31文字）

kkk
メッセージ種別

RPC：RPCメッセージ

MCP：MCPメッセージ

MCH：MCHメッセージ

ll....ll
メッセージ長（10進数，最大10けた）
メッセージ長が0の場合，xxxxxxxxからzzzzzzzzzzzzzzzzの項目は出力しません。

nn....nn
送信先サービスグループ名（最大31文字）

oo....oo
送信先サービス名（最大31文字）

xxxxxxxx
メッセージの先頭からのロケーション（16進数，8けた）

yyyyyyyy
メッセージの内容（16進数，最大8けた）
1行前に出力した行と同一の場合，次の文字列を出力します。

TO NEXT LINE LOCATION SAME AS ABOVE

複数行同一の場合，次の文字列を一度だけ出力します。

TO NEXT LINE LOCATION SAME AS ABOVE

ただし，最終行の2行が同一の場合は，「TO NEXT LINE LOCATION SAME AS ABOVE」を出力しません。

zzzzzzzzzzzzzzzz
メッセージの内容（ASCII文字で最大16文字）
表示できないASCII文字の場合は「.」を出力します。

-eオプションにfを指定した場合

eetrbqueedコマンドの出力形式（-eオプションにfを指定した場合）を次の図に示します。

図6-10　eetrbqueedコマンドの出力形式（-eオプションにfを指定した場合）

注※1

指定されたファイルがキューダンプファイルの場合，キューダンプファイルの情報を繰り返し出力します。

注※2

指定されたファイルがキューダンプファイル以外の場合に出力します。

変数の説明

変数
意味

aa-aa-aa
コマンドを実行したTP1/EEのバージョン

bb-bb-bb
コマンドを実行したXTCのバージョン

cc....cc
編集コマンドの引数

dd....dd
キューダンプファイル名

eeee/ee/ee ee:ee:ee eee.eee
ファイルに出力を開始した日付
年号/月/日　時間：分：秒 ミリ秒．マイクロ秒

ff-ff-ff
ファイルを作成したTP1/EEのバージョン

gg-gg-gg
ファイルを作成したXTCのバージョン

hh....hh
サービスグループ名（最大31文字）

iiiiiiii
TP1/EEのランID（16進数，8けた）

出力メッセージ

メッセージID | 内容 | 出力先
KFSB95400-E | メモリを確保できません。 | 標準エラー出力
KFSB95401-E | コマンドの形式が不正です。 | 標準エラー出力
KFSB95402-E | コマンドのオプションが不正です。 | 標準エラー出力
KFSB95403-E | コマンドのオプションの組み合わせが不正です。 | 標準エラー出力
KFSB95409-E | バージョンが不一致です。 | 標準エラー出力
KFSB95447-I | ヘルプメッセージ | 標準出力

注意事項

編集対象の滞留メッセージがない場合，ヘッダ情報だけを表示します。

eetrbwtor（メッセージへの応答）

TP1/EEの運用コマンドです。

TP1キャッシュ機能を使用する場合，応答するメッセージに次のメッセージが追加になります。

KFSB85801-Qメッセージ

KFSB85802-Qメッセージ

機能

eetrbwtorコマンド実行待ちメッセージを出力したTP1/EEに応答します。

オプションの説明

応答するメッセージによって，指定できるオプションが異なります。メッセージごとの指定できるオプションを次の表に示します。

表6-6　eetrbwtorコマンドに指定できるオプション

メッセージID
内容
オプション
オプションの意味

KFSB85801-Q
実行系孤立時の，孤立終了モードの指定
｛-a｜-b｝

-a：孤立終了モードAで終了します。

-b：孤立終了モードBで終了します。

KFSB85802-Q
キューダンプファイルの出力障害
｛-r｜-c｝

-r：キューダンプファイルの出力をリトライします。

-c：キューダンプファイルの出力を中止して，オンラインを終了します。

7.　CL連携による系切り替え機能

この章では，CL連携による系切り替え機能の仕組みと運用方法について説明します。

＜この章の構成＞

7.1　CL連携の概要

7.2　自動系切り替えの監視対象となる障害

7.3　系の状態表示

7.4　実行系孤立状態になった場合の対処

7.5　実行系と待機系の間で通信障害が発生した場合の対処

7.6　転送処理によるリソースの永続化

7.7　システム間通信でのメッセージ転送処理

7.8　転送処理での時間監視機能

7.9　転送処理で障害が発生したときのXTCの処理

7.10　系切り替えが発生したときのXTCの処理

7.11　CLサーバで実行できるHAモニタのコマンド

7.1　CL連携の概要

CLサーバでは，CL連携による系切り替えを行って高可用性を実現しています。ここでは，CL連携による系切り替えの概要について説明します。

なお，この章の説明は，HAモニタによる系切り替え機能の基礎的な知識があることを前提としています。HAモニタについては，マニュアル「高信頼化システム監視機能 HAモニタ Linux(R)編」を参照してください。

＜この節の構成＞

7.1.1　CL連携による系切り替え

7.1.2　待機系がなくなった場合のXTCの処理

7.1.3　系が切り替わるときの処理の流れ

7.1.4　CL連携時の制限事項

7.1.5　HAモニタ情報ファイル

7.1.1　CL連携による系切り替え

CL連携による系切り替え機能には，次の3種類があります。

自動系切り替え

計画系切り替え

連動系切り替え

＜この項の構成＞

(1)　自動系切り替え

(2)　計画系切り替え

(3)　連動系切り替え

(1)　自動系切り替え

CLサーバでは，HAモニタのマルチスタンバイ機能を使用して，システムを三重化して障害に備えています。処理を実行しているマシンで障害が発生した場合，待機しているマシンに自動的に業務処理が切り替わります。これを自動系切り替えといいます。

自動系切り替えを次の図に示します。

図7-1　自動系切り替え

説明

実行系でTP1/EEのプロセスダウンが発生した場合，待機系の一つを実行系に切り替えて，オンライン処理を続行します。

なお，オンライン中に業務処理を行っている系を実行系，待機している系を待機系といいます。XTCの開始時，どのサーバが実行系，待機系になるかはHAモニタの定義で設定します。

なお，CL連携を行うサーバのグループをクラスタグループといいます。クラスタグループは，UDPグループ情報関連定義のclgrpdef定義コマンドで定義します。

参考

HAサーバは，マルチキャストによってCLサーバの各サーバにメッセージを送信しているため，どのサーバが実行系であるかを意識する必要はありません。

(2)　計画系切り替え

HAモニタの計画系切り替えコマンドを実行すると，実行系を強制停止して待機系に切り替えます。これを，計画系切り替えといいます。

(3)　連動系切り替え

実行系で複数のサーバが動作している場合に，障害発生や計画系切り替えコマンドの実行を契機として，複数のサーバを一括して切り替える機能を連動系切り替えといいます。

連動系切り替えは，複数のサーバをグループ化することで実現します。グループ化したサーバでは，そのうちの一つに障害が発生した際に，グループ単位で系を切り替えることができます。なお，グループ化したサーバ内でも，障害発生によって系を切り替えるサーバと系を切り替えないサーバを個別に設定できます。

連動系切り替えの環境設定は，HAモニタで行います。

7.1.2　待機系がなくなった場合のXTCの処理

TP1/EEのプロセスダウンが続くと，待機系がなくなり，実行系だけの1台構成になることがあります。この状態を実行系孤立状態といいます。実行系孤立状態となった場合，XTCはデータの保全を最優先して，メモリ上のダンプ情報をファイルに出力して停止します。

実行系孤立状態となったときのXTCの処理を次の図に示します。

図7-2　実行系孤立状態となったときのXTCの処理

説明

実行系孤立状態となった場合，キューダンプとメモリダンプをファイルに出力して，TP1/EEを終了します。

CLサーバが1台のサーバだけで稼働することはありません。

実行系孤立状態となった場合の対処については，「7.4　実行系孤立状態になった場合の対処」を参照してください。

なお，実行系と待機系で通信ができないために，実行系孤立状態になることがあります。通信障害が発生したときのXTCの処理については，「7.5　実行系と待機系の間で通信障害が発生した場合の対処」を参照してください。

7.1.3　系が切り替わるときの処理の流れ

系が切り替わるときの処理の流れを次の図に示します。ここでは，障害発生を契機とした系切り替えを例に説明します。

図7-3　系が切り替わるときの処理の流れ

説明

HAモニタからの系切り替え指示を検知します。

自系のHAモニタに自系のTP1/EEが待機系から実行系に切り替わることを連絡します。

キューログ回復処理によって，自系のTP1/EEと待機系のリソースの状態を一致させます。キューログ回復処理については，「7.10　系切り替えが発生したときのXTCの処理」を参照してください。

実行系連絡トランザクション（UI）を起動します。
系切り替えが発生した場合，待機系が実行系に切り替わったことをユーザに通知するために実行系連絡トランザクションが起動されます。

切り替わった系で処理を再開します。

注意

XTCの開始処理中は系切り替えが発生しないため，実行系連絡トランザクションが起動することはありません。しかし，XTCの終了処理中に障害が発生すると，タイミングによっては実行系連絡トランザクションが起動することがあります。

実行系連絡トランザクションでは，系切り替え前の実行系の状態を参照できます。実行系連絡トランザクション（UI）のXTC拡張トランザクションインタフェース情報にEERPC_STATUS_BEFORE_MEが設定されている場合は，実行系連絡トランザクションの終了後にXTCの終了処理を行います。そのため，新規のトランザクションや，リソースの転送が発生するAPIまたはコマンドを実行しないでください。XTCの終了処理が完了する前に系切り替えが発生すると，再度実行系連絡トランザクションが起動されます。このとき，同じAPIまたはコマンドを実行すると，データベースの二重更新や，メッセージの二重送信などが発生するおそれがあります。

7.1.4　CL連携時の制限事項

CL連携による系切り替えの制限事項を次に示します。

CLサーバの稼働中は，プロセスダウンしたTP1/EEを再開始できません。そのため，TP1/EEのプロセスダウンによって2台構成になったCLサーバを3台構成に戻すには，CLサーバの各サーバをいったん停止し，3台構成に戻したあと，CLサーバを再起動する必要があります。

CLサーバのシミュレート機能を使用している場合は，HAモニタと連携しません。CLサーバのシミュレート機能については，「2.10.1　CLサーバのシミュレート機能」を参照してください。

7.1.5　HAモニタ情報ファイル

XTCがHAモニタに接続したとき，$DCDIR/spool/dceeinf下にHAモニタ情報ファイルが作成されます。このファイルはXTCとHAモニタの間で使用され，XTCの正常終了時，XTCがHAモニタ情報ファイルを自動的に削除します。

XTCの稼働中にHAモニタ情報ファイルの読み込みまたは書き込みに失敗すると，XTCは異常終了します。この場合，原因を取り除いたあとに，XTCを再起動する必要があります。

なお，XTCが異常終了した場合，HAモニタ情報ファイルが自動的に削除されないことがあります。XTCの再起動時にHAモニタ情報ファイルが存在すると，KAMN308-Eメッセージ（待機サーバが異常終了した旨のメッセージ）が出力されますが，XTCの再起動には影響ありません。そのため，このメッセージは無視してください。

7.2　自動系切り替えの監視対象となる障害

HAモニタは，TP1/EEのプロセスを監視しています。HAモニタがTP1/EEのプロセスダウンを検知したときに，HAモニタが系を切り替えます。また，そのほかに，ハードウェア障害や，カーネル障害が発生したときも，HAモニタによって系が切り替えられます。

＜この節の構成＞

7.2.1　HAモニタが監視する障害

7.2.2　系切り替えの単位

7.2.1　HAモニタが監視する障害

HAモニタが監視する障害を次の表に示します。これらの障害が発生したときに系が切り替わります。

表7-1　HAモニタが監視する障害

項番 | 障害の種類 | 系切り替えの単位※
1 | ハードウェア障害 | HAモニタ単位
2 | ハードウェアの電源断
3 | カーネル障害
4 | HAモニタの異常終了
5 | TP1/Server Baseの異常終了 | TP1/Server Base単位
6 | スレッドハングアップ時間監視や，トランザクション処理時間監視によるTP1/EEのプロセスダウン | TP1/EEプロセス単位
7 | TP1/EEプロセスの論理エラー
8 | リソースの障害（障害によってシステムの運転が続行できない場合）

注※

系切り替えの単位の詳細については，「7.2.2　系切り替えの単位」を参照してください。

通信障害は，HAモニタの監視対象外となります。通信障害が発生した場合のXTCの処理については，「7.5　実行系と待機系の間で通信障害が発生した場合の対処」を参照してください。

■スローダウンの検知

TP1/EEのスレッドハングアップ時間監視によってシステムのスローダウンを検知しています。スレッドハングアップ時間監視によってTP1/EEのプロセスをダウンさせて，系を切り替える仕組みになっています。

7.2.2　系切り替えの単位

発生した障害の種類によって系が切り替わる単位が異なります。次に示す三つのうちのどれかの単位で系が切り替わります。

HAモニタ単位

TP1/Server Base単位

TP1/EEプロセス単位

＜この項の構成＞

(1)　HAモニタ単位の系切り替え

(2)　TP1/Server Base単位の系切り替え

(3)　TP1/EEプロセス単位の系切り替え

(1)　HAモニタ単位の系切り替え

ハードウェア障害，カーネル障害，HAモニタが異常終了した場合などは，系障害として系切り替えが行われます。この場合，このサーバ下の全TP1/EEプロセスの系が切り替わります。これをHAモニタ単位の系切り替えといいます。

(2)　TP1/Server Base単位の系切り替え

TP1/Server BaseはHAモニタの監視対象外のため，TP1/Server Baseが異常終了しても，TP1/Server Baseの系は切り替わりません。TP1/Server Baseが異常終了した場合，TP1/EEのプロセスもダウンします。このTP1/EEのプロセスダウンをHAモニタが検知して，系を切り替える仕組みになっています。この場合，TP1/Server Base下の全TP1/EEプロセスの系が切り替わります。これをTP1/Server Base単位の系切り替えといいます。

注意

CL連携を行う場合，CLサーバのTP1/Server Baseは常に実行系として動作するため，TP1/Server BaseをHAモニタの監視対象にしないでください。そのためには，システムサービス構成定義のha_confオペランドにNを指定してください。

(3)　TP1/EEプロセス単位の系切り替え

TP1/EEのプロセスダウンが発生した場合，プロセスダウンしたTP1/EEプロセスの系だけが切り替わります。ほかのTP1/EEプロセスの系は切り替わりません。これをTP1/EEプロセス単位の系切り替えといいます。

7.3　系の状態表示

CLサーバの各サーバの状態は，HAモニタのmonshowコマンド，またはTP1/EE/XTCのeehamlsコマンドで確認できます。確認できる内容を次の表に示します。

コマンド
確認できる内容

monshow

XTCが稼働中かを確認できます。

実行系XTCが稼働中のホストを確認できます。

eehamls

実行系のXTCでeehamlsコマンドを実行すると系切り替えできる状態かを確認できます。
ONLの系が1つ，SBYの系が2つ表示された場合は，系切り替えできる状態です。
ONLの系が1つ，SBYの系が1つの場合，系切り替え後，孤立終了モードとなる状態です。

7.4　実行系孤立状態になった場合の対処

ここでは，待機系がなくなり，実行系孤立状態になったときのXTCの処理と管理者の対処について説明します。

＜この節の構成＞

(1)　XTCの処理

(2)　管理者の対処

(3)　DB管理者の対処

(1)　XTCの処理

実行系孤立状態となった場合，XTCは次に示す順序で終了処理を行います。

受信メッセージに対してエラーを応答するか，または受信メッセージを破棄します。送信元で発行したAPIによって処理が異なります。XTCの処理は次に示すどちらかになります。

一方送信メッセージを受信した場合，受信メッセージを破棄します。送信元では，エラートランザクションを起動します。

RPCメッセージを受信した場合，受信メッセージを破棄します。送信元で発行したAPIがエラーとなります。

出力キューを閉塞します。

トランザクションの受け付けを休止します。
実行中のトランザクションの終了を待ちます。新規トランザクションは起動しません。

キューログ回復処理を行います。
キューログ回復処理については，「7.10　系切り替えが発生したときのXTCの処理」を参照してください。

キューダンプを出力します。
XTCの終了時に出力するキューダンプと同じ情報が出力されます。キューダンプの出力先については，「2.9.2(2)(b)実行系孤立状態になったとき」を参照してください。

XDBのデータベースのデータを格納したメモリダンプを出力します。
メモリダンプについては，マニュアル「TP1/EE/Extended Data Cache 使用の手引」を参照してください。

eetrbwtorコマンドの入力待ち状態になります。
管理者は，孤立終了モードを指定してeetrbwtorコマンドを実行してください。詳細については，「(2)管理者の対処」を参照してください。
この間，トランザクションの受け付けを休止しているため，新規トランザクションは起動されません。

実行系連絡トランザクション（UI）を起動します。

トランザクションの受け付けを開始します。

出力キューの閉塞を解除します。

XTCの終了処理を行います。
eetrbwtorコマンドに指定された孤立終了モードに従ってXTCを終了します。
このとき，終了トランザクションのトランザクションインタフェース情報のプロセス終了要因に孤立終了モードが設定されます。

参考

XTCの開始処理中に実行系孤立状態になった場合，XTCの開始処理を中止します。

(2)　管理者の対処

XTCがメモリダンプを出力したあと，eetrbwtorコマンドの入力待ち状態になります。管理者は，孤立終了モードを指定してeetrbwtorコマンドを実行し，XTCを終了してください。

■孤立終了モード

孤立終了モードには，次に示す2種類があります。

孤立終了モードA
正常終了と同様に，処理キュー上の受け付け済みのサービス要求をすべて処理したあとにXTCを終了します。出力キュー（OTQ）の終了監視は，mch_send_end_otqwatchオペランドの指定値に従います。このとき，ERRTRN4を起動します。

孤立終了モードB
計画停止Bと同様に処理キュー上の受け付け済みのサービス要求をすべて破棄します。出力キューの終了監視は行いません。

なお，次に示す場合は，孤立終了モードAでXTCが終了します。

eetrbwtorコマンドを実行する前にeesvstopコマンドを実行した場合

XTCの終了処理中に実行系孤立状態となった場合

(3)　DB管理者の対処

メモリダンプファイルから表データを抽出する場合，最新のメモリダンプファイルを使用してください。最新のメモリダンプファイルの判断方法は，すべての系のメモリダンプファイル名称を比較し，一番進んでいるコミット通番から判断してください。プロセスダウンなどでメモリダンプファイルが出力されないものは比較対象から除いてください。

メモリダンプファイル名称は次のようになります。

”サービスグループ名_ノードID_ランID_CL通番_xdb_コミット通番”

ランID：16進数8けた固定

CL通番：16進数16けた固定

コミット通番：16進数16けた固定

7.5　実行系と待機系の間で通信障害が発生した場合の対処

ここでは，実行系と待機系の間で通信障害が発生した場合のXTCの処理と管理者の対処ついて説明します。

＜この節の構成＞

7.5.1　通信障害が発生した場合のXTCの処理と管理者の対処

7.5.2　実行系とすべての待機系との間で通信ができない場合のXTCの処理

7.5.1　通信障害が発生した場合のXTCの処理と管理者の対処

CL連携では，実行系と待機系の間で通信を行い，実行系の状態を待機系に逐次反映しています。実行系と待機系の間で通信障害が発生した場合，通信障害が発生した待機系をクラスタグループから切り離します。

実行系と待機系の間で通信障害が発生した場合のXTCの処理を次の図に示します。

図7-4　実行系と待機系の間で通信障害が発生した場合のXTCの処理

■管理者の対処

切り離された待機系（図中の待機系B）でeesvstopコマンドなどを実行して，待機系をすぐに終了してください。

注意

切り離された待機系（図中の待機系B）が終了する前に実行系が異常終了した場合，切り離された待機系が実行系になることがあります。この場合，リソースなどが正しく待機系に転送されないで，メモリ内の情報が古くなっているおそれがあります。そのため，管理者は次に示す手順で実行系を切り替えてください。

切り替わった実行系と待機系の間（図中の待機系Aと待機系Bの間）で通信ができることを確認してください。

切り替わった実行系（図中の待機系B）を終了させて，もう一つの待機系（図中の待機系A）を実行系にしてください。
このとき，実行系孤立状態になります。対処方法については，「7.4　実行系孤立状態になった場合の対処」を参照してください。

なお，切り替わった実行系と待機系の間で通信ができない場合は，系を切り替えることはできません。

通信障害によって待機系がなくなり，実行系孤立状態になった場合は，メモリ上のダンプ情報をファイルに出力して停止します。詳細については，「7.1.2　待機系がなくなった場合のXTCの処理」を参照してください。

なお，通信障害はHAモニタで監視できません。そのため，HAモニタが管理しているサーバの状態と，XTCが管理しているサーバの状態が異なることがあります。

7.5.2　実行系とすべての待機系との間で通信ができない場合のXTCの処理

実行系とすべての待機系との間で通信ができない場合は，キューダンプとメモリダンプをファイルに出力して，実行系を終了します。そして，待機系のうちの一つを実行系にして業務を続行します。

実行系とすべての待機系との間で通信ができない場合のXTCの処理を次の図に示します。

図7-5　実行系とすべての待機系との間で通信ができない場合のXTCの処理

7.6　転送処理によるリソースの永続化

XTCでは，次に示す情報を待機系に逐次転送して永続化しています。

実行系で更新されたリソースの情報

実行系で処理されたトランザクションの情報

これによって，実行系でTP1/EEのプロセスダウンが発生しても，実行系のリソース更新結果とトランザクションを待機系で保証しています。これら一連の処理を転送処理といいます。

ここでは，転送処理によるリソースの永続化処理について説明します。

＜この節の構成＞

7.6.1　待機系に転送されるリソース

7.6.2　入力メッセージの永続化

7.6.3　トランザクションと同期して転送されるリソースの永続化

7.6.4　トランザクションと非同期に転送されるリソースの永続化

7.6.5　UAPからロールバック要求があった場合の転送処理

7.6.6　UAPが異常終了した場合の転送処理

7.6.1　待機系に転送されるリソース

ここでは，転送処理によって待機系に転送されるリソースについて説明します。

待機系に転送されるリソースの一覧を次の表に示します。XTCでは，これらのリソースを待機系に転送することでリソースを永続化しています。

表7-2　待機系に転送されるリソースの一覧

項番
待機系に転送されるリソース
説明

1
入力メッセージ※1
実行系で受信した次の入力メッセージです。

RPCメッセージ
RPC要求メッセージ（RPC関連定義のrpc_recv_permanenceオペランドにYを指定）です。

MCPメッセージ
MCPが受信したメッセージ（MCP構成定義のeemcpfunc定義コマンドで-mオプションのrecvpermanenceオペランドにyesを指定）です。

MCHメッセージ
永続指定のトランザクション同期の一方送信メッセージ，およびトランザクション非同期の一方送信メッセージです。

2
トランザクションと同期して転送されるリソース※2
送信メッセージ
UAPからのee_mch_cmtsend関数（永続指定）要求時のメッセージを永続化します。

3
XDBの更新ログ
データベースの更新情報を永続化します。

4
タイマトランザクションの起動要求
UAPからのee_tim_execap関数（永続指定）要求時のメッセージを永続化します。

5
滞留メッセージ
UAPからのee_scd_msg_receive関数の発行によって受信した永続指定の入力メッセージを永続化します。

6
トランザクションと非同期で転送されるリソース※3
サービスの閉塞状態
次に示す閉塞状態を永続化します。

スレッドダウンによるサービスの自動閉塞

eedctsvコマンド，eeactsvコマンド，またはee_thd_abdctl関数で変更されたサービスの閉塞状態

7
出力キュー（OTQ）の閉塞状態
次に示す閉塞状態を永続化します。

一方送信メッセージの障害による出力キューの自動閉塞

eemchotqactコマンド，eemchotqdctコマンド，またはee_mch_otqbkctl関数で変更された出力キューの閉塞状態

8
サービスの最大同時処理限界数
eelspceコマンドで変更したサービスの最大同時処理限界数を永続化します。

9
出力キュー中の未送信メッセージのスキップ状態
eemchotqskipコマンド，またはee_mch_otqskip関数で変更した出力キュー中の未送信メッセージのスキップ状態を永続化します。

10
滞留メッセージのスキップ状態
eepceskipコマンド，またはee_scd_msg_skip関数で変更した滞留メッセージのスキップ状態を永続化します。

注※1

詳細については，「7.6.2　入力メッセージの永続化」を参照してください。

注※2

詳細については，「7.6.3　トランザクションと同期して転送されるリソースの永続化」を参照してください。

注※3

詳細については，「7.6.4　トランザクションと非同期に転送されるリソースの永続化」を参照してください。

7.6.2　入力メッセージの永続化

ここでは，入力メッセージの永続化の処理方式について，メッセージの種類別に説明します。

＜この項の構成＞

(1)　RPCメッセージの永続化

(2)　MCPメッセージの永続化

(3)　MCHメッセージの永続化

(1)　RPCメッセージの永続化

クライアントからCLサーバに対してメッセージの送信要求を行います。RPCメッセージは，実行系が待機系に転送することで永続化されます。

RPCメッセージを永続化するには，RPC関連定義のrpc_recv_permanenceオペランドにYを指定します。また，永続化できるのは，RPC要求メッセージの受信メッセージだけです。

RPCメッセージの永続化処理の流れを次の図に示します。

図7-6　RPCメッセージの永続化処理の流れ

説明

実行系はクライアントからRPCメッセージを受信したあと，メッセージ転送用の処理キューを登録します。処理キューは，サービスごとにシリアライズされます。サービス名の不正を検知した場合は，処理キューを登録しないでERRTRN1を起動します。

送信スレッドで処理キューが引き出され，受信したRPCメッセージを待機系に転送します。このメッセージのように，実行系から待機系にリソースの永続化を要求するメッセージを CL同期メッセージといいます。CL同期メッセージを送信したあと，待機系からの送達確認メッセージの待ち合わせを行います。

待機系は実行系から転送されたRPCメッセージを受信したあと，処理キュー制御用バッファ（PCE）を確保し，処理キューを仮登録します。そのあと，実行系に対して送達確認メッセージを送信します。

実行系は待機系からの送達確認メッセージをすべて受信したあとに，RPCメッセージを処理キューに登録します。

処理スレッドで処理キューが引き出され，UAPにRPCメッセージを引き渡します。

以降の処理については，次の項以降で説明します。

なお，RPCメッセージの永続化の場合，次の制限があります。

TCP/IPプロトコルのRPCメッセージを永続化した場合，次の機能は使用できません。

RPC応答メッセージのトランザクションまたがり送信機能

ERRTRNRによるRPC応答メッセージ送信機能

ee_rpc_cmtsend関数の自プロセス通信の場合，RPCメッセージを永続化できません。

CL構成でのRPCメッセージ受信であるため，トランザクション連携するRPCメッセージは永続化に失敗します。

(2)　MCPメッセージの永続化

クライアントからCLサーバのMCPあてにメッセージの送信要求を行います。MCPメッセージは，実行系が待機系に転送することで永続化されます。

MCPメッセージを永続化するには，MCP構成定義のeemcpfunc定義コマンドで-mオプションのrecvpermanenceオペランドにyesを指定します。また，永続化できるのは，MCPメッセージの受信メッセージだけです。

MCPメッセージの永続化処理の流れを次の図に示します。

図7-7　MCPメッセージの永続化処理の流れ

説明

実行系はクライアントからMCPメッセージを受信したあと，MCP構成定義の指定値に従って，入力セグメント判定UOC，端末キュー登録，および入力メッセージ編集UOCを実行します。そのあと，メッセージ転送用の処理キューを登録します。処理キューは，サービスごとにシリアライズされます。サービス名の不正を検知した場合は，処理キューを登録しないでERRTRN1を起動します。

送信スレッドで処理キューが引き出され，受信したMCPメッセージを待機系にCL同期メッセージとして転送したあと，待機系からの送達確認メッセージの待ち合わせを行います。

待機系は実行系から転送されたMCPメッセージを受信したあと，処理キュー制御用バッファ（PCE）を確保し，処理キューを仮登録します。そのあと，実行系に対して送達確認メッセージを送信します。

実行系は待機系からの送達確認メッセージをすべて受信したあとに，MCPメッセージを処理キューに登録します。

処理スレッドで処理キューが引き出され，UAPにMCPメッセージを引き渡します。

以降の処理については，次の項以降で説明します。

(3)　MCHメッセージの永続化

HAサーバからCLサーバの各サーバに対して，マルチキャストでメッセージの送信要求を行います。MCHメッセージは，実行系と待機系がそれぞれ保持することで永続化されます。MCHメッセージの永続化処理の流れを次の図に示します。

図7-8　MCHメッセージの永続化処理の流れ

説明

HAサーバからCLサーバの各サーバに対して，マルチキャストでメッセージが送信されます。

待機系は，HAサーバからメッセージを受信したあと，処理キュー制御用バッファ（PCE）を確保し，処理キューを仮登録します。そのあと，実行系に対して送達確認メッセージを送信します。

実行系は，HAサーバからのメッセージを受信したあと，待機系からの送達確認メッセージの待ち合わせを行います。

実行系は，待機系からの送達確認メッセージをすべて受信したあとに，HAサーバに対して送達確認メッセージを送信します。

以降の処理については，次の項以降で説明します。

参考

ここでは，MCHメッセージの送信元としてHAサーバを仮定しています。CLサーバから別のクラスタグループのCLサーバへマルチキャストでメッセージを送信することもできます。その場合，HAサーバがCLサーバになります。

7.6.3　トランザクションと同期して転送されるリソースの永続化

次に示すリソースは，トランザクションと同期して待機系に転送されます。

送信メッセージ

XDBの更新ログ

タイマトランザクションの起動要求

滞留メッセージ

ここでは，トランザクションと同期して転送されるリソースの永続化について説明します。永続トランザクションの場合と，非永続トランザクションの場合に分けて説明します。

■永続トランザクションと非永続トランザクション

待機系にトランザクション起動元となる入力メッセージがあるトランザクションを，永続トランザクションといいます。

待機系に入力メッセージがないトランザクションを，非永続トランザクションといいます。

＜この項の構成＞

(1)　永続トランザクションでのリソースの永続化

(2)　非永続トランザクションでのリソースの永続化

(1)　永続トランザクションでのリソースの永続化

永続トランザクションでのリソースの永続化の処理方式について説明します。

(a)　送信メッセージの永続化

UAPから送信要求された永続指定のメッセージを待機系に転送して，送信メッセージを永続化します。送信メッセージの永続化処理の流れを次に示します。

実行系のUAPから永続指定のメッセージ送信要求を受け付けると，コミット確定後に出力キュー（OTQ）にメッセージを登録（出力キュー通番を採番）し，メッセージ送信指示を行います。

永続化するメッセージをCL同期メッセージとして待機系に転送します。CL同期メッセージを受信した待機系は，出力キュー通番の通番抜けがないことを確認後，仮登録済みの処理キューに送信メッセージを追加し，出力キューにメッセージを登録します。そのあと，送達確認メッセージを応答します。出力キュー通番の通番抜けがある場合は，送達確認メッセージの応答を待ち合わせます。

実行系は，UAPから送信要求されたメッセージの送信指示を行ったあと，待機系に対して送信が完了した旨のメッセージを転送します。このメッセージをCL同期済み通知メッセージといいます。

CL同期済み通知メッセージを受信した待機系は，仮登録済みの処理キューを登録します。

(b)　XDBの更新ログの永続化

XDBの更新ログ（実行系のデータベースの更新情報）を待機系に転送して，更新ログを永続化します。待機系では，更新ログに付加されたコミット通番に従ってデータベースへの反映を行います。更新ログの永続化処理の流れを次の図に示します。

図7-9　更新ログの永続化処理の流れ

説明

UAPからSQLの更新要求を受け付けると，コミット確定後，実行系は待機系に更新ログをCL同期メッセージとして転送します。

CL同期メッセージを受信した待機系は，仮登録済みの処理キューに転送された更新ログを追加し，送達確認メッセージを応答します。更新ログの通番抜けがある場合は，送達確認メッセージの応答を待ち合わせます。

実行系から待機系に，CL同期済み通知メッセージが転送されます。

CL同期済み通知メッセージを受信した待機系は，仮登録済みの処理キュー（同時実行数1）を登録します。更新ログの通番抜けがある場合は，処理キュー登録を待ち合わせます。

(c)　タイマトランザクションの起動要求の永続化

UAPからのタイマトランザクションの起動要求時に永続指定がある場合，待機系にタイマトランザクションの情報を転送して，タイマトランザクションの起動要求を永続化します。タイマトランザクションの起動要求の永続化の流れを次に示します。

UAPからの永続指定のタイマトランザクション起動要求を実行系で受け付けると，コミット確定後，実行系は待機系にCL同期メッセージを送信します。

CL同期メッセージを受信した待機系は，タイマトランザクション起動用の処理キューを仮登録し，送達確認メッセージを応答します。

送達確認メッセージを受信した実行系は，CL同期済み通知メッセージを待機系に送信します。

CL同期済み通知メッセージを受信した待機系は，仮登録済みの処理キューを登録します。

実行系は，タイマトランザクションのコミット確定後，待機系にCL同期メッセージを送信します。

CL同期メッセージを受信した待機系は，送達確認メッセージを応答します。

送達確認メッセージを受信した実行系は，CL同期済み通知メッセージを待機系に送信します。

CL同期済み通知メッセージを受信した待機系は，仮登録済みのタイマトランザクション用処理キューを登録します。

(d)　滞留メッセージの永続化

UAPからのee_scd_msg_receive関数の発行によって受信した入力メッセージを待機系に転送します。このとき，待機系で受信済みの入力メッセージは破棄されます。

(2)　非永続トランザクションでのリソースの永続化

非永続トランザクションで，永続指定の送信メッセージや，XDBの更新ログなどの永続化が必要なリソースがある場合，待機系にリソースを転送してリソースを永続化します。ただし，リソースを転送する前に実行系が異常終了した場合，待機系には仮登録した処理キューがないため，UAPの再起動によるリソースの回復はできません。

非永続トランザクションでのXDBの更新ログの永続化処理の流れを次に示します。

実行系のUAPからSQL（更新）要求を受け付けると，コミット確定後に待機系に更新ログを転送します（CL同期メッセージ）。

CL同期メッセージを受信した待機系は，仮登録済みの処理キューがないため，処理キュー制御用バッファ（PCE）を確保して処理キューの仮登録を行います。そのあと，実行系に送達確認メッセージを応答します。

以降の処理は，永続トランザクションでのリソースの永続化処理の流れと同じになります。

なお，非永続トランザクションの場合，待機系に転送するリソースがないときは，CL同期メッセージまたはCL同期済み通知メッセージは送信されません。

7.6.4　トランザクションと非同期に転送されるリソースの永続化

次に示すリソースは，リソースの状態に変更があったときに待機系に転送されます。

サービスの閉塞状態

出力キュー（OTQ）の閉塞状態

サービスの最大同時処理限界数

出力キュー中の未送信メッセージのスキップ状態

滞留メッセージのスキップ状態

ただし，実行系の異常終了のタイミングによっては，実行系のリソースの状態が待機系に正しく引き継がれないことがあります。そのため，次に示すリソースについては，系が切り替わったあとに運用コマンドでリソースの状態を確認してください。

■サービスの閉塞状態

系が切り替わった場合に，閉塞中のサービスがある旨のメッセージが出力されたときは，eelssvコマンドでサービスの状態を確認してください。そのあと，必要に応じてeedctsvまたはeeactsvコマンドで，サービスの閉塞状態を変更してください。

■出力キュー（OTQ）の閉塞状態

系が切り替わったときに，出力キューが閉塞中のサービスがある旨のメッセージが出力された場合，eemchotqlsコマンドで出力キューの状態を確認してください。そのあと，必要に応じてeemchotqdctまたはeemchotqactコマンドで，出力キューの閉塞状態を変更してください。

7.6.5　UAPからロールバック要求があった場合の転送処理

ここでは，UAPからロールバック要求があった場合のXTCの処理について説明します。

同時引き出しなしのサービスの場合と，同時引き出しありのサービスの場合で処理が異なります。それぞれの処理を説明します。

＜この項の構成＞

(1)　同時引き出しなしのサービスの場合

(2)　同時引き出しありのサービスの場合

(1)　同時引き出しなしのサービスの場合

実行される関数によって処理が異なります。

(a)　ee_trn_chained_rollback関数によるロールバック要求の場合

UAPからee_trn_chained_rollback関数によるロールバック要求があった場合，入力メッセージを未読み出し状態に戻したあと（処理キューを引き戻したあと），再度処理キューを引き出してトランザクションを実行します。

ロールバック時の処理の流れを次に示します。

UAPからロールバック要求を受け付けると，同期してロールバック決着を行い，入力メッセージを未読み出し状態に戻します。ただし，連鎖モード連携機能の使用有無によっては，UAPからのリターン後に入力メッセージを未読み出し状態に戻す場合があります。

UAPからのリターン後，コミット決着を行いリターンします。永続化が必要なリソースがある場合は，CL同期メッセージを待機系に送信します。

引き戻した処理キューを再度引き出し，UAPに制御を渡します。

(b)　ee_trn_rollback_mark関数によるロールバック要求の場合

UAPからee_trn_rollback_mark関数によるロールバック要求があった場合，入力メッセージを未読み出し状態に戻したあと（処理キューを引き戻したあと），再度処理キューを引き出してトランザクションを実行します。

ロールバック時の処理の流れを次に示します。

UAPからロールバック要求を受け付けると，UAPからのリターン後にロールバック決着を行い，入力メッセージを未読み出し状態に戻します。

引き戻した処理キューを再度引き出し，UAPに制御を渡します。

(2)　同時引き出しありのサービスの場合

実行される関数によって処理が異なります。

(a)　ee_trn_chained_rollback関数によるロールバック要求の場合

UAPからee_trn_chained_rollback関数によるロールバック要求があった場合，ロールバック情報を待機系へ転送し，入力メッセージを削除します。

ロールバック時の処理の流れを次に示します。

UAPからロールバック要求を受け付けると，同期してロールバック決着を行い，ロールバック決着情報を転送（CL同期メッセージ）し，続けてCL同期済み通知メッセージを送信します。ただし，連鎖モード連携機能の使用有無によっては，UAPからのリターン後にCL同期メッセージまたはCL同期済み通知メッセージを送信する場合があります。

CL同期済み通知メッセージを受信した待機系は，仮登録済みの処理キューを登録し，ロールバック決着を行います。

(b)　ee_trn_rollback_mark関数によるロールバック要求の場合

UAPからee_trn_rollback_mark関数によるロールバック要求があった場合，UAPリターン後にロールバック情報を待機系に転送します。

7.6.6　UAPが異常終了した場合の転送処理

UAPが異常終了した場合，待機系に転送したリソースは削除されます。

このとき，実行系はロールバック処理を行い，ERRTRN3を起動してUAPに制御を戻します。

7.7　システム間通信でのメッセージ転送処理

CLサーバでは，UDP通信機能を使用してメッセージのシステム間通信を行っています。

ここでは，UDP通信機能を使用したシステム間通信の処理の流れについて，メッセージの種類ごとに説明します。

＜この節の構成＞

7.7.1　一方送信メッセージの処理の流れ

7.7.2　CL同期メッセージの処理の流れ

7.7.1　一方送信メッセージの処理の流れ

一方送信メッセージの処理の流れを次の図に示します。

図7-10　一方送信メッセージの処理の流れ

説明

実行系は，一方送信メッセージに対する肯定応答（ACK）を送信したあと，待機系からの送達確認メッセージの待ち合わせを行います。

待機系は，一方送信メッセージを受信したあと，実行系に送達確認メッセージを肯定応答不要で送信します。

実行系は，待機系から送達確認メッセージを受信したあと，HAサーバに送達確認メッセージを肯定応答不要で送信します。

参考

ここでは，入力メッセージの送信元としてHAサーバを仮定しています。CLサーバから別のクラスタグループのCLサーバへマルチキャストでメッセージを送信することもできます。その場合，HAサーバがCLサーバになります。

HAサーバは，マルチキャストによってCLサーバの各サーバにメッセージを送信し，送達確認メッセージをCLサーバの実行系から受け取ります。このように，HAサーバは，CLサーバの各サーバにメッセージを送信しているため，どのサーバが実行系であるかを意識する必要がありません。

7.7.2　CL同期メッセージの処理の流れ

通常，CLサーバの待機系では，実行系からのCL同期メッセージを受信した場合，処理キューを経由してCL同期メッセージを受信したスレッドとは別のスレッドで実行系へ送達確認メッセージを送信します。

mch_clreq_rcvthdオペランドにYを指定した場合は，CL同期メッセージ受信完了時，処理キューを経由しないで，実行系へ送達確認メッセージを送信するため，実行系での同期処理時間を短縮できます。

ただし，実行系から転送する処理スレッドが多い場合や，転送するデータサイズが大きい場合は実行系での同期処理時間が短縮できない場合もあります。

mch_clreq_rcvthdオペランドにNを指定したときのCL同期メッセージの処理の流れを次の図に示します。

図7-11　CL同期メッセージの処理の流れ

説明

実行系は，リソースを一括して待機系に送信します。

待機系は，送信されたデータサイズに応じて肯定応答（ACK）を送信します。

待機系は，すべてのCL同期メッセージを受信したあと，実行系に送達確認メッセージを肯定応答不要で送信します。

mch_clreq_rcvthdオペランドにYを指定したときのCL同期メッセージの処理の流れを次の図に示します。

図7-12　CL同期メッセージの処理の流れ（mch_clreq_rcvthdオペランドにYを指定したとき）

説明

mch_clreq_rcvthdオペランドにYを指定したときは，CL同期メッセージの肯定応答（ACK）送信後，処理キューを経由せずに同一スレッドから送達確認メッセージを送信します。

なお，送達確認メッセージの送信タイミング以外は，通常時の処理の流れと同じです。

7.8　転送処理での時間監視機能

ここでは，転送処理での時間監視機能について説明します。転送処理での時間監視機能では，次に示すことを監視できます。

送信メッセージの監視

待機系で仕掛かり中のリソースの監視

＜この節の構成＞

7.8.1　送信メッセージの監視

7.8.2　待機系で仕掛かり中のリソースの監視

7.8.1　送信メッセージの監視

実行系のXTCでは，メッセージ送信処理が正常に行われたかどうかを，次に示す二つの監視時間によって判断します。

CL同期待ち監視時間

CL同期後続待ち監視時間

これらの時間監視でタイムアウトが発生した場合，XTCはメッセージ送信処理が正常に行われなかったと判断し，エラー処理を行います。タイムアウト発生時の処理については，「7.9　転送処理で障害が発生したときのXTCの処理」を参照してください。

＜この項の構成＞

(1)　CL同期待ち監視時間の設定

(2)　CL同期後続待ち監視時間の設定

(1)　CL同期待ち監視時間の設定

実行系のXTCでは，CL同期待ち監視時間として次に示す時間を監視します。

実行系がCL同期メッセージを送信してから，待機系からの送達確認メッセージを最初に受信するまでの時間

実行系が一方送信メッセージを受信してから，すべての待機系からの送達確認メッセージを受信するまでの時間

実行系が待機系からの送達確認メッセージを受信してから，一方送信メッセージを受信するまでの時間

CL同期待ち監視時間は，クラスタ連携関連定義のmch_clsend_ack_timerオペランドで指定します。

(2)　CL同期後続待ち監視時間の設定

実行系のXTCでは，CL同期後続待ち監視時間として次に示す時間を監視します。

実行系が待機系からの送達確認メッセージを受信してから，後続の送達確認メッセージを受信するまでの時間

CL同期後続待ち監視時間は，クラスタ連携関連定義のmch_clsend_next_timerオペランドで指定します。

CL同期待ち監視時間とCL同期後続待ち監視時間の関係を次の図に示します。

図7-13　CL同期待ち監視時間とCL同期後続待ち監視時間の関係

7.8.2　待機系で仕掛かり中のリソースの監視

待機系のXTCでは，待機系で仕掛かり中のリソースがあるかどうかを一定間隔でチェックしています。仕掛かり中の時間が監視時間に達した場合，仕掛かり中のリソースに関するKFSB88300-Iメッセージを出力します。

監視時間は，クラスタ連携関連定義のmch_commit_wait_msg_intervalオペランドで指定します。また，監視対象とする範囲を監視レベルとして，mch_commit_wait_msg_levelオペランドで指定します。監視レベルには次に示す二つの種類があります。

監視レベル1
トランザクション決着後のCL同期メッセージの受信から，CL同期済み通知メッセージの受信による処理キュー登録までの時間を監視対象とします。

監視レベル2
CL同期済み通知メッセージの受信から，CL同期済み通知メッセージの受信による処理キュー登録までの時間を監視対象とします。

7.9　転送処理で障害が発生したときのXTCの処理

転送処理で障害が発生したときのXTCの処理を次の表に示します。

表7-3　転送処理で障害が発生したときのXTCの処理

項番
障害要因
XTCの処理

1
HAサーバからの一方送信メッセージを受信したあとに，待機系からの送達確認メッセージの受信待ちタイムアウトが発生した

送信元に送達確認エラーメッセージ（CL同期エラーメッセージ）を送信します。

受信メッセージを破棄します。

待機系に受信メッセージを破棄するメッセージを送信します。

2
待機系から送達確認メッセージを受信したあとに，HAサーバからの一方送信メッセージの受信待ちタイムアウトが発生した

HAサーバに送達確認エラーメッセージ（CL同期エラーメッセージ）を送信します。

待機系に受信メッセージを破棄するメッセージを送信します。

3
HAサーバへの送達確認メッセージの送信エラー（リトライ失敗）が発生した
処理キューの登録後，送信エラーのメッセージを出力します。HAサーバに送達確認メッセージが届いている場合があるため，受信メッセージは破棄しません。

4
待機系へのCL同期メッセージの送信エラー（リトライ失敗）が発生した

送信エラーのメッセージを出力します。

実行系孤立状態になったときのXTCの処理については，「7.4　実行系孤立状態になった場合の対処」を参照してください。

5
待機系へのCL同期済み通知メッセージの送信エラー（リトライ失敗）が発生した

参考

ここでは，入力メッセージの送信元としてHAサーバを仮定しています。CLサーバから別のクラスタグループのCLサーバへマルチキャストでメッセージを送信することもできます。

転送処理で障害が発生したときのXTCの処理をケース別に説明します。

＜この節の構成＞

(1)　一方送信メッセージが実行系に届かない場合

(2)　一方送信メッセージが待機系に届かない場合

(3)　一方送信メッセージに対する送達確認メッセージがHAサーバに届かない場合

(4)　CL同期メッセージまたはCL同期済み通知メッセージの送信に失敗した場合

(1)　一方送信メッセージが実行系に届かない場合

ネットワーク障害などによって，HAサーバからの一方送信メッセージが実行系に届かないときの処理を次に示します。

■実行系の処理

待機系からの送達確認メッセージを受信したあと，CL同期待ち監視時間のタイムアウトを検知し，HAサーバに送達確認エラーメッセージ（CL同期エラーメッセージ）を送信します。

受信メッセージを破棄するメッセージをマルチキャストで待機系に送信します。

■待機系の処理

HAサーバからの一方送信メッセージを受信したあと，実行系に送達確認メッセージを送信します。

実行系からの，受信メッセージを破棄するメッセージを受信したあと，HAサーバからの受信メッセージを破棄します。

■HAサーバの処理

実行系が送信した送達確認エラーメッセージを受信します。送達確認エラーメッセージを受信したときのHAサーバの処理については，「2.2.8　障害処理」を参照してください。

(2)　一方送信メッセージが待機系に届かない場合

ネットワーク障害などによって，HAサーバからの一方送信メッセージがすべての待機系に届かないときの処理を次に示します。

■実行系の処理

HAサーバからの一方送信メッセージが待機系に届かなかったことを，クラスタ連携関連定義のmch_clsend_ack_timerオペランドの時間監視によるタイムアウトで検知し，HAサーバに送達確認エラーメッセージ（CL同期エラーメッセージ）を送信します。

HAサーバからの受信メッセージを破棄します。

受信メッセージを破棄するメッセージをマルチキャストで待機系に送信します。

■待機系の処理

実行系からの，受信メッセージを破棄するメッセージを受信したあと，HAサーバからの受信メッセージを破棄します。

なお，HAサーバからの受信メッセージを破棄するのは，HAサーバからの一方送信メッセージを受信した待機系だけです。

■HAサーバの処理

実行系が送信した送達確認エラーメッセージを受信します。送達確認エラーメッセージを受信したときのHAサーバの処理については，「2.2　高速メッセージ送信制御」を参照してください。

(3)　一方送信メッセージに対する送達確認メッセージがHAサーバに届かない場合

一方送信メッセージに対する送達確認メッセージが，ネットワーク障害などによってHAサーバに届かないときの処理を次に示します。

■実行系の処理

障害によって送達確認メッセージがHAサーバに送信できない場合，高速メッセージ送信関連定義のmch_send_retry_countオペランドの指定に従って送信リトライ処理を行います。

送信リトライ処理に失敗した場合，送信エラーのメッセージを出力します。

(4)　CL同期メッセージまたはCL同期済み通知メッセージの送信に失敗した場合

CL同期メッセージまたはCL同期済み通知メッセージの送信がエラーとなった場合，クラスタ連携関連定義のmch_clsend_retry_countオペランドの指定に従ってメッセージを再送します。すべての待機系への再送が失敗した場合は，待機系を切り離して実行系孤立状態となります。CL同期メッセージまたはCL同期済み通知メッセージの送信に失敗した場合の処理の流れを次の図に示します。

図7-14　CL同期メッセージまたはCL同期済み通知メッセージの送信に失敗した場合の処理の流れ

説明

実行系からのCL同期メッセージの送信に失敗した場合，クラスタ連携関連定義のmch_clsend_retry_countオペランドの指定に従ってメッセージの送信リトライ処理を行います。

送信リトライ処理に失敗した場合，送信エラーのメッセージを出力し，該当する待機系を切り離して処理を続行します。ただし，すべての待機系を切り離した場合は，実行系孤立状態となります。

再送されたCL同期メッセージが待機系で受信済みの場合は，受信したCL同期メッセージを破棄します。

7.10　系切り替えが発生したときのXTCの処理

系切り替えが発生したタイミングによっては，仕掛かり中のリソースの状態が，二つの待機系の間で異なることがあります。この場合，XTCでは，リソースの状態を一致させてから，系切り替え後の実行系で業務処理を開始します。これら一連の処理（リソースの状態を一致させる一連の処理）をキューログ回復処理といいます。

系切り替えが発生したときのキューログ回復処理を次の図に示します。

図7-15　系切り替えが発生したときのキューログ回復処理

説明

HAモニタからの障害連絡を待機系の系監視スレッドが受け付けると，系の状態が待機系から実行系に変わります。

リソースの状態を一致させる前に，リソースの状態の更新を中断します。また，外部からのメッセージの受信を抑止したあと，実行中のすべての処理が終了するのを待ち合わせます。この処理をサーバの静止化といいます。
サーバの静止化中は受信メッセージを破棄しますが，メッセージ送信元が静止化を解除するまで送信リトライするため，静止化を解除したあとにメッセージを受け取ることができます。

リソース回復トランザクションを登録します。このトランザクションによって，待機系（図中の待機系2）とリソースの状態を一致させます。このリソースの状態を合わせる処理をネゴシエーションといいます。
なお，待機系がない場合は，この処理は行われません。

リソース回復トランザクションの終了後，系監視スレッドは実行系連絡トランザクション（UI）を実行し，サーバの静止化を解除します。

すべての系切り替え処理が終了したあとにメッセージの受信抑止を解除します。

7.11　CLサーバで実行できるHAモニタのコマンド

CLサーバでは，実行できるHAモニタのコマンドが限定されています。CLサーバで実行できるHAモニタのコマンドを次の表に示します。

表7-4　CLサーバで実行できるHAモニタのコマンド

項番 | HAモニタのコマンド | コマンドの説明
1 | monact | 待ち状態のサーバを実行系のサーバとして起動します。
2 | monchange | HAモニタやサーバの稼働中に設定を変更します。
3 | moncheck | 定義チェックを実施します。
4 | mondeact | 待ち状態のサーバを停止します。
5 | monlink | HAモニタとほかのHAモニタを接続します。
6 | monmp | MPの状態を表示します。
7 | monodrshw | サーバの切り替え順序制御の状態を表示します。
8 | monpath | 監視パスの状態を表示します。
9 | monsetup | HAモニタの環境設定をします。
10 | monshow | サーバと系の状態を表示します。
11 | monstart | HAモニタを起動します。
12 | monstop | HAモニタを停止します。
13 | monswap | 計画系切り替えをします。
14 | monts | HAモニタのトラブルシュート情報を収集します。

各コマンドの詳細については，マニュアル「高信頼化システム監視機能 HAモニタ Linux(R)編」を参照してください。

8.　障害時の運用

この章では，障害時の運用について説明します。

＜この章の構成＞

8.1　想定される障害

8.2　障害に備えて取得する情報

8.1　想定される障害

ここでは，TP1キャッシュ機能使用時の運用で想定される障害と対処方法について説明します。

＜この節の構成＞

8.1.1　XTCの開始時に発生する障害

8.1.2　XTCの終了時に発生する障害

8.1.3　メッセージの送受信で発生する障害

8.1.4　キュー満杯時に発生する障害

8.1.5　システムダウン時の動作

8.1.6　UAPの障害（SQLでの問題）

8.1.1　XTCの開始時に発生する障害

CLサーバでのXTCの開始時に発生する障害について説明します。

＜この項の構成＞

(1)　実行系の開始処理中での障害

(1)　実行系の開始処理中での障害

実行系の開始処理中に障害が発生した場合，系切り替えは発生しません。そのため，実行系の開始処理中に障害が発生した場合に待機系が起動していると，クラスタグループ内は待機系だけとなります。この場合，ユーザの運用によって待機系をすべて終了させる必要があります。クラスタグループ内で待機系だけが起動している状態では，実行系を起動できません。

8.1.2　XTCの終了時に発生する障害

CLサーバでのXTCの終了時に発生する障害について説明します。

＜この項の構成＞

(1)　実行系の終了検知エラー

(1)　実行系の終了検知エラー

実行系の終了時，何らかの障害によって待機系で実行系の終了が検知できなかった場合，CLサーバ内は待機系だけとなります。このような場合，ユーザの運用によってCLサーバ内に残っている待機系を終了させる必要があります。待機系を終了させないで実行系を起動することはできません。

8.1.3　メッセージの送受信で発生する障害

メッセージの送受信で発生する障害を次の図に示します。

図8-1　メッセージの送受信で発生する障害

説明

障害
障害内容
障害時の動作
システムまたはユーザの対応
ユーザによる対処

1
端末障害
MCPではメッセージが受信できません。端末が起動できない場合は，送信メッセージを破棄します。
MCPでは，リトライによる接続を試みます。リトライ失敗時はメッセージを破棄します。
出力されたメッセージを基に，原因を取り除く必要があります。

2
端末とのLAN障害

メッセージの動作は障害1と同様です。

TCP/IPによる通信の場合，通信障害が発生して，通信回線上でメッセージが消失するおそれがあります。

3
MCPの障害（HAサーバ）
プロセスダウンになります（UOCを含みます）。
障害原因を取り除く必要があります。

4
XTCの障害（HAサーバ系）
プロセスダウンになります。

5
LAN障害（1LAN）
W-send機能によって，処理を継続できます。業務には影響ありません。
XTCでの対応はありません。LANの起動が必要です。

6
LAN障害（2LAN）

転送ができなくなり，エラーが発生します。

出力キュー（OTQ）を閉塞します。

XTCでは，リトライによる再送を試みます。リトライ失敗時はメッセージを破棄します。

7
XTCの障害（CLサーバの実行系）
待機系が起動している場合は，系切り替えが発生します。
障害原因を取り除く必要があります。
ユーザによる対処がなくても，オンラインを継続できます。
障害のあった実行系については，必要に応じて障害対策を実施してください。

8
XTCの障害（CLサーバの待機系）
待機系が停止します。メモリの内容は消失します。
出力されたメッセージを基に，原因を取り除く必要があります。

8.1.4　キュー満杯時に発生する障害

キュー満杯時に発生する障害を次の図に示します。

図8-2　キュー満杯時に発生する障害

説明

障害 | 障害内容 | 障害時の動作 | システムまたはユーザの対応 | ユーザによる対処
1 | 処理キュー満杯（実行系） | リトライ処理に失敗すると，送信元はエラーとなります。 | XTCでの対応はありません。 | 出力されたメッセージを基に，原因を取り除く必要があります。
2 | マルチキャストメッセージ送信時の出力キュー（OTQ）満杯
3 | 処理キュー満杯（待機系） | 実行系だけが受信していた場合には，待機系を切り離します。
4 | CL同期の転送障害 | リトライ処理に失敗すると，同期点でエラーが発生し，待機系を切り離します。 | XTCでは，リトライによる再送を試みます。リトライ失敗時はメッセージを破棄します。

8.1.5　システムダウン時の動作

障害発生によってCLサーバのオンラインが1台となった場合，1台構成となったことを検知した時点でオンラインが停止します。この場合，キューダンプファイルおよびメモリダンプファイルを取得します。

詳細については，「7.　CL連携による系切り替え機能」を参照してください。

8.1.6　UAPの障害（SQLでの問題）

UAPに障害が発生した場合，トラブルシュート情報を利用して障害要因を調査します。

TP1キャッシュ機能使用時は，TP1/EEのトラブルシュート情報に加えて，XDBによるXDBトレース情報を取得できます。XDBトレース情報によって，UAPの障害がSQLでの問題だった場合に対処できます。詳細については，マニュアル「TP1/EE/Extended Data Cache 使用の手引」を参照してください。

8.2　障害に備えて取得する情報

障害に備えて，TASKTMファイルや回線トレースファイルなどをTP1/EEで取得します。障害時に取得する情報の詳細については，マニュアル「TP1/Server Base Enterprise Option 使用の手引」を参照してください。

ただし，一部のファイルでは容量見積もりの方法が異なります。「3.　XTCが扱うファイルの種類と容量見積もり」もあわせて参照してください。

付録

＜この付録の構成＞

付録A　インストールディレクトリとファイル

付録B　各バージョンの変更内容

付録C　用語解説

付録A　インストールディレクトリとファイル

XTCのインストールディレクトリの構成とファイルを次の図に示します。

図A-1　XTCのインストールディレクトリの構成とファイル

付録B　各バージョンの変更内容

各バージョンの変更内容を示します。

＜この節の構成＞

(1)　変更内容（3000-3-F54-10）

(1)　変更内容（3000-3-F54-10）

次の製品の変更内容（3000-3-F54-10）を表に示します。

uCosminexus TP1/EE/Extended Transaction Controller　01-02

追加・変更内容

タイマ監視範囲について，説明を追加した。

一方送信メッセージを一括送信できるようにした。
これに伴い，次のオペランドを追加した。

高速メッセージ送信関連定義

mch_send_lump_count

また，次のオペランドの説明を変更した。

RPC関連定義

rpc_udp_lmsg_deliverychk_size

RPCメッセージ，およびタイマメッセージを，ee_scd_msg_receive関数で受信できるようにした。

RPCメッセージ，およびMCPメッセージでも，永続化できるようにした。
これに伴い，次のオペランドを追加した。

RPC関連定義

rpc_recv_permanence

次のオペランドをCLサーバで指定できるようにした。

プロセス関連定義

mcp_use

トランザクション関連定義

trn_expiration_time_rl

また，次のコマンドの説明を変更した。

eetrbqueed

XTCを配置した実行系1台で，TP1キャッシュ機能を実現できる，CL単独起動機能をサポートした。
これに伴い，次の定義の説明を変更した。

クラスタ連携関連定義

cluster_test_mode

standby_start_watch_time

UDPグループ情報関連定義（コマンド形式）

myudprcvdef定義コマンド

clgrpdef定義コマンド

また，次のコマンドの説明を変更した。

eehamls

回線トレース情報の取得量を変更できるようにした。
これに伴い，次のオペランドの指定値を追加した。

RPC関連定義

rpc_udp_linetrace

次のオペランドの説明に，永続指定の一方送信メッセージの送信先にCLサーバが含まれる場合の説明を追加した。

高速メッセージ送信関連定義

mch_send_ack_timer

CLサーバで実行できるHAモニタのコマンドから，monhelpコマンドを削除した。また，monchangeコマンドを追加した。

付録C　用語解説

英字｜ア行｜カ行｜サ行｜タ行｜ハ行｜マ行｜ラ行

このマニュアルで使用している用語について説明します。

英字

CLサーバ

メッセージやRPCの受信側となって，高速データ処理を行うサーバです。実行系1台，待機系2台の3台で構成します。

CL単独起動機能を使用する場合は，実行系1台だけで構成することもできます。

CLサーバのシミュレート機能

UAPの動作確認テストを支援する機能です。この機能を使用すると，待機系の動作をシステムがシミュレートして稼働するため，実行系1台だけでUAPの動作確認テストができます。

HAモニタおよびCLサーバの待機系の環境設定が必要ないため，テスト環境の構築が容易になります。

CL同期

CLサーバ内の各サーバのリソースの状態を一致させることです。

CL連携

XTCとHAモニタの連携によって，高信頼性と高可用性を実現するクラスタリングのことです。

HAサーバ

メッセージやRPCの送信側となるサーバです。実行系1台，待機系1台の2台で構成します。

HAモニタ情報ファイル

XTCがHAモニタに接続したときに作成されるファイルです。XTCとHAモニタの間で使用されます。

TP1キャッシュ機能

インメモリデータ処理技術を中心とした高速トランザクション処理機能の総称です。TP1キャッシュ機能を使用することで，トランザクション処理の高速化と，高信頼性，高可用性を同時に実現するオンライントランザクション処理システムを構築できます。

W-send機能

ネットワーク経路を多重化した構成でhbondingドライバを適用し，二つの経路から同一のパケットを送受信する機能です。W-send機能を使用するためには，hbondingドライバのバージョンが02-01以降であり，hbondingドライバの動作モードにbroadcastモードを選択する必要があります。

XDB用ワーク領域（XDBPOOL）

XDBが利用するワーク領域です。

XTC用ワーク領域（XTCPOOL）

XTCが利用するワーク領域です。

ア行

永続メッセージ

CLサーバに送信するメッセージのうち，待機系で保証するメッセージです。

カ行

キューダンプ機能

オンライン終了時にキューに滞留しているメッセージのファイル出力および編集をする機能です。

キューダンプファイル

キューダンプを取得するファイルです。

クラスタグループ

CL連携を行うサーバのグループのことです。クラスタグループは，UDPグループ情報関連定義のclgrpdef定義コマンドで定義します。

計画系切り替え

HAモニタのmonswapコマンドを実行して系を切り替えることです。

更新ログ

実行系のXDBのデータベースの更新情報です。

高速メッセージ送信制御

TP1キャッシュ機能使用時の，UDPプロトコルによるシステム間通信です。

孤立終了モード

実行系孤立状態になったときに管理者が選択するXTCの終了形態です。孤立終了モードには，孤立終了モードAと孤立終了モードBの二つがあります。

サ行

実行系孤立状態

待機系がなくなり，実行系だけとなった状態です。

自動系切り替え

実行系で障害が発生した場合に，自動的に系を切り替えることです。

ステータスファイルレス機能

ステータスファイルに取得するシステム制御情報を限定する機能です。

タ行

滞留メッセージ

オンライン終了時に，キューに滞留したメッセージのことです。

転送処理

実行系で更新されたリソースの情報を待機系に逐次転送して，実行系のリソース更新結果を待機系で保証する処理です。

ハ行

非永続メッセージ

CLサーバに送信するメッセージのうち，待機系で保証しないメッセージです。

マ行

マルチスタンバイ機能

一つの実行系に対して，複数の待機系を準備する機能です。マルチスタンバイ機能はHAモニタの機能です。

ラ行

連動系切り替え

複数のクラスタグループをグループ化しておき，障害が発生した場合，グループ内の全クラスタグループを待機系に切り替える機能です。

索引

[Ｃ][Ｅ][Ｈ][Ｍ][Ｒ][Ｓ][Ｔ][Ｕ][Ｗ][Ｘ]
[ア行][カ行][サ行][タ行][ナ行][ハ行][マ行][ヤ行][ラ行]

(英字)

(Ｃ)

clgrpdef（クラスタグループ情報定義）

cluster_mode

cluster_test_mode

CLサーバ

CLサーバ〔用語解説〕

CLサーバでのXTCの開始

CLサーバでのXTCの終了

CLサーバのシミュレート機能

CLサーバのシミュレート機能〔用語解説〕

CL単独起動機能

CL同期〔用語解説〕

CL同期エラーメッセージ

CL同期後続待ち監視時間

CL同期済み通知メッセージ

CL同期待ち監視時間

CL同期メッセージ

CL同期メッセージの処理の流れ

CL連携〔用語解説〕

CL連携による系切り替え機能

(Ｅ)

eeactsv（サービスの閉塞解除）

eedctsv（サービスの閉塞）

eehamls（系の状態表示）

eelspce（処理キュー制御用バッファの状態表示およびサービスの最大同時処理限界数の変更）

eelspcenum（処理キュー制御用バッファの状態表示（通番付き））

eemchotqact（出力キューの閉塞解除）

eemchotqdct（出力キューの閉塞）

eemchotqend（出力キューの未送信メッセージの監視終了）

eemchotqls（出力キューの状態表示）

eemchotqskip（出力キューの未送信メッセージのスキップ）

eemchsrvdef（出力キュー情報定義）

eepcerefer（滞留メッセージのファイル出力）

eepceskip（滞留メッセージのスキップ）

eesvgdef（相手サービスグループ情報定義）

eetrbqueed（キューダンプファイルの編集）

eetrbwtor（メッセージへの応答）

eeudpdef（あて先UDPグループ情報定義）

event_trn

(Ｈ)

ham_isolate_wtor_interval_time

ham_onl_interval_time

ham_sby_interval_time

ham_stop_msg_interval_time

ham_wait_interval_time

HAサーバ

HAサーバ〔用語解説〕

HAサーバで指定できないXTCサービス定義

HAサーバでのXTCの開始

HAサーバでのXTCの終了

HAモニタ

HAモニタ〔監視する障害〕

HAモニタ関連定義

HAモニタ情報ファイル

HAモニタ情報ファイル〔用語解説〕

HAモニタ単位の系切り替え

HAモニタの環境設定

HAモニタの起動

HAモニタのコマンド

HAモニタの停止

hbondingドライバ

(Ｍ)

mch_clreq_rcvthd

mch_clsend_ack_retry_count

mch_clsend_ack_retry_interval

mch_clsend_ack_timer

mch_clsend_next_timer

mch_clsend_retry_count

mch_clsend_retry_interval

mch_clsend_rrn_timer

mch_clsend_rs_retry_interval

mch_clsend_sta_timer

mch_commit_wait_msg_interval

mch_commit_wait_msg_level

mch_receive_limit

mch_send_ack_retry_count

mch_send_ack_retry_interval

mch_send_ack_timer

mch_send_end_otqwatch

mch_send_end_otqwatch_time

mch_send_lump_count

mch_send_max_count

mch_send_otqschedule_interval

mch_send_otqwatch_time_interval

mch_send_retry_count

mch_send_retry_interval

mch_send_rs_retry_interval

mch_xdb_buf_pool_count

mem_ibf_extend_num

mem_obf_extend_num

mem_uibf_extend_num

mem_uobf_extend_num

memory_mdpsys_area_size

memory_mdpusr_area_size

memory_xdb_area_size

memory_xdb_limit_size

memory_xtc_area_size

memory_xtc_limit_size

monact

monchange

moncheck

mondeact

monlink

monmp

monodrshw

monpath

monsetup

monshow

monstart

monstop

monswap

monts

MPSPOOL

MPUPOOL

myudprcvdef（受信UDPグループ情報定義）

myudpsnddef（送信UDPグループ情報定義）

(Ｒ)

rpc_recv_permanence

rpc_tcp_communication_use

rpc_udp_congestion_packet_count

rpc_udp_departure_limit

rpc_udp_linetrace

rpc_udp_lmsg_deliverychk_size

rpc_udp_msg_deliverychk_size

rpc_udp_packet_size

RPC応答の送信タイミング変更機能

RPC関連定義

(Ｓ)

scd_rollback_retry_mode

send_thread_no

service_attr（サービス属性定義）

standby_start_error_switch

standby_start_watch_time

sts_fileless_level

sts_fileless_use

system_start_ui

(Ｔ)

TASKTMファイルの容量見積もり

TP1/EEプロセス単位の系切り替え

TP1/Server Base単位の系切り替え

TP1キャッシュ機能〔用語解説〕

TP1キャッシュ機能使用時のサーバ構成

TP1キャッシュ機能とは

TP1キャッシュ機能の全体像

trb_pcerefer_output_time

trb_quedump_io_watch_msg_time

trb_quedump_io_watch_time

trb_quedump_wtor_interval_time

trn_cl_rpc_reply_timing

trn_expiration_time_mv

trn_expiration_time_ui

trn_transactional_rpcless_use

(Ｕ)

UAPの障害

udp_recv_message_buf_cnt

udp_recv_message_buf_size

udp_send_message_buf_cnt

udp_send_message_buf_size

UDPグループ情報関連定義（コマンド形式）

UDPソケット送受信バッファ

UDP通信機能

UDPプロトコルを使用したRPC通信

UDP用受信バッファ

UDP用送受信バッファ

UDP用送信バッファ

UIBF

UOBF

uoc_func（ユーザオウンコーディング定義）

(Ｗ)

W-send機能

W-send機能〔用語解説〕

(Ｘ)

XDBPOOL

XDBPOOL〔用語解説〕

XDB用ワーク領域

XDB用ワーク領域〔用語解説〕

XTCPOOL

XTCPOOL〔用語解説〕

XTCが扱うファイルの種類

XTCサービス定義

XTCのRPC通信

XTCの開始

XTCの終了

XTC用ワーク領域

XTC用ワーク領域〔用語解説〕

(ア行)

(い)

一方送信メッセージの受信

一方送信メッセージの処理の流れ

一方送信メッセージの送信

インストール

インストールディレクトリとファイル

(う)

運用コマンドの一覧

運用性を向上させる機能

(え)

永続化〔XDBの更新ログ〕

永続化〔送信メッセージ〕

永続化〔タイマトランザクションの起動要求〕

永続化〔滞留メッセージ〕

永続化〔入力メッセージ〕

永続化〔非永続トランザクション〕

永続化〔リソース〕 ,[2]

永続トランザクション

永続メッセージ

永続メッセージ〔用語解説〕

(カ行)

(か)

開始時に発生する障害

回線トレース情報の取得量の変更

回線トレースファイルの容量見積もり

環境設定

監視対象となる障害

監視パスの状態表示

(き)

キューダンプ機能

キューダンプ機能〔用語解説〕

キューダンプファイル

キューダンプファイル〔用語解説〕

キューダンプファイルの容量見積もり

キュー満杯時に発生する障害

キューログ回復処理

(く)

クラスタグループ

クラスタグループ〔用語解説〕

クラスタ連携関連定義

(け)

計画系切り替え ,[2]

計画系切り替え〔用語解説〕

系切り替え機能

系障害

系の状態表示

(こ)

高信頼性を実現する機能

更新ログ〔用語解説〕

更新ログの永続化

高速通信・高速処理を実現する機能

高速メッセージ送信関連定義

高速メッセージ送信制御

高速メッセージ送信制御〔用語解説〕

後続メッセージの読み出し

コマンド〔HAモニタ〕

コミット通番

孤立終了モード

孤立終了モード〔用語解説〕

(サ行)

(さ)

サーバの静止化

サービスグループ情報関連定義（コマンド形式）

サービス先行解放

再送タイマ

(し)

仕掛かり中のリソース

システム構成

システムダウン時の動作

システム定義

システム定義の設定

実行系

実行系孤立状態

実行系孤立状態〔対処方法〕

実行系孤立状態〔用語解説〕

実行系孤立状態になった場合の対処

自動系切り替え

自動系切り替え〔用語解説〕

自動系切り替えの監視対象となる障害

終了時に発生する障害

受信用ポート

障害時の運用

障害に備えて取得する情報

状態表示〔系切り替え機能〕

処理キューの仮登録

処理キューの制御

(す)

ステータスファイル関連定義

ステータスファイルレス機能

ステータスファイルレス機能〔用語解説〕

(そ)

送信先サービス関連定義（コマンド形式）

送信メッセージの永続化

送信メッセージの監視

送信用ポート

送達確認範囲

(タ行)

(た)

待機系

タイマトランザクションの起動要求の永続化

滞留メッセージ

滞留メッセージ〔用語解説〕

滞留メッセージの永続化

大量処理用システム領域

大量処理用メモリ管理機能

大量処理用ユーザ領域

(つ)

通信障害〔系切り替え機能〕

通信障害が発生した場合の対処

(て)

転送処理

転送処理〔UAPが異常終了した場合〕

転送処理〔時間監視機能〕

転送処理〔障害が発生した場合〕

転送処理〔用語解説〕

転送処理〔ロールバック要求があった場合〕

(と)

トラブルシュート関連定義

トランザクショナルRPCの抑止（CLサーバ）

トランザクション関連定義

トランザクション制御

トランザクション同期の一方送信メッセージ

トランザクション非同期の一方送信メッセージ

(ナ行)

(に)

入力メッセージの永続化

(ね)

ネゴシエーション

(ハ行)

(は)

バッファ不足時の面数拡張

(ひ)

非永続トランザクション

非永続メッセージ

非永続メッセージ〔用語解説〕

(ふ)

ファイルの運用

ファイルの容量見積もり

負荷分散機能

複数メッセージの一括送受信機能

輻輳制御

(ほ)

ポート

(マ行)

(ま)

マルチキャストでの通信

マルチキャストループバック受信

マルチスタンバイ機能

マルチスタンバイ機能〔用語解説〕

(め)

メッセージの送受信で発生する障害

メッセージの同時引き出し

メモリ関連定義

メモリダンプファイルの容量見積もり

(ヤ行)

(ゆ)

ユーザサービス関連定義

ユーザサービス関連定義（コマンド形式）

ユニキャストでの通信

(よ)

容量見積もり

読み出しメッセージの差し戻し

(ラ行)

(り)

リソース〔待機系に転送されるリソース〕

リソースの永続化 ,[2] ,[3]

リソースの監視

(れ)

連鎖モード連携機能 ,[2]

連動系切り替え

連動系切り替え〔用語解説〕

(ろ)

ロールバック

ロールバック時の読み出しメッセージの扱い

ロールバックリトライ

■ 商標類

HITACHI，HAモニタ，HiRDB，OpenTP1，uCosminexusは，（株）日立製作所の商標または登録商標です。
AMDは，Advanced Micro Devices, Inc.の商標です。
Linuxは，Linus Torvalds氏の日本およびその他の国における登録商標または商標です。
OracleとJavaは，Oracle Corporation 及びその子会社，関連会社の米国及びその他の国における登録商標です。
Red Hatは，米国およびその他の国でRed Hat, Inc. の登録商標もしくは商標です。
UNIXは，The Open Groupの米国ならびに他の国における登録商標です。
その他記載の会社名，製品名は，それぞれの会社の商標もしくは登録商標です。