OpenTP1 Version 7　分散トランザクション処理機能　OpenTP1 解説

解説書

3000-3-D50-C0

前書き

対象製品

・適用OS：AIX V6.1，AIX V7.1，AIX V7.2，AIX 7.3

P-1M64-2141 uCosminexus TP1/Server Base 07-53

P-1M64-2341 uCosminexus TP1/FS/Direct Access 07-51

P-1M64-2441 uCosminexus TP1/FS/Table Access 07-51

P-1M64-2541 uCosminexus TP1/Client/W 07-52

P-1M64-2741 uCosminexus TP1/Online Tester 07-50

P-1M64-2841 uCosminexus TP1/Multi 07-50

P-1M64-2941 uCosminexus TP1/High Availability 07-50

P-1M64-8541 uCosminexus TP1/Extension 1 07-50

P-1M64-3141 uCosminexus TP1/Message Control 07-51

P-1M64-3241 uCosminexus TP1/NET/Library 07-51

P-1M64-C381 uCosminexus TP1/Message Queue 07-53

P-F1M64-31411 uCosminexus TP1/Message Control/Tester 07-50

P-F1M64-31412 uCosminexus TP1/Message Control - Extension 1 07-50

P-F1M64-32411 uCosminexus TP1/NET/User Agent 07-50

P-F1M64-32414 uCosminexus TP1/NET/OSI-TP 07-50

P-F1M64-32415 uCosminexus TP1/NET/XMAP3 07-50

P-F1M64-32418 uCosminexus TP1/NET/OSAS-NIF 07-50

P-F1M64-3241B uCosminexus TP1/NET/Secondary Logical Unit - TypeP2 07-50

P-F1M64-3241C uCosminexus TP1/NET/TCP/IP 07-50

P-F1M64-3241D uCosminexus TP1/NET/High Availability 07-50

P-F1M64-3241U uCosminexus TP1/NET/User Datagram Protocol 07-50

P-1M64-8141 uCosminexus TP1/Shared Table Access 07-50

P-1M64-8341 uCosminexus TP1/Resource Manager Monitor 07-50

P-1M64-1121 uCosminexus TP1/Server Base(64) 07-53

P-1M64-1321 uCosminexus TP1/FS/Direct Access(64) 07-51

P-1M64-1421 uCosminexus TP1/FS/Table Access(64) 07-51

P-1M64-1521 uCosminexus TP1/Client/W(64) 07-52

P-1M64-1921 uCosminexus TP1/High Availability(64) 07-50

P-1M64-1L21 uCosminexus TP1/Extension 1(64) 07-50

P-1M64-4121 uCosminexus TP1/Message Control(64) 07-51

P-1M64-4221 uCosminexus TP1/NET/Library(64) 07-51

P-F1M64-41212 uCosminexus TP1/Message Control - Extension 1(64) 07-50

P-F1M64-4221C uCosminexus TP1/NET/TCP/IP(64) 07-50

P-1M64-D121 uCosminexus TP1/Message Queue(64) 07-53

P-F1M64-4221D uCosminexus TP1/NET/High Availability(64) 07-50

P-F1M64-4221U uCosminexus TP1/NET/User Datagram Protocol(64) 07-50

・適用OS：HP-UX 11i V3 (IPF)

P-1J64-2171 uCosminexus TP1/Server Base 07-51

P-1J64-2371 uCosminexus TP1/FS/Direct Access 07-51

P-1J64-2471 uCosminexus TP1/FS/Table Access 07-51

P-1J64-8571 uCosminexus TP1/Extension 1 07-50

P-1J64-8971 uCosminexus TP1/High Availability 07-50

P-1J64-C381 uCosminexus TP1/Message Queue 07-52

P-1J64-3171 uCosminexus TP1/Message Control 07-51

P-1J64-3271 uCosminexus TP1/NET/Library 07-51

P-F1J64-31712 uCosminexus TP1/Message Control - Extension 1 07-50

P-F1J64-32715 uCosminexus TP1/NET/XMAP3 07-51

P-F1J64-3271C uCosminexus TP1/NET/TCP/IP 07-51

P-F1J64-3271D uCosminexus TP1/NET/High Availability 07-50

P-1J64-1171 uCosminexus TP1/Server Base(64) 07-51

P-1J64-1371 uCosminexus TP1/FS/Direct Access(64) 07-51

P-1J64-1471 uCosminexus TP1/FS/Table Access(64) 07-51

P-1J64-8671 uCosminexus TP1/Extension 1(64) 07-50

P-1J64-8A71 uCosminexus TP1/High Availability(64) 07-50

P-1J64-C581 uCosminexus TP1/Message Queue (64) 07-52

P-1J64-4171 uCosminexus TP1/Message Control(64) 07-51

P-1J64-4271 uCosminexus TP1/NET/Library(64) 07-51

P-F1J64-41712 uCosminexus TP1/Message Control - Extension 1(64) 07-50

P-F1J64-4271C uCosminexus TP1/NET/TCP/IP(64) 07-51

P-F1J64-4271D uCosminexus TP1/NET/High Availability(64) 07-50

・適用OS：Red Hat Enterprise Linux Server 6 (32-bit x86)，Red Hat Enterprise Linux Server 6 (64-bit x86_64)，Red Hat Enterprise Linux Server 7 (64-bit x86_64)，Red Hat Enterprise Linux Server 8 (64-bit x86_64)

P-8164-2111 uCosminexus TP1/Server Base 07-57

P-8164-2311 uCosminexus TP1/FS/Direct Access 07-51

P-8164-2411 uCosminexus TP1/FS/Table Access 07-51

P-8164-2911 uCosminexus TP1/High Availability 07-50

P-8164-8511 uCosminexus TP1/Extension 1 07-50

P-8164-3111 uCosminexus TP1/Message Control 07-52

P-8164-3211 uCosminexus TP1/NET/Library 07-52

P-8164-C311 uCosminexus TP1/Message Queue 07-53

P-F8164-31112 uCosminexus TP1/Message Control - Extension 1 07-50

P-F8164-32111 uCosminexus TP1/NET/User Agent 07-50

P-F8164-3211C uCosminexus TP1/NET/TCP/IP 07-52

P-F8164-3211D uCosminexus TP1/NET/High Availability 07-50

P-F8164-3211U uCosminexus TP1/NET/User Datagram Protocol 07-50

R-1945F-12 uCosminexus TP1/Web 07-50

・適用OS：Red Hat Enterprise Linux Server 6 (64-bit x86_64)，Red Hat Enterprise Linux Server 7 (64-bit x86_64)，Red Hat Enterprise Linux Server 8 (64-bit x86_64)

P-8264-2111 uCosminexus TP1/Server Base(64) 07-57

P-8264-2311 uCosminexus TP1/FS/Direct Access(64) 07-51

P-8264-2411 uCosminexus TP1/FS/Table Access(64) 07-51

P-8264-2911 uCosminexus TP1/High Availability(64) 07-50

P-8264-8511 uCosminexus TP1/Extension 1(64) 07-50

P-8264-3111 uCosminexus TP1/Message Control(64) 07-52

P-8264-3211 uCosminexus TP1/NET/Library(64) 07-52

P-8264-C311 uCosminexus TP1/Message Queue(64) 07-53

P-F8264-31112 uCosminexus TP1/Message Control - Extension 1(64) 07-50

P-F8264-3211C uCosminexus TP1/NET/TCP/IP(64) 07-52

P-F8264-3211D uCosminexus TP1/NET/High Availability(64) 07-50

P-F8264-3211U uCosminexus TP1/NET/User Datagram Protocol(64) 07-50

R-1S45F-12 uCosminexus TP1/Web(64) 07-50

・適用OS：Red Hat Enterprise Linux Server 9 (64-bit x86_64)

P-8764-2111 uCosminexus TP1/Server Base 07-60

P-8764-2311 uCosminexus TP1/FS/Direct Access 07-60

P-8764-2411 uCosminexus TP1/FS/Table Access 07-60

P-8764-2911 uCosminexus TP1/High Availability 07-60

P-8764-8511 uCosminexus TP1/Extension 1 07-60

P-8764-3111 uCosminexus TP1/Message Control 07-60

P-8764-3211 uCosminexus TP1/NET/Library 07-60

P-F8764-31112 uCosminexus TP1/Message Control - Extension 1 07-60

P-F8764-3211C uCosminexus TP1/NET/TCP/IP 07-60

P-F8764-3211D uCosminexus TP1/NET/High Availability 07-60

P-F8764-3211U uCosminexus TP1/NET/User Datagram Protocol 07-60

P-8864-2111 uCosminexus TP1/Server Base(64) 07-60

P-8864-2311 uCosminexus TP1/FS/Direct Access(64) 07-60

P-8864-2411 uCosminexus TP1/FS/Table Access(64) 07-60

P-8864-2911 uCosminexus TP1/High Availability(64) 07-60

P-8864-8511 uCosminexus TP1/Extension 1(64) 07-60

P-8864-3111 uCosminexus TP1/Message Control(64) 07-60

P-8864-3211 uCosminexus TP1/NET/Library(64) 07-60

P-F8864-31112 uCosminexus TP1/Message Control - Extension 1(64) 07-60

P-F8864-3211C uCosminexus TP1/NET/TCP/IP(64) 07-60

P-F8864-3211D uCosminexus TP1/NET/High Availability(64) 07-60

P-F8864-3211U uCosminexus TP1/NET/User Datagram Protocol(64) 07-60

・適用OS：Windows 7，Windows 7 x64 Edition，Windows 8，Windows 8 x64 Edition，Windows 8.1，Windows 8.1 x64 Edition，Windows 10，Windows 10 x64 Edition，Windows 11，Windows Server 2008 R2，Windows Server 2012，Windows Server 2012 R2，Windows Server 2016，Windows Server 2019，Windows Server 2022

P-2464-2154 uCosminexus TP1/Client/P 07-51

P-2464-2284 uCosminexus TP1/Server Base 07-53

P-2464-2384 uCosminexus TP1/FS/Direct Access 07-51

P-2464-2484 uCosminexus TP1/FS/Table Access 07-51

P-2464-2554 uCosminexus TP1/Extension 1 07-51

P-2464-3164 uCosminexus TP1/Message Control 07-51

P-2464-3264 uCosminexus TP1/NET/Library 07-50

P-2464-7834 uCosminexus TP1/Client for .NET Framework 07-50

P-2464-C384 uCosminexus TP1/Message Queue 07-52

P-F2464-31642 uCosminexus TP1/Message Control - Extension 1 07-50

P-F2464-32645 uCosminexus TP1/NET/XMAP3 07-51

P-F2464-3264C uCosminexus TP1/NET/TCP/IP 07-51

P-F2464-3264D uCosminexus TP1/NET/High Availability 07-51

R-1545B-27 uCosminexus TP1/LiNK 07-51

R-15451-27 uCosminexus TP1/Connector for .NET Framework 07-50

R-15452-27 uCosminexus TP1/Extension for .NET Framework 07-50

・適用OS：Windows 7 x64 Edition，Windows 8 x64 Edition，Windows 8.1 x64 Edition，Windows 10 x64 Edition，Windows 11，Windows Server 2008 R2，Windows Server 2012，Windows Server 2012 R2，Windows Server 2016，Windows Server 2019，Windows Server 2022

P-2964-2124 uCosminexus TP1/Client/P(64) 07-51

P-2964-2224 uCosminexus TP1/Server Base(64) 07-53

P-2964-2324 uCosminexus TP1/FS/Direct Access(64) 07-51

P-2964-2424 uCosminexus TP1/FS/Table Access(64) 07-51

P-2964-2524 uCosminexus TP1/Extension 1(64) 07-50

P-2964-3124 uCosminexus TP1/Message Control(64) 07-51

P-2964-3224 uCosminexus TP1/NET/Library(64) 07-50

P-2964-C324 uCosminexus TP1/Message Queue(64) 07-52

P-F2964-3224C uCosminexus TP1/NET/TCP/IP(64) 07-51

P-F2964-3224D uCosminexus TP1/NET/High Availability(64) 07-50

・適用OS：Windows Server 2008 R2，Windows Server 2012，Windows Server 2012 R2，Windows Server 2016，Windows Server 2019，Windows Server 2022

P-2464-2944 uCosminexus TP1/High Availability 07-51

P-2964-2924 uCosminexus TP1/High Availability(64) 07-50

・適用OS：Windows 10，Windows 10 x64 Edition，Windows 11，Windows Server 2016，Windows Server 2019，Windows Server 2022

P-2464-2294 uCosminexus TP1/Server Base 07-60

P-2464-2564 uCosminexus TP1/Extension 1 07-60

P-2464-2164 uCosminexus TP1/Client/P 07-60

・適用OS：Windows 10 x64 Edition，Windows 11，Windows Server 2016，Windows Server 2019，Windows Server 2022

P-2964-2234 uCosminexusTP1/Server Base(64) 07-60

P-2964-2534 uCosminexus TP1/Extension 1(64) 07-60

P-2964-2134 uCosminexus TP1/Client/P(64) 07-60

・適用OS：Windows Server 2016，Windows Server 2019，Windows Server 2022

P-2464-2954 uCosminexus TP1/High Availability 07-60

P-2964-2934 uCosminexus TP1/High Availability(64) 07-60

・適用OS：Java VM

P-2464-73B4 uCosminexus TP1/Client/J 07-53

これらのプログラムプロダクトのほかにもこのマニュアルをご利用になれる場合があります。詳細は「リリースノート」でご確認ください。

輸出時の注意

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

なお、不明な場合は、弊社担当営業にお問い合わせください。

商標類

HITACHI，Cosminexus，DCCM，HAモニタ，HiRDB，JP1，OpenTP1，OSAS，ServerConductor，SEWB，uCosminexus，XDM，XMAPは，株式会社 日立製作所の商標または登録商標です。

AMDは，Advanced Micro Devices, Inc.の商標です。

DockerおよびDockerロゴは，Docker Inc.の米国およびその他の国における商標もしくは登録商標です。

IBM，AIX，MQSeries，WebSphereは，世界の多くの国で登録されたInternational Business Machines Corporationの商標です。

Intelは，Intel Corporationまたはその子会社の商標です。

Linuxは，Linus Torvalds氏の米国およびその他の国における登録商標です。

Microsoft，Windows，Windows Serverは，マイクロソフト 企業グループの商標です。

OpenShift is a registered trademark of Red Hat, Inc. in the United States and other countries.

Oracle(R)，Java，MySQL及びNetSuiteは，Oracle，その子会社及び関連会社の米国及びその他の国における登録商標です。

Red Hat, and Red Hat Enterprise Linux are registered trademarks of Red Hat, Inc. in the United States and other countries. Linux(R) is the registered trademark of Linus Torvalds in the U.S. and other countries.

UNIXは，The Open Groupの登録商標です。

その他記載の会社名，製品名などは，それぞれの会社の商標もしくは登録商標です。

本書には，X/Openの許諾に基づき X/Open CAE Specification System Interfaces and Headers，Issue4，（C202 ISBN 1-872630-47-2）Copyright (C) July 1992，X/Open Company Limitedの内容が含まれています；

なお，その一部は IEEE Std 1003.1-1990，(C) 1990 Institute of Electrical and Electronics Engineers, Inc.及び IEEE std 1003.2/D12，(C) 1992 Institute of Electrical and Electronics Engineers, Inc.を基にしています。

事前に著作権所有者の許諾を得ずに，本書の該当部分を複製，複写及び転記することは禁じられています。

本書には，X/Openの許諾に基づき X/Open Preliminary Specification Distributed Transaction Processing : The TxRPC Specification（P305 ISBN 1-85912-000-8）Copyright (C) July 1993，X/Open Company Limitedの内容が含まれています；

事前に著作権所有者の許諾を得ずに，本書の該当部分を複製，複写及び転記することは禁じられています。

本書には，Open Software Foundation, Inc.が著作権を有する内容が含まれています。

This document and the software described herein are furnished under a license, and may be used and copied only in accordance with the terms of such license and with the inclusion of the above copyright notice. Title to and ownership of the document and software remain with OSF or its licensors.

発行

2024年4月　3000-3-D50-C0

著作権

All Rights Reserved. Copyright (C) 2006, 2024, Hitachi, Ltd.

変更内容

変更内容（3000-3-D50-C0） uCosminexus TP1/Server Base 07-60，uCosminexus TP1/Server Base(64) 07-60，uCosminexus TP1/Message Control 07-60，uCosminexus TP1/Message Control(64) 07-60，uCosminexus TP1/Message Control 07-52，uCosminexus TP1/Message Control(64) 07-52

追加・変更内容

変更個所

Red Hat Enterprise Linux Server 9 (64-bit x86_64)に対応した。

TP1/Server Base 07-60

TP1/FS/Direct Access 07-60

TP1/FS/Table Access 07-60

TP1/High Availability 07-60

TP1/Extension 1 07-60

TP1/Message Control 07-60

TP1/NET/Library 07-60

TP1/Message Control - Extension 1 07-60

TP1/NET/TCP/IP 07-60

TP1/NET/High Availability 07-60

TP1/NET/User Datagram Protocol 07-60

TP1/Server Base(64) 07-60

TP1/FS/Direct Access(64) 07-60

TP1/FS/Table Access(64) 07-60

TP1/High Availability(64) 07-60

TP1/Extension 1(64) 07-60

TP1/Message Control(64) 07-60

TP1/NET/Library(64) 07-60

TP1/Message Control - Extension 1(64) 07-60

TP1/NET/TCP/IP(64) 07-60

TP1/NET/High Availability(64) 07-60

TP1/NET/User Datagram Protocol(64) 07-60

−

関連製品にJP1 Version 13を追加した。

−

TP1/NET/High Availabilityの説明を変更した。

1.3.1(6)

性能検証用トレース取得機能の注意事項の説明を変更した。

5.3.6(4)

DockerおよびKubernetesの表記をコンテナオーケストレーションツールに変更した。

8.

この章を読む際の留意事項に説明を追加した。

8.1

前提ソフトウェアにPodmanを追加した。

8.2.2(1)

OpenShiftを使用する場合の説明を追加した。

8.3，8.3.1

トランザクション制御のリソースマネジャ連携にHiRDBを追加した。

8.4.1 表8-11

TP1/NET/TCP/IPにコネクション切り替え機能を使うときの説明を追加した。

付録A.1(1)

アプリケーション起動プロセス用論理端末の未送信メッセージ数に関する情報を表示できるようにした。

これに伴い，次のコマンドを追加した。

mcfalspsv

付録B 表B-2

次に示すバージョンの変更点に，TP1/Message Control 07-52の記載を追加した。

07-52での変更点

付録C.3 表C-5

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

変更内容（3000-3-D50-B0） uCosminexus TP1/Server Base 07-60，uCosminexus TP1/Server Base(64) 07-60

追加・変更内容

マニュアル訂正の内容を反映した。

ソケット受信型サーバは廃止したため使用できないことを記載した。

DockerおよびKubernetesを使用したコンテナ環境に関する動作について説明を追加した。

システム構成に関する次の説明を追加，変更した。

システム構成図の矢印について誤りを訂正

システム構成図にWindowsプラットフォームを追加

システム構成図に示す製品のバージョンに関する説明を追加

また，上記変更に伴い，次に示す表を変更した。

表8-2 サポートバージョン

表8-3 旧バージョンのTP1/Server BaseからのRPC通信可否

表8-4 旧バージョンのTP1/Client/JからのRPC通信可否

表8-5 旧バージョンのTP1/Server BaseへのRPC通信可否

表8-6 TP1/Client/Jから旧バージョンのTP1/Server BaseへのRPC通信可否

表8-7 他製品からTP1/Server BaseへのRPC

表8-8 TP1/Server Baseから他製品へのRPC

変更内容（3000-3-D50-A0） uCosminexus TP1/Server Base 07-57，uCosminexus TP1/Server Base(64) 07-57，uCosminexus TP1/Server Base 07-56，uCosminexus TP1/Server Base(64) 07-56

追加・変更内容

マニュアル訂正の内容を反映した。

DockerおよびKubernetesを使用したOpenTP1の構成と構築の説明を追加した。

次に示すバージョンの変更点の説明を追加した。

TP1/Server Base 07-56

変更内容（3000-3-D50-91） uCosminexus TP1/Server Base 07-54，uCosminexus TP1/Server Base(64) 07-54，uCosminexus TP1/Server Base 07-53，uCosminexus TP1/Server Base(64) 07-53

追加・変更内容

マニュアル訂正の内容を反映した。

常駐/非常駐プロセスによるマルチサーバの概要図を変更した。

系切り替え機能を使用する場合の説明を追加した。

キャッシュブロック数しきい値指定機能に関する説明を変更した。

回復対象外のDAMファイルのキャッシュレスアクセスに関する説明を追加した。

共有ディスク装置の割り当てに関する説明を変更した。

システムサービスプロセスの説明を追加および変更した。

次に示すバージョンの変更点の説明を変更した。

TP1/Server Base 07-07

変更内容（3000-3-D50-90） uCosminexus TP1/Server Base 07-53，uCosminexus TP1/Server Base(64) 07-53

追加・変更内容

販売終了製品に関連する機能の記載を削除した。

変更内容（3000-3-D50-80） uCosminexus TP1/Server Base 07-53，uCosminexus TP1/Server Base(64) 07-53，uCosminexus TP1/Server Base 07-52，uCosminexus TP1/Server Base(64) 07-52

追加・変更内容

OpenTP1監視サービスの説明を追加した。

OpenTP1の状態確認に関する説明を追加した。

OpenTP1の監視に関する説明を追加した。

強制停止処理中の系切り替え抑止機能に関する説明を追加した。

入出力ファイルの記述を削除した。

共用メモリの使用状況の表示に関する記述を削除した。

OpenTP1監視サービスで使用する共用メモリの説明を追加した。

次に示すバージョンの変更点を記載した。

TP1/Server Base 07-53

TP1/Server Base 07-52

変更内容（3000-3-D50-71） uCosminexus TP1/Server Base 07-51，uCosminexus TP1/Server Base(64) 07-51，uCosminexus TP1/Message Control 07-51，uCosminexus TP1/Message Control(64) 07-51，uCosminexus TP1/NET/Library 07-51，uCosminexus TP1/NET/Library(64) 07-51

追加・変更内容

マニュアル訂正の内容を反映した。

変更内容（3000-3-D50-70） uCosminexus TP1/Server Base 07-51，uCosminexus TP1/Server Base(64) 07-51，uCosminexus TP1/Message Control 07-51，uCosminexus TP1/Message Control(64) 07-51，uCosminexus TP1/NET/Library 07-51，uCosminexus TP1/NET/Library(64) 07-51

追加・変更内容

ERREVT2が通知された原因に関する説明を追加した。

MHPの再スケジュールに関する説明を追加した。

ノードをわたったOpenTP1プロセス間のTCP/IP通信の場合に限り，通信処理を終了した時点で毎回コネクションを切断するノード間通信時の毎回コネクション断機能の説明を追加した。

次に示すバージョンの変更点を記載した。

TP1/Server Base 07-51

TP1/Message Control 07-51およびTP1/NET/Library 07-51

次に示すバージョンの変更点の説明を変更した。

TP1/Server Base 07-50

次に示すバージョンの変更点の説明を変更した。

TP1/Server Base 07-00

変更内容（3000-3-D50-60） uCosminexus TP1/Server Base 07-50，uCosminexus TP1/Server Base(64) 07-50，uCosminexus TP1/Message Control 07-50，uCosminexus TP1/Message Control(64) 07-50，uCosminexus TP1/NET/Library 07-50，uCosminexus TP1/NET/Library(64) 07-50

追加・変更内容

XAリソースサービス使用時のタイマ監視範囲の説明を変更した。

注意事項に，起動通知機能を使用できない理由の説明を追加した。

注意事項に，ノード監視機能を使用できない理由の説明を追加した。

メッセージ制御機能におけるOpenTP1再開始時のメッセージの扱いに関する説明を追加した。

入力キューと出力キューの保留に関する説明を追加した。

閉塞されている論理端末のメッセージが未処理送信メッセージ滞留時間の対象とならないことを追加した。

dc_mcf_execap関数でアプリケーションを起動する順序に関する説明を追加した。

SPPのスケジュールでの，スケジュール対象の選択について説明を追加した。

マルチサーバ負荷バランス機能の説明を変更した。

ダイナミックコネクションスケジュールモードの説明を変更した。

ジャーナル容量に対する考え方について，説明を追加した。

TAMファイルのバックアップとリストアの説明を変更した。

TAMファイルからのユーザデータの抽出と，TAMファイルの再作成について説明を追加した。

システムサービスプロセスにprcteeを追加した。

受信用ポート番号を指定できるシステム定義のオペランドに，rpc_port_baseを追加した。

次に示すバージョンの変更点を記載した。

TP1/Server Base 07-50

TP1/Message Control 07-50およびTP1/NET/Library 07-50

TP1/Server Base 07-07

次に示すバージョンの変更点の説明を変更した。

TP1/Server Base 07-06

TP1/Server Base 07-05

TP1/Server Base 07-02

TP1/Server Base 07-00

変更内容（3000-3-D50-50） uCosminexus TP1/Server Base 07-06，uCosminexus TP1/Server Base(64) 07-06

追加・変更内容

OpenTP1の拡張機能を使うときに必要な製品（TP1/Extension 1，およびTP1/Message Control - Extension1）に関する説明を追加した。

ノード構成の変更（ノードの追加や削除）に自動的に対応する機能（ノード自動追加機能）を追加した。これに伴い，ノードリストファイルを追加した。

ユーザサーバごとに，共有化したバッファの使用サイズを制限できるようにした。

TP1/Client/JがDCCM3と通信する場合の説明を変更した。

rapクライアントマネジャの管理テーブルについての説明を追加した。

性能検証用トレースの情報をCSV形式で出力し，トレース解析できるようにした。

ネームサービス定義のname_audit_confオペランドに1または2を指定している場合，実行形式ファイルnamaudtdの稼働数が1になる旨を追加した。

OpenTP1で使用している受信用ポート番号domain_masters_portを削除した。

次に示すバージョンの変更点を記載した。

TP1/Server Base 07-06

TP1/Server Base 07-05

TP1/Server Base 07-02

TP1/Message Control 07-01およびTP1/NET/Library 07-02

TP1/Message Control 07-00およびTP1/NET/Library 07-00

一つのサービス要求ごとに実行するプロセスを起動し直せるようにした（非常駐UAPプロセスのリフレッシュ機能）。

uCosminexus TP1/Server Base 07-05，uCosminexus TP1/Server Base(64) 07-05，uCosminexus TP1/Message Control 07-05，uCosminexus TP1/Message Control(64) 07-05

追加・変更内容

入力キューと出力キューについて説明を変更した。

メッセージ出力通番について説明を追加した。

一つのリソースマネジャを複数の制御単位に分け，接続するユーザ名称などを変更してリソースマネジャに接続できるようにした（リソースマネジャ接続先選択機能）。

システムの稼働数についての説明を追加した。

uCosminexus TP1/Server Base 07-02，uCosminexus TP1/Message Control 07-01

追加・変更内容

前回のオンライン停止時に残っていた未処理受信メッセージや未送信メッセージを引き継ぎ，TP1/Message Controlの構成を変更できるようにした（MCF構成変更再開始機能）。

また，OpenTP1の日常的な運用にOpenTP1のMCF構成変更準備停止を追加した。

uCosminexus TP1/Message Control 07-00，uCosminexus TP1/Message Control(64) 07-00

追加・変更内容

リモートMCFサービスに関連する記述を削除した。

変更内容（3000-3-D50-40） uCosminexus TP1/Server Base 07-04，uCosminexus TP1/Server Base(64) 07-04，uCosminexus TP1/Message Control 07-05，uCosminexus TP1/Message Control(64) 07-05，uCosminexus TP1/NET/Library 07-05，uCosminexus TP1/NET/Library(64) 07-05

追加・変更内容

異常終了したMHPを，自動的に再スケジュールできるようにした。

チェックポイントダンプ取得契機のスキップ回数を監視できるようにした。

次に示すシステムサービスプロセスの説明を変更した。

trnrvd

jnlsdd

admrsvre

OpenTP1で使用しているポート番号の説明を変更した。

サービス関数動的ローディング機能で使用する，UAP共用ライブラリのサーチパスをオンライン中に変更できるようにした。

OpenTP1の起動コマンドがリターンした直後にMCFの運用コマンドを実行する場合，mcftlscomコマンドでMCF通信サービスの開始を待ち合わせられるようにした。

次に示すバージョンの変更点を記載した。

TP1/Message Control 07-05およびTP1/NET/Library 07-05

TP1/Server Base 07-04

TP1/Message Control 07-02およびTP1/NET/Library 07-03

TP1/Server Base 07-00

変更内容（3000-3-D50-30） uCosminexus TP1/Server Base 07-03，uCosminexus TP1/Server Base(64) 07-03，uCosminexus TP1/Message Control 07-03，uCosminexus TP1/Message Control(64) 07-03，uCosminexus TP1/NET/Library 07-04，uCosminexus TP1/NET/Library(64) 07-04

追加・変更内容

ジャーナルサービスで性能検証用トレース（JNL性能検証用トレース）を出力できるようにした。

ロックサービスを使用した排他制御の各種イベントの性能検証用トレース（LCK性能検証用トレース）を出力できるようにした。

グローバルドメインの説明を追加した。

特定のノードのサービス情報を優先的に使用する機能（サービス情報優先度指定機能）を追加した。

UAP異常終了通知イベント，および未処理送信メッセージ廃棄通知イベントの，MCFイベントが通知された原因の説明を変更した。

縮退運転の説明を変更した。

メッセージが回復できない場合の説明を追加した。

メッセージの送信順序の説明を変更した。

dc_rpc_cltsend関数で通知したデータを受け取る関数の説明を変更した。

OpenTP1ファイルシステムとOSが提供するファイルシステムとの違いの説明を変更した。

OpenTP1ファイルへのアクセス要求で，イベントトレース（FILイベントトレース）を出力できるようにした。

キャッシュレスアクセス指定のDAMファイルを使用する場合のDAMサービス専用共用メモリサイズについて説明を変更した。

性能検証用トレース取得サービスの稼働数を変更した。また，関連する定義を変更した。

受信用ポート番号を指定できるシステムサービスについて説明を追加した。

アプリケーションに関するタイマ起動要求の状態を表示できるようにした。

OpenTP1の標準出力，標準エラー出力をリダイレクトするprcteeプロセスを停止・再開始できるようにした。

ユーザタイマ監視の状態を表示できるようにした。

次に示すバージョンの変更点を記載した。

TP1/Server Base 07-03

TP1/Message Control 07-03およびTP1/NET/Library 07-04

TP1/Message Control 07-02およびTP1/NET/Library 07-03

TP1/Message Control 07-01およびTP1/NET/Library 07-01

リモートプロシジャコールの処理の概要を追加した。

uCosminexus TP1/Message Control 07-02，uCosminexus TP1/NET/Library 07-03

追加・変更内容

MHPでサービス関数動的ローディング機能を使用できるようにした。

次の操作を，ライブラリ関数でできるようにした。

コネクションの状態表示，確立，および解放

サーバ型コネクションの確立要求の状態表示，および受付開始・終了

アプリケーションに関するタイマ起動要求の削除

論理端末の状態表示，閉塞，閉塞解除，および出力キューの削除

MCF通信サービスまたはアプリケーション起動サービスの状態表示

MCF静的共用メモリが不足し未使用領域から自動的に追加確保する場合に，メッセージを出力できるようにした。

相手システムとのメッセージ送受信に関するネットワークの状態を表示できるようにした。

uCosminexus TP1/Message Control 07-01，uCosminexus TP1/NET/Library 07-01

追加・変更内容

メッセージ送受信での主なイベントで，性能検証用トレース（MCF性能検証用トレース）を出力できるようにした。

サーバ型コネクションの確立要求の受付開始・終了を手動でできるようにした。

変更内容（3000-3-D50-20） uCosminexus TP1/Server Base 07-02，uCosminexus TP1/Message Control 07-01，uCosminexus TP1/NET/Library 07-01

追加・変更内容

XAリソースサービスで性能検証用トレース（prfトレース）を出力できるようにした。

サービス関数を動的にローディングできる機能を追加した。

タイマ監視機能によるタイマ監視の対象を追加した。また，監視対象に対応するOpenTP1の定義を変更した。

スケジュールサービスの動作をサービス単位で指定できるようにした。

MS-DOS用のTP1/Client/Pでのユーザ認証機能の使い方を削除した。

リモートAPI機能に関する説明を変更した。

監査ログを出力する機能を追加した。

システムジャーナルファイルの並列アクセス機能を追加した。

ネームサービスでイベントトレースを出力できるようにした。

プロセスサービスでイベントトレースを出力できるようにした。

システムジャーナルファイルを使用しないでシステムを運用する機能（ジャーナルファイルレス機能）を追加した。

これに伴い，システムサービスプロセスの稼働数を変更した。

次に示すバージョンの変更点を記載した。

TP1/Server Base 07-02

TP1/Message Control 07-01およびTP1/NET/Library 07-01

はじめに

このマニュアルは，分散トランザクション処理機能OpenTP1の概要について説明したものです。

本文中に記載されている製品のうち，このマニュアルの対象製品ではない製品については，OpenTP1 Version 7対応製品の発行時期をご確認ください。

TP1/Message Queueは，米国International Business Machines Corporationとのライセンス契約に基づき，IBM MQ（旧称：WebSphere MQまたはMQSeries）のMQI，MQFAP，MQクラスタの仕様をベースに実装しています。

次に示す製品，および各製品に示したバージョン以降で，ソケット受信型サーバに関する機能はすべて廃止しました。

P-1M64-2141 uCosminexus TP1/Server Base：07-53-01以降

P-1M64-1121 uCosminexus TP1/Server Base(64)：07-53-01以降

P-1J64-2171 uCosminexus TP1/Server Base：07-51-02以降

P-1J64-1171 uCosminexus TP1/Server Base(64)：07-51-01以降

P-8164-2111 uCosminexus TP1/Server Base：07-57以降

P-8264-2111 uCosminexus TP1/Server Base(64)：07-57以降

P-2464-2294 uCosminexus TP1/Server Base：07-60以降

P-2964-2234 uCosminexus TP1/Server Base(64)：07-60以降

なお，該当する機能を使用した場合の動作は保証できないため，ご注意ください。

対象読者

システム管理者，システム設計者，プログラマ，およびオペレータの方を対象としています。なお，オペレーティングシステム，オンラインシステムの基礎的な知識があることを前提としています

関連マニュアル

マニュアル「OpenTP1 プロトコル」の各プロトコル編については，ご使用の製品のバージョンに対応するマニュアルの発行時期をご確認ください。

●関連製品

索引順編成ファイル管理 ISAM（3000-3-046）

Linux(R)，HP-UX　通信管理　XNF/LS　使用の手引（3000-3-B51）

AIX 通信管理 XNF/AS 解説・運用編（3000-3-B61）

高信頼化システム監視機能 HAモニタ AIX(R)編（3000-9-130）

高信頼化システム監視機能 HAモニタ AIX(R)編（3000-9-202）

高信頼化システム監視機能 HAモニタ Linux(R)編（3000-9-132）

高信頼化システム監視機能 HAモニタ HP-UX（IPF）編（3000-9-133）

高信頼化システム監視機能 HAモニタ メッセージ（3000-9-134）

高信頼化システム監視機能 HAモニタ Linux(R)（x86）編（3000-9-140）

Hitachi HA Toolkit（3000-9-115）

JP1 Version 8 JP1/Automatic Job Management System 2 - Scenario Operation（3020-3-K42）

JP1 Version 8 JP1/ServerConductor/Deployment Manager（3020-3-L53）

JP1 Version 9 JP1/ServerConductor/Deployment Manager（3020-3-T77）

SEWB+ クライアントサーバシステム開発ガイド（3020-3-N83）

HiRDB Version 9 システム導入・設計ガイド（UNIX(R)用）（3000-6-452）

HiRDB Version 9 システム導入・設計ガイド（Windows(R)用）（3020-6-452）

HiRDB Version 9 UAP開発ガイド（3020-6-456）

HiRDB Version 10 システム導入・設計ガイド（UNIX(R)用）（3020-6-552）

HiRDB Version 10 システム導入・設計ガイド（Windows (R)用）（3020-6-553）

HiRDB Version 10 UAP開発ガイド（3020-6-560）

XMAP3 Version 5 画面・帳票サポートシステム XMAP3 実行ガイド（3020-7-514）

JP1 Version 10 JP1/Base 運用ガイド（3021-3-001）

JP1 Version 10 JP1/Base メッセージ（3021-3-002）

JP1 Version 10 JP1/Base 関数リファレンス（3021-3-003）

JP1 Version 10 JP1/Automatic Job Management System 3 入門（3021-3-101）

JP1 Version 10 JP1/Automatic Job Management System 3 導入ガイド（3021-3-102）

JP1 Version 10 JP1/Automatic Job Management System 3 設計ガイド（システム構築編）（3021-3-103）

JP1 Version 10 JP1/Automatic Job Management System 3 設計ガイド（業務設計編）（3021-3-104）

JP1 Version 10 JP1/Automatic Job Management System 3 構築ガイド1（3021-3-105）

JP1 Version 10 JP1/Automatic Job Management System 3 構築ガイド2（3021-3-106）

JP1 Version 10 JP1/Automatic Job Management System 3 運用ガイド（3021-3-107）

JP1 Version 10 JP1/Automatic Job Management System 3 トラブルシューティング（3021-3-108）

JP1 Version 10 JP1/Automatic Job Management System 3 操作ガイド（3021-3-109）

JP1 Version 10 JP1/Automatic Job Management System 3 コマンドリファレンス1（3021-3-110）

JP1 Version 10 JP1/Automatic Job Management System 3 コマンドリファレンス2（3021-3-111）

JP1 Version 10 JP1/Automatic Job Management System 3 連携ガイド（3021-3-112）

JP1 Version 10 JP1/Automatic Job Management System 3 メッセージ1（3021-3-113）

JP1 Version 10 JP1/Automatic Job Management System 3 メッセージ2（3021-3-114）

JP1 Version 10 JP1/Audit Management - Manager 構築・運用ガイド（3021-3-165）

JP1 Version 11 JP1/Base 運用ガイド（3021-3-A01）

JP1 Version 11 JP1/Base メッセージ（3021-3-A02）

JP1 Version 11 JP1/Base 関数リファレンス（3021-3-A03）

JP1 Version 11 ジョブ管理 基本ガイド（ジョブスケジューラー編）（3021-3-B11）

JP1 Version 11 JP1/Automatic Job Management System 3 導入ガイド（3021-3-B12）

JP1 Version 11 JP1/Automatic Job Management System 3 設計ガイド（システム構築編）（3021-3-B13）

JP1 Version 11 JP1/Automatic Job Management System 3 設計ガイド（業務設計編）（3021-3-B14）

JP1 Version 11 JP1/Automatic Job Management System 3 構築ガイド（3021-3-B15）

JP1 Version 11 JP1/Automatic Job Management System 3 運用ガイド（3021-3-B16）

JP1 Version 11 JP1/Automatic Job Management System 3 トラブルシューティング（3021-3-B17）

JP1 Version 11 JP1/Automatic Job Management System 3 操作ガイド（3021-3-B18）

JP1 Version 11 JP1/Automatic Job Management System 3 コマンドリファレンス（3021-3-B19）

JP1 Version 11 JP1/Automatic Job Management System 3 連携ガイド（3021-3-B20）

JP1 Version 11 JP1/Automatic Job Management System 3 メッセージ（3021-3-B21）

JP1 Version 11 JP1/Audit Management - Manager 構築・運用ガイド（3021-3-A17）

JP1 Version 12 JP1/Base 運用ガイド（3021-3-D65）

JP1 Version 12 JP1/Base メッセージ（3021-3-D66）

JP1 Version 12 JP1/Base 関数リファレンス（3021-3-D67）

JP1 Version 12 ジョブ管理 基本ガイド（ジョブスケジューラー編）（3021-3-D20）

JP1 Version 12 JP1/Automatic Job Management System 3 導入ガイド（3021-3-D21）

JP1 Version 12 JP1/Automatic Job Management System 3 設計ガイド（システム構築編）（3021-3-D22）

JP1 Version 12 JP1/Automatic Job Management System 3 設計ガイド（業務設計編）（3021-3-D23）

JP1 Version 12 JP1/Automatic Job Management System 3 構築ガイド（3021-3-D24）

JP1 Version 12 JP1/Automatic Job Management System 3 運用ガイド（3021-3-D25）

JP1 Version 12 JP1/Automatic Job Management System 3 トラブルシューティング（3021-3-D26）

JP1 Version 12 JP1/Automatic Job Management System 3 操作ガイド（3021-3-D27）

JP1 Version 12 JP1/Automatic Job Management System 3 コマンドリファレンス（3021-3-D28）

JP1 Version 12 JP1/Automatic Job Management System 3 連携ガイド（3021-3-D29）

JP1 Version 12 JP1/Automatic Job Management System 3 メッセージ（3021-3-D30）

JP1 Version 13 JP1/Base 運用ガイド（3021-3-L09）

JP1 Version 13 JP1/Base メッセージ（3021-3-L10）

JP1 Version 13 JP1/Base 関数リファレンス（3021-3-L11）

JP1 Version 13 ジョブ管理 基本ガイド（ジョブスケジューラー編）（3021-3-L41）

JP1 Version 13 JP1/Automatic Job Management System 3 導入ガイド（3021-3-L42）

JP1 Version 13 JP1/Automatic Job Management System 3 設計ガイド（システム構築編）（3021-3-L43）

JP1 Version 13 JP1/Automatic Job Management System 3 設計ガイド（業務設計編）（3021-3-L44）

JP1 Version 13 JP1/Automatic Job Management System 3 構築ガイド（3021-3-L45）

JP1 Version 13 JP1/Automatic Job Management System 3 運用ガイド（3021-3-L46）

JP1 Version 13 JP1/Automatic Job Management System 3 トラブルシューティング（3021-3-L47）

JP1 Version 13 JP1/Automatic Job Management System 3 操作ガイド（3021-3-L48）

JP1 Version 13 JP1/Automatic Job Management System 3 コマンドリファレンス（3021-3-L49）

JP1 Version 13 JP1/Automatic Job Management System 3 連携ガイド（3021-3-L50）

JP1 Version 13 JP1/Automatic Job Management System 3 メッセージ（3021-3-L51）

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

正式名称

このマニュアルでの表記

OpenTP1　クライアント使用の手引 TP1/Client/W，TP1/Client/P編

OpenTP1　クライアント使用の手引

OpenTP1　クライアント使用の手引　TP1/Client/J編

OpenTP1 メッセージキューイング機能 TP1/Message Queue 使用の手引

TP1/Message Queue 使用の手引

OpenTP1 メッセージキューイング機能 TP1/Message Queue プログラム作成の手引

TP1/Message Queue プログラム作成の手引

OpenTP1 メッセージキューイング機能 TP1/Message Queue プログラム作成リファレンス

TP1/Message Queue プログラム作成リファレンス

メッセージキューイングアクセス機能 TP1/Message Queue Access 使用の手引

TP1/Message Queue Access 使用の手引

メッセージキューイング運用監視機能 Message Queue - Operation 使用の手引

Message Queue - Operation 使用の手引

高信頼化システム監視機能 HAモニタ AIX(R)編

高信頼化システム監視機能 HAモニタ

高信頼化システム監視機能 HAモニタ Linux(R)編

高信頼化システム監視機能 HAモニタ Linux(R)（x86）編

高信頼化システム監視機能 HAモニタ HP-UX（IPF）編

高信頼化システム監視機能 HAモニタ メッセージ

JP1 Version 10 JP1/Base 運用ガイド

JP1/Base 運用ガイド

JP1/Base

JP1 Version 11 JP1/Base 運用ガイド

JP1 Version 12 JP1/Base 運用ガイド

JP1 Version 13 JP1/Base 運用ガイド

JP1 Version 10 JP1/Base メッセージ

JP1/Base メッセージ

JP1 Version 11 JP1/Base メッセージ

JP1 Version 12 JP1/Base メッセージ

JP1 Version 13 JP1/Base メッセージ

JP1 Version 10 JP1/Base 関数リファレンス

JP1/Base 関数リファレンス

JP1 Version 11 JP1/Base 関数リファレンス

JP1 Version 12 JP1/Base 関数リファレンス

JP1 Version 13 JP1/Base 関数リファレンス

JP1 Version 10 JP1/Automatic Job Management System 3 構築ガイド1

JP1/Automatic Job Management System 構築ガイド

JP1 Version 10 JP1/Automatic Job Management System 3 構築ガイド2

JP1 Version 11 JP1/Automatic Job Management System 3 構築ガイド

JP1 Version 12 JP1/Automatic Job Management System 3 構築ガイド

JP1 Version 13 JP1/Automatic Job Management System 3 構築ガイド

JP1 Version 10 JP1/Automatic Job Management System 3 操作ガイド

JP1/Automatic Job Management System 操作ガイド

JP1 Version 11 JP1/Automatic Job Management System 3 操作ガイド

JP1 Version 12 JP1/Automatic Job Management System 3 操作ガイド

JP1 Version 13 JP1/Automatic Job Management System 3 操作ガイド

JP1 Version 8 JP1/Automatic Job Management System 2 - Scenario Operation

JP1/Automatic Job Management System 2 - Scenario Operation

JP1 Version 10 JP1/Audit Management - Manager 構築・運用ガイド

JP1/NETM/Audit

JP1 Version 11 JP1/Audit Management - Manager 構築・運用ガイド

JP1 Version 8 JP1/ServerConductor/Deployment Manager

JP1/ServerConductor/Deployment Manager

JP1 Version 9 JP1/ServerConductor/Deployment Manager

HiRDB Version 9 システム導入・設計ガイド（UNIX(R)用）

HiRDB システム導入・設計ガイド

HiRDB Version 10 システム導入・設計ガイド（UNIX(R)用）

HiRDB Version 9 システム導入・設計ガイド（Windows(R)用）

HiRDB Version 10 システム導入・設計ガイド（Windows(R)用）

HiRDB Version 9 UAP開発ガイド

HiRDB UAP開発ガイド

HiRDB Version 10 UAP開発ガイド

関連マニュアルの読書手順

OpenTP1の一連の関連マニュアルは，利用目的に合わせて，選択して読むことができます。次の案内に従ってお読みいただくことをお勧めします。

図中で使用する記号

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

このマニュアルでの表記

(1)製品名

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

製品名称

略称

AIX V6.1

AIX

AIX V7.1

AIX V7.2

AIX 7.3

COBOL2002 Net Developer

COBOL

COBOL2002 Net Server Runtime

COBOL2002 Net Server Runtime(64)

COBOL2002 Net Server Suite

COBOL2002 Net Server Suite(64)

COBOL85

JP1/ServerConductor/Deployment Manager

DPM

HiRDB Server Version 9

HiRDB

HiRDB Server Version 10

HP-UX 11i V2 (IPF)

HP-UX (IPF)

HP-UX

HP-UX 11i V3 (IPF)

Itanium Processor Family

IPF

Java Virtual Machine

Java VM

JP1/Automatic Job Management System 3 - Agent

JP1/AJS - Agent

JP1/AJS

JP1

JP1/Automatic Job Management System 3 - Manager

JP1/AJS - Manager

JP1/Automatic Job Management System 3 - View

JP1/AJS - View

JP1/Automatic Job Management System 2 - Scenario Operation Manager

JP1/AJS2 - Scenario Operation Manager

JP1/AJS2 - Scenario Operation

JP1/Automatic Job Management System 2 - Scenario Operation View

JP1/AJS2 - Scenario Operation View

JP1/Audit Management - Manager

JP1/NETM/Audit

Red Hat Enterprise Linux Server 6 (32-bit x86)

Linux (AMD64／Intel EM64T／x86)

Linux

Red Hat Enterprise Linux Server 6 (64-bit x86_64)

Red Hat Enterprise Linux Server 7 (64-bit x86_64)

Red Hat Enterprise Linux Server 8 (64-bit x86_64)

Red Hat Enterprise Linux Server 9 (64-bit x86_64)

JP1/NETM/DM Client

NETM/DM

JP1/NETM/DM Manager

JP1/NETM/DM SubManager

Oracle 9i Database

Oracle

Oracle Database 10g

Oracle Database 11g

Oracle Database 12c

Oracle Database 18c

Oracle Database 19c

Oracle Database 21c

Solaris 8

Solaris

Solaris 9

Solaris 10

uCosminexus TP1/Client/J

TP1/Client/J

TP1/Client

uCosminexus TP1/Client/P

TP1/Client/P

uCosminexus TP1/Client/P(64)

uCosminexus TP1/Client/W

TP1/Client/W

uCosminexus TP1/Client/W(64)

uCosminexus TP1/Client for .NET Framework

TP1/Client for .NET Framework

Client .NET

uCosminexus TP1/Connector for .NET Framework

TP1/Connector for .NET Framework

Connector .NET

uCosminexus TP1/Extension for .NET Framework

TP1/Extension for .NET Framework

Extension.NET

uCosminexus TP1/Server Base Enterprise Option

TP1/EE

uCosminexus TP1/Server Base Enterprise Option(64)

uCosminexus TP1/Extension 1

TP1/Extension 1

uCosminexus TP1/Extension 1(64)

uCosminexus TP1/FS/Direct Access

TP1/FS/Direct Access

uCosminexus TP1/FS/Direct Access(64)

uCosminexus TP1/FS/Table Access

TP1/FS/Table Access

uCosminexus TP1/FS/Table Access(64)

uCosminexus TP1/High Availability

TP1/High Availability

uCosminexus TP1/High Availability(64)

uCosminexus TP1/LiNK

TP1/LiNK

uCosminexus TP1/Message Control

TP1/Message Control

uCosminexus TP1/Message Control(64)

uCosminexus TP1/Message Control/Tester

TP1/Message Control/Tester

uCosminexus TP1/Message Control - Extension 1

TP1/Message Control - Extension 1

uCosminexus TP1/Message Control - Extension 1(64)

uCosminexus TP1/Message Queue

TP1/Message Queue

uCosminexus TP1/Message Queue(64)

uCosminexus TP1/Message Queue Access

TP1/Message Queue Access

uCosminexus TP1/Message Queue Access(64)

uCosminexus TP1/Messaging

TP1/Messaging

uCosminexus TP1/Multi

TP1/Multi

uCosminexus TP1/NET/High Availability

TP1/NET/High Availability

uCosminexus TP1/NET/High Availability(64)

uCosminexus TP1/NET/Library

TP1/NET/Library

uCosminexus TP1/NET/Library(64)

uCosminexus TP1/NET/OSAS-NIF

TP1/NET/OSAS-NIF

uCosminexus TP1/NET/OSI-TP

TP1/NET/OSI-TP

uCosminexus TP1/NET/Secondary Logical Unit - TypeP2

TP1/NET/SLU - TypeP2

uCosminexus TP1/NET/TCP/IP

TP1/NET/TCP/IP

uCosminexus TP1/NET/TCP/IP(64)

uCosminexus TP1/NET/User Datagram Protocol

TP1/NET/UDP

uCosminexus TP1/NET/User Datagram Protocol(64)

uCosminexus TP1/NET/User Agent

TP1/NET/User Agent

uCosminexus TP1/NET/XMAP3

TP1/NET/XMAP3

uCosminexus TP1/Offline Tester

TP1/Offline Tester

uCosminexus TP1/Online Tester

TP1/Online Tester

uCosminexus TP1/Resource Manager Monitor

TP1/Resource Manager Monitor

uCosminexus TP1/Server Base

TP1/Server Base

uCosminexus TP1/Server Base(64)

uCosminexus TP1/Shared Table Access

TP1/Shared Table Access

uCosminexus TP1/Web

TP1/Web

uCosminexus TP1/Web(64)

Windows 7 Enterprise (x86)

Windows 7

Windows 7

Windows 7 Professional (x86)

Windows 7 Ultimate (x86)

Windows 7 Enterprise (x64)

Windows 7 x64 Edition

Windows 7 Professional (x64)

Windows 7 Ultimate (x64)

Windows 8 Enterprise (x86)

Windows 8

Windows 8

Windows 8 Pro (x86)

Windows 8 Enterprise (x64)

Windows 8 x64 Edition

Windows 8 Pro (x64)

Windows 8.1 Enterprise (x86)

Windows 8.1

Windows 8.1

Windows 8.1 Pro (x86)

Windows 8.1 Enterprise (x64)

Windows 8.1 x64 Edition

Windows 8.1 Pro (x64)

Windows 10 Enterprise (x86)

Windows 10

Windows 10

Windows 10 Pro (x86)

Windows 10 Enterprise (x64)

Windows 10 x64 Edition

Windows 10 Pro (x64)

Windows 11 Enterprise

Windows 11

Windows 11 Pro

Windows Server 2008 R2 Datacenter

Windows Server 2008 R2

Windows Server 2008

Windows Server 2008 R2 Enterprise

Windows Server 2008 R2 Standard

Windows Server 2012 Datacenter

Windows Server 2012

Windows Server 2012 Standard

Windows Server 2012 R2 Datacenter

Windows Server 2012 R2

Windows Server 2012 R2 Standard

Windows Server 2016 Datacenter

Windows Server 2016

Windows Server 2016 Standard

Windows Server 2019 Datacenter

Windows Server 2019

Windows Server 2019 Standard

Windows Server 2022 Datacenter

Windows Server 2022

Windows Server 2022 Standard

Windows 7，Windows 8，Windows 8.1，Windows 10，Windows 11，Windows Server 2008，Windows Server 2012，Windows Server 2012 R2，Windows Server 2016，Windows Server 2019，およびWindows Server 2022で機能差がない場合，Windowsと表記しています。

AIX，HP-UX，Linux，およびSolarisを総称してUNIXと表記しています。

(2)適用OSによる違いについて

Windows版の製品をご使用になる場合，マニュアルの記述を次のように読み替えてください。

項目

マニュアルの表記

読み替え

環境変数の表記

$aaaaaa

例　$DCDIR

%aaaaaa%

例　%DCDIR%

複数のパス名を列挙するときの区切り文字

:

;

ディレクトリの区切り文字

/

¥

完全パス名

ルートディレクトリから指定します。

例　/tmp

先頭にドライブ文字を付加して，ルートディレクトリから指定します。

例　C:¥tmp

実行形式ファイル名

ファイル名だけを指定します。

例　mcfmngrd

ファイル名に拡張子を付加して指定します。

例　mcfmngrd.exe

makeコマンド

make

nmake

(3)インストールディレクトリのパスの違いについて

このマニュアルでは，OpenTP1のインストールディレクトリを「/BeTRAN」と表記しています。インストールディレクトリはOSによって異なります。ご利用のOSに応じて，次の表のとおりに読み替えてください。

このマニュアルでの表記

適用OSごとの読み替え

AIX，HP-UXまたはSolaris

Linux

Windows

/BeTRAN

/BeTRAN

/opt/OpenTP1

OpenTP1をインストールしたディレクトリ

(4)JISコード配列のキーボードとASCIIコード配列のキーボードとの違いについて

JISコード配列とASCIIコード配列では，次に示すコードで入力文字の違いがあります。このマニュアルの文字入力例（コーディング例）の表記は，JISコード配列（日本語のキーボード）に従った文字に統一しています。

コード

JISコード配列

ASCIIコード配列

(5c)₁₆

' ¥ '（円記号）

' ＼ '（バックスラッシュ）

(7e)₁₆

' ￣ '（オーバライン）

' ~ '（チルド）

略語一覧

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

英略語

英字での表記

ACL

Access Control List

ANSI

American National Standards Institute

AP

Application Program

API

Application Programming Interface

C/S

Client/Server

CGI

Common Gateway Interface

CPU

Central Processing Unit

CRM

Communication Resource Manager

CUP

Client User Program

DAM

Direct Access Method

DAM FRC

DAM File Recovery

DB

Database

DBMS

Database Management System

DCE

Distributed Computing Environment

DHCP

Dynamic Host Configuration Protocol

DID

Distributed Identifier

DML

Data Manipulation Language

DNS

Domain Name System

DPM

ServerConductor/DeploymentManager

DTP

Distributed Transaction Processing

EX

Exclusive

FDDI

Fiber Distributed Data Interface

FEP

Front End Processor

FIFO

First-In-First-Out

FRC

File Recovery

GUI

Graphical User Interface

HA

High Availability

HTML

Hyper Text Markup Language

I/O

Input/Output

ID

Identifier

IDL

Interface Definition Language

IP

Internet Protocol

ISAM

Indexed Sequential Access Method

IST

Internode Shared Table

J2EE

Java 2 Enterprise Edition

JCA

J2EE Connector Architecture

JDBC

Java DataBase Connectivity

LAN

Local Area Network

MCF

Message Control Facility

MHP

Message Handling Program

MQ

Message Queue

MQA

Message Queue Access

MQI

Message Queue Interface

MQT

Message Queue Transfer

MSDTC

Microsoft Distributed Transaction Coordinator

NIF/OSI

Network Interface Feature/OSI

NIS

Network Information Service

OLTP

Online Transaction Processing

OS

Operating System

OSI

Open Systems Interconnection

OSI TP

Open Systems Interconnection Transaction Processing

PC

Personal Computer

PR

Protected Retrieve

PRF

Performance

RI

Recovery Information

RM

Resource Manager

RMM

Resource Manager Monitor

RPC

Remote Procedure Call

RTS

Real Time Statistic

SCSI

Small Computer Systems Interface

SNA

Systems Network Architecture

SPP

Service Providing Program

SRF

Server Recovery Journal File

SUP

Service Using Program

TAM

Table Access Method

TAM FRC

TAM File Recovery

TCO

Total Cost of Ownership

TCP/IP

Transmission Control Protocol/Internet Protocol

TP

Transaction Processing

TRF

Transaction Recovery journal File

UAP

User Application Program

UID/GID

User Identifier/Group Identifier

UOC

User Own Coding

UTC

Coordinated Universal Time

VM

Virtual Machine

WAN

Wide Area Network

WS

Workstation

WWW

World Wide Web

XA

Extended Architecture

XAR

Extended Architecture Resource

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

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

1　概要

この章では，OpenTP1の特長，システム形態，ソフトウェア構成，およびサービスについて説明します。

1.1　OpenTP1の特長

分散トランザクション処理機能OpenTP1は，オープンシステム上でオンライントランザクション処理※（OLTP　Online Transaction Processing）をできるようにするソフトウェア（TPモニタ）です。

近年の情報処理システムの形態は，分散システム化，オープンシステム化の傾向にあります。さらに，業務の拡大に柔軟に対応できる拡張性が求められています。OpenTP1を使用すると，現存する資産を生かしながら，分散システムやオープン環境に対応できるOLTPを実現できます。

OpenTP1の特長を次の図に示します。

図1‒1　OpenTP1の特長

注※

データ通信業務では，業務処理ごとの単位に区切って，それぞれの処理の結果を有効にするか無効にするかを明確に決める必要があります。有効にするか無効にするかどちらかに決定する処理の単位をトランザクションといいます。

1.1.1　トランザクション処理ができる分散コンピューティング環境の実現

従来のOLTPは，大規模コンピュータで一括して処理する，集中型のOLTPでした。OpenTP1を使うと，資源・機能を適切に分散配置した，分散コンピューティング環境でのOLTPを実現できます。そのため，システム規模や業務量など，それぞれのシステム固有の状況に適した構成を柔軟に選択できます。

従来のシステムと，分散コンピューティング環境のOLTPの比較を次の図に示します。

図1‒2　従来のシステムと分散コンピューティング環境のOLTPの比較

1.1.2　柔軟なシステム構成

OpenTP1では，分散コンピューティング環境でのOLTPを実現するために，ユーザアプリケーションプログラム（UAP）を含めたシステム構成が，クライアント/サーバ構造をしています。このため，プログラムやデータベースなどのソフトウェア資源を，ハードウェアの構成から独立させることができます。さらに，業務量の増加などでハードウェア構成を変更しても，ソフトウェア資源にはほとんど影響がありません。

柔軟なシステム構成を次の図に示します。

図1‒3　柔軟なシステム構成

1.1.3　基幹システムと連携した大規模システムの実現

OpenTP1を使用したシステムは，VOS3システムなどの基幹システムと接続できます。このため，基幹システムの大容量データベース管理やネットワーク管理の業務に，OpenTP1の分散コンピューティング環境を統合できます。

その結果，基幹システムからワークステーションまでの広範囲にわたる大規模システムを実現できます。

基幹システムと連携した大規模システムを次の図に示します。

図1‒4　基幹システムと連携した大規模システム

1.1.4　オープンシステム化推進の支援

OpenTP1の構造は，オープンシステムの標準化団体であるX/Openで規定しているDTPモデルに準拠しています。そのため，OpenTP1で構築したOLTPシステムを使用すると，オープンシステムの利点を生かしたデータ通信システムを構築できます。主な特長を次に示します。

OpenTP1のUAPでは，X/Openに準拠したAPI（TXインタフェースでのトランザクション制御，XATMIインタフェースでの通信，TxRPCインタフェースでの通信）を使用できます。

OpenTP1は，X/OpenのXAインタフェースに準拠した，DBMSなど各種リソースマネジャと接続できます。

1.1.5　システム構築の高生産性と高信頼性の実現

分散コンピューティング環境でのビジネスアプリケーションのトランザクション処理には，高い生産性と信頼性が必要です。OpenTP1では，生産性と信頼性を上げるための各種機能を提供しています。これらの機能を使用することで，分散処理システムを構築する上でのユーザの負担を軽減させ，目的業務に応じたシステム設計ができます。

UAPをコーディングするときには，C言語，C++言語，およびCOBOL言語を使えます。C言語でコーディングする場合には，ANSI C形式，またはANSI準拠前のK&R形式のどちらでも使えます。COBOL言語でコーディングする場合には，COBOL85またはCOBOL2002のどちらでも使えます。そのため，プログラマの技術環境に合った言語で開発できます。

COBOL言語ではデータ操作言語（DML）も使用できるので，従来のホストコンピュータでのUAP作成環境を，OpenTP1で実現できます。

高い信頼性を要求される24時間運転業務に対応するため，OpenTP1ではシステムの二重化を支援する機能（系切り替え機能）を備えています。系切り替え機能を使用すると，システムの障害による停止時間を最小限に抑えて，システム全体の稼働率を向上できます。

1.2　OpenTP1のシステム形態

OpenTP1を使用したシステム（OpenTP1システム）は，次のような形態へ適用できます。

1.2.1　クライアント/サーバシステム（C/Sシステム）の形態

クライアント/サーバ方式で構築する，水平分散のシステム形態です。複数のOpenTP1システムが，互いに協調して一つのオンラインシステムとして動作します。

業務を拡大するときは，必要なハードウェアを追加してシステムを拡張できます。ソフトウェア資源を煩雑に再編成する必要はありません。そのため，必要な規模に合わせたシステムを柔軟に構築できます。また，水平分散のトランザクション処理によるサーバ間の連携や，GUIのアプリケーションを使用したオンラインシステムにも対応しています。

クライアント/サーバシステム（C/Sシステム）の形態の例を次の図に示します。

図1‒5　クライアント/サーバシステム（C/Sシステム）の形態の例

1.2.2　フロントエンドプロセサ（FEP）の形態

大型コンピュータのセンタ業務を分担する，フロントエンドプロセサ（FEP）にOpenTP1を適用するシステム形態です。大型コンピュータとFEPは，高速LAN（FDDI　LAN，またはチャネル接続）で接続させます。

FEP上のOpenTP1では，通信プロトコル処理や業務処理の一部を実行します。大型コンピュータの負荷を軽減したり，大型コンピュータで障害が起こった場合にセンタ業務を継続したりできます。

OpenTP1システムを使うと，多種の通信プロトコルで，多回線接続ができます。そのため，広域網を介した各種通信に対応したFEPとして使用できます。

フロントエンドプロセサ（FEP）の形態の例を次の図に示します。

図1‒6　フロントエンドプロセサ（FEP）の形態の例

1.2.3　分散処理システムの形態

大型コンピュータと接続された営業店や支店（分散システム）にOpenTP1を適用する，垂直分散のシステム形態です。大型コンピュータの業務処理を分散システムで分担して実行できます。また，大型コンピュータと分散システム内のワークステーション，パーソナルコンピュータとの中継ができます。

分散処理システムの形態の例を次の図に示します。

図1‒7　分散処理システムの形態の例

1.3　OpenTP1のソフトウェア構成

OpenTP1のソフトウェア構成の概要を次の図に示します。

図1‒8　OpenTP1のソフトウェア構成の概要

1.3.1　OpenTP1のソフトウェア製品

OpenTP1のソフトウェア製品と，関連するソフトウェア製品を次に示します。

(1)　OpenTP1の基本部分を構成する製品

OpenTP1の基本部分を構成する製品を次に示します。

TP1/Server Base

分散トランザクション処理の基本制御をする製品です。トランザクションを制御したり，UAPをスケジュールしたりします。

(2)　ユーザデータを管理する製品

ユーザデータを管理するOpenTP1の製品を次に示します。

TP1/FS/Direct Access

OpenTP1専用のユーザファイルを，直接編成ファイルとして使えるようにする製品です。TP1/FS/Direct Accessを使うと，ユーザファイル（DAMファイル）をトランザクション処理と同期して管理できます。

TP1/FS/Table Access

OpenTP1専用のユーザファイルを，テーブルアクセス法で使えるようにする製品です。テーブルアクセス法とは，共用メモリ上にあるテーブルで回復可能なファイルとしてアクセスする方法です。TP1/FS/Table Accessを使うと，ユーザファイル（TAMファイル）をトランザクション処理と同期して管理できます。

TP1/Shared Table Access

共用メモリ上にあるテーブル（ISTテーブル）を，複数のOpenTP1システムで共用できるようにする製品です。テーブルの実体がどのノードにあるかを意識しないで，UAPからデータを参照，更新できるようにします。TP1/Shared Table Accessの場合，ユーザファイルの実体はなく，メモリ上のISTテーブルにデータが格納されます。そのため，オンラインが異常終了した場合はデータを回復できません。

(3)　メッセージ制御機能を使うときに必要な製品

メッセージで通信できるようにするOpenTP1の製品を次に示します。

TP1/Message Control

OpenTP1システムがほかのシステムと，ネットワークを通して通信できるようにする製品です。TP1/Message Controlを使った通信では，メッセージを使って通信します。

TP1/NET/Library

ネットワークを制御するのに必要な運用，構成管理，スケジュールなどの役割をするライブラリの製品です。

TP1/Message ControlとTP1/NET/Libraryは，メッセージ送受信機能を実現します。メッセージで通信する場合は，メッセージ送受信機能の製品と，通信プロトコル対応製品（TP1/NET/××××）が必要です。通信プロトコル対応製品については，「付録A　TP1/Message Controlで使える通信プロトコル対応製品」を参照してください。

TP1/Messaging

TP1/Message ControlとTP1/NET/Libraryに相当する機能を持っています。また，TCP/IP通信機能（TP1/NET/TCP/IPの機能）も持っています。

TP1/Messagingについては，マニュアル「TP1/Messaging 使用の手引」を参照してください。

(4)　メッセージキューイング機能を使うときに必要な製品

OpenTP1のメッセージキューイング機能を使うときに必要な製品を次に示します。

TP1/Message Queue

OpenTP1システムのUAP間，およびネットワークを介した他システムのUAPとの間で，非同期にメッセージを転送する場合に使用します。通信相手のUAPの状態に関係なくメッセージを転送でき，通信相手からの応答を待たないで処理できます。

(5)　OSI TP通信を使うときに必要な製品

クライアント/サーバ形態の通信で，通信プロトコルにOSI TPを使う場合に必要となる製品を次に示します。

TP1/NET/OSI-TP-Extended

OSI TP通信のプロトコル管理をする製品です。TP1/NET/OSI-TP-Extendedに関する定義およびセットアップ手順については，マニュアル「OpenTP1 プロトコル TP1/NET/OSI-TP-Extended編」を参照してください。

(6)　系切り替え機能を使うときに必要な製品

OpenTP1システムを二重化する機能（系切り替え機能）を使えるようにする製品を次に示します。

TP1/High Availability

系切り替え機能を使ったシステム形態でOpenTP1を使うときに必要な製品です。系切り替え機能では，HAモニタが前提となります。

TP1/NET/High Availability

メッセージ制御機能を使うときに必要な製品です。TP1/High Availabilityが前提となります。

(7)　OpenTP1の拡張機能を使うときに必要な製品

OpenTP1の性能の確保，運用を容易にするための拡張機能を使うときに必要な製品を次に示します。

TP1/Extension1

次の拡張機能を使用する場合に必要な製品です。

性能検証用トレース

負荷テストや本番環境で，サービス呼び出しのどこに時間が掛かっているのかを詳細に分析することができます。

マルチスケジューラ機能

多数のクライアントから長大データを受け取る場合に複数のスケジューラを起動できるようにし，スケジューラのボトルネックを解消できます。

ノード直接指定RPC

あて先ノードのIPアドレスを直接指定してRPCを発行できます。これによって，ネームサーバのドメイン外へのRPC，およびネットワーク経路が二重化されている場合の経路の選択ができるようになります。

オンライン中サーバプロセス多重度変更コマンド

オンライン中のサービスの処理プロセス数をコマンドで変更し，処理能力の拡張や縮退ができます。

プロセスごとのサービス処理時刻表示コマンド

コマンドで，プロセスごとにサービスを受付けた時刻と終了した時刻を表示することができます。

ユーザサーバのプロセスのリフレッシュ機能

オンラインを停止することなく，ユーザサーバのロードモジュールを入れ替えられます。

TP1/Message Control - Extension1

メッセージ制御機能に関する，次の拡張機能を使用する場合に必要な製品です。

MCF構成変更再開始機能

前回のオンライン停止時に，入出力キュー上に残っていた未処理メッセージを次回オンラインに引き継ぎつつ，OpenTP1ファイルシステムやキューグループの構成変更，および論理端末（コネクション）やアプリケーションの構成を変更できます。

(8)　OpenTP1のUAPをテストするときに必要な製品

OpenTP1システムで使うUAPをテストするときに必要な製品を次に示します。

TP1/Offline Tester

オフラインテスタ機能を使うときに必要な製品です。システムでOpenTP1が稼働していない環境でも，UAPをテストできます。

TP1/Online Tester

オンラインテスタ機能を使うときに必要な製品です。OpenTP1が稼働している環境で，UAPをテストできます。

TP1/Message Control/Tester

MCFオンラインテスタ機能を使うときに必要な製品です。メッセージ制御機能を使うUAPをテストできます。

(9)　OpenTP1のクライアント用マシンに必要な製品

OpenTP1のサーバへサービスを要求する，クライアント用マシンに必要な製品を次に示します。

TP1/Client/W，TP1/Client/P

WSやPCをクライアント用マシンとして，OpenTP1のサーバへサービスを要求できるようにする製品です。

TP1/Client/J

Javaアプレット，Javaアプリケーション，またはJavaサーブレットから，OpenTP1のサーバへサービスを要求できるようにする製品です。

TP1/Client/W，TP1/Client/P，およびTP1/Client/Jについては，「2.2.2　OpenTP1クライアント機能の概要」を参照してください。

(10)　分散アプリケーションサーバ機能で必要な製品

TP1/LiNK

分散システム環境で，UAPのスケジュールなどの基本制御をする製品です。TP1/Server Baseに比べ，小規模な部門に適用できます。製品の組み込みからセットアップまでを，簡単に操作できるようにしています。

(11)　クラスタ/並列システムでOpenTP1を使うときに必要な製品

OpenTP1をクラスタ/並列システムに使うときに必要な製品を次に示します。

TP1/Multi

クラスタ/並列システム環境でOpenTP1を使う場合に必要な製品です。一つのノードから複数のノードを操作できるマルチノード機能を使えるようにします。

(12)　OpenTP1提供以外のリソースマネジャを制御するときに必要な製品

OpenTP1提供以外のリソースマネジャを制御できるようにする必要な製品を次に示します。

TP1/Resource Manager Monitor

OpenTP1提供以外のリソースマネジャを制御できるようにする製品です。TP1/Resource Manager Monitorを使うと，OpenTP1で，リソースマネジャの開始と終了を制御できます。

(13)　OpenTP1システムに関連する製品

OpenTP1に関連する製品について説明します。

ISAM，ISAM/B（HP-UXだけ）

ユーザファイルをX/OpenのISAMモデルに準拠した索引順編成ファイルとして使えるようにする製品です。ユーザファイル（ISAMファイル）をトランザクション処理と同期して管理する場合は，ISAMに加えて，ISAM/Bが必要になります。

HAモニタ

OpenTP1システムの信頼性を上げるために，システムを二重化するときに必要になる製品です。HAモニタを使ったOpenTP1システムについては，「6.1　系切り替え機能」を参照してください。

1.3.2　X/OpenのDTPモデルとOpenTP1システムの関係

OpenTP1を使った分散トランザクション処理システムは，X/OpenのDTPモデルに準拠しています。X/OpenのDTPモデルの構成を次の図に示します。

図1‒9　X/OpenのDTPモデルの構成

(1)　DTPモデルの構成

DTPモデルは，次に示す要素から構成されます。

AP（アプリケーションプログラム）

システム利用者が高級言語で作成するアプリケーションプログラムです。OpenTP1のUAPのことです。

トランザクションマネジャ

システムのトランザクションを管理して，資源の更新情報を基に一貫性を保証します。

RM（リソースマネジャ）

ユーザデータなどシステムの資源を管理します。

CRM（コミュニケーションリソースマネジャ）

システム間の通信に関する資源を管理します。

(2)　各要素間のインタフェース

DTPモデルを構成する各要素は，次に示すインタフェースで連携できます。

TXインタフェース

APからトランザクションマネジャへトランザクションの開始と終了を指示します。

XATMIインタフェース，TxRPCインタフェース

APからCRMへ通信を指示します。

XAインタフェース

トランザクションマネジャとRMで資源の更新情報に基づいて同期を取ります。

XA+インタフェース

CRMを使ってほかのシステムと通信する場合に，トランザクションマネジャで管理するトランザクションをほかのシステムの処理まで拡張します。

RMが提供するインタフェース

APからRMへ資源の更新を指示します。RMへのAPIには，SQLなどがあります。

(3)　OpenTP1が提供するリソースマネジャ

OpenTP1で使えるRMを次に示します。

ファイルなど，ユーザ資源を管理するRM

TP1/FS/Direct Access，TP1/FS/Table Access，ISAM（ISAM/B），およびX/Openの仕様に準拠したRM

メッセージを使った通信を管理するRM

TP1/Message Control，TP1/NET/Library，TP1/Message Queue，TP1/Messaging

OpenTP1でOSI TP通信をする場合は，XA+インタフェースによって，他システムへトランザクション処理を拡張できます。

X/OpenのDTPモデルとOpenTP1で構築するシステムの関係を次の図に示します。

図1‒10　X/OpenのDTPモデルとOpenTP1で構築するシステムの関係

1.4　OpenTP1システムのサービス

1.4.1　OpenTP1のサービスの種類

クライアント/サーバ構造に基づいたオンライントランザクション処理システムを構築するため，OpenTP1システムでは，各種のサービス機能を使えます。ほかのプロセスから呼び出して利用できるプログラムの単位をサービス，サービスを提供するプロセスをサーバといいます。

OpenTP1のサービスをシステムサービスといいます。これに対して，ユーザで作成したUAPによって，業務処理としてサービスを提供するサーバをユーザサーバといいます。

1.4.2　OpenTP1のシステムサービス

OpenTP1で提供するシステムサービスを次に示します。（　）は，サービスを識別する名称です。

(1)　OpenTP1システムの前提になるシステムサービス

トランザクションサービス（trn）

トランザクション処理の開始，終了，およびトランザクションの同期点取得による資源の更新処理を管理します。

ネームサービス（nam）

UAP間の通信（リモートプロシジャコール）を実現するために，LANのネットワークアドレスとユーザサーバの対応を管理します。

スケジュールサービス（scd）

RPCのスケジュールや，メッセージ制御機能のスケジュールを管理します。

プロセスサービス（prc）

ノード内のプロセスを管理します。

ステータスサービス（sts）

主に，トランザクションとは関係ない履歴情報を，専用のファイルに格納して，管理します。

インタバルサービス（itv）

各システムサービスでの内部処理の監視時間を管理します。

ジャーナルサービス（jnl）

トランザクション処理に関係する履歴情報（ジャーナル）を，システムジャーナルファイルに格納して，管理します。

チェックポイントダンプサービス（cpd）

ジャーナルの読み込み時間を短縮するため，システムジャーナルファイルにチェックポイントを設定して管理します。

ロックサービス（lck）

トランザクション処理に伴う各種の排他制御を管理します。

ログサービス（log）

OpenTP1システムからオペレータに内部情報を知らせるためのメッセージログを管理します。

タイマサービス（tim）

トランザクション経過時間の監視など，各種の時間監視機能を提供します。

(2)　ユーザデータを管理するシステムサービス

DAMサービス（dam）

業務処理に使用する，OpenTP1専用のユーザファイル（DAMファイル）を管理します。

TAMサービス（tam）

業務処理に使用する，OpenTP1専用のユーザファイル（TAMファイル）を管理します。

ISTサービス（ist）

複数のOpenTP1システムで共用する，メモリ上のテーブル（ISTテーブル）を管理します。

(3)　メッセージ送受信関連のシステムサービス

MCFサービス（MCFマネジャサービス，MCF通信サービス，アプリケーション起動サービス）

メッセージを使用した通信をする場合に，各種のメッセージ制御機能を実現します。

メッセージキューサービス（que）

メッセージ制御機能を使用する場合に，メッセージを格納する待ち行列（入出力キュー）を管理します。

マッピングサービス（map）

GUI対応の拡張プレゼンテーションシステムをOpenTP1で使う場合に，その機能を支援します。

これらのサービスは，メッセージ制御用のRMであるTP1/Message Controlが前提となります。

(4)　メッセージキューイング関連のシステムサービス

MQAサービス（mqa）

UAP間で非同期にメッセージを転送する場合に，メッセージキューイング機能を実現します。メッセージキューイング制御用のRMであるTP1/Message Queueが前提となります。

(5)　OSI TPを使ったクライアント/サーバ形態関連のシステムサービス

XATMI通信サービス（xat）

OSI TPを使ったクライアント/サーバ形態の通信を管理します。

この通信をする場合には，TP1/NET/OSI-TP-Extendedが前提となります。

(6)　リソースマネジャを管理するシステムサービス

リソースマネジャモニタサービス（rmm）

リソースマネジャの開始や終了を，OpenTP1で制御します。

(7)　OpenTP1クライアント機能（TP1/Client）で使うプロセスを管理するシステムサービス

クライアントサービス（clt）

TP1/ClientのAP（CUP）からトランザクションを開始する場合に，TP1/Server Baseに必要なプロセスを管理します。

(8)　オンラインテスタ（TP1/Online Tester）を管理するシステムサービス

テスタサービス（uto）

オンラインテスタの実行環境を管理します。

(9)　補助的なシステムサービス

トランザクションジャーナルサービス（tjl）

長時間掛かるトランザクションの処理の履歴情報（ジャーナル）を，専用のジャーナル（トランザクションリカバリジャーナル）として格納して，管理します。

リアルタイム統計情報サービス（rts）

OpenTP1システムの稼働状況をリアルタイムに把握するための，リアルタイム統計情報を管理します。

(10)　マルチノード環境で，アーカイブジャーナルファイルを管理するシステムサービス

グローバルアーカイブジャーナルサービス（jnl）

クラスタ/並列システムで，各OpenTP1ノードのシステムジャーナルファイルをアーカイブして管理します。

(11)　X/Open準拠の索引順編成ファイルを管理するシステムサービス

ISAMサービス（ism）

業務処理に使う，X/Openに準拠した索引順編成のユーザファイル（ISAMファイル）を管理します。

(12)　OpenTP1を監視するシステムサービス

OpenTP1監視サービス（dcmon）

OpenTP1システムの正常稼働を維持するために，プロセスサービスの稼働状態を監視します。

1.4.3　OpenTP1のシステム定義

OpenTP1の動作環境やOpenTP1が使う各種の資源は，システム定義に指定します。OpenTP1のシステム定義は，次のように分けられます。

システムサービス定義

OpenTP1の基本機能（TP1/Server Base），各種ファイルサービス，マルチノード機能，およびメッセージキューイング機能に関連する項目について定義します。

ネットワークコミュニケーション定義

メッセージ送受信機能（TP1/Message Control）を使う場合に定義します。

メッセージキュー定義

メッセージキューイング機能（TP1/Message Queue）を使う場合に定義します。

ネットワークライブラリ定義

TP1/NET/OSI-TP-Extendedを使ったOSI TP通信をする場合に定義します。

定義を作成するときは，テキストエディタでファイルを作成します。システム定義については，マニュアル「OpenTP1 システム定義」を参照してください。

OpenTP1のシステム定義の体系を，次の図に示します。

図1‒11　OpenTP1システム定義の体系

注※1　グローバルアーカイブジャーナルサービスを使うOpenTP1ノードでは，定義しません。

注※2　XAリソースサービス機能を使う場合に定義します。

注※3　ジャーナルファイルレス機能を使用するOpenTP1ノードでは，定義しません。

注※4　TP1/Multiを使う場合に定義します。

注※5　グローバルアーカイブジャーナルサービスを使う場合に定義します。

注※6　TP1/FS/Direct Accessを使う場合に定義します。

注※7　TP1/FS/Table Accessを使う場合に定義します。

注※8　TP1/Client/W，またはTP1/Client/Pを使う場合に定義します。

注※9　ISAMファイルをトランザクション処理する機能（ISAM/B）を使う場合に定義します。定義の内容については，マニュアル「索引順編成ファイル管理 ISAM」を参照してください。

注※10　TP1/Shared Table Accessを使う場合に定義します。

注※11　TP1/Resource Manager Monitorを使う場合に定義します。

注※12　TP1/NET/OSI-TP-Extendedを使ったOSI TP通信をする場合に定義します。定義の内容については，マニュアル「OpenTP1 プロトコル TP1/NET/OSI-TP-Extended編」を参照してください。

注※13 メッセージ送受信機能（TP1/Message Control）を使う場合に定義します。

注※14　リモートAPI機能を使う場合に定義します。

注※15　リアルタイム統計情報サービスを使う場合に定義します。

注※16　メッセージキューイング機能（TP1/Message Queue）を使う場合に定義します。定義の内容については，マニュアル「TP1/Message Queue 使用の手引」を参照してください。

注※17　TP1/Online Testerを使う場合に定義します。定義の内容については，マニュアル「OpenTP1テスタ・UAPトレース使用の手引」を参照してください。

2　業務処理の形態

この章では，OpenTP1でできる業務処理の形態，関連する製品，およびアプリケーションプログラムについて説明します。

2.1　OpenTP1の通信形態

分散コンピューティング環境の業務をするため，OpenTP1では，次に示す形態で通信できます。

クライアント/サーバ形態の通信

TCP/IPプロトコルで接続したLANを介してOpenTP1システム間で通信する形態です。OpenTP1のUAPからリモートプロシジャコールを発行して通信します。また，X/Openに準拠したAPIで通信したり，OpenTP1以外のオープンシステムと通信したりすることもできます。

またTP1/Webを使えば，インターネット上のWWWサーバとWWWブラウザの情報のやり取りをOpenTP1のリモートプロシジャコールに変換して，OpenTP1のUAPを実行できます。この機能によってWWWブラウザを端末とする業務システムを構築できます。

メッセージ送受信形態の通信

ネットワークを介して，他システムとメッセージを使って通信する形態です。メッセージ送受信形態では，各種の通信プロトコルに準拠した手順で通信します。この形態の通信では，メッセージ送受信機能の製品（TP1/Message Control，TP1/NET/Library），および通信プロトコル対応製品が必要です。

このマニュアルでは，OpenTP1のメッセージ送受信機能の製品と通信プロトコル対応製品を総称した機能を，以降MCF（Message Control Facility）またはMCFサービスと表記します。

メッセージキューイング機能を使った形態の通信

TCP/IPプロトコルで接続したネットワークを介して，キューマネジャを使って通信する形態です。この形態で通信するOpenTP1システムには，キューマネジャとしてTP1/Message Queueが必要です。

上記のほかにも，複数のOpenTP1を使うシステム形態（系切り替え形態，クラスタ/並列システム形態）があります。詳細は，「6.　複数のOpenTP1を使用する場合の機能」を参照してください。

2.2　クライアント/サーバ形態の処理概要

クライアント/サーバ形態の通信とは，使用する通信プロトコル手順を意識しないで，ほかのUAPプロセスと通信する方法です。クライアント/サーバ形態の通信の概要について説明します。

2.2.1　リモートプロシジャコールを使った通信

OpenTP1のUAPでは，ほかのUAPとリモートプロシジャコール（RPC）を使用して通信できます。リモートプロシジャコールとは，UAPプロセスからほかのUAPプロセスへサービスを要求し，サービスを要求されたUAPプロセスは要求元のUAPへ処理結果を返す通信です。

クライアント/サーバ形態の通信の処理概要を次の図に示します。

図2‒1　クライアント/サーバ形態の通信の処理概要

注※1

TP1/Clientは，OpenTP1のサーバへサービスを要求する，クライアント専用の製品です。

TP1/Clientについては，「2.2.2　OpenTP1クライアント機能の概要」および「3.5　OpenTP1クライアント機能（TP1/Client）」を参照してください。

注※2

OpenTP1独自のインタフェースを使うと，ファイアウォールの内側にあるサーバUAPにもリモートプロシジャコールを使って通信できます。ただし，ファイアウォールを通過した場合，通過先のサーバUAPをトランザクション処理に含めることはできません。ファイアウォールを通過する場合については，「3.7.1　リモートAPI機能の使用例」を参照してください。

(1)　クライアントUAPとサーバUAP

サービスを要求するUAPとサービスを提供するUAPは，クライアントとサーバの関係になります。サービスを要求する側のUAPをクライアントUAP，サービスを提供する側のUAPをサーバUAPといいます。

UAPについては，「2.6　OpenTP1のアプリケーションプログラム」を参照してください。

(2)　トランザクショナルRPC

リモートプロシジャコールでは，サービス要求をしてから結果が返ってくるまでの処理をトランザクションとするかどうかを選べます。トランザクションとするRPCを，トランザクショナルRPCといいます。トランザクショナルRPCの場合は，複数のノードにわたって処理しているRPCでも，一つのトランザクションとして処理できます。

(3)　OpenTP1で使えるリモートプロシジャコール

OpenTP1でクライアント/サーバ形態の通信をする場合は，次に示すインタフェースを使えます。

(a)　OpenTP1独自のインタフェース

OpenTP1独自のライブラリ関数を使ってサービスを要求する通信方法です。

(b)　X/Openに準拠したインタフェース

X/Openに準拠した通信方法を次に示します。

XATMIインタフェース

X/Openで規定するライブラリ関数を使ってサービスを要求する通信方法です。

TxRPCインタフェース

X/Openで規定した手順で作成したUAPの関数を直接呼び出して通信する方法です。

これらのほかにも，OpenTP1以外のオープンシステムと通信することもできます。クライアント/サーバ形態の通信については，「3.2　クライアント/サーバ形態の通信」を参照してください。

(4)　クライアント/サーバ形態の通信プロトコル

OpenTP1のクライアント/サーバ形態の通信プロトコルには，TCP/IPとOSI TPを使えます。どちらを使う場合でも，UAPの処理で通信プロトコルを意識する必要はありません。

通信プロトコルにOSI TPを使う場合には，通信プロトコルを管理する製品としてTP1/NET/OSI-TP-Extendedが必要です。OSI TPを使ったクライアント/サーバ形態の通信については，「3.6　OSI TPを使ったクライアント/サーバ形態の通信」を参照してください。

(5)　TCP_NODELAY

TCP_NODELAYは，送信済みデータの応答待ちの状態でも遅延させることなくデータを送信できるようにする機能です※。この機能では，OpenTP1がノード間で使用する通信ソケット（INETドメイン）に，TCP_NODELAYオプションを使用します。

データ送信の際にTCP_NODELAYオプションを使用するかどうかは，スケジュールサービス定義，ユーザサービス定義，またはユーザサービスデフォルト定義のipc_tcpnodelayオペランドで指定します。なお，TCP_NODELAYオプションを使用すると，INETドメイン通信時の送信効率が低下し，ネットワークの負荷が大きくなる場合があります。TCP_NODELAYオプションを使用する場合は，ipc_sendbuf_sizeオペランド，ipc_recvbuf_sizeオペランド，ネットワークの帯域などを考慮し，この機能の必要性を十分に検討してください。

注※

TCP/IPのNagleアルゴリズムを無効にすることで，この機能を実現させています。

2.2.2　OpenTP1クライアント機能の概要

OpenTP1で構築したサーバシステムへ，クライアント用のWSまたはPCからサービスを要求できます。この通信をするための製品をOpenTP1クライアント機能（TP1/Client）といいます。

OpenTP1クライアント機能は，UAPを作成して，OpenTP1のサーバUAPと通信できます。クライアント側に期待する性能，接続数，およびOSに応じて，クライアント側の製品を選択できます。OpenTP1クライアント側の製品には，次の製品があります。

TP1/Client/W（WS向け）

TP1/Client/P（PC向け）

TP1/Client/J（Java動作環境向け）

OpenTP1クライアント機能でできる通信の概要を次の図に示します。

図2‒2　OpenTP1クライアント機能でできる通信の概要

TP1/Clientの機能の詳細については，「3.5　OpenTP1クライアント機能（TP1/Client）」を参照してください。

2.3　メッセージ送受信形態の処理概要

メッセージ送受信とは，OpenTP1以外のシステムと通信規約（通信プロトコル）に定められた手順でメッセージをやり取りする通信方法です。メッセージ送受信の概要について説明します。

2.3.1　メッセージ送受信の概要

メッセージ送受信では，メッセージを格納する待ち行列（メッセージキュー）を使用します。

OpenTP1システムで，相手システムからメッセージを受信すると，MCFは受信したメッセージを入力キュー（受信メッセージの待ち行列）に格納して，メッセージを処理するUAPを起動します。UAPではメッセージを受信して，処理します。メッセージを処理したあとで，送信するメッセージを出力キュー（送信メッセージの待ち行列）に格納します。出力キューに格納したメッセージは，MCFで相手システムへ送信します。

メッセージ送受信の処理概要を次の図に示します。

図2‒3　メッセージ送受信の処理概要

2.3.2　使用できるネットワーク

メッセージを送受信するには，ネットワークの各種プロトコルに対応したOpenTP1の通信プロトコル対応製品を使用します。主にIPネットワーク上でメッセージを送受信できます。

2.3.3　XMAP3を使ったメッセージ送受信の形態

メッセージ送受信の業務処理形態で，XMAP3を使用した通信を実現できます。XMAP3を使用すると，OpenTP1システムのUAPの処理で，PCに画面を表示したり，帳票を印刷したりできます。

XMAP3を使用した通信では，TP1/NET/XMAP3を使用します。OpenTP1システムの通信相手となるPCにはXMAP3が必要です。PCで動作するXMAP3は，GUI機能を提供します。OpenTP1システムにサービス要求するクライアントUAPとして，PC側でプログラムを作成する必要はありません。

XMAP3を使ったメッセージ送受信形態の例を次の図に示します。

図2‒4　XMAP3を使ったメッセージ送受信形態

プレゼンテーション機能の特長を次に示します。

(1)　メッセージ送受信による画面データの操作

XMAP3を使う場合，TP1/NET/XMAP3は，XMAP3 Serverと連携して物理マップと論理マップ間のマッピング処理を実行しています。

UAPを作成するときは，画面上のマッピングについて意識する必要はありません。また，画面表示のために特別なメッセージを作成する必要はありません。通常のメッセージ送受信で論理メッセージを扱うのと同様に，UAPを作成できます。

(2)　PCのGUI環境での操作の実現

XMAP3を使うと，PCの画面で操作できます。さらに，GUIを使ったインタフェース環境で，各種のデータ操作を実現できます。

(3)　業務形態に適合したシステムを構築

XMAP3は，クライアント/サーバシステムを採用しています。そのため，OpenTP1システムとPCの間で，最適な業務形態に合わせたシステムを構築できます。

TP1/NET/XMAP3については，マニュアル「OpenTP1 プロトコル TP1/NET/XMAP3編」を，XMAP3については，マニュアル「XMAP3 Version 5 画面・帳票サポートシステム XMAP3 実行ガイド」を参照してください。

2.4　メッセージキューイング機能を使った形態の処理概要

OpenTP1では，米国IBM社で開発した通信仕様（メッセージキューイング機能）を使って通信できます。

メッセージキューイング機能を使う場合は，メッセージキューイング機能を管理する製品（キューマネジャ）が必要です。メッセージキューイング機能では，アプリケーション間通信をキューマネジャが管理するため，UAPで通信手順を意識する必要はありません。

OpenTP1システムのキューマネジャとなる製品は，TP1/Message Queueです。メッセージキューイング機能を使う場合には，OpenTP1システムにTP1/Message Queueが必要です。

OpenTP1のメッセージキューイング機能については，マニュアル「TP1/Message Queue 使用の手引」を参照してください。

メッセージキューイング機能を使ったOpenTP1システムの構成の例を次の図に示します。

図2‒5　メッセージキューイング機能を使ったOpenTP1システムの構成の例

2.4.1　メッセージキューイング機能の特長

メッセージキューイング機能の通信では，UAPがキューマネジャへメッセージを登録したり，キューマネジャからメッセージを取り出したりして通信します。UAPが通信先のあて先をメッセージに設定して登録すれば，キューマネジャが通信相手のキューマネジャへメッセージを送信します。

キューにメッセージを登録する場合もメッセージを取り出す場合も，通信する相手のUAPと同期を取らなくて済みます。そのため，UAPでは任意のタイミングでメッセージを扱え，電子メールのような通信ができます。

UAPからキューへアクセスするときには，MQIというAPIを使います。MQIはキューマネジャで共通であるため，コーディングした処理をほかのキューマネジャのシステムで使えるようにしています。

UAPから登録されたメッセージを格納するキューをメッセージキューといいます。メッセージキューには，キューマネジャの目的別に各種のキューを格納できます。メッセージキューを格納するファイルを，MQAキューファイルといいます。キューの種類については，マニュアル「TP1/Message Queue 使用の手引」を参照してください。

メッセージキューイング機能を使った処理の概要を次の図に示します。

図2‒6　メッセージキューイング機能を使った処理の概要

2.4.2　メッセージキューイング機能を使った通信の概要

メッセージキューイング機能を使った通信の概要について説明します。

(1)　メッセージの登録

通信相手にメッセージを渡したい場合は，UAPはキューマネジャへメッセージを登録します。メッセージを登録するときには，MQPUTを使います。MQPUTが正常に終了すると，メッセージは登録され，UAPはほかの処理を実行できます。

通信相手のUAPからの応答を待つ（会話型の通信）場合は，MQPUTに応答を待つように設定します。

(2)　メッセージの受け取り

メッセージを受け取るときは，MQGETを使います。メッセージを受け取るタイミングは，メッセージを受け取るUAPが稼働しているかどうかで，次に示す2とおりに分かれます。

UAPのプロセスが稼働している場合

UAPがMQGETを実行した時点で，そのUAPあてのメッセージをキューマネジャから受け取れます。

UAPのプロセスが稼働していない場合

キューマネジャがメッセージ受け取りを知らせる通知をします。この機能をトリガといい，通知される情報をトリガイベントといいます。トリガイベントは，専用のUAPで受信するようにします。トリガイベントを受けるUAPを，トリガモニタアプリケーションといいます。トリガモニタアプリケーションは，該当するUAPを起動します。

(3)　メッセージキューイング機能のトランザクション処理

OpenTP1では，メッセージキューイング機能の処理をトランザクションとして扱えます。UAPでデータを更新してメッセージをキューマネジャへ登録したあとにトランザクションをコミットすると，登録が有効になります。トランザクションがロールバックされると，登録処理を無効にできます。トランザクションについては，「3.1　トランザクション制御」を参照してください。

2.4.3　メッセージキューイング機能を使う場合の注意

メッセージキューイング機能の特長は，UAPを常に起動させておかなくてもよいため，UAPが任意のタイミングでメッセージを受け取れることです。メッセージキューイング機能で会話型の通信もできますが，RPCに比べると性能が落ちることがあります。システム間の通信にメッセージキューイング機能を使うかどうかは，業務目的に従ってください。

2.5　OpenTP1に関連するソフトウェア製品

OpenTP1システムを支援するソフトウェア製品について説明します。OpenTP1に関連する製品を次に示します。

統合システム運用管理機能　JP1

アプリケーション開発支援ツール　SEWB+

これらの製品と連携してOpenTP1システムを構築すると，OpenTP1の分散トランザクション処理に加えて，JP1による効率的なバッチジョブの運用，ネットワーク管理，およびソフトウェア配布ができるようになります。

2.5.1　統合システム運用管理機能　JP1

統合システム運用管理機能 JP1 とは，ネットワークコンピューティング環境の中で，システム全体の運用の自動化，省力化を統合的に支援し，エンタープライズTCO（企業情報システム全体の運用管理コスト）を最適化する製品です。

JP1を使ったOpenTP1システムの構成を次の図に示します。

図2‒7　JP1を使ったOpenTP1システムの構成

ジョブ管理

OpenTP1システムにJP1を使うと，メインフレームの業務であるバッチ処理をUNIXシステムでできるようになります。そのため，OpenTP1の業務をオンライン中の業務とバッチ処理業務に分けることができ，システムを効率良く運用できます。さらに，OpenTP1の開始，終了などのイベントをJP1イベントサービス機能（JP1/Base）に登録すると，JP1ジョブ管理機能（JP1/AJS）と連携したOpenTP1システムの自動運転ができるようになります。

配布管理・資産管理

JP1/NETM/DMを使うと，プログラムを一括してオンライン配布できます。

シナリオテンプレートを利用したシステムの運用

JP1/AJS2 - Scenario Operationは，JP1/AJSで管理していたジョブ，およびジョブネットを，統合的に管理する製品です。

システム構成の変化に対応した運用手順をシナリオテンプレートとして定義したり，運用環境に応じたシナリオを実行したりできます。また，OpenTP1で提供するシナリオテンプレートを組み合わせてシナリオを作成したり，実行したりすることができます。シナリオテンプレートによって，システムを自動的に運用できます。

JP1/AJS2 - Scenario Operationは，次の製品で構成されます。

JP1/AJS2 - Scenario Operation Manager

シナリオテンプレートの定義を保存し，シナリオテンプレートの実行を管理します。JP1/AJS - Managerと接続して，保存したシナリオテンプレートをJP1/AJSのジョブネットとして登録できます。

JP1/AJS2 - Scenario Operation View

GUIを使用してJP1/AJS2 - Scenario Operationの操作または監視をします。

JP1/AJS2 - Scenario Operationを使用して，シナリオテンプレートをシステム運用に利用する場合の詳細については，「3.10　シナリオテンプレートを利用したシステムの運用」またはマニュアル「OpenTP1 運用と操作」を参照してください。

システム運用機能に応じたJP1製品の使用方法については，使用するJP1製品のマニュアルを参照してください。

2.5.2　アプリケーション開発支援ツール　SEWB+

アプリケーション開発支援ツール　SEWB+とは，ワークステーション（WS）でのプログラミングを支援するアプリケーション開発支援ツールです。SEWB+には，次のような機能があります。

プログラム開発に必要な情報を統合して管理できます。

設計仕様やプログラムの論理構造を図形で表現できるので，プログラムを効率良く開発できます。

OpenTP1システムにSEWB+を使うと，UAPやUOCを効率良く開発できます。さらに，C言語，C++言語，COBOL85，およびCOBOL2002を使うこともできます。SEWB+に関連する製品については，マニュアル「SEWB+ クライアントサーバシステム開発ガイド」を参照してください。

2.6　OpenTP1のアプリケーションプログラム

OpenTP1のUAPについて説明します。

2.6.1　業務形態と，使用するアプリケーションプログラム

OpenTP1のUAPには，次に示す種類があります。

(1)　クライアント/サーバ形態の通信で使用するUAP

サービス利用プログラム（SUP）

クライアント専用のUAPです。

サービス提供プログラム（SPP）

クライアントUAPからの要求に対して，サービスを提供するUAP（サーバUAP）です。

(2)　メッセージ送受信形態の通信で使用するUAP

メッセージ処理プログラム（MHP）

通信回線を経由して送られたメッセージを受信して処理するUAPです。

(3)　ユーザファイルを初期化するUAP

オフラインの業務をするUAP

ユーザ任意の処理をするUAPです。

(4)　OpenTP1クライアント機能（TP1/Client）で使用するUAP

クライアントユーザプログラム（CUP）

OpenTP1クライアント機能（TP1/Client）で使用する，クライアント専用のUAPです。

なお，TP1/Client/Jを使用すると，SPPのサービスを要求するJavaアプレット，Javaアプリケーション，およびJavaサーブレットを作成できます。

2.6.2　アプリケーションプログラムの概要

OpenTP1のUAPの概要について説明します。UAPについては，マニュアル「OpenTP1 プログラム作成の手引」を参照してください。OpenTP1のUAPを次に示します。

SUP

SPP

MHP

オフラインの業務をするUAP

CUP

CUPについては，マニュアル「OpenTP1 クライアント使用の手引」を参照してください。

(1)　サービスを利用するUAP（SUP）

クライアント/サーバ型の通信で，UAPの業務処理を開始するクライアント専用のUAPをサービス利用プログラム（SUP）といいます。クライアント/サーバ型の通信では，すべての業務処理はSUPから開始します。

SUPでは，トランザクションの開始/終了の制御や，サーバUAPへのサービス要求ができます。

SUPは，OpenTP1の開始と同時に開始させることも，オンライン中にOpenTP1のコマンド（dcsvstartコマンド）で，任意の時期に開始させることもできます。このように，SUPは業務に応じた運用ができます。OpenTP1の開始と同時に開始させるかどうかは，ユーザサービス構成定義に指定します。

SUPの終了は，OpenTP1では制御していないので，業務終了後にSUP自身で終了するように作成します。

SUPはクライアント専用のUAPなので，サーバUAPとしてほかのUAPにサービスを提供できません。

(2)　サービスを提供するUAP（SPP）

クライアント/サーバ型の通信で，ユーザサーバとしてサービスを提供するサーバUAPをサービス提供プログラム（SPP）といいます。SPPでは，クライアントUAPからのサービス要求を処理します。また，トランザクションの開始，メッセージの送信もできます。

SPPは，OpenTP1の開始と同時にサービス要求を受け付けられる状態にすることも，オンライン中にOpenTP1のコマンド（dcsvstartコマンド）で，任意の時期に開始させることもできます。OpenTP1の開始と同時に開始させるかどうかは，ユーザサービス構成定義に指定します。

SPPを業務処理ごとに作成しておくことで，必要な業務をサービスとして提供できるので，拡張しやすいシステムを構築できます。

SPPからSPPへサービスを要求できるので，業務処理のネストを実現できます。

SUPとSPPの位置を次の図に示します。

図2‒8　SUPとSPPの位置

(a)　SPPの構造

要求されるSPPのサービスに対応する処理を，関数として作成します。この一つ一つの関数を，C言語の場合はサービス関数，COBOL言語の場合はサービスプログラムといいます。個々に作成したサービス関数をまとめる関数を，C言語の場合はメイン関数，COBOL言語の場合はメインプログラムといいます。

(b)　翻訳，結合

UAPのソースプログラムをコンパイル/リンケージして，実行形式ファイルを作成します。リンケージの際に，各サービス関数の入り口点を定義したスタブを結合させます。

ただし，すべてのサービス関数をUAP共用ライブラリ化※してサービス関数動的ローディング機能を使う場合，スタブは不要です。サービス関数動的ローディング機能の詳細については，「3.8　サービス関数動的ローディング機能」を参照してください。

注※

UAP共用ライブラリ化とは，UAPのソースファイルを翻訳（コンパイル）して作成したUAPオブジェクトファイルを結合（リンケージ）して，共用ライブラリとしてまとめることです。

SPPの構造を，スタブを使う場合とサービス関数動的ローディング機能を使う場合に分けて，それぞれを以降の図に示します。UAPの作成方法については，マニュアル「OpenTP1 プログラム作成の手引」を参照してください。

図2‒9　SPPの構造（スタブを使う場合）

図2‒10　SPPの構造（サービス関数動的ローディング機能を使う場合）

(c)　UAPとRPCとの関係

SPPの実行形式ファイルをサービスグループ名として，それぞれのサービス関数をサービス名として，ユーザサービス定義で指定します。サービス名はRPCインタフェース定義で指定した入り口点と対応づけます。

クライアントUAPからサービスを要求するときは，SPPのサービスグループ名とサービス名を設定します。

一つのSPPを別々のサービスグループとして開始することも，異なるサービスグループのサービス処理を同じサービス名で開始することもできます。

(3)　メッセージを処理するUAP（MHP）

メッセージ送受信をする場合に使う，メッセージ処理専用のUAPをメッセージ処理プログラム（MHP）といいます。MHPでは，他システムからのメッセージを受信して，処理をします。

MHPでは，メッセージ送信/受信を始めとする，MCFで提供する各種サービスを使用できます。また，MHPからSPPへのサービス要求もできます。

MHPは，メッセージを受信したことを契機に業務処理を開始します。

MHPをOpenTP1の開始時から開始するかどうかは，ユーザサービス構成定義に指定します。MHPをOpenTP1の開始時に開始させる指定をすれば，オンライン開始からメッセージを受信できる状態になります。また，開始する指定でないMHPは，OpenTP1のコマンド（dcsvstartコマンド）で，任意の時期に開始できます。

MHPが稼働するノードは，TP1/Message Controlが前提です。

MHPの位置を次の図に示します。

図2‒11　MHPの位置

(a)　MHPの構造

メッセージ送受信処理では，メッセージを処理するUAPの単位をアプリケーションといいます。アプリケーションに対応するMHPの処理を，関数として作成します。この一つ一つの関数を，C言語の場合はサービス関数，COBOL言語の場合はサービスプログラムといいます。個々に作成したサービス関数をまとめる関数を，C言語の場合はメイン関数，COBOL言語の場合はメインプログラムといいます。

(b)　翻訳，結合

MHPのソースプログラムをコンパイル/リンケージして，実行形式ファイルを作成します。リンケージの際に，各サービス関数の入り口点を定義したスタブを結合させます。スタブは，RPCインタフェース定義を作成したあと，stbmakeコマンドを実行して作成します。

ただし，すべてのサービス関数をUAP共用ライブラリ化※してサービス関数動的ローディング機能を使う場合，スタブは不要です。サービス関数動的ローディング機能の詳細については，「3.8　サービス関数動的ローディング機能」を参照してください。

注※

UAP共用ライブラリ化とは，UAPのソースファイルを翻訳（コンパイル）して作成したUAPオブジェクトファイルを結合（リンケージ）して，共用ライブラリとしてまとめることです。

MHPの構造を，スタブを使う場合とサービス関数動的ローディング機能を使う場合に分けて，それぞれを以降の図に示します。UAPの作成方法については，マニュアル「OpenTP1 プログラム作成の手引」を参照してください。

図2‒12　MHPの構造（スタブを使う場合）

図2‒13　MHPの構造（サービス関数動的ローディング機能を使う場合）

(c)　MHPのサービス名とアプリケーションの関係

MHPの実行形式ファイルをサービスグループ名として，それぞれのサービス関数をサービス名として，ユーザサービス定義で指定します。サービス名はRPCインタフェース定義で指定した入り口点と対応づけます。

ユーザサービス定義で指定したサービス名は，MCFアプリケーション定義，アプリケーション属性定義で，アプリケーション名と対応づけます。このアプリケーション名を基に，受信したメッセージを処理します。

(d)　アプリケーションの型

MHPのサービス（アプリケーション）には，メッセージを処理する形態別にアプリケーションの型を決めておきます。アプリケーションの型には次の三つがあります。

応答型（ans型）

通信相手システムに応答を返すMHP

非応答型（noans型）

通信相手システムに応答を返さないMHP

継続問い合わせ応答型（cont型）

通信相手システムとのメッセージの受信/送信を連続させるMHP

アプリケーションの型は，MCFアプリケーション定義，アプリケーション属性定義で指定します。

(4)　オフラインの業務をするUAP

オフライン環境でDAMファイルにアクセスするUAPを作成できます。オフラインの業務をするUAPでは，OpenTP1開始前にDAMファイルを初期化する処理をします。

オフラインの業務をするUAPからは，DAMファイルの初期化処理以外のOpenTP1の機能（RPCやメッセージの処理）は使えません。

オフラインの業務をするUAPは，シェルから開始します。オフラインの業務をするUAPの開始，終了はユーザで管理します。

2.6.3　SPP，MHPとユーザプロセスの関連

OpenTP1では，サービスグループを実行するためのプロセスを複数起動できるマルチサーバを実現できます。同じサービスグループでも，クライアントUAPが異なれば，決まったプロセスで実行されるとは限りません。また，あるサービスから同じサービスグループに属するサービスを要求する場合でも，そのサービスグループを実行するための新しいプロセスが必要になります。

OpenTP1では，サービスグループごとに実行できる最大プロセス数を定義できます。また，サービス要求は同じサービスグループを処理する待機中のプロセスに渡すため，それぞれのプロセスに掛かる負荷を平均化できます。

UAPのプロセス制御については，「3.4.3　プロセスの制御」を参照してください。

2.6.4　UAPのテスト，デバッグ機能

作成したUAPを実際にOpenTP1の業務に使う前に，UAPの処理動作をテストできます。UAPのテスト機能には，オフラインテスタ，オンラインテスタ，およびMCFオンラインテスタがあります。UAPのテスト機能については，マニュアル「OpenTP1 テスタ・UAPトレース使用の手引」を参照してください。

(1)　オフラインテスタ

オンライン業務用のUAPを，オフライン環境でテストするときに使用します。OpenTP1システムでUAPを使う前にテストする場合に使います。

オフラインテスタでは，SPP，MHPの動作をテストできます。

オフラインテスタを実行するマシンには，TP1/Offline Testerが組み込まれていることが前提です。

(2)　オンラインテスタ

オンライン環境で，OpenTP1と連携して，UAPをテストするときに使います。UAPに実際の業務をさせる前に，OpenTP1のサービスを使って動作をテストできます。

オンラインテスタではSUP，SPPの動作をテストできます。さらに，MHPをSPPとしてテストできます。

オンラインテスタを実行するマシンには，TP1/Online Testerが組み込まれていることが前提です。

(3)　MCFオンラインテスタ

オンライン環境で，TP1/Message Controlと連携して，MHPをテストするときに使います。オンラインテスタと同様に，オンライン中にOpenTP1のサービスを使ってMHPの動作をテストできます。

MCFオンラインテスタを実行するマシンには，TP1/Message Control/Testerが組み込まれていることが前提です。

2.7　インターネットを使った形態の処理概要

TP1/Webは，インターネット上のWWWサーバとWWWブラウザの情報のやり取りをOpenTP1のRPCに変換し，OpenTP1サーバ上のUAPを実行します。この機能によってWWWブラウザを端末とする業務システムを構築できます。

TP1/Webは，OpenTP1と連携して次のような業務システムに適用できます。

インターネットによる通信販売業務・オンラインショッピング

インターネットによる乗り物，イベントなどの座席予約やホテルの客室予約のシステム

国内外の拠点，出張先からインターネット経由で利用する企業オンラインシステム

また，TP1/Webは，インターネットに接続した構成だけでなく企業内のLANに接続した構成にも適用できます。次の図にTP1/Webを使った構成を示します。

図2‒14　TP1/Webを使った構成

注※　TP1/Webを使用する場合，TP1/Clientが必要です。

3　機能

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

3.1　トランザクション制御

OpenTP1を使うと，分散コンピューティング環境で高い信頼性を要求される業務処理プログラムに必要な，各種のトランザクション制御機能を実現できます。OpenTP1を運用しているときにこれらの機能を使うことで，分散システムに特有な障害対策の負担を軽減できます。

3.1.1　分散トランザクション

トランザクションとは，関連する複数の処理を一つのまとまった処理として扱うための論理的な単位です。一つのトランザクション内で実行した処理は，すべてが有効になるか，すべてが無効になるかのどちらかです。

これまでのオンラインシステムは，トランザクションを単体の大型コンピュータで実行していました。このため，一つのコンピュータ内でしかトランザクションの整合性を保証していませんでした。

分散コンピューティング環境で動作するOpenTP1では，トランザクションはほかのコンピュータに分散して実行されます。このようなトランザクション処理を分散トランザクションといいます。OpenTP1は，分散して処理する一連のトランザクション全体の整合性を保証しています。

トランザクションは，リソースマネジャの排他制御によって，複数のトランザクションが同時に，同じ資源を更新することはありません。資源は常にトランザクションごとに更新されます。

トランザクションが正常に終了して，トランザクションを有効にすると決定した場合，その後のUAPの処理に関係なく資源を更新することをリソースマネジャに指示します。このため，資源間の不整合が起きません。これは，障害が発生しても資源間で不整合が生じないように，トランザクションに関する履歴情報を，システムジャーナルとして取得しているためです。トランザクションの処理途中に障害が発生して，トランザクションを有効にしないと決定した場合には，トランザクションを開始する前の状態に資源を戻すことをリソースマネジャに指示します。

このように，業務をトランザクションとして処理することで，資源の整合性を保てます。

分散トランザクションを次の図に示します。

図3‒1　分散トランザクション

3.1.2　グローバルトランザクション

トランザクション処理をするUAPプロセスをトランザクションブランチといいます。RPCを使用した場合，複数のUAPプロセスで構成されるトランザクション処理ができます。複数のUAPプロセスで構成されるトランザクションブランチの集合をグローバルトランザクションといいます。特に，トランザクションの開始を宣言したプロセスをルートトランザクションブランチといいます。

グローバルトランザクションを次の図に示します。

図3‒2　グローバルトランザクション

3.1.3　トランザクションのコミットとロールバック

トランザクションは，成功または失敗することによって終了します。トランザクションが成功すること，つまり整合性を保って資源を更新することを，トランザクションのコミットといいます。トランザクションがコミットしたときに初めて，グローバルトランザクション内のすべてのトランザクションブランチでの資源の更新が有効になります。トランザクションをコミットするかどうか最終的に決定するトランザクション処理の区切りを，同期点といいます。資源は，同期点で更新します。

トランザクションが失敗して，トランザクションで更新するはずの資源の状態を，トランザクション開始直前の状態に戻すことを，トランザクションのロールバックといいます。トランザクションをコミットできなかった場合や，処理の不整合を検出した場合には，これまでの処理をロールバックで取り消して，データの整合性を保ちます。トランザクションがロールバックした要因はログに取得できます。ロールバック要因をログに取得するかどうか，トランザクションサービス定義のtrn_rollback_information_putオペランドで指定してください。

OpenTP1はトランザクションブランチごとに経過時間を監視しています。経過時間を過ぎてもトランザクションが終了しないときには，トランザクションをロールバックします。経過時間の監視については，マニュアル「OpenTP1 システム定義」を参照してください。

トランザクションのロールバックを次の図に示します。

図3‒3　トランザクションのロールバック

3.1.4　2相コミット

(1)　2相コミットの概要

複数の資源を更新するとき，トランザクションは同期点で，2相コミットと呼ばれる方法で最終的に資源を更新するかどうか決定します。2相コミットとは，同期点処理を資源の更新準備処理（プリペア処理）と，資源の更新処理（コミット処理またはロールバック処理）の二段階に分ける方法です。同期点処理を二つの相に分けることで，複数の資源を矛盾なく更新できます。

同期点の第1相で，ルートトランザクションブランチがグローバルトランザクション内のすべてのトランザクションブランチに，コミットの準備を要求します。トランザクションブランチは，コミットの準備が完了したか，ロールバックしたかを，ルートトランザクションブランチに報告します。

同期点の第2相で，グローバルトランザクションをロールバックするかコミットするか決定します。すべてのトランザクションブランチでコミットの準備が完了すると，ルートトランザクションブランチはグローバルトランザクション全体のコミットを決定します。トランザクションブランチのどれかがロールバックしたときには，ルートトランザクションブランチはグローバルトランザクション全体のロールバックを決定します。グローバルトランザクション内のトランザクションブランチはすべて，ルートトランザクションブランチでの決定に従います。

トランザクションの決着（コミット決定，またはロールバック決定）以降にシステムに障害が発生した場合に備えて，2相コミット処理の過程でトランザクションに関する履歴情報を，システムジャーナルに取得します。

2相コミットの流れを次の図に示します。

図3‒4　2相コミットの流れ

(2)　ヒューリスティック決定

ルートトランザクションブランチがトランザクションブランチにコミットの準備を指示したあとで通信障害が発生して，ルートトランザクションブランチでの決定がトランザクションブランチに届かなくなることを，ヒューリスティックハザードといいます。ヒューリスティックハザードが起こった場合には，コマンドを使って，トランザクションブランチごとにトランザクションを強制的に決着できます。ルートトランザクションブランチの同期点処理を待たないで，コマンドでトランザクションブランチのトランザクションを強制的に決着することを，ヒューリスティック決定といいます。

ヒューリスティック決定には，次に示す種類があります。

ヒューリスティックコミット

トランザクションブランチを独自にコミットすることです。

ヒューリスティックロールバック

トランザクションブランチを独自にロールバックすることです。

ヒューリスティックコミットにするときにはtrncmtコマンドを，ヒューリスティックロールバックにするときにはtrnrbkコマンドを使います。コミットまたはロールバックしたトランザクションブランチを強制終了する場合は，trnfgtコマンドを使います。

コミットかロールバックかは，ルートトランザクションブランチとトランザクションブランチとで一致させてください。一致させるためには，まずルートトランザクションブランチがコミットしたかロールバックしたかをtrnlsコマンドを使って調べます。trnlsコマンドで表示した状態を参照した上で，trncmtコマンドまたはtrnrbkコマンドを実行します。

コマンドでトランザクションを決着させた場合，トランザクションの扱いについては十分考慮してください。ルートトランザクションブランチの決着とトランザクションブランチの決着とが矛盾（ヒューリスティックミックス）しないように十分注意してからtrncmtコマンド，またはtrnrbkコマンドを実行してください。

ヒューリスティック決定の操作方法については，マニュアル「OpenTP1 運用と操作」のトランザクションに関する運用の説明を参照してください。

ヒューリスティック決定の流れを次の図に示します。

図3‒5　ヒューリスティック決定の流れ

3.1.5　UAPとトランザクションの関係

UAPの処理をトランザクションにするかどうかを，事前に決められます。トランザクションとして処理するUAPを，トランザクション属性のUAPといいます。グローバルトランザクションのトランザクションブランチとなるUAPには，必ずトランザクション属性を指定しておいてください。トランザクション属性は，ユーザサービス定義のatomic_updateオペランドで指定します。ファイルの情報を更新するUAPをトランザクション処理として，演算処理だけのUAPはトランザクション処理としない指定をしておくと，トランザクション処理に掛かるシステムの負担を軽くできます。

(1)　SUP，SPPとトランザクションの関係

トランザクション属性のSPPは，トランザクションとして処理しているプロセスからRPCで呼び出されると，自動的にトランザクションブランチになります。

ルートトランザクションブランチやトランザクションブランチから呼び出されても，トランザクション属性でないSPPは，グローバルトランザクションに含まれません。このとき，トランザクション属性でないSPPがトランザクション属性のSPPを呼び出したとしても，呼び出されたSPPはトランザクションブランチにはなりません。

SUP，SPPのグローバルトランザクションを次の図に示します。

図3‒6　SUP，SPPのグローバルトランザクション

SUP またはSPPの処理をトランザクションにする場合は，dc_trn_begin関数を呼び出して，トランザクションの開始を宣言します。同期点を取得する場合も，SUPまたはSPPからdc_trn_××××_commit関数またはdc_trn_××××_rollback関数を呼び出します（××××は，同期点を取得したあとに，それまでとは別の新しいトランザクションを開始するかどうかで異なります）。トランザクションの開始と同期点を取得する関数は，ルートトランザクションブランチからだけ呼び出せます。

(2)　MHPとトランザクションの関係

MHPのサービスを呼び出した時点で，トランザクションの処理が開始します。MHPでは，dc_trn_begin関数は使えません。MHPからSPPへサービスを要求する場合，MHPがルートトランザクションブランチとなります。MHPのトランザクションは，MHPが終了するかまたは同期点を取得する関数（dc_mcf_commit関数，dc_mcf_rollback関数）を呼び出すと決着します。MHPの処理の中で同期点を取得した場合は，同期点取得以降の処理は，それまでとは別の，新しいトランザクションの処理となります。なお，非トランザクション属性のMHPも作成できます。この場合，MHPで同期点は取得できません。

MHPのグローバルトランザクションを次の図に示します。

図3‒7　MHPのグローバルトランザクション

3.1.6　TXインタフェースによるトランザクション制御

OpenTP1では，X/Openで規定するDTPモデルに準拠したトランザクション制御の関数（TX_関数）を使用できます。関数の使い方については，マニュアル「OpenTP1 プログラム作成の手引」を参照してください。

3.1.7　XAリソースサービスによるトランザクション制御

XAリソースサービスとは，OpenTP1と次に示す連携先との間で2相コミットによるトランザクション連携を行うための機能です。

J2EEで動作するアプリケーションサーバ

.NET Frameworkアプリケーション（.NET Framework上で動作するアプリケーション）

OpenTP1と.NET Frameworkアプリケーションとの間で連携する機能を，MSDTC連携機能といいます。MSDTC連携機能を使用すると，MSDTCと連携できるリソースとOpenTP1上のリソースとの間でトランザクション連携ができます。MSDTC連携機能を使用するためには，XAリソースサービス定義のxar_msdtc_useオペランドにYを指定する必要があります。

ここでは，XAリソースサービスを使ったトランザクション制御の概要について説明します。操作方法については，マニュアル「OpenTP1 運用と操作」のXAリソースサービスの記述を参照してください。また，XAリソースサービスのトレース情報の詳細については，「5.3.6(5)　XAR性能検証用トレース」，および「5.3.6(9)　XARイベントトレース」を参照してください。

なお，J2EEで動作するアプリケーションサーバと.NET Frameworkアプリケーションで機能差がない場合，XAリソースサービスで連携するアプリケーションサーバと呼びます。

(1)　XAリソースサービスの概要

XAリソースサービスの主な機能は，XAリソースサービスで連携するアプリケーションサーバから渡されたXID（トランザクションの識別子）のステータスを管理し，OpenTP1のXIDとマッピングすることです。MSDTC連携機能を使用する場合は，RI（トランザクション回復情報）も管理します。RIとは，トランザクション決着処理で障害が発生した場合にトランザクションを回復するため情報で，トランザクション決着処理時にMSDTCが作成します。これらのトランザクションの状態は，必要に応じてOpenTP1ファイルシステムに記録されます。

注

XAリソースサービスの「XA」は，OpenTP1がDBMSに対してトランザクション決着の指示を行うXA連携機能の「XA」とは異なります。

(a)　J2EEで動作するアプリケーションサーバと連携する場合

J2EEで動作するアプリケーションサーバは，JCAに準拠したuCosminexus TP1 ConnectorまたはCosminexus TP1 Connectorを経由してトランザクションを制御します。OpenTP1では，J2EEで動作するアプリケーションサーバからのトランザクション要求をrapサーバで受信し，XAリソースサービスを使用してトランザクション処理を行います。

J2EEで動作するアプリケーションサーバと連携する場合のトランザクション制御の流れを次の図に示します。

図3‒8　J2EEで動作するアプリケーションサーバと連携する場合のトランザクション制御

(b)　.NET Frameworkアプリケーションと連携する場合

.NET Frameworkアプリケーションは，MSDTCを使用してトランザクションを制御し，Connector .NETを経由してOpenTP1へのトランザクション指示をします。OpenTP1では，.NET Frameworkアプリケーションからのトランザクション指示をrapサーバで受信し，XAリソースサービスを使用してトランザクション処理を行います。

.NET Frameworkアプリケーションと連携する場合のトランザクション制御の流れを次の図に示します。

図3‒9　.NET Frameworkアプリケーションと連携する場合のトランザクション制御

(2)　JCAのXAリソースインタフェース

J2EEで動作するアプリケーションサーバからOpenTP1に対するトランザクション制御は，JCAに従って行われます。JCAとは，アプリケーションサーバとリソースアダプタとの間を接続するための標準仕様のことです。

JCAに従うことで，アプリケーションサーバは，DBMSやほかのリソースアダプタを扱うのと同様に，OpenTP1のトランザクションを制御できます。また，OpenTP1は，さまざまなアプリケーションサーバ上で標準リソースアダプタとして動作できます。

JCAに従ったトランザクション制御のインタフェースには，次の二つがあります。

XAリソースインタフェース

ローカルトランザクションインタフェース

各インタフェースの詳細については，JCAのドキュメントを参照してください。

XAリソースサービスは，OpenTP1上で，XAリソースインタフェースを使用したトランザクション制御を受け付けるための機能です。

(3)　XAリソースサービスの前提機能

XAリソースサービスを使用するためには，リモートAPI機能と，次に示す製品を使用する必要があります。

J2EEで動作するアプリケーションサーバと連携する場合

TP1/Client/J

uCosminexus TP1 ConnectorまたはCosminexus TP1 Connector

.NET Frameworkアプリケーションと連携する場合

Client .NET

Connector .NET

なお，.NET Frameworkアプリケーションと連携する場合，TP1/Client for .NET Framework構成定義の<extendLevel要素>のvalue属性には00000001を指定することをお勧めします。<extendLevel要素>のvalue属性に00000001を指定すると，XARファイルのレコード長が不足したことによってトランザクションの決着処理に失敗した場合に，KFCA32045-Eメッセージにトランザクション要求元のIPアドレスを表示させることができます。

(a)　リモートAPI機能

リモートAPI機能は，クライアント側が発行したAPIを，OpenTP1がサーバ側に転送してサーバ側のプロセスで代理実行する機能です。また，APIを代理実行するサーバをrapサーバといいます。

XAリソースサービスは，リモートAPI機能を使用したrapサーバ上で動作します。XAリソースサービスで連携するアプリケーションサーバからのトランザクション要求は，すべてrapサーバ上で管理します。そのため，XAリソースサービスを使用する場合は，rapサーバをあらかじめ起動しておく必要があります。rapサーバが起動していない場合，XAリソースサービスで連携するアプリケーションサーバからのトランザクション要求はすべてエラーとなります。

OpenTP1は，リモートAPIを要求したUAPとrapサーバとの間に，常設コネクションという論理的な通信路を設定します。常設コネクションのスケジュール方式には，スタティックコネクションスケジュールモードとダイナミックコネクションスケジュールモードの2種類があります。XAリソースサービスは，どちらのモードを使用しても動作します。

リモートAPI機能の詳細については，「3.7　リモートAPI機能」を参照してください。

(b)　TP1/Client/JまたはClient .NET

TP1/Client/Jは，J2EEで動作するアプリケーションサーバからのトランザクション要求をOpenTP1に伝える際に経由する製品です。

Client .NETは，.NET Frameworkアプリケーションからのトランザクション要求をOpenTP1に伝える際に経由する製品です。

XAリソースサービスを使用する場合は，リモートAPI機能が前提となります。したがって，TP1/Client/JまたはClient .NETのRPCによるサービス要求方式は，リモートAPI機能に限られます。また，リモートAPI機能を使用するときのコネクトモードは，オートコネクトモードに限られます。

TP1/Client/JまたはClient .NETのRPCのサービス呼び出し形態には，同期応答型，非応答型，連鎖型およびトランザクションを引き継がない形態の4種類があります。XAリソースサービスは，どの形態も使用できます。

通常のRPCでは，トランザクション要求に対する窓口となるOpenTP1のホスト名を複数指定できますが，XAリソースサービスを使用する場合，XAリソースサービスで連携するアプリケーションサーバからのトランザクション要求に対する窓口となるOpenTP1のホスト名は，一つだけ指定できます。

XAリソースサービスで使用できるTP1/Client/JまたはClient .NETの機能を次の表に示します。

表3‒1　XAリソースサービスで使用できるTP1/Client/JまたはClient .NETの機能一覧

TP1/Client/JまたはClient .NETの機能

方式

使用の可否

RPCのサービス要求方式

リモートAPI機能

○

スケジューラダイレクト機能

×

ネームサービス機能

×

コネクトモード

オートコネクトモード

○

非オートコネクトモード

×

RPCのサービス呼び出し形態

同期応答型

○

非応答型

○

連鎖型

○

トランザクションを引き継がない形態

○

窓口となるOpenTP1ホスト名の指定（dchostオペランドで指定）

一つだけ指定できる

○

ユーザデータの圧縮

データ圧縮機能

○

（凡例）

○：使用できます。

×：使用できません。

TP1/Client/Jの各機能の詳細については，マニュアル「OpenTP1 クライアント使用の手引 TP1/Client/J編」を，Client .NETの各機能の詳細については，マニュアル「TP1/Client for .NET Framework 使用の手引」を参照してください。

(c)　uCosminexus TP1 ConnectorまたはCosminexus TP1 Connector

uCosminexus TP1 ConnectorまたはCosminexus TP1 Connectorは，OpenTP1の通信およびトランザクションを，JCAに従ったリソースアダプタとして制御するための製品です。J2EEで動作するアプリケーションサーバは，uCosminexus TP1 ConnectorまたはCosminexus TP1 Connectorに対するトランザクション制御を行うことで，OpenTP1に2相コミットを伝えます。

XAリソースサービスを使用してOpenTP1とJ2EEで動作するアプリケーションサーバと連携するときの注意事項については，uCosminexus TP1 ConnectorまたはCosminexus TP1 Connectorのドキュメントを参照してください。

(d)　Connector .NET

Connector .NETは，.NET Framework環境からOpenTP1への通信およびトランザクションを制御する製品です。MSDTC連携機能では，Connector .NETはMSDTCのトランザクションに参加するリソースマネジャとして機能します。MSDTCは，Connector .NETに対するトランザクション制御を行うことで，OpenTP1に2相コミットを伝えます。

XAリソースサービスを使用してOpenTP1と.NET Frameworkアプリケーションと連携するときの注意事項については，マニュアル「TP1/Connector for .NET Framework 使用の手引」を参照してください。

(4)　タイマ監視機能

XAリソースサービスで連携するアプリケーションサーバからの要求が停止した場合や，業務プログラムの処理が滞留した場合，各種タイマ監視機能を使用してトランザクション処理を打ち切ることができます。

XAリソースサービスで連携するアプリケーションサーバ，rapサーバ，およびSPPのタイマ監視機能の範囲を次の図に示します。

図3‒10　各種タイマ監視機能の範囲

図中のタイマ監視t1〜t9の対象と，指定するオペランドを次の表に示します。

表3‒2　タイマ監視の対象とオペランドの一覧

区間

タイマ監視の対象

J2EEで動作するアプリケーションサーバ※

.NET Frameworkアプリケーション※

OpenTP1

t1

問い合わせ間隔の監視

TP1/Client/J環境定義のdccltinquiretimeオペランド

TP1/Client for .NET Framework構成定義の<rapService>要素のinquireTime属性

rapリスナーサービス定義のrap_inquire_timeオペランド

t2

メッセージ送受信の監視

TP1/Client/J環境定義のdcwatchtimオペランド

TP1/Client for .NET Framework構成定義の<rpc>要素のwatchTime属性

rapリスナーサービス定義，ユーザサービスデフォルト定義，またはシステム共通定義のwatch_timeオペランド

t3

トランザクションブランチの処理の監視

TP1/Client/J環境定義のdcclttrexptmオペランド

TP1/Client for .NET Framework構成定義の<xarTransaction>要素のexpireTime属性

rapリスナーサービス定義，ユーザサービスデフォルト定義，またはトランザクションサービス定義のtrn_expiration_timeオペランド

t4

アイドル状態のトランザクションブランチの監視

−

−

XAリソースサービス定義のxar_session_timeオペランド

t5

トランザクションブランチの処理の完了監視

−

−

rapリスナーサービス定義，ユーザサービスデフォルト定義，またはトランザクションサービス定義のtrn_completion_limit_timeオペランド

t6

トランザクションブランチの処理の監視

−

−

ユーザサービス定義，ユーザサービスデフォルト定義，またはトランザクションサービス定義のtrn_expiration_timeオペランド

サービス関数の処理の監視

−

−

ユーザサービス定義，ユーザサービスデフォルト定義のservice_expiration_timeオペランド

t7

トランザクションブランチの処理の完了監視

−

−

ユーザサービス定義，ユーザサービスデフォルト定義，またはトランザクションサービス定義のtrn_completion_limit_timeオペランド

t8

トランザクション同期点処理時の最大通信待ち時間

TP1/Client/J環境定義のdcclttrwatchtimeオペランド

TP1/Client for .NET Framework構成定義の<transaction>要素のinternalWatchTime属性

rapリスナーサービス定義のtrn_watch_timeオペランド

t9

−

−

ユーザサービス定義，ユーザサービスデフォルト定義，またはトランザクションサービス定義のtrn_watch_timeオペランド

（凡例）

−：該当しません。

注※

定義の詳細については，マニュアル「OpenTP1 クライアント使用の手引 TP1/Client/J編」，「TP1/Client for .NET Framework 使用の手引」を参照してください。

3.1.8　XAインタフェースについて

XAインタフェースは，X/Openが規定したDTPモデルの一部です。

XAインタフェースとは，トランザクションマネジャとリソースマネジャとの間での指示のやり取りを規定したものです。したがって，UAPがXAインタフェースを直接使用することはありません。OpenTP1とリソースマネジャが使用するXAライブラリ・サブルーチンを次の表に示します。

表3‒3　XAライブラリ・サブルーチン

関数名

XAライブラリ・サブルーチン

ax_reg

トランザクションマネジャに，リソースマネジャを追加します。

ax_unreg

トランザクションマネジャでの，リソースマネジャの登録を削除します。

xa_close

リソースマネジャをクローズします。

xa_commit

すべてのリソースマネジャがコミット可能（prepare状態）であることがわかったので，リソースマネジャにコミットすることを通知します。

xa_end

リソースマネジャに，トランザクションの終了を通知します。

xa_forget

リソースマネジャの判断で，終了していたトランザクションの情報を破棄してよいということを通知します。

xa_open

リソースマネジャをオープンします。

xa_prepare

トランザクションがコミットしようとしていることを，リソースマネジャに通知します。

xa_recover

リソースマネジャ内の，未決着トランザクションのリストを取得します。

xa_rollback

トランザクションをロールバックすることを，リソースマネジャに通知します。

xa_start

トランザクションが開始，再開始されたことを，リソースマネジャに通知します。

3.2　クライアント/サーバ形態の通信

OpenTP1では，次に示す三つのクライアント/サーバ形態の通信ができます。

OpenTP1のリモートプロシジャコール（RPC）通信

OpenTP1のライブラリ関数を使った，UAPプロセス間の通信方法です。UAPから関数を使って，通信相手にサービスを要求します。通常のRPCでは，各ノードのネームサービスが管理しているサーバUAPのサービス情報を使って通信しています。各ノードのネームサービスは，目的のサーバUAPがネットワーク上のどのノードにあるかを，サービス情報を交換することで管理します。また，サービス情報検索の付加機能を使用することで，運用形態に合わせたサービスの要求方法を選択できます。さらに，ノード管理を行うことで，ネットワーク障害によってOpenTP1同士の通信ができなくなった場合，そのあとに実行するRPCに障害が発生するのを防止します。

それぞれについては，次を参照してください。

RPCの概要：3.2.1　OpenTP1のリモートプロシジャコール通信

サービス情報検索の付加機能：3.2.2　サービス情報検索の付加機能

ノード管理：3.2.3　OpenTP1のノード管理

RPCの処理の流れ：付録D　リモートプロシジャコールの処理の概要

XATMIインタフェースの通信

X/Openで規定するDTPモデルに準拠した通信方法です。

TxRPCインタフェースの通信

X/Openで規定する，トランザクション機能付きのDCE RPCができる通信方法です。TxRPCの通信では，ユーザが作った関数を直接呼び出す形式で通信します。

通信プロトコルにTCP/IPを使っている場合は，上記のクライアント/サーバ形態の通信はすべてできます。通信プロトコルにOSI TPを使っている場合は，XATMIインタフェースの通信を使います。OSI TP通信をする場合は，OpenTP1システムにTP1/NET/OSI-TP-Extendedが必要です。OSI TP通信については，「3.6　OSI TPを使ったクライアント/サーバ形態の通信」を参照してください。

3.2.1　OpenTP1のリモートプロシジャコール通信

OpenTP1のライブラリ関数を使ったRPCについて説明します。

(1)　サービスの要求方法

クライアントUAP（SUP，MHP，SPP）では，サービス要求に必要な項目をdc_rpc_call関数に設定してサーバUAP（SPP）にサービスを要求します。サーバUAPは，複数のサービスを実行できます。サービスとは，RPCで呼び出す処理単位であり，各サーバUAPがクライアントUAPに提供する機能です。また，一つのサーバUAPが提供するサービスの集まりをサービスグループといいます。

クライアントUAPは，dc_rpc_call関数にサービスグループ名およびサービス名を指定して，サーバUAPにサービスを要求します。ネームサービスでサーバUAPがあるノードのネットワークアドレスとサービス名を管理しているので，ネットワーク上のどのノードにサーバUAPがあるかをクライアントUAPで意識する必要はありません。

(2)　リモートプロシジャコールの形態

RPCは，応答を受け取るかどうかで，応答型RPCと非応答型RPCに分類されます。RPCの種類を次の図に示します。

図3‒11　RPCの種類

RPCの形態別の処理概要を次の図に示します。

図3‒12　RPCの形態別の処理概要

(a)　同期応答型RPC

サービスを要求してから，応答が返ってくるのを待つRPCです。応答が返るまでの待ち時間を監視します。最大応答待ち時間を過ぎた場合，サービス要求はエラーリターンします。最大応答待ち時間は，システム共通定義，またはユーザサービス定義で指定します。

同期応答型RPCは，単純型RPCともいいます。

(b)　非同期応答型RPC

サービスを要求してから，応答が返ってくるのを待たないで，処理を続けるRPCです。応答を受信する関数（dc_rpc_poll_any_replies関数）を使って，応答を受信します。応答を受信する関数は，応答を受信するまで待ちます。この関数に設定した応答待ち時間を過ぎた場合，関数はエラーリターンします。

非同期応答型RPCは，ノーウェイト型RPCともいいます。

(c)　非応答型RPC

サービス要求の処理結果が戻らないRPCです。非応答型RPCでサービス要求をした場合，応答は受け取れません。サービスを要求したUAPは，処理を続けます。

非応答型RPCは，ノーリプライ型RPCともいいます。

サービス要求を受け取ったサーバUAPから，さらに別のサービスを要求することもできます（RPCのネスト）。

(3)　リモートプロシジャコールの連鎖（連鎖RPC）

サーバUAPの実行プロセスは，マルチサーバ（同じサーバUAPを複数のプロセスで同時に起動する機能）の場合，サービスが要求されるたびに起動されます。一つのクライアントUAPから同じサービスグループを2回以上呼び出したとき，そのサービスグループのサーバUAPが以前と同じプロセスで実行されるとは限りません。ただし，同期応答型RPCで，かつ同じサービスグループに属するサービスを2回以上要求する場合に限り，そのサービスを以前と同じプロセスで実行させることができます。これを連鎖RPCといいます。連鎖RPCでサービスを要求すると，マルチサーバのサーバUAPでも前回のRPCと同じプロセスで実行されるため，トランザクション処理に必要なプロセスを最小限にできます。UAPのプロセスはサービスグループごとに確保されるため，同じサービスグループに属していれば，異なるサービスに対しても一つのプロセスでサービスを実行できます。

通常のRPCと連鎖RPCの比較を次の図に示します。

図3‒13　通常のRPCと連鎖RPCの比較

連鎖RPCの処理は，トランザクションとしてもトランザクションとしなくても実行できます。トランザクションとして連鎖RPCを実行する場合は，一つのグローバルトランザクションとして処理されます。

連鎖RPCは，クライアントUAPのプロセス単位で保証されます。同じグローバルトランザクション内でも，クライアントUAPが異なれば，複数回呼び出されたサービスが同じプロセスで起動されることは保証されません。

(a)　連鎖RPCの時間監視

連鎖RPCの処理中に通信障害などで次のサービス要求を受け取れない場合，SPPがプロセスを確保したままになってしまうことがあります。これを防ぐため，連鎖RPCで実行しているSPPでは，応答を返してから次のサービス要求，または連鎖RPCの終了要求が来るまでの時間（最大時間間隔）を監視しています。連鎖RPC間隔監視時間は，ユーザサービス定義のwatch_next_chain_timeオペランドに指定します。この監視時間を過ぎても次のサービス要求，または連鎖RPCの終了要求が来ない場合は，OpenTP1はクライアントUAPで障害が起こったものと見なして，該当するSPPのプロセスを異常終了させます。

(4)　リモートプロシジャコールの送信データの圧縮

LANのネットワークの負荷を軽減するため，RPCでやり取りするデータを圧縮できます。データを圧縮する場合は，システム定義に次に示す値を指定します。

TP1/Server Baseの場合

システム共通定義のrpc_datacompオペランドにYを指定します。

TP1/Clientの場合

クライアント環境定義にデータの圧縮を指定します。

クライアント側のシステムがデータの圧縮を指定している場合は，rpc_datacompオペランドの指定に関係なく，サーバのOpenTP1が自動的に圧縮データを復元して処理します。その後再び圧縮してクライアントへ応答を返します。

送信データの圧縮でネットワークの負荷が軽減できても，ノード内のデータ圧縮と復元の処理が原因で通信時間が長くなってしまう場合があります。送信データの圧縮を指定するかどうかは，業務内容や通信形態に応じて判断してください。

(5)　大規模な分散システムでのサービスの要求方法

(a)　ドメインネームシステムの概要

WANを介したネットワークシステムや，部門間を接続する全社システムなどの大規模な分散システムでは，名前の検索に時間が掛かり，システム名の管理に手間が掛かります。大規模な分散システムでリモートプロシジャコールを使う場合，ドメインネームシステムを構築することで，これらの問題を改善できます。

ドメインネームシステムを構築すると，システム全体を管理しないで，ドメインとして構成したグループごとに管理できます。ドメインは，小規模システムや，各部門のシステムに該当します。ドメインは，自ドメインだけを意識して管理するため，システム全体のサービスの名前などを管理する手間が省けます。

ドメインの概要を次の図に示します。

図3‒14　ドメインの概要

（説明）

ほかのドメインにあるサービスを利用するには，dc_rpc_call関数の引数にドメイン名を付けます。

ドメインsysにあるクライアントから，ドメイン名（siteA.soft.hitachi）を付けてサービスを要求すると,ドメインhitachi，soft，siteAの順で問い合わせます。

(b)　サービスの要求方法

サービスの要求方法を次に示します。

「サービスグループ名とサービス名」の指定

通常，サービスを要求するには，dc_rpc_call関数で「サービスグループ名とサービス名」を指定します。

大規模な分散システムの場合，dc_rpc_call関数での「サービスグループ名とサービス名」の指定では，ドメイン間のサービスを利用できません。

「サービスグループ名+ドメイン名とサービス名」の指定

大規模な分散システムでドメイン間のサービスを利用する場合，dc_rpc_call関数で「サービスグループ名+ドメイン名とサービス名」を指定します。

dc_rpc_call関数のサービスグループ名にこのドメイン名を付けると，ドメインの窓口のスケジュールサービスにサービス要求が渡ります。ドメインの窓口となるスケジュールサービスを，ドメイン代表スケジュールサービスと呼びます。ドメイン代表スケジュールサービスがドメインを構成するサーバのサーバUAPにスケジュールします。

このため，指定したドメインにあるサーバUAPにスケジュールされ，ほかのドメインにあるサーバUAPにスケジュールされることはありません。また，ドメイン代表スケジュールサービスだけ意識するため，ネームサービスですべてのノードのネットワークアドレスを管理する必要がありません。

なお，サーバUAPをソケット受信型サーバとした場合は，dc_rpc_call関数のサービスグループ名にドメイン名は付けられません。ソケット受信型サーバについては，「3.4.1　SPPのスケジュール」を参照してください。

サービス要求先の位置の指定

dc_rpc_call関数が位置透過であるのに対して，サービスを要求するサーバの位置をユーザが認識して，dc_rpc_call_to関数で特定のサービスを利用できます。サービス要求先の位置を指定する方法について次に示します。

「ホスト名称」指定

ネットワーク管理上の/etc/hostsファイル，またはDNSなどでIPアドレスとマッピングできるホスト名を指定することによって，利用するサービスが存在しているマシンを指定する方法です。

指定したホスト内のOpenTP1のシステム共通定義のname_portの指定値は，dc_rpc_call_to関数を発行したOpenTP1のシステム共通定義のname_portの指定値と同じであることが前提です。

「ノード識別子」指定

システム共通定義のnode_idで指定したノード識別子を指定することによって，OpenTP1システムを指定する方法です。

指定したノード識別子に対応するサービス要求先のOpenTP1ノードのホスト名がグローバルドメイン内にあることが前提です。

ここでのグローバルドメインとは，次のノード名の集合を指します。

システム共通定義のname_domain_file_useオペランドにNを指定している場合

システム共通定義のall_nodeオペランド，all_node_exオペランドで指定したノード名の集合です。

システム共通定義のname_domain_file_useオペランドにYを指定している場合

ドメイン定義ファイルに指定したノード名の集合です。なお，ドメイン定義ファイルの格納場所は，次のとおりです。

all_nodeのドメイン定義ファイル

　$DCCONFPATH/dcnamndディレクトリ下

all_node_exのドメイン定義ファイル

　$DCCONFPATH/dcnamndexディレクトリ下

「ホスト名称＋ポート番号」指定

次の値を指定することでサービス要求先を特定します。

/etc/hostsにファイル，またはDNSなどでIPアドレスとマッピングできるホスト名

上記で指定したホストに存在するOpenTP1システムの，システム共通定義のname_portに指定したネームサービスのポート番号

このとき，サービス要求先のname_portオペランドに指定した値と，サービス要求元のname_portオペランドに指定した値は同じでなくてもかまいません。

なお，この機能は，TP1/Extension 1をインストールしていることが前提です。TP1/Extension 1をインストールしていない場合の動作は保証できませんので，ご了承ください。

(c)　大規模な分散システムでの環境設定

ドメインを構成するノードは，システム共通定義のall_nodeオペランドに指定したノードです。

ドメイン代表スケジュールサービスは，ドメイン代表スケジュールサービスがあるホスト名をnamdomainsetupコマンドで登録します。そして，「/etc/services」に，ドメイン代表スケジュールサービスのポート番号と，サービス名「OpenTP1scd」を指定します。

ドメインネームシステムを使う場合，サーバシステムの起動時に各ノードのアドレスを問い合わせるため，システムの起動完了までに時間が掛かる場合があります。このような場合には，あらかじめシステム共通定義のdomain_masters_addrオペランドにドメイン名とホスト名を，domain_masters_portオペランドにドメイン代表スケジュールサービスのポート番号を指定しておきます。この指定をしておくと，サーバ起動時に各ノードのアドレスを問い合わせる時間を削減できます。

(6)　ネームサービスを使わないサービスの要求方法

通常のRPCでは，各ノードのネームサービスが管理している，サーバUAPのサービス情報を使って通信しています。各ノードのネームサービスは，目的のサーバUAPがネットワーク上のどのノードにあるかを，サービス情報を交換することで管理しています。多数のノードを接続した大規模システムでは，ネームサービスによるサービス情報のやり取りが，ネットワークに負荷をかける場合があります。

定義ファイルにサービス情報を定義しておくことで，ネームサービスを使わずにRPCができます。ネームサービスへサービス情報を問い合わせないため，ネットワークに掛かる負荷を軽減できます。

ユーザはユーザサービスネットワーク定義ファイルにサーバUAPのサービスグループ名とサービス情報（ホスト名とポート番号）を定義します。また，dc_rpc_call関数発行時にネームサービスを使うか，定義ファイルのサービス情報を使うかを，ユーザサービス定義のrpc_destination_modeオペランドで指定します。ユーザサービス定義で定義ファイルのサービス情報を使うと指定されたUAPからdc_rpc_call関数が呼び出されると，OpenTP1はユーザサービスネットワーク定義ファイルを参照します。サーバUAPの情報が定義されていれば定義情報を基に，定義されていなければネームサービスを使ってサーバUAPを呼び出します。なお，ユーザサービスネットワーク定義に指定するサーバUAPは，ユーザサービス定義でreceive_from=queueが指定されたUAP（キュー受信型サーバ）でなければいけません。

ユーザサービスネットワーク定義ファイルのサービス情報（ホスト名）を複数指定した場合，指定したサービス情報からランダムにサービス要求先が選択され，サービス要求が送信されます。サービス要求が成功すると，UAP内で以降に呼び出す同じサービスグループ名へのdc_rpc_callは，障害が発生するまで同じホストにサービス要求の送信を継続します。

なお，dcsvgdef定義コマンドの-tオプションであて先再選択間隔に値を指定し，次に示す時間があて先再選択間隔に指定した時間を超えていた場合，再度ランダムにサービス要求先を選択しサービス要求を送信します。

UAP内で同じサービスグループ名へのdc_rpc_callを呼び出し時に，サービス要求の送信を継続しているホストとの，初回から今回のサービス要求までの経過時間

3.2.2　サービス情報検索の付加機能

サービス情報検索の付加機能には，グローバル検索機能と，サービス情報優先度指定機能があります。これらの機能を使用すると，OpenTP1システム内で水平分散を利用したサービス要求をしたり，特定のノードのサービス情報を優先的に使用したりできます。

(1)　グローバル検索機能

グローバル検索機能を使用すると，次に示すサービス情報を取得できます。

all_nodeオペランドで指定された各ノードで起動するサービス情報

1.のノード上のネームサービスが管理する，all_nodeオペランドで起動するサービス情報

グローバル検索機能使用時のシステム構成例を次の図に示します。各OpenTP1ノードのネームサービス定義のname_global_lookupオペランドを次の図のように指定してください。name_global_lookupオペランドの指定方法の詳細については，マニュアル「OpenTP1 システム定義」を参照してください。

図3‒15　グローバル検索機能使用時のシステム構成

OpenTP1-Aからの検索範囲は，OpenTP1-BおよびCのall_nodeオペランドで指定したOpenTP1ノードまでとなります。つまり，OpenTP1システム1だけでなく，OpenTP1システム2および3までのサービスと通信できるようになります。なお，OpenTP1-D，E，FおよびGのall_nodeオペランドで指定したノードは検索対象となりません。

グローバル検索機能を使用した環境では，DCRPC_BINDTBL_SET関数の引数portnoにネームサービスのポート番号を指定した，dc_rpc_call_to関数は使用できません。

DCRPC_BINDTBL_SET関数の引数nidにノード識別子を指定した，dc_rpc_call_to関数を使用する場合は，必ずグローバル検索機能の検索範囲（図のOpenTP1システム1〜3）内のすべてのOpenTP1ノードのノード識別子を一意に定義してください。

サービス情報（閉塞，負荷状態など）は，検索元OpenTP1（図のOpenTP1-A）まで通知されないため，OpenTP1システム2内のOpenTP1-DとEの間，およびOpenTP1システム3内のOpenTP1-FとGの間のように，OpenTP1システム内で相互にall_nodeオペランドを指定し合い，水平分散を利用したサービス要求を行うことをお勧めします。

ネームサービス定義のname_cache_sizeオペランドの指定値は，自ノードから検索を要求するサービス情報の数に，all_nodeオペランドで指定されたノードにキャッシュされるサービス情報の数まで含めて算出する必要があります。

グローバル検索機能を使用したOpenTP1（図のOpenTP1-A）に対し，TP1/Client/P，TP1/Client/WまたはTP1/Client/Jからサービス要求が送信された場合，OpenTP1システム1だけでなく，OpenTP1システム2および3のサービス情報まで取得します。

(2)　サービス情報優先度指定機能

サービス情報優先度指定機能とは，ネームサービスがサービス要求元のクライアントUAPにサービス情報を返すときに，特定のノードのサービス情報を優先的に返す機能です。サービス情報を優先的に返すノードを，優先選択ノードと呼びます。

通常のRPCを実行する場合，高負荷などの状態を除き，クライアントUAPのサービス要求を処理するサーバUAPが複数ある場合には，それらを同じ優先度で扱います。このため，システム共通定義のall_nodeオペランドに指定したすべてのノードのネームサービスに対してサービス情報の検索要求を送信し，応答によって取得したすべてのサービス情報をクライアントUAPに返します。クライアントUAPは，返ってきたサービス情報の中からRPCのあて先となるサーバUAPをランダムに選び出し，RPCを実行します。

これに対して，サービス情報優先度指定機能を使用すると，クライアントUAPのサービス要求を処理するサーバUAPが複数ある場合には，優先選択ノードのサービス情報を優先してクライアントUAPに返します。クライアントUAPは，優先選択ノードのサーバUAPに対してRPCを実行します。また，優先選択ノードでサーバUAPの閉塞などの障害が発生した場合には，優先選択ノード以外のノードのサービス情報をクライアントUAPに返します。このように，サービス情報優先度指定機能を使用すると，通常は優先選択ノードのサーバUAPを使用し，障害が発生した場合だけ優先選択ノード以外のノードのサーバUAPを使用できるため，サーバUAPを実行系と待機系に分けて扱うことができます。

優先選択ノードは，システム共通定義のall_nodeオペランドで指定します。優先選択ノードの定義ファイルの指定方法は，ドメイン定義ファイルの指定と同じです。優先選択ノードの指定方法については，マニュアル「OpenTP1 システム定義」を参照してください。

以降，通常のRPCの流れと，サービス情報優先度指定機能を使用した場合のRPCの流れの違いを説明します。なお，以降の説明のグローバルキャッシュとは，ネームサービスが，他ノードで起動しているサーバのサービス情報を管理する領域を示します。

通常のRPCの流れ

通常のRPCの流れを次の図に示します。

図3‒16　通常のRPCの流れ

図で示したRPCの流れについて説明します。番号は図中の番号と対応しています。

RPCを実行するクライアントUAPが，TP1-Aのネームサービスへサービス情報の検索要求をします。

ネームサービスは，システム共通定義のall_nodeオペランドで指定されたTP1-B，およびTP1-Cのネームサービスにサービス情報の検索要求を送信します。

検索要求を受けたTP1-B，およびTP1-Cのネームサービスは，自ノードで稼働しているSPP-Aのサービス情報を要求元のTP1-Aへ送信します。

TP1-Aのネームサービスは，受信したサービス情報をグローバルキャッシュに登録します。

ネームサービスは，グローバルキャッシュに登録されたすべてのサービス情報をクライアントUAPに返します。

クライアントUAPは，RPCのあて先をランダムに選びます。ここでは，TP1-BをRPCのあて先に決定したものとします。

クライアントUAPは，TP1-BにRPCを実行します。

サービス情報優先度指定機能を使用した場合のRPCの流れ

サービス情報優先度指定機能を使用した場合のRPCの流れを次の図に示します。ここでは，TP1-CおよびTP1-Dを優先選択ノードに指定しています。

図3‒17　サービス情報優先度指定機能を使用した場合のRPCの流れ

図で示したRPCの流れについて説明します。番号は図中の番号と対応しています。

RPCを実行するクライアントUAPが，TP1-Aのネームサービスへサービス情報の検索要求を送信します。

ネームサービスは，システム共通定義のall_nodeオペランドで指定されたTP1-B，TP1-C，およびTP1-Dのネームサービスにサービス情報の検索要求を送信します。

検索要求を受けたTP1-B，TP1-C，およびTP1-Dのネームサービスは，自ノードで稼働しているSPP-Aのサービス情報を要求元のTP1-Aへ送信します。

TP1-Aのネームサービスは，受信したサービス情報をグローバルキャッシュに登録します。

TP1-CおよびTP1-Dを優先選択ノードに指定しているため，ネームサービスは，TP1-CおよびTP1-Dのサービス情報だけをクライアントUAPに返します。

ここでは，クライアントUAPは返されたサービス情報の中からTP1-CをRPCのあて先に決定したものとします。

クライアントUAPは，TP1-CにRPCを実行します。

優先選択ノードのサーバUAPが閉塞していたり，グローバル検索機能を使用したりする場合は，上の図で示したサービス情報優先度指定機能を使用した場合のRPCの流れとは異なります。RPCの流れが異なる場合について，(a)〜(c)で説明します。なお，以降の説明では，ネームサービスの処理を省略しています。

(a)　サーバUAPが閉塞している場合のRPCの流れ

優先選択ノードのサーバUAPが閉塞している場合のRPCの流れを次の図に示します。

図3‒18　サーバUAPが閉塞している場合のRPCの流れ

TP1-Aは，TP1-Cを優先選択ノードとして指定していますが，TP1-CのサーバUAPは閉塞しています。TP1-CのサーバUAPの閉塞がTP1-Aに通知されると，TP1-AはTP1-CをRPCのあて先の選択候補から除きます。そのため，TP1-Aは，優先選択ノードに指定していないTP1-BのサーバUAPにRPCを実行します。

注意事項

TP1-CのサーバUAPの閉塞情報がTP1-Aに通知されていない間は，TP1-AはTP1-CのサーバUAPへRPCを実行します。このとき，TP1-Cのシステム共通定義のall_nodeオペランドにTP1-Bを指定していると，TP1-CからTP1-BへRPCが転送されることがあります。一方，TP1-Cのシステム共通定義のall_nodeオペランドにTP1-Bを指定していないときは，RPCはエラーリターンします。

また，閉塞情報はサーバ単位で通知されます。そのため，TP1-CのサーバUAPがサービス単位で閉塞した場合，閉塞情報はTP1-Aに通知されません。したがって，TP1-AはTP1-CのサーバUAPにRPCを実行します。この要求先のサービスが閉塞していた場合，RPCはエラーリターンします。

(b)　サーバUAPが高負荷状態になっている場合のRPCの流れ

優先選択ノードのサーバUAPが高負荷状態になっている場合のRPCの流れを次の図に示します。

図3‒19　サーバUAPが高負荷状態になっている場合のRPCの流れ

TP1-Aは優先選択ノードにTP1-Cを指定しているため，TP1-Cで稼働しているサーバUAPがRPCのあて先の選択候補になります。しかし，TP1-CのサーバUAPが高負荷状態であるため，TP1-Cのシステム共通定義のall_nodeオペランドに指定したノードのサーバUAPにRPCを転送します。ここでは，TP1-CからTP1-BのサーバUAPへRPCが転送され，TP1-BのサーバUAPがTP1-AのRPCを実行します。

(c)　グローバル検索機能とサービス情報優先度指定機能を併用した場合のRPCの流れ

グローバル検索機能とサービス情報優先度指定機能は，併用できます。この二つの機能を併用した場合，グローバル検索中継ノードを優先選択ノードに指定しているかどうかで，RPCの流れが異なります。

グローバル検索中継ノードを優先選択ノードに指定している場合は，グローバル検索機能の検索範囲の中で指定された優先選択ノードがRPCのあて先になります。グローバル検索中継ノードを優先選択ノードに指定していない場合は，要求元で指定した優先選択ノードがRPCのあて先になります。それぞれの場合について説明します。

グローバル検索中継ノードを優先選択ノードに指定した場合のRPCの流れ

グローバル検索中継ノードを優先選択ノードに指定した場合のRPCの流れを次の図に示します。

図3‒20　グローバル検索中継ノードを優先選択ノードに指定した場合のRPCの流れ

グローバル検索機能を使用しているため，TP1-Aは，TP1-Bを経由して，TP1-Bのシステム共通定義のall_nodeオペランドに指定されているTP1-Cのサービス情報を取得します。

TP1-Aは優先選択ノードにTP1-Bを指定しているため，TP1-Bのall_nodeオペランドに指定されているTP1-Cのサービス情報が，優先選択ノードで稼働しているものとして扱われます。この結果，TP1-Aは，TP1-Cのサービス情報を優先的に選択します。

つまり，サービス要求元のノード（TP1-A）での優先度に関係なく，優先選択ノードに指定したグローバル検索中継ノード（TP1-B）を経由して取得したサービス情報（TP1-Cのサービス情報）が，優先選択ノードで稼働しているものとして扱われて，優先的に選択されます。

グローバル検索中継ノードを優先選択ノードに指定していない場合のRPCの流れ

グローバル検索中継ノードを優先選択ノードに指定していない場合のRPCの流れを次の図に示します。

図3‒21　グローバル検索中継ノードを優先選択ノードに指定していない場合のRPCの流れ

グローバル検索機能を使用しているため，TP1-Aは，TP1-Bを経由して，TP1-Bのシステム共通定義のall_nodeオペランドに指定されているTP1-CおよびTP1-Dのサービス情報を取得しようとします。このとき，TP1-Bは，TP1-Bの優先選択ノードであるTP1-Dで稼働しているサービス情報を選択して，TP1-Aに返します。

この結果，TP1-Aは，優先選択ノードであるTP1-Eを選択します。

つまり，サービス要求元のノード（TP1-A）での優先度が有効となります。グローバル検索中継ノード（TP1-B）での優先度に関係なく，優先選択ノードではないグローバル検索中継ノード（TP1-B）を経由して取得したサービス情報（TP1-Dのサービス情報）は，選択されません。

(d)　サービス情報優先度指定機能を使用する場合の注意事項

サービス情報優先度指定機能を使用する場合の注意事項を次に示します。

優先選択ノードに一つ以上のノードを指定し，かつRPCを実行するノードでもRPC先となるサーバUAPが稼働している場合は，RPCを実行するノードも優先選択ノードになります。

dc_rpc_call_to関数を実行した場合，サービス情報優先度指定機能は無効になります。そのため，指定されたホスト名称が示すノードで稼働しているサーバUAPへRPCを実行します。

優先選択ノードで稼働しているサーバUAPがすべて閉塞していた場合，そのノードは優先選択ノードから除きます。そのため，優先選択ノードに指定していないノードで稼働しているサーバUAPへRPCを実行します。

優先選択ノードで稼働しているサーバUAPが高負荷状態の場合，優先選択ノード以外のノードで稼働している同一サービスグループにRPCが転送されてしまうことがあります。そのため，優先選択ノードに指定していないノードで稼働しているサーバUAPでRPCが実行されることがあります。

高負荷状態の詳細については，「3.4.3(6)　ノード間負荷バランス機能」を参照してください。

3.2.3　OpenTP1のノード管理

OpenTP1同士の通信はTCP/IPによって実装したRPCを使用します。TCP/IPでは，通信するサーバ間でコネクションを確立した状態で通信します。

ネットワーク障害によってOpenTP1との通信ができなくなった場合，コネクション障害を検知できません。このため，そのあとに実行したRPCが障害となることがあります。このような状態を防止するためのOpenTP1の機能について説明します。

(1)　起動通知機能

OpenTP1の起動時に，他ノードで起動するOpenTP1のネームサービスに対して，自ノードが起動したことを通知し，それまで接続されていたコネクションを強制的に切断します。この機能は，系切り替えをする場合などに使用します。

OpenTP1の起動を通知する場合，送信側および受信側の両方のノードでシステム共通定義のname_notifyオペランドにYを指定してください。

この機能を使用するには，送信側および受信側の両方のノードでOpenTP1のバージョンを05-02以降にする必要があります。

起動通知機能を系切り替え時に使用した場合の構成例を次の図に示します。

図3‒22　起動通知機能を系切り替え時に使用した場合

OpenTP1-Bがサーバ障害などでダウンすると系切り替えが発生します。OpenTP1-Aでは，OpenTP1-Bからの障害を検知できなくてコネクションは残留します。

系切り替えが行われ，待機系でOpenTP1-Cが開始されます。

起動通知機能を使用した場合，OpenTP1-Cでは起動通知をOpenTP1-Aに通知します。

OpenTP1-Aでは，OpenTP1-Bへのコネクションを強制切断します。

このように，OpenTP1-A，OpenTP1-B，OpenTP1-Cとの通信はコネクション確立から再開するため，通信障害を発生させることなく処理できます。

何らかの要因でOpenTP1-Aに起動通知できなかった場合，OpenTP1-CでKFCA00642-Wメッセージが出力されます。この場合，OpenTP1-Aでnamunavlコマンドを実行する必要があります。OpenTP1-Cで起動通知を通知できなかったノードは，namunavlコマンドに-lオプションを指定して実行することで確認できます。

注意事項

この機能は，ノードごとにユニークなIPアドレスが割り振られていることを前提としているため，同一のIPアドレスで複数のOpenTP1が起動する（1LANボードだけ使用時など）システムでは，起動通知機能を使用できません。

(2)　ノード監視機能

定期的にノードとの通信を行い，障害を検知します。

ノード監視機能を使用すると，システム共通定義のall_nodeオペランドおよびall_node_exオペランドに指定されたノードの起動状況を監視できます。この機能では，起動を検出できなかったOpenTP1ノードのすべてのサービス情報をキャッシュから削除し，さらに，そのノードとのコネクションを切断します。

障害を検知し，障害ノードと接続されているコネクションを強制切断できるため，障害を最小にできます。

ノード監視機能で，他ノードを監視する例を次の図に示します。

図3‒23　ノード監視機能を使用した他ノードの監視

ノード監視機能を使用すると，OpenTP1-AからOpenTP1-B，OpenTP1-C，OpenTP1-Dを定期的に監視します。

OpenTP1-Cでノードダウンが発生すると，ノード監視機能がOpenTP1-Cとの通信障害を検知します。

OpenTP1-Cのコネクションを切断し，KFCA00650-Iを出力します。

RPC抑止リスト※に登録します。キャッシュに登録しているサービス情報のうち，未起動を検知したノードのサービス情報を削除します。

注※

RPC抑止リストは，OpenTP1システムが未起動のOpenTP1ノードの情報を保持しているリストです。

ノード監視機能は，ネームサービス定義のname_audit_intervalオペランドに指定された時間ごとに，各ノードの起動状況を確認します。ノード監視機能を使用する場合は，ネームサービス定義のname_audit_confオペランドに1，または2を指定してください。

name_audit_confオペランドの指定値ごとにノード監視機能の動作を次に示します。

name_audit_confに1を指定した場合

一方送信型ノード監視を行います。送信処理が終了した時点で次の動作をします。

稼働状態だったノードとの送信処理が失敗したとき

送信処理に失敗したノードが停止状態になったと判断し，KFCA00650-Iメッセージを標準出力へ出力したあと，該当するノードの情報をRPC抑止リストに登録します。

停止状態だったノードとの送信処理が成功したとき

停止状態だったノードが稼働状態になったと判断し，KFCA00651-Iメッセージを標準出力へ出力したあと，該当するノードの情報をRPC抑止リストから削除します。

name_audit_confに2を指定した場合

送受信型ノード監視を行います。送受信処理が終了した時点で次の動作をします。

稼働状態だったノードとの送信処理が失敗，または，稼働状態だったノードからの受信処理に失敗※したとき

送受信処理に失敗したノードが停止状態になったと判断し，KFCA00650-Iメッセージを標準出力へ出力したあと，該当するノードの情報をRPC抑止リストに登録します。

停止状態だったノードとの送受信処理が成功したとき

停止状態だったノードが稼働状態になったと判断し，KFCA00651-Iメッセージを標準出力へ出力したあと，該当するノードの情報をRPC抑止リストから削除します。

注※

受信処理で受信タイムアウトが発生した場合も，失敗したと認識します。タイムアウト監視時間は，ネームサービス定義のname_audit_watch_timeオペランドに指定した値です。

ノード監視機能を使用した場合のノードの起動状況によって次の動作をします。

稼働状態だったノードとの通信が失敗したとき

通信に失敗したノードが停止状態になったと判断し，KFCA00650-Iメッセージを標準出力へ出力したあと，該当するノードの情報をRPC抑止リストへ登録します。

停止状態だったノードとの通信が成功したとき

停止状態だったノードが稼働状態になったと判断し，KFCA00651-Iメッセージを標準出力へ出力したあと，該当するノードの情報をRPC抑止リストから削除します。

ノードの起動状況は，namalivechkコマンドでも確認できます。ノード監視機能を使用した場合とnamalivechkコマンドを使用した場合のノード監視の違いについて，次の表に示します。

表3‒4　ノード監視機能使用時とnamalivechkコマンド使用時のノード監視の比較

比較項目

ノード監視機能使用時

namalivechkコマンド使用時

監視対象

システム共通定義のall_nodeオペランドに指定されたすべてのノード（起動／未起動にかかわらずすべてのノード）

システム共通定義のall_node_exオペランドに指定されたすべてのノード（起動／未起動にかかわらずすべてのノード）

システム共通定義のall_nodeオペランドに指定されたノードのうち，OpenTP1が未起動を検知していないノード

システム共通定義のall_node_exオペランドに指定されたすべてのノード（起動／未起動にかかわらずすべてのノード）

ノードの未起動を検知した場合の動作

all_nodeオペランドに指定されたノードで，かつRPC抑止リストに登録されていないノードの場合，ノードの情報をRPC抑止リストへ登録します。すでにRPC抑止リストに登録されているノードの場合，何もしません。

未起動を検知したノードとのコネクションを切断します。

キャッシュに登録しているサービス情報のうち，未起動を検知したノードのサービス情報を削除します。

all_nodeオペランドに指定されたノードのうち，起動を検出できなかったノードの情報をRPC抑止リストへ登録します。

未起動を検知したノードとのコネクションを切断します。

キャッシュに登録しているサービス情報のうち，未起動を検知したノードのサービス情報を削除します。

ノードの起動を検知した場合の動作

all_nodeオペランドに指定されたノードで，かつRPC抑止リストに登録されているノードの場合，RPC抑止リストからノードの情報を削除します。

何もしません。

注意事項

この機能は，ノードごとにユニークなIPアドレスが割り振られていることを前提としているため，同じIPアドレスを使用するノードをシステム共通定義のall_nodeオペランドまたはall_node_exオペランドに複数指定しているノードや，同一のIPアドレスで複数のOpenTP1が起動する（1LANボードだけ使用時など）ノードに対しては，ノード監視機能を使用できません。

ノード監視機能の監視用通信処理で，ノードダウン検知の感度をチューニングする場合，次のオペランドを変更してください。

name_audit_confオペランドに1を指定した場合

システム共通定義のipc_conn_intervalオペランドを変更してください。

name_audit_confオペランドに2を指定した場合

ネームサービス定義のname_audit_watch_timeオペランドを変更してください。

ノード監視機能で同時に監視できるノード数は60ノードまでです。システム共通定義のall_nodeオペランド，およびall_node_exオペランドに指定したノード数が60を超える場合，60ノード単位で監視を繰り返します。

システム共通定義のall_nodeオペランド，およびall_node_exオペランドに多くのノードを指定している場合，ノード監視機能を使用するとUAPで実行するRPCに影響を及ぼすおそれがあります。この場合，name_audit_intervalオペランドに小さな値を指定しないでください。また，namalivechkコマンドを繰り返し実行する場合，その間隔を短くしないでください。

(3)　RPC抑止リストに登録されたノードの監視機能

ネームサービスでは，ノード監視機能とは別に180秒ごとにRPC抑止リストに登録されたノードの起動状況を確認できます。この機能の使用有無は，ネームサービス定義のname_rpc_control_listオペランドで指定します。

ノードの監視機能の設定を考慮して，この機能を使用してください。例えば，次に示す状態の場合，RPC抑止リストに登録されたノードの監視機能を無効にする必要があります。

name_audit_intervalオペランドに指定した時間が経過していなくても，障害から復旧したノードがRPC抑止リストから削除されることがあります。この場合，KFCA00651-Iメッセージは出力されません。

name_audit_confオペランドに2を指定している場合，KFCA00650-Iメッセージが定期的に出力されることがあります。

RPC抑止リストに登録されたノードの監視機能を無効にした場合，name_audit_intervalオペランドに指定した時間が180秒以上のとき，障害から復旧したノードがRPC抑止リストから削除されるまでの時間が従来よりも長くなります。

ノード監視機能とRPC抑止リストに登録されたノードの監視機能について，推奨する設定を次に示します。

name_audit_confオペランドに1または2を指定し，かつname_audit_intervalオペランドに180以下を指定した場合

name_rpc_control_listオペランドにNを指定することをお勧めします。

name_audit_confオペランドを省略するか，または0を指定した場合

name_rpc_control_listオペランドを省略するか，Yを指定することをお勧めします。

なお，name_audit_confオペランドを省略するか，または0を指定した場合，name_rpc_control_listオペランドにNを指定したときは，ノード監視機能およびRPC抑止リストへの監視機能は無効になるので次に示す状態になります。

RPC抑止リストに登録したノードから自ノードに対して通信が発生しないかぎり，RPC抑止リストから該当ノードは削除されません。

RPC抑止リストに登録したノードのall_nodeオペランドに自ノードを指定していない場合，自ノードのOpenTP1を再起動しないかぎり，RPC抑止リストから該当ノードが削除されません。

(4)　ノード自動追加機能

ノード自動追加機能とは，OpenTP1システムにノードを追加する手順を容易にするための機能です。ノード自動追加機能では，ノード情報を管理するノードを定義します。このノードのことをマネジャノードといいます。逆にマネジャノードに管理されるノードのことをエージェントノードといいます。

マネジャノードが管理するノードの情報のリストをノードリストといいます。ノードリストは，マネジャノードからエージェントノードへ配布され，OpenTP1システム内でノードリストを共有します。

ノード自動追加機能を使用してノードを追加する場合のノードリストの流れを次の図に示します。

図3‒24　ノード自動追加機能を使用してノードを追加する場合のノードリストの流れ

図で示したノードリストの流れについて説明します。番号は図中の番号と対応しています。

追加するノード（ノードX）からマネジャノードに対して，ノードリスト要求を送信します。

マネジャノードは，ノードXのノード情報をノードリストに追加します。

マネジャノードからノードXにノードリストを返します。

マネジャノードから各ノードへノードXのノード情報を配布します。

各ノードで，ノードXをノードリストに追加します。

(a)　ノード自動追加機能を使用するメリット

ノード自動追加機能を使用すると，次のメリットがあります。

ノード追加時の作業手順の軽減

ノード自動追加機能を使用すれば，ノード追加時に修正する定義は，追加ノード分だけです。また，そのほかのノードを再起動する必要もありません。

大規模構成への対応

ノード追加時の定義の修正作業が緩和されることによって，大規模システム構成への対応が容易になります。マネジャノードは最大511のノードを管理できます。

(b)　ノードの追加手順

ノード自動追加機能を使用する場合と，使用しない場合のノードの追加手順の違いを次に示します。

●ノード自動追加機能を使用した場合のノードの追加手順

追加するノードの作業

システム共通定義の次のオペランドを指定します。

name_service_modeオペランドにagentを指定

name_manager_nodeオペランドにマネジャノードのノード名を指定

OpenTP1システム内のそのほかのノードの作業は必要ありません。

●ノード自動追加機能を使用しない場合のノードの追加手順

追加するノードの作業

システム共通定義のall_nodeオペランドにOpenTP1システム内のすべてのノードを指定します。

次のどちらかの方法で手順1で指定した定義を有効にします。

namndchgコマンドを実行

OpenTP1を停止し，再起動

OpenTP1システム内のそのほかのノードの作業

システム共通定義のall_nodeオペランドに追加するノードを指定します。

次のどちらかの方法で手順1で指定した定義を有効にします。

namndchgコマンドを実行

OpenTP1を停止し，再起動

OpenTP1システム内のすべてのノードに対して，手順1〜2を繰り返します。

ノード自動追加機能を使用する場合の運用方法については，マニュアル「OpenTP1 運用と操作」を参照してください。

(5)　ノードの情報表示

namsvinfコマンドを実行すると，OpenTP1ノードの起動結果，IPアドレス，およびネームサービスのポート番号を表示できます。情報を表示できるOpenTP1ノードは，システム共通定義のall_nodeオペランドおよびall_node_exオペランドに指定されたノードです。

3.2.4　XATMIインタフェースの通信

XATMIインタフェースとは，X/Openで規定するDTPモデルに準拠した，クライアント/サーバ形態の通信をするAPIです。OpenTP1では，XATMIインタフェースを使って，UAPプロセス間で通信できます。

XATMIインタフェースの通信は，通信プロトコルにOSI TPだけが使えます。なお，OSI TPは，ノード間通信でだけ使えます。自ノード内通信では使えません。

XATMIインタフェースの通信を使用できるのは，SUPとSPPです。SUPとSPPの両方に，XATMIインタフェース定義ファイルから作成したスタブを結合しておいてください。

MHPを作成するときには，XATMIインタフェースの関数は使えません。

XATMIインタフェースの通信については，マニュアル「OpenTP1 プログラム作成の手引」を参照してください。

(1)　XATMIインタフェースの通信形態

XATMIインタフェースでは，次に示す通信形態を提供します。

リクエスト/レスポンス型サービスの通信

サービス関数に対して一つの要求を送信し，一つの応答を受信する形態の通信です。OpenTP1のリモートプロシジャコールと同様の，サービスを要求して結果を受信する形態の通信です。

会話型サービスの通信

通信相手のサービス関数を起動して確立したコネクションを介して，サービス関数と互いにデータを送受信する通信です。通信プロトコルにOSI TPを使っている場合は，会話型サービスの通信は使えません。

XATMIインタフェースの通信の概要を次の図に示します。

図3‒25　XATMIインタフェースの通信の概要

注※　リクエスト／レスポンス型サービスの通信の，応答を返さない形態は，サービス要求をトランザクションにできません。

(2)　サービスの要求方法

サービスを要求するときは，サーバUAPのサービス関数を識別する名称（サービス名）を引数に設定して，通信する関数を呼び出します。

(3)　通信に使用するデータ

XATMIインタフェースの通信では，プロセス間の通信で使用するデータの型を設定します。XATMIインタフェースの通信で使用する，型付きのデータを格納するバッファを型付きバッファ（タイプトバッファ）または型付きレコード（タイプトレコード）といいます。

3.2.5　TxRPCインタフェースの通信

TxRPCインタフェースとは，X/Openで規定するクライアント/サーバ形態の通信方法です。OpenTP1のUAPプロセス間で，TxRPCインタフェースの方式で通信できます。

ほかのクライアント/サーバ形態の通信と異なり，TxRPCの通信ではユーザが作成した関数をクライアントから呼び出して通信します。

TxRPCの通信をするUAPでは，OpenTP1のRPC（dc_rpc_call関数）を使って，ほかのUAPと通信することもできます。

(1)　TxRPC通信の種類

TxRPCの通信方法には，DCE RPCを使うかどうかで次に示す2種類があります。

IDL-only TxRPC

IDLコンパイラから生成されるファイルだけを使ってUAPを作成する方式です。IDL-only TxRPCの場合は，DCEを前提としません。

RPC TxRPC

通信プロトコルにDCE RPCを使う方式です。このバージョンではRPC TxRPCをサポートしていません。

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

(2)　作成できるアプリケーションプログラム

TxRPCで通信するUAPとして，次のものが作成できます。

クライアントUAP（SUP）

サーバUAP（SPP）

TxRPC通信では，作成するUAPの種類によって，前提となるライブラリが異なります。

(a)　SUP またはSPPを作成する場合

次に示す製品がシステムに組み込んであることが前提です。

TP1/Server Base

(3)　TxRPC通信のUAPを作成する手順

TxRPCの通信をするUAPを作成するときの手順を，次の図に示します。

図3‒26　TxRPC通信のUAP作成手順

TxRPCの通信のUAPを作成する手順については，マニュアル「OpenTP1 プログラム作成の手引」，および「OpenTP1 プログラム作成リファレンス C言語編」を参照してください。

3.3　メッセージ制御

OpenTP1システムでは，OpenTP1を使っていないシステムと通信するために，各種の通信プロトコルに準拠した形式の通信ができます（メッセージ制御機能）。この通信形態を使うと，OpenTP1を使っていないシステムと水平，または垂直分散型のネットワークシステムを構築できます。

OpenTP1のメッセージ制御機能を使うときは，次に示す製品が前提となります。

TP1/Message Control（メッセージ制御機能を管理する製品）

TP1/NET/Library（ネットワークを制御するための製品）

TP1/NET/××××（通信プロトコル別のインタフェースを制御する製品）

メッセージ制御機能で使うUAPは，MHPです。さらに，一部のメッセージの送受信はSPPでもできます。

なお，OSがWindowsの場合は，一部の機能が使用できません。Windowsでサポートしていないメッセージ制御機能については，マニュアル「OpenTP1 使用の手引 Windows(R)編」を参照してください。

3.3.1　メッセージ送受信

OpenTP1は，相手システムからメッセージを受信すると，入力キューにメッセージを書き込み，該当するMHPにメッセージを渡します。MHPは，送信先を指定してメッセージを出力キューに書き込みます。出力キューに書き込まれたメッセージは，OpenTP1が優先度に従って相手システムに送信します。

MHPがメッセージを受け取ってからリターンするまでの間が，MHPのグローバルトランザクションです。また，トランザクション属性を持つSPPから他システムへメッセージを送信することもできます。

メッセージの送受信は，通信プロトコルごとにMCF通信プロセスが管理します。MCF通信プロセスを起動するため，通信プロトコルごとにMCF通信構成定義を作成してください。

メッセージの送受信の流れを次の図に示します。

図3‒27　メッセージの送受信の流れ

3.3.2　メッセージの構造

通信で意味を持つ単位を論理メッセージといいます。そして，UAPの関数で扱うメッセージの単位をセグメントといいます。論理メッセージは，一つのセグメントから構成される場合と，複数のセグメントから構成される場合があります。

論理メッセージとセグメントの関係を次の図に示します。

図3‒28　論理メッセージとセグメントの関係

3.3.3　アプリケーションプログラムの構造とアプリケーション名の関連

MHPはメイン関数とサービス関数から構成されます。このMHPの実行形式ファイルをTP1/Server Baseに登録するため，ユーザサービス定義を作成します。そして，MCFで使えるようにMHPをMCFアプリケーション定義に指定します。ここでは，MHPのサービス関数とアプリケーション名を対応づけます。これで，MHPのサービス関数がMCFのアプリケーションとして使えるようになります。

アプリケーションプログラムの構造とアプリケーション名の関連を次の図に示します。

図3‒29　アプリケーションプログラムの構造とアプリケーション名の関連

3.3.4　メッセージの通信形態

MHPで使えるメッセージの通信形態を次に示します。通信プロトコルによって使える形態は異なります。

ここで説明するメッセージの通信形態は，MHPでだけ使えます。

メッセージの通信形態とアプリケーションの型を次の図に示します。

図3‒30　メッセージの通信形態とアプリケーションの型

(1)　問い合わせ応答形態

相手システムから送られてきたメッセージを受信して，応答のメッセージを送信する形態です。メッセージを受信するときは，dc_mcf_receive関数を使い，応答メッセージを送信するときは，dc_mcf_reply関数を使います。

問い合わせ応答形態の通信をするMHPのアプリケーションの型には，応答型（ans型）を指定します。応答型を指定したMHPでdc_mcf_reply関数を呼び出さないで終了すると，エラーが起こったと見なして，MHPは異常終了します。

(2)　非問い合わせ応答形態（一方受信形態）

相手システムから送られてきたメッセージを受信するだけで，応答のメッセージを送信しない形態です。メッセージを受信するときは，dc_mcf_receive関数を使います。

非問い合わせ応答形態（一方受信形態）の通信をするMHPのアプリケーションの型には，非応答型（noans型）を指定します。

(3)　継続問い合わせ応答形態

問い合わせ応答形態を連続させる形態です。dc_mcf_receive関数でメッセージを受信してdc_mcf_reply関数で応答メッセージを送信したあとに，続けてメッセージを受信します。続けてメッセージを受信するMHPは，同じMHPでも異なったMHPでもかまいません。継続問い合わせ応答形態の通信を終了するときは，dc_mcf_contend関数を使います。

継続問い合わせ応答形態の通信をするMHPのアプリケーションの型には，継続問い合わせ応答型（cont型）を指定します。

3.3.5　通信形態に依存しないメッセージ

MHPまたはSPPから送受信できるメッセージについて説明します。

(1)　一方送信メッセージ

OpenTP1のUAPから送信するメッセージです。一方送信メッセージを送信するときは，dc_mcf_send関数を使います。dc_mcf_send関数を呼び出したUAPのトランザクションがコミットしてから，実際に相手システムにメッセージが送信されます。

一方送信メッセージの概要を次の図に示します。

図3‒31　一方送信メッセージの概要

(2)　メッセージの再送

OpenTP1のUAPからいったん送信したメッセージを，再び送り直すことをメッセージの再送といいます。メッセージを再送するときは，dc_mcf_resend関数を使います。

(3)　同期型のメッセージ

同期型のメッセージとは，UAPからの関数呼び出しと同期してメッセージを送受信する形式のメッセージです。同期型のメッセージには，次に示す3種類があります。

(a)　同期送信

同期送信のメッセージを使うときは，dc_mcf_sendsync関数を呼び出します。UAPからdc_mcf_sendsync関数を呼び出すと，UAPの処理をいったん止めて，出力キューにメッセージが書き込まれます。そして，相手システムにメッセージを送信し終わってから，関数がリターンします。

(b)　同期受信

同期受信のメッセージを使うときは，dc_mcf_recvsync関数を呼び出します。UAPからdc_mcf_recvsync関数を呼び出すと，UAPの処理をいったん止めて，関数に指定したアプリケーション名へのメッセージを入力キューから探します。メッセージがある場合は，セグメントを受信して関数がリターンします。該当するメッセージがない場合は，送信されてくるまで待ちます。

(c)　同期送受信

同期送受信のメッセージを使うときは，dc_mcf_sendrecv関数を呼び出します。UAPからdc_mcf_sendrecv関数を呼び出すと，UAPの処理をいったん止めて，出力キューにメッセージが書き込まれます。そして，相手システムにメッセージを送信し終わってから，応答を自システムで受信し，その後，関数がリターンします。

3.3.6　メッセージ制御のトランザクション

MCFのトランザクション処理について説明します。

(1)　トランザクションとして処理する場合

相手システムからMCFでメッセージを受信したあとで，MHPのサービスを呼び出した時点でトランザクションが開始します。メッセージを処理したMHPが正常終了すると，トランザクションがコミットしたことになり，該当するMHPの処理が有効になります。

MHPの処理では，トランザクションをコミットすることもロールバックすることもできます。コミットするときは，dc_mcf_commit関数を，ロールバックするときはdc_mcf_rollback関数を使います。

(2)　トランザクションとして処理しない場合

受信したメッセージの処理をトランザクションとして処理しないこともできます。トランザクションとして処理しないと，UAPに障害が起こった場合に回復できませんが，処理効率は良くなります。トランザクションとして処理しないMHPを非トランザクション属性のMHPといいます。非トランザクション属性のMHPを利用する場合，アプリケーション属性定義のtrnmodeオペランドでnontrnを指定します。

3.3.7　MHPの起動

MCFは，次に示す場合にMHPを起動させます。

MCFがメッセージを受信した場合

UAPがアプリケーションを起動する関数（dc_mcf_execap関数）を呼び出した場合

MCFイベントが通知された場合

MHPを起動させるコマンド（mcfuevtコマンド）を実行した場合

(1)　メッセージ受信によるMHPの起動

MCFは，入力メッセージを基に，MHPを起動する名前（アプリケーション名）を決めます。

アプリケーション名の決定方法を次の図に示します。

図3‒32　アプリケーション名の決定方法

アプリケーション名を決定する方法には，アプリケーション名決定ユーザオウンコーディング（UOC）を組み込まない方法と，組み込む方法の二つがあります。

(a)　アプリケーション名決定UOCを組み込んでいない場合

MCFは，入力メッセージの先頭から最初に空白が現れるまでの8文字以内の文字列をアプリケーション名と見なします。OpenTP1はアプリケーション名をMHPのサービスグループ名とサービス名に変換し，該当するMHPを起動します。先頭から9文字目まで空白の場合は，アプリケーション名不正としてエラーとなります。

アプリケーション名と，サービスグループ名およびサービス名の対応は，MCFアプリケーション定義のアプリケーション属性定義で指定します。

(b)　アプリケーション名決定UOCを組み込んでいる場合

MCFは，UOCを呼び，そのUOCが設定した名称をアプリケーション名と見なします。OpenTP1はアプリケーション名をMHPのサービスグループ名とサービス名に変換し，該当するMHPを起動します。

アプリケーション名と，サービスグループ名・サービス名の対応は，MCFアプリケーション定義のアプリケーション属性定義で指定します。なお，UOCを組み込んでいてもUOCでアプリケーション名を設定しなければ，入力メッセージの先頭から最初に空白が現れるまでの8文字以内の文字列をアプリケーション名と見なします。先頭から9文字目まで空白の場合は，アプリケーション名不正としてエラーとなります。

(2)　UAPからの関数発行によるMHPの起動

MHPやSPPから関数（dc_mcf_execap関数）を呼び出して，ほかのMHPを起動できます。MHPやSPPからMHPを起動する機能を，アプリケーション起動機能といいます。

起動されるMHPは，起動要求元のMHPやSPPが正常終了したあと，または指定された時間が経過したあとに，アプリケーション起動プロセスが起動します。

MHPから関数（dc_mcf_rollback関数）を呼び出してトランザクションをロールバックするとき，関数の引数にリトライを指定すると，ロールバックしたMHPを再び起動して処理を再実行します。この場合もアプリケーション起動プロセスが起動します。

このように，UAPから関数を呼び出してアプリケーションを起動，または再起動するときには，アプリケーション起動プロセスを起動する必要があります。MCF通信プロセスとは別に，アプリケーション起動プロセスのMCF通信構成定義を作成してください。アプリケーション起動プロセスでプロトコルに依存しない処理をすることで，MCF通信プロセスの負荷を軽減します。

起動要求元のMHPやSPPがMCFにデータを渡す，MCF内部の論理的な通信路を内部通信路といい，アプリケーション起動環境定義で指定します。MCFが，起動されるアプリケーションにデータを渡すときにも，内部通信路を使用します。

(3)　MCFイベントによるMHPの起動

エラーや障害の発生，コネクションの確立や解放などを通知するためのメッセージをMCFイベントといいます。このMCFイベントに対応して起動させるMHPを作成できます。MCFイベントに対応して起動させるMHPを，MCFイベント処理用MHPといいます。MCFイベント処理用MHPを作成しておくと，オンライン中に発生した現象を特定の端末に通知するなど，ユーザ独自の対応がとれます。

(a)　MCFイベントの種類

MCFイベントには，エラーや障害発生などのエラーイベントと，コネクションの確立や解放などプロトコルに依存する通信イベントの2種類があります。

2種類のイベントには，発生した現象の内容に応じてMCFイベントコードがあります。MCFイベントコードと，MCFイベント処理用MHPのサービスグループ名とサービス名は，アプリケーション属性定義で対応づけます。各MCFイベントに対応したMHPのサービスを，アプリケーション起動プロセス，またはMCF通信プロセスが起動します。エラーイベント用のMCFイベント処理用MHPはアプリケーション起動プロセスまたはMCF通信プロセスで，通信イベント用のMCFイベント処理用MHPはMCF通信プロセスで起動します。エラーイベント用のMCFイベント処理用MHPを使用する場合は，アプリケーション起動プロセス用のMCF通信構成定義も作成してください。

通信イベントが障害となった場合に，エラーイベントを通知できます。この通知の有無はアプリケーション属性定義のerrevtオペランドで指定できます。ただし，エラーイベントの障害によるエラーイベントは通知できません。

MCFイベントの一覧を次の表に示します。MCFイベントについては，マニュアル「OpenTP1 プログラム作成の手引」および「OpenTP1 プロトコル」の該当するプロトコル編を参照してください。

表3‒5　MCFイベントの一覧

MCFイベント名

MCFイベントコード

MCFイベントが通知された原因

MCFイベント処理用MHPで実行する処理の例

不正アプリケーション名検出通知イベント

ERREVT1

メッセージのアプリケーション名がMCFアプリケーション定義にありません。

該当するアプリケーション名がなかったことを知らせます。

受信したメッセージが問い合わせメッセージの場合は，応答メッセージを送信できます。

メッセージ廃棄通知イベント

ERREVT2

次に示す理由で，MCFで受信した入力キューのメッセージ，または即時指定のアプリケーション起動機能によって入力キューに入力されたメッセージを廃棄しました。

入力キューに障害が発生しました。

入力メッセージ最大格納数を超過しました。

動的共用メモリが不足しました。

キューファイルが満杯になりました。

MHPのサービス，サービスグループ，またはアプリケーションが閉塞しています。

スケジュール閉塞されているサービスグループの入力キューに未処理受信メッセージが残った状態で，OpenTP1を正常終了または計画停止Aで終了しました。

MHPのサービスグループ，またはアプリケーションがセキュア状態です。

MHPで呼び出すdc_mcf_receive関数にセグメントを渡す前に，MHPが異常終了しました。

アプリケーション名に相当するMHPのサービスがありません。

ユーザサーバ未起動などによって，MHPの起動に失敗しました。

DBMSの障害などによって，トランザクションの開始に失敗しました。

メッセージを廃棄したことを知らせます。

受信したメッセージが問い合わせメッセージの場合は，応答メッセージを送信できます。

UAP異常終了通知イベント

ERREVT3

MHPで呼び出すdc_mcf_receive関数にセグメントを渡したあとで，MHPが異常終了，またはロールバック※しました。

UAPが異常終了，またはロールバックしたことを知らせます。

受信したメッセージが問い合わせメッセージの場合は，応答メッセージを送信できます。

タイマ起動メッセージ廃棄通知イベント

ERREVT4

タイマ指定のアプリケーション起動機能によって入力キューに入力されたメッセージをERREVT2に示す理由で破棄しました。

メッセージを廃棄したことを知らせます。

受信したメッセージが問い合わせメッセージの場合は，応答メッセージを送信できます。

未処理送信メッセージ廃棄通知イベント

ERREVTA

次に示す理由で，UAPから送信した未処理送信メッセージを廃棄しました。

MCFの正常終了処理時に，未処理送信メッセージの滞留時間監視の時間切れ（タイムアウト）が起こりました。

mcftdlqleコマンドまたはdc_mcf_tdlqle関数で，出力キューが削除されました。

タイマ起動要求や閉塞されている論理端末の出力キューに未処理送信メッセージが残った状態で，dcstopコマンドが実行されました。

未処理送信メッセージを廃棄したことを知らせます。

受信した未処理送信メッセージは，任意のファイルへ退避します。

送信障害通知イベント

SERREVT

メッセージを送信する途中で，通信プロトコルの障害が起こりました。

通信プロトコルの障害でメッセージを送信できなかったことを知らせます。

送信完了通知イベント

SCMPEVT

相手システムへ，メッセージを正常に送信できました。

相手システムまでメッセージを正常に送信できたことを知らせます。

障害通知イベント

CERREVT（VERREVT）

通信管理プログラムで，コネクション障害，または論理端末障害が起こりました。コネクション確立再試行を定義している場合は，通知されません。

コネクション，または論理端末に障害が起こったことを知らせます。

状態通知イベント

COPNEVT（VOPNEVT）

コネクションが確立しました。

メッセージを送受信できることを知らせます。

CCLSEVT（VCLSEVT）

コネクションが正常に解放されました。

メッセージを送受信できないことを知らせます。

注

ERREVT1，ERREVT2，ERREVT3，ERREVT4，ERREVTAはエラーイベントを示します。

SERREVT，SCMPEVT，CERREVT，COPNEVT，CCLSEVTは通信イベントを示します。

注※

MCFアプリケーション定義（mcfaalcap -g）のrecvmsgオペランドにrを指定した場合，またはdc_mcf_rollbackのactionにDCMCFRTRYもしくはDCMCFRRTNを指定した場合は除きます。

(b)　通信イベント障害時のエラーイベント通知

通信イベント障害時のエラーイベント通知は，通信イベントの障害をエラーイベントによってユーザに通知する機能です。通信イベント障害時のエラーイベント通知を使用することによって通信イベントの障害の回復手段にMCFイベント処理用MHPを使用でき，通信イベントのメッセージは第2セグメントで受信できます。

通信イベント障害時のエラーイベント通知の機能を使用するには，アプリケーション属性定義の-nオプションのerrevtオペランドにyesを指定します。

次の図にCOPNEVT障害時のERREVT2通知の概要を示します。

図3‒33　COPNEVT障害時のERREVT2通知の概要

COPNEVTが入力キューの障害によって破棄される。

制御がMCFに戻り，ERREVT2が通知されて，ERREVT2のMCFイベント処理用MHPがスケジュールされる。

ERREVT2のMCFイベント情報を先頭セグメントで受信できる。障害となったCOPNEVTのMCFイベント情報を第2セグメントで受信できる。受信したMCFイベント情報を参照し，COPNEVTのMCFイベント処理用MHPで実行する予定であった処理を，ERREVT2のMCFイベント処理用MHPで実行することによって，障害に対処できる。

(4)　コマンドを使用したMHPの起動

コマンドを入力して，MHPを起動できます。メッセージ受信を契機に起動するMHPでも，コマンドで直接MHPを起動することで他システムへのメッセージ送信ができるようになります。

起動できるMHPは，非応答型（noans型）だけです。コマンドで起動するMHPには，MCFアプリケーション定義のアプリケーション属性定義でnoans型を指定してください。

(a)　コマンドで起動するMHPの定義

コマンドで起動するMHPのアプリケーション名は，UCMDEVTとします。MCFアプリケーション定義のアプリケーション属性定義mcfaalcapコマンドの-nオプションに，次の値を指定しておきます。

nameオペランド：UCMDEVT

kindオペランド：user（または省略）

typeオペランド：noans（または省略）

(b)　MHPの起動方法

MHPを起動するときは，mcfuevtコマンドを実行します。mcfuevtコマンドの引数として，MCF通信プロセス識別子とMHPに渡す入力メッセージを指定します。

UCMDEVTを定義していない場合にmcfuevtコマンドを実行したときは，mcfuevtコマンドはエラーリターンします。このとき，ERREVT1は通知されません。

コマンドで起動するMHPは通信プロトコルに依存しないので，mcfuevtコマンドに指定するMCF通信プロセスには，アプリケーション起動プロセスを指定することをお勧めします。

(5)　MCFがMHPを起動させる要因

MCFがMHPを起動させる要因を次の図に示します。

図3‒34　MCFがMHPを起動させる要因

3.3.8　メッセージキュー

(1)　入力キューと出力キュー

OpenTP1は，送受信するメッセージをキューに蓄えます。相手システムから受信した入力メッセージを管理する待ち行列を入力キュー（ITQ）といいます。また，相手システムへ送信する出力メッセージを管理する待ち行列を出力キュー（OTQ）といいます。

入力キューや出力キューの割り当て先として，ディスクキューとメモリキューを選択できます。

割り当て先としてディスクキューを使用する場合，入力キューおよび出力キューに蓄えられたメッセージは，オンラインシステムが異常終了した場合などの再開始時に，引き継ぐことができます。また，メッセージの再送を使用する場合は，出力キューにディスクキューを割り当てる必要があります。

一方，メモリキューを使用する場合，再開始時にメッセージを引き継ぐことはできませんが，ディスクへの入出力が発生しないため，ディスクキューと比較して処理性能が向上します。再開始時に情報を引き継ぐ必要のないメッセージは，応答時間の短いメモリキューの使用をお勧めします。

OpenTP1は，ディスクキューとして，メッセージキューファイルを使用します。ディスクキューを使用する指定をした場合には，メッセージキューファイルを作成してください。メッセージキューファイルについては，「4.3.1　メッセージキューファイル」を参照してください。

入力キュー用にディスクキューを使用するのか，またはメモリキューを使用するのかは，アプリケーションごとにアプリケーション属性定義（mcfaalcap）のquekindオペランドで指定します。

出力キュー用にディスクキューを使用するのか，またはメモリキューを使用するのかは，論理端末ごとに論理端末定義（mcftalcle）のquekindオペランドで指定します。

ただし，出力キューにディスクキューを使用する指定をしていても，次のメッセージの場合はメモリキューを使用します。

問い合わせ応答型や継続問い合わせ応答型のアプリケーションで，問い合わせメッセージが使用した入力キューがメモリキューのときの応答メッセージの送信

同期型のメッセージの送信

入力キューまたは出力キューにディスクキューを使用したメッセージ送受信を次の図に示します。

図3‒35　入力キューまたは出力キューにディスクキューを使用したメッセージ送受信

(2)　OpenTP1再開始時のメッセージの扱い

OpenTP1の再開始時にメッセージを引き継ぐかどうかは，メッセージの種類によって異なります。

OpenTP1の再開始時のメッセージの扱いを次の表に示します。なお，メッセージが格納されているキューの割り当て先がメモリキューの場合，表の内容に関係なくOpenTP1の再開始時にメッセージを破棄します。

表3‒6　OpenTP1の再開始時のメッセージの扱い

キュー種別

メッセージの種類

OpenTP1再開始時のメッセージの扱い

入力キュー

一方送信メッセージ

問い合わせメッセージ

通信プロトコル対応製品によって，動作が異なります。表3-7〜表3-8を参照してください。

MCFイベント

ERREVT1

通信プロトコル対応製品によって，動作が異なります。表3-7〜表3-8を参照してください。※1

ERREVT2

ERREVT3

ERREVT4

ERREVTA

エラーイベントが発生したメッセージの種類によって，動作が異なります。

OpenTP1の再開始時に引き継がれるメッセージの場合，エラーイベントを引き継ぎます。OpenTP1の再開始時に破棄されるメッセージの場合，エラーイベントを破棄します。※1

SERREVT

SCMPEVT

破棄します。

通信イベント（SERREVT，SCMPEVTを除く）

通信プロトコル対応製品によって，動作が異なります。表3-7〜表3-8を参照してください。

UAPからの関数発行によるアプリケーション起動メッセージ※2

＜非応答型のアプリケーションを起動する場合＞

引き継ぎます。

＜応答型，継続問い合わせ応答型のアプリケーションを起動する場合＞

起動元のメッセージの種類によって，動作が異なります。

OpenTP1の再開始時に引き継がれるメッセージの場合，アプリケーション起動メッセージを引き継ぎます。OpenTP1の再開始時に破棄されるメッセージの場合，アプリケーション起動メッセージを破棄します。

運用コマンド（mcfuevt）によるアプリケーション起動メッセージ

引き継ぎます。

ユーザタイマ監視機能によるアプリケーション起動メッセージ

破棄します。

出力キュー

一方送信メッセージ

引き継ぎます。

応答メッセージ

通信プロトコル対応製品によって，動作が異なります。表3-7〜表3-8を参照してください。

同期型のメッセージ

破棄します。

注※1

エラーイベントの場合，OpenTP1の再開始時にメッセージを引き継ぐかどうかを選択できます。詳細については，マニュアル「OpenTP1 システム定義」のUAP共通定義（mcfmuap）を参照してください。

注※2

アプリケーション起動メッセージを再開始時に引き継ぐ場合，入力キューだけでなくアプリケーション起動用論理端末が使用する出力キューにも，ディスクキューを割り当ててください。アプリケーション起動用論理端末が使用する出力キューにメモリキューを割り当てた場合，再開始時にメッセージが引き継がれないことがあります。

また，指定した時間が経過したあとに起動する（タイマ起動）アプリケーションを再開始時に引き継ぐ場合，さらにアプリケーション起動環境定義（mcftpsvr）のreruntmオペランドでyesを指定します。再開始時のタイマ起動の扱いについては，マニュアル「OpenTP1 プログラム作成の手引」を参照してください。

表3‒7　通信プロトコル対応製品とOpenTP1再開始時のメッセージの扱い1

メッセージの種類

通信プロトコル対応製品

TP1/NET/OSAS-NIF

TP1/NET/OSI-TP

TP1/NET/SLU - TypeP2

TP1/NET/TCP/IP

一方送信メッセージ

○

×

○

○

問い合わせメッセージ

○

−

−

×

応答メッセージ

○

−

−

×

ERREVT1

○

×

○

○

通信イベント（SERREVT，SCMPEVTを除く）

×

×

×

○

（凡例）

○：OpenTP1の再開始時に引き継がれます。

×：OpenTP1の再開始時に破棄されます。

−：該当する通信プロトコル対応製品では使用できないメッセージです。

表3‒8　通信プロトコル対応製品とOpenTP1再開始時のメッセージの扱い2

メッセージの種類

通信プロトコル対応製品

TP1/NET/User Agent

TP1/NET/UDP

TP1/NET/XMAP3

一方送信メッセージ

○

○

○

問い合わせメッセージ

×

−

×

応答メッセージ

×

−

×

ERREVT1

△

○

×

通信イベント（SERREVT，SCMPEVTを除く）

×

○

×

（凡例）

○：OpenTP1の再開始時に引き継がれます。

×：OpenTP1の再開始時に破棄されます。

△：問い合わせ型（request）または受信型（receive）の論理端末の場合，OpenTP1の再開始時に引き継がれます。応答型（reply）の論理端末の場合，OpenTP1の再開始時に破棄されます。

−：該当する通信プロトコル対応製品では使用できないメッセージです。

(3)　メモリキューでの縮退運転

ディスクキューを使用する場合には，OpenTP1の開始時に何らかの理由でディスクキューが使えないとき，メモリキューを代わりに使って開始できます。これをメモリキューでの縮退運転といいます。メモリキューで縮退運転するかどうかを，入力キューと出力キューそれぞれの拡張予約定義で指定します。メモリキューで縮退運転しない場合は，ディスクキューに格納されるメッセージが廃棄されます。このとき，メッセージ廃棄通知イベント（ERREVT2）に対応するMCFイベント処理用MHPがあれば，起動されます。

メモリキューで縮退運転する場合は，メッセージ（KFCA11065-WまたはKFCA11066-W）が出力されます。

メモリキューで縮退してOpenTP1を開始させる場合，メモリキューはオンライン停止後の全面回復時にメッセージを回復できない点に注意してください。

オンライン中にディスクキューが使用できなくなったときは，メモリキューで縮退運転できません。

縮退運転の原因と復旧方法については，マニュアル「OpenTP1 運用と操作」を参照してください。

(4)　ディスクキューのメッセージを保持

ディスクキューを使用した場合には，読み出されたあとの再読み出しに備えて，メッセージを残しておけます。再読み出しに備えて残しておくメッセージを，保持メッセージといいます。保持メッセージ数は，メッセージキューサービス定義で指定します。

メモリキューを使用した場合には，メッセージを残しておけません。

ディスクキューごとに，取り出し待ちメッセージの数と保持メッセージの数が，ユーザが定義した一定の割合を超えたとき，ディスクキューの使用率を警告するメッセージを出力できます。警告メッセージを出力するディスクキューの使用率（使用容量警告率　%で表示）は，メッセージキューサービス定義で指定します。

(5)　ディスクキュー満杯時の処理

ディスク入力キューに空きがなくなった場合は，到着したメッセージを廃棄します。メッセージ廃棄通知イベント（ERREVT2）に対応するMCFイベント処理用MHPがあれば，これを起動します。ディスク出力キューに空きがなくなった場合は，メッセージを送信する関数がエラーリターンします。

(6)　入力キューと出力キューの保留

入力キューおよび出力キューへの書き込みや読み込みは，それぞれmcfthldiqコマンド，mcfthldoqコマンドで一時的に停止できます。これを保留といいます 。

保留の目的は次のとおりです。

オンライン中にユーザサーバの入れ替えができます。

入力キューまたは出力キューの内容を複写できます。

入力キューまたは出力キューに滞留しているメッセージを削除できます。

保留には入力キューまたは出力キューへの書き込みの保留（入力保留）と入力キューまたは出力キューからの読み込みの保留（スケジュール保留）があります。

保留状態は，入力キューはmcftrlsiqコマンド，出力キューはmcftrlsoqコマンドで解除できます。また，MCFマネジャ定義の状態引き継ぎ定義（mcfmsts）やMCF通信構成定義の状態引き継ぎ定義（mcftsts）を指定すれば，OpenTP1が異常終了した場合などの再開始時にも引き継ぐことができます。

保留中にOpenTP1を終了した場合，OpenTP1を強制停止します。OpenTP1を終了する前に必ず保留を解除してください。

入力保留とスケジュール保留を次の図に示します。

図3‒36　入力保留とスケジュール保留

保留中に受信または送信したメッセージに対する処理を次の表に示します。

表3‒9　保留中に受信または送信したメッセージに対する処理

キュー種別

保留種別

受信または送信したメッセージに対する処理

保留したあとに受信または送信したメッセージ

保留する前にキューに格納されていたメッセージ

入力キュー

入力保留

入力保留が解除されるまでMCF通信プロセスまたはアプリケーション起動プロセスの動作を停止します。

該当するMHPを正常に起動します。

スケジュール保留

入力キューにメッセージを格納し，スケジュール保留が解除されるまでMHPがメッセージを取り出しません。

スケジュール保留が解除されるまでMHPがメッセージを取り出しません。

入力保留とスケジュール保留

入力保留が解除されるまでMCF通信プロセスまたはアプリケーション起動プロセスの動作を停止します。

スケジュール保留が解除されるまでMHPがメッセージを取り出しません。

出力キュー※1

入力保留

入力保留が解除されるまでUAPの動作を停止します。※2

MCF通信プロセスが正常にメッセージを処理します。

スケジュール保留

出力キューにメッセージを格納し，スケジュール保留が解除されるまでMCF通信プロセスがメッセージを取り出しません。

スケジュール保留が解除されるまでMCF通信プロセスがメッセージを取り出しません。

入力保留とスケジュール保留

入力保留が解除されるまでUAPの動作を停止します。※2

スケジュール保留が解除されるまでMCF通信プロセスがメッセージを取り出しません。

注※1

同期型メッセージの場合，出力キューへの書き込みや読み込みを保留できません。保留状態に関わらず出力キューにメッセージを格納し，MCF通信プロセスが正常にメッセージを処理します。

注※2

出力キューの入力保留の場合，UAPの動作を停止するタイミングを同期点処理で待ち合わせるか関数発行時に待ち合わせるかを選択できます。詳細については，マニュアル「OpenTP1 システム定義」のUAP共通定義（mcfmuap）を参照してください。

注意事項

入力キューを保留して，オンライン中にユーザサーバを入れ替える場合，スケジュール保留だけを行ってください。入力保留を行った場合，MCF通信プロセスまたはアプリケーション起動プロセスの動作が停止することで，他のユーザサーバでのメッセージ送受信ができなくなることがあります。

保留状態を再開始時に引き継ぐ指定をした場合，次のことをするときは，mcfthldiqコマンドやmcfthldoqコマンドに-rオプションを指定することを推奨します。

入力キューまたは出力キューの内容の複写

滞留しているメッセージの削除

オンライン中のユーザサーバの入れ替え

3.3.9　アプリケーションプログラムのメッセージ送受信

(1)　UAPのメッセージ受信

OpenTP1は，相手システムからコネクションを通してメッセージを受信します。コネクションとは，相手システムとMCFの論理的な通信路のことです。OpenTP1が受信したメッセージは，MCF通信プロセスが管理します。MCFは，メッセージに組み込まれたアプリケーション名をサービスグループ名とサービス名に変換し，受信メッセージを入力キューに書き込みます。

入力キューは，サービス要求としての入力を管理する待ち行列です。ディスクキューに書き込むメッセージの場合，サービスグループ単位にキューを割り当てます。ディスクキューのうち，個々のサービスグループに割り当てた部分をキューファイルといいます。対応するサービスグループの名称がキューファイル名になります。メモリキューに書き込むメッセージの場合も同様に，サービスグループ単位でキューを管理します。

MCFは，入力キューに受信メッセージの最終セグメントを書き込んだ時点で，サービス要求を該当するMHPのスケジュールキューに登録します。スケジュールされたMHPは，受信メッセージをセグメント単位にdc_mcf_receive関数で受信します。

UAPのメッセージ受信の概要を次の図に示します。

図3‒37　UAPのメッセージ受信の概要

(2)　UAPのメッセージ送信

MCFは，メッセージに組み込まれた論理端末名称を基に，送信メッセージを出力キューに書き込みます。論理端末名称とは，マルチウィンドウを持つワークステーションの一つのウィンドウや，プリンタなどの端末の実体ごとに，ユーザが任意に付ける名称です。OpenTP1は，端末の実体を論理端末名称を持つ論理端末として識別します。論理端末名称は，論理端末定義で指定します。

ディスクキューを使用する送信メッセージの場合，論理端末ごとにキューを割り当てます。ディスクキューのうち，個々の論理端末に割り当てた部分をキューファイルといいます。対応する論理端末の名称がキューファイル名になります。メモリキューを使用する送信メッセージの場合も同様に，論理端末ごとにキューを管理します。

プロトコル対応に作成したMCF通信プロセスが，セグメント単位で他システムにメッセージを送信します。

UAPのメッセージ送信の概要を次の図に示します。

図3‒38　UAPのメッセージ送信の概要

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

MHPとSPPは，dc_mcf_send関数で相手システムへ一方送信メッセージを送信できます。送信先として論理端末名称を指定します。

(b)　問い合わせに対する応答メッセージの送信

MHPは，相手システムからの問い合わせメッセージをdc_mcf_receive関数で受信したあと，応答メッセージをdc_mcf_reply関数で問い合わせ発生元論理端末へ送信できます。

(c)　問い合わせメッセージの送信

MHPとSPPは，相手システムへ問い合わせメッセージをdc_mcf_send関数で送信できます。

(d)　同期型のメッセージの送信

MHPとSPPは，相手システムへ同期型のメッセージをdc_mcf_sendsync関数，またはdc_mcf_sendrecv関数で送信できます。

dc_mcf_sendsync関数は，相手システムにメッセージを送信し終わるまでUAPの処理を止めるため，相手システムのUAP処理と同期がとれます。

dc_mcf_sendrecv関数は，相手システムにメッセージを送信し終わってから，応答を自システムで受信するまでUAPの処理を止めるため，相手システムのUAP処理と同期がとれます。

(3)　UAPからのアプリケーションの起動

アプリケーション起動機能を使えば，メッセージの編集・送信用のMHPを作成することで，メッセージ送信を一元化できます。

応答メッセージを編集して送信するMHPを作成すれば，問い合わせメッセージを受信したMHPに代わって，問い合わせ発生元論理端末への応答を任せることができます。また，一方送信メッセージを編集して送信するMHPを作成すれば，MHPまたはSPPからこのMHPを起動することで，メッセージ送信を任せることもできます。どちらの場合も，送信要求元のUAPからdc_mcf_execap関数を呼び出すことでメッセージの送信を一元化します。

dc_mcf_execap関数は非同期型の通信関数です。MCFは，メッセージを編集して送信するMHPを，関数を呼び出したMHPやSPPのサービス正常終了直後，または指定された時間が経過したあとに起動（タイマ起動）します。このため，送信要求元のMHPやSPPと，メッセージを編集して送信するMHPとは，別のグローバルトランザクションになります。送信要求元のMHPやSPPは，送信先の論理端末名称などの必要なデータをMCF経由で，メッセージを編集して送信するMHPに渡します。なお，タイマ起動の場合には，mcfadltapコマンドまたはdc_mcf_adltap関数で起動要求をキャンセルできます。

メッセージ送信の一元化を次の図に示します。

図3‒39　メッセージ送信の一元化

(4)　OpenTP1終了時のメッセージの扱い

(a)　未処理メッセージの監視

MCFは，終了処理の開始から出力キューのメッセージがなくなるまでの時間を監視します。出力キューのメッセージが処理されないで，終了処理に時間が掛かることを防止するためです。出力キューのメッセージがなくなるまでの監視時間を，未処理送信メッセージ滞留時間といいます。監視時間を超えても出力キューに残っているメッセージは廃棄し，未処理送信メッセージ廃棄イベント（ERREVTA）に対応するMCFイベント処理用MHPが作成してあれば，これを起動します。ただし，応答メッセージ，閉塞されている論理端末のメッセージおよびタイマ起動によるアプリケーション起動のメッセージの場合，未処理送信メッセージ滞留時間の対象にはなりません。システム終了時に滞留しているメッセージは無条件に削除されます。このとき，閉塞されている論理端末のメッセージおよびタイマ起動によるアプリケーション起動のメッセージの場合はERREVTAで通知しますが，応答メッセージの場合はERREVTAで通知されません。

また，MCFは終了処理の開始から入力キューのメッセージがなくなるまでの時間を監視します。MHPで異常な処理をしたために入力キューのメッセージが処理されないで，終了処理が終わらないことを防止するためです。また，正常終了時にサービスグループの閉塞によって滞留しているメッセージは破棄されERREVT2で通知されます。入力キューのメッセージがなくなるまでの監視時間を，未処理受信メッセージ滞留時間といいます。未処理受信メッセージ滞留時間を過ぎても，入力キューにメッセージが残っている場合には，MHPに何らかの異常があるものと見なして，MCFを異常終了させます。

未処理送信メッセージ滞留時間と未処理受信メッセージ滞留時間は，MCF通信構成定義で指定します。

(b)　OpenTP1の終了モードと未処理メッセージの監視との関係

OpenTP1の終了モードには，正常終了，強制正常終了，計画停止A，計画停止B，および強制停止があります。

正常終了および強制正常終了のときには，新たなメッセージの受け付けを禁止したあと，未処理受信メッセージ滞留時間と未処理送信メッセージ滞留時間を監視して，入力キューと出力キューのメッセージがなくなるまで処理を続けます。

計画停止Aのときには，新たなメッセージの受け付けを禁止したあと，入力キューのメッセージがなくなるまで処理を続けます。出力キューにメッセージが残っていても終了します。出力キューに残ったメッセージは，次回の再開始時に処理します。ただし，メモリ出力キューのメッセージ，およびMCF通信構成定義のmcftpsvrコマンドの-oオプションにreruntm=noを指定している場合のタイマ起動要求のメッセージは回復できません。計画停止Aのときには，未処理受信メッセージ滞留時間だけを監視します。

計画停止Bのときには，OpenTP1が現在実行しているサービスだけを完了させて終了します。入力キューや出力キューのメッセージは処理されないままになるため，未処理メッセージの滞留時間を監視しません。入出力キューに残ったメッセージは，次回の再開始時に処理します。ただし，メモリキューのメッセージ，およびMCF通信構成定義のmcftpsvrコマンドの-oオプションにreruntm=noを指定している場合のタイマ起動要求のメッセージは回復できません。

強制停止のときには，OpenTP1が現在実行しているサービスの完了を待たないで終了します。未処理メッセージの滞留時間も監視しません。入出力キューに残ったメッセージは，次回の再開始時に処理します。ただし，メモリキューのメッセージ，およびMCF通信構成定義のmcftpsvrコマンドの-oオプションにreruntm=noを指定している場合のタイマ起動要求のメッセージは回復できません。

相手システムにメッセージを送信したあとに，自システムがオンラインダウン，または強制停止し，送信済みのメッセージが送信完了扱いとならない場合，再開始後に再度，メッセージが送信されることがあります。そのため，相手システムとの間で，二重送信の扱いについて考慮する必要があります。

OpenTP1の終了と入出力キューのメッセージに対する処理を次の表に示します。

表3‒10　OpenTP1の終了と入出力キューのメッセージに対する処理

終了モード

入力キュー中のメッセージ

出力キュー中のメッセージ

正常終了，強制正常終了

すべて処理する

すべて処理する

計画停止A

すべて処理する

残す

計画停止B

残す

残す

強制停止

残す

残す

(5)　メッセージ出力通番

OpenTP1は，UAPからの送信メッセージに対して，メッセージ種別（問合せ応答メッセージ，一般分岐メッセージ，および優先分岐メッセージ）ごとに一連の番号を付けられます。この一連の番号をメッセージ出力通番（出力通番）と呼びます。

出力通番の目的は次のとおりです。

メッセージログやジャーナルの出力通番を確認して，システム障害時または通信障害時のメッセージの送信抜けや二重の送信を知ることができます。

メッセージを再送するときのキーにできます。

dc_mcf_send関数またはdc_mcf_reply関数を呼び出すときに，出力通番を付けるかどうかを指定できます。出力通番を付ける指定をしたdc_mcf_send関数またはdc_mcf_reply関数を呼び出した場合，OpenTP1はメッセージに出力通番を付けたあと，メッセージを出力キューに書き込みます。

また，UAPに送信メッセージの通番編集UOCを組み込んだ場合，出力通番を付ける指定をしたdc_mcf_send関数またはdc_mcf_reply関数の先頭セグメントの送信時に，OpenTP1は送信メッセージの通番編集UOCを呼び出します。このUOCでは，先頭セグメントの任意の位置に出力通番を設定するなどの処理ができます。

出力通番は，OpenTP1の再開始時に引き継がれます。

出力キュー内の先頭と最後の未送信メッセージに付けられている出力通番は，mcftlsleコマンドで表示できます。

3.3.10　メッセージを送信する順序とアプリケーションを起動する順序

OpenTP1では，相手システムへのメッセージの送信とdc_mcf_execap関数によるアプリケーションの起動を次のようにスケジュールします。

(1)　論理端末にメッセージを送信する順序

OpenTP1では，コネクションで接続されている論理端末間で，先入れ先出し（FIFO）とメッセージの優先度に従って送信しています。

一つのメッセージが複数のセグメントから構成される場合，各セグメントを連続して送信します。一つのメッセージを送信後，次のメッセージを論理端末に送信します。複数のUAPからの送信要求に対する処理順序を関数の呼び出し順とするかコミット順とするかは，UAP共通定義（mcfmuap -c）のorderオペランドで指定します。論理端末への送信順序を次の図に示します。

図3‒40　論理端末への送信順序

(2)　メッセージの種類と送信優先度の関係

UAPが送信するメッセージの種類によって，優先度が異なります。一つの論理端末に対して異なる種類のメッセージが送信待ちの場合，優先度の高いものから先に送信します。同じ種類のメッセージの場合は，FIFOで順次送信します。

メッセージ種別ごとの送信優先度を次の表に示します。

表3‒11　メッセージ種別ごとの送信優先度

メッセージ種別

送信優先度

応答メッセージ

高

一方送信メッセージ（優先）

中

一方送信メッセージ（一般）／問い合わせメッセージ

低

OpenTP1では，FIFOによる送信順序と，送信優先度による送信順序とを組み合わせて送信しています。FIFOと送信優先度の組み合わせ送信順序を次の図に示します。

図3‒41　FIFOと送信優先度の組み合わせ送信順序

(3)　dc_mcf_execap関数でアプリケーションを起動する順序

複数のUAPからのdc_mcf_execap関数に対する処理順序を関数の呼び出し順とするかコミット順とするかは，UAP共通定義（mcfmuap -c）のorderオペランドで指定します。アプリケーションの起動順序を次の図に示します。

図3‒42　アプリケーションの起動順序

3.3.11　オンライン中のMCF通信サービスの部分入れ替え

次の通信プロトコル対応製品を使用する場合，OpenTP1を停止しないでMCF通信サービスのメイン関数，UOC，およびライブラリを変更できます。

TP1/NET/TCP/IP

TP1/NET/SLU - TypeP2

TP1/NET/OSAS-NIF

OpenTP1を停止しないでMCF通信サービスのメイン関数，UOC，およびライブラリを変更するには，変更対象のMCF通信サービスだけを部分的に停止し，該当ファイルを入れ替えます。この方法を利用すると，変更対象のMCF通信サービス以外を停止させることなく変更できるので，システムの連続運転が可能になります。入れ替えられるファイルは次のファイルです。

MCF通信サービスのロードモジュール（メイン関数）

MCF通信サービスが使用しているユーザ作成のライブラリ（UOC）

対象の通信プロトコル製品が提供しているライブラリ

MCF通信サービスを部分的に入れ替えるには，MCF通信サービス管理の運用コマンド（mcftlscom，mcftstart，mcftstop）を使用します。これらの運用コマンドの詳細については，マニュアル「OpenTP1 運用と操作」を参照してください。

3.3.12　MCF構成変更再開始機能

OpenTP1の再開始は，前回のオンライン時のシステムの構成要素と再開始時のシステムの構成要素とが同一であることを前提としています。このため，オフライン中にOpenTP1のシステム定義やOpenTP1ファイルシステムを変更してオンラインを再開始した場合，OpenTP1が正常に開始できないことがあります。

MCF構成変更再開始機能は，前回のオンライン停止時に入力キュー（ディスクキュー）上に残っていた未処理受信メッセージおよび出力キュー（ディスクキュー）上に残っていた未送信メッセージを次回のオンラインに引き継ぎつつ，OpenTP1ファイルシステムやキューグループの構成変更，および論理端末やアプリケーションの構成変更をできるようにする機能です。

MCF構成変更再開始機能を使用するためには，TP1/Message Control - Extension 1が必要です。

また，通信プロトコル製品には次のどちらかを使用できます。

TP1/NET/TCP/IP

TP1/NET/XMAP3

MCF構成変更再開始機能を使用する場合，システム構成を変更するモード（MCF構成変更準備停止）でOpenTP1を停止します。システム停止後，システムの構成変更を実施し，構成変更が反映されるモード（MCF構成変更再開始）でオンラインシステムを再開始します。

MCF構成変更準備停止によるオンライン終了時に，未処理受信メッセージおよび未送信メッセージがディスクキューの入出力キュー上に残っている場合，未処理受信メッセージおよび未送信メッセージをキューから取り出し，MCF構成変更準備停止時のバックアップファイルに格納します。

MCF構成変更再開始が行われたときに，自動的にMCF構成変更準備停止時のバックアップファイルから元々格納されていたキューに未処理受信メッセージおよび未送信メッセージをリストアします。

MCF構成変更再開始機能使用時の流れを次の図に示します。

図3‒43　MCF構成変更再開始機能使用時の流れ

MCF構成変更再開始機能の詳細については，マニュアル「OpenTP1 運用と操作」を参照してください。

3.4　アプリケーションプログラムのスケジュール

SPP，またはMHPへのサービス要求を効率良く処理するため，スケジュールとプロセスを制御する機能をスケジュール機能といいます。

3.4.1　SPPのスケジュール

(1)　SPPのスケジュールの方法

OpenTP1は，SPPのサービスグループごとにスケジュールキューを作成してスケジュールします。クライアントUAPがRPCで指定したサービスグループ名とサービス名を基に，SPPへのサービス要求をスケジュールキューに登録します。登録したサービス要求は，先入れ先出しでスケジュールキューから取り出します。

クライアントUAPが指定したSPPのサービスグループが，ほかのノードにある場合でも，スケジュールできます。

SPPのスケジュールを次の図に示します。

図3‒44　SPPのスケジュール

(2)　サービス要求のスケジュールプライオリティの設定

クライアントUAPからのサービス要求に，優先順位（スケジュールプライオリティ）を付けられます。サービス要求のスケジュールプライオリティは，クライアントUAPでRPCを使う直前に，dc_rpc_set_service_prio関数で宣言します。ここで宣言したスケジュールプライオリティに従って，サーバUAP側のスケジュールサービスでスケジュールします。

クライアントUAPのスケジュールプライオリティの指定に従うかどうかは，サーバUAP側のユーザサービス定義で指定します。

(3)　SPPのスケジュールの閉塞

サービス実行中のSPPが異常終了したときに，SPPのスケジュールを閉塞するかどうかをユーザサービス定義に指定します。

SPPのスケジュールの閉塞を次の図に示します。

図3‒45　SPPのスケジュールの閉塞

(a)　スケジュールを閉塞する単位

スケジュールを閉塞する単位として，サービスグループ単位，サービス単位のどちらかを指定します。サービスグループ単位で閉塞すると指定した場合は，異常終了したサービスがあるSPPをすぐに閉塞します。サービス単位で閉塞すると指定した場合は，該当のサービスのスケジュールだけを閉塞して，同じサービスグループに属するほかのサービスのスケジュールは閉塞しません。

(b)　SPPの異常終了時の処理

SPPのUAPプロセスが異常終了したときに閉塞すると指定した場合は，そのサービスのスケジュールを閉塞します。閉塞されたサービスにサービス要求が来た場合，サービス要求元のクライアントUAPにエラーリターンします。また，サービスを閉塞した時点ですでにスケジュールキューに入っていたサービス要求も，サービス要求元のクライアントUAPにエラーリターンします。

SPPのUAPプロセスが異常終了したときに閉塞しないと指定した場合は，閉塞しないでスケジュールを続けます。ただし，ユーザサービス定義に指定した時間内に3回以上異常終了した場合は，そのSPPをサービスグループ単位またはサービス単位で閉塞します。

(c)　SPPの閉塞を解除する方法

SPPの閉塞を解除して再開始するときは，scdrlesコマンドを実行します。

(d)　再開始時の閉塞状態の扱い

オンライン停止後の全面回復時に，SPPの閉塞状態を引き継ぐかどうかを，SPPごとにユーザサービス定義で指定します。オンライン停止時に閉塞状態だったSPPのうち，閉塞状態を引き継ぐ指定をしたSPPは，全面回復後も閉塞状態で再開始されます。閉塞しているSPPにサービスを要求しても，サービス要求元にエラーリターンされます。

閉塞状態を引き継がないと指定したSPPは，閉塞が解除された状態で再開始されて，要求されたサービスを実行します。

(e)　コマンドによる閉塞

scdholdコマンドとscdrlesコマンドで，SPPをサービスグループ単位，またはサービス単位で閉塞/閉塞解除できます。

SPPの実行形式ファイルをオンライン中に入れ替える場合は，サービスグループ単位で閉塞します。そして閉塞済みのSPPを新しいSPPと入れ替えます。入れ替えが完了してから，scdrlesコマンドで閉塞を解除すれば，新しいSPPを実行できます。

このように，コマンドで閉塞/閉塞解除することで，オンライン中にSPPを変更したり修正したりできます。

scdholdコマンドに指定するサーバ名に，-pオプションを付けて指定する（scdhold -s サーバ名 -p）と，SPPを閉塞したあとでも，該当するSPPへのサービス要求を受け付けられます。受け付けたサービス要求は，スケジュールキューに保持されます。該当するSPPがサービスを処理できる状態になったら，保持していたサービス要求のスケジュールを再開します。

サービス要求を保持できるのは，UAPのサービスグループ単位で閉塞する場合だけです。サービス単位で閉塞する場合は，コマンドの引数にサービス要求を保持する指定はできません。

スケジュールキューにサービス要求を保持する閉塞を次の図に示します。

図3‒46　スケジュールキューにサービス要求を保持する閉塞

(4)　ソケット受信型サーバ

この機能は廃止したため使用できません。廃止した製品のバージョンについては，「はじめに」を参照してください。

(5)　サービス単位のスケジュール制御

ユーザサービス定義またはユーザサービスデフォルト定義にscdsvcdef定義コマンドを指定することで，SPPのスケジュールキューに対してサービス単位のスケジュール制御ができます。指定できるスケジュール制御は次のとおりです。なお，scdsvcdef定義コマンドの詳細については，マニュアル「OpenTP1 システム定義」を参照してください。

サービスごとに同時実行可能なサービス数を指定する。

サービスごとにキューイング可能なサービス要求数を指定する。

サービスごとにキューイング可能なメッセージ格納バッファプール長を指定する。

(a)　サービスごとに同時実行可能なサービス数を指定する

該当サービスを処理しているサーバプロセス数が，scdsvcdef定義コマンドで指定した同時実行可能なサービス数に達している場合，同時実行可能なサービス数に達していないサービスへのサービス要求を，登録順およびスケジュールプライオリティに関係なくスケジュールします。

スケジュールキューに登録されているすべてのサービス要求が，同時実行可能なサービス数に達しているサービスへのサービス要求であった場合，実行中のサービス処理が終了するのを待ち合わせます。サービスごとの同時実行可能なサービス数を次の図に示します。

図3‒47　サービスごとの同時実行可能なサービス数

scdsvcdef定義コマンドの-cオプション，および-pオプションに次のように指定して，サービスSV1およびサービスSV2の同時実行可能なサービス数を1に指定します。

scdsvcdef -c SV1 -p 1
scdsvcdef -c SV2 -p 1

1.でサービスの同時実行数を指定しているため，指定を超えたサービス要求は，スケジュールキューで待ち合わせます。

(b)　サービスごとにキューイング可能なサービス要求数を指定する

該当サービスへのサービス要求数が，scdsvcdef定義コマンドで指定したキューイング可能なサービス要求数に達している場合，スケジュールキューへは登録しないで，ほかのOpenTP1ノードへの再スケジュールを試みます。

再スケジュールできない場合には，サービス要求元にメッセージ格納バッファ不足としてエラーリターンします。サービスごとのキューイング可能なサービス要求数を次の図に示します。

図3‒48　サービスごとのキューイング可能なサービス要求数

scdsvcdef定義コマンドの-cオプション，および-nオプションに次のように指定して，サービスSV1のキューイング可能なサービス要求数を2に，サービスSV2のキューイング可能なサービス要求数を1に指定します。

scdsvcdef -c SV1 -n 2
scdsvcdef -c SV2 -n 1

1.でサービスのキューイング可能なサービス要求数を指定しているため，指定を超えたサービス要求はキューイングできません。

(c)　サービスごとにキューイング可能なメッセージ格納バッファプール長を指定する

該当サービスへのサービス要求のメッセージ格納バッファプール長が，scdsvcdef定義コマンドで指定したキューイング可能なメッセージ格納バッファプール長に達している場合，スケジュールキューへは登録しないで，ほかのOpenTP1ノードへの再スケジュールを試みます。

再スケジュールできない場合には，サービス要求元にメッセージ格納バッファ不足としてエラーリターンします。サービスごとのキューイング可能なメッセージ格納バッファプール長を次の図に示します。

図3‒49　サービスごとのキューイング可能なメッセージ格納バッファプール長

scdsvcdef定義コマンドの-cオプション，および-lオプションに次のように指定して，サービスSV1のキューイング可能なメッセージ格納バッファプール長を2048に，サービスSV2のキューイング可能なメッセージ格納バッファプール長を1024に指定します。

scdsvcdef -c SV1 -l 2048
scdsvcdef -c SV2 -l 1024

1.でサービスのキューイング可能なメッセージ格納バッファプール長を指定しているため，指定を超えたサービス要求はキューイングできません。

(6)　スケジュール対象の選択

ノード間負荷バランス機能が使用できる環境で，クライアントからのサービス要求をどのノードのサーバUAPにスケジューリングするかは，各ノードのサーバUAPの状態によって判断します。次に示した状態のサーバUAPはスケジューリングの対象外となります。ただし，通信先を指定（ノード識別子指定）したRPCの場合は該当しません。

正常停止した（または未起動）

閉塞している

負荷レベルがLEVEL2※

注※

負荷レベルがLEVEL2のサーバUAPでも，そのほかのサーバUAPの状態が停止や閉塞の状態，またはすべてのサーバUAPの負荷レベルがLEVEL2の場合は，負荷レベルがLEVEL2のサーバUAPもスケジュール対象となります。

3.4.2　MHPのスケジュール

(1)　MHPのスケジュールの方法

OpenTP1は，MHPのサービスグループ単位にスケジュールキューを作成してスケジュールします。まず，MCFはメッセージに組み込まれたアプリケーション名をサービスグループ名とサービス名に変換し，受信メッセージを入力キューに登録します。アプリケーション名と，サービスグループ名・サービス名の対応は，アプリケーション属性定義で指定します。MCFは，入力キューに受信メッセージの最終セグメントを格納した時点で，変換されたサービスグループ名とサービス名を基に，MHPへのサービス要求をスケジュールキューに登録します。登録したサービス要求は，スケジュールキューから先入れ先出しで取り出します。

MHPのサービスグループが，メッセージを受信したMCFと同じノードにないとスケジュールできません。

MHPのスケジュールを次の図に示します。

図3‒50　MHPのスケジュール

(2)　MHPのスケジュールの閉塞

(a)　OpenTP1のコマンドによる閉塞

コマンドでMHPのアプリケーション名を指定して，対応するアプリケーションを閉塞できます。MHPを閉塞，閉塞を解除するコマンドを次に示します。

閉塞するコマンド

mcfadctapコマンド：アプリケーション単位の閉塞

mcftdctsgコマンド：サービスグループ単位の閉塞

mcftdctsvコマンド：サービス単位の閉塞

閉塞を解除するコマンド

mcfaactapコマンド：アプリケーション単位の閉塞の解除

mcftactsgコマンド：サービスグループ単位の閉塞の解除

mcftactsvコマンド：サービス単位の閉塞の解除

コマンドを入力してMHPを閉塞した場合のMHPの閉塞状態は，オンラインシステム停止後の全面回復時に引き継げます。閉塞状態を引き継ぐかどうかを，状態引き継ぎ定義で指定します。なお，mcftdctsgコマンドでサービスグループを閉塞するとき，閉塞状態を引き継がない指定ができます。この場合，全面回復時にmcftactsgコマンドで閉塞を解除する必要はありません。

アプリケーション単位の閉塞

MHPをアプリケーション名単位で閉塞するときは，mcfadctapコマンドを使います。コマンドの引数によって，次に示す3種類の閉塞を選べます。

MHPのアプリケーション名による閉塞を次の表に示します。

表3‒12　MHPのアプリケーション名による閉塞

閉塞種別

タイミング

閉塞したあとに到着したメッセージに対する処理

閉塞する前に到着してすでに入力キューに登録されているメッセージに対する処理

入力とスケジュールを閉塞

MCFイベント処理用MHP（ERREVT2）対応の入力キューに登録します。

MCFイベント処理用MHP（ERREVT2）対応の入力キューに登録し直します。

入力だけを閉塞

MCFイベント処理用MHP（ERREVT2）対応の入力キューに登録します。

該当するMHPを正常に起動します。

スケジュールだけを閉塞

MCFイベント処理用MHP（ERREVT2）対応の入力キューに登録します。

MCFイベント処理用MHP（ERREVT2）対応の入力キューに登録し直します。

サービス名に対応するアプリケーション名を，プロトコルごとに付けることができます。プロトコルごとにアプリケーション名を変えておくと，アプリケーション名によって閉塞することで，特定のプロトコルからのサービス要求だけを拒否できます。

アプリケーション名による閉塞を次の図に示します。

図3‒51　アプリケーション名による閉塞

サービス単位の閉塞

MHPをサービス単位で閉塞するときは，mcftdctsvコマンドを使います。コマンドの引数によって，次に示す3種類の閉塞を選べます。あるサービスを閉塞しても，同じMHPのサービスグループにあるほかのサービスは使えます。

MHPのサービスを閉塞する方法を次の表に示します。

表3‒13　MHPのサービスの閉塞

閉塞種別

タイミング

閉塞したあとに到着したメッセージに対する処理

閉塞する前に到着してすでに入力キューに登録したメッセージに対する処理

入力とスケジュールを閉塞

MCFイベント処理用MHP（ERREVT2）対応の入力キューに登録します。

MCFイベント処理用MHP（ERREVT2）対応の入力キューに登録し直します。

入力だけを閉塞

MCFイベント処理用MHP（ERREVT2）対応の入力キューに登録します。

該当するMHPを正常に起動します。

スケジュールだけを閉塞

MCFイベント処理用MHP（ERREVT2）対応の入力キューに登録します。

MCFイベント処理用MHP（ERREVT2）対応の入力キューに登録し直します。

サービスグループ単位の閉塞

MHPをサービスグループ単位で閉塞するときは，mcftdctsgコマンドを使います。コマンドの引数によって，次に示す3種類の閉塞を選べます。さらに，入力キューがディスクキューかメモリキューかによって，一部の処理が異なります。

MHPのサービスグループの閉塞を次の表に示します。

表3‒14　MHPのサービスグループの閉塞

閉塞種別

タイミング

閉塞したあとに到着したメッセージに対する処理

閉塞する前に到着してすでに入力キューに登録されているメッセージに対する処理

ディスク入力キュー

入力とスケジュールを閉塞

MCFイベント処理用MHP（ERREVT2）対応の入力キューに登録します。

スケジュール待ち状態にし，閉塞解除後に該当するMHPを正常に起動します。

入力だけを閉塞

MCFイベント処理用MHP（ERREVT2）対応の入力キューに登録します。

該当するMHPを正常に起動します。

スケジュールだけを閉塞

入力キューに登録し，スケジュール待ち状態にします。※

スケジュール待ち状態にし，閉塞解除後に該当するMHPを正常に起動します。

メモリ入力キュー

入力とスケジュールを閉塞

MCFイベント処理用MHP（ERREVT2）対応の入力キューに登録します。

MCFイベント処理用MHP（ERREVT2）対応の入力キューに登録し直します。

入力だけを閉塞

MCFイベント処理用MHP（ERREVT2）対応の入力キューに登録します。

該当するMHPを正常に起動します。

スケジュールだけを閉塞

MCFイベント処理用MHP（ERREVT2）対応の入力キューに登録します。

MCFイベント処理用MHP（ERREVT2）対応の入力キューに登録し直します。

注※

ディスク入力キューに登録されたメッセージの数が最大格納数を超えたときには，格納数を超えた分のメッセージは，MCFイベント処理用MHP（ERREVT2）対応の入力キューに登録します。

(b)　異常終了による自動閉塞

MHPがサービスを実行中に異常終了したときの閉塞単位をアプリケーション属性定義で指定すると，異常終了したときに，定義した単位で自動的に閉塞できます。

アプリケーション単位で閉塞するには，アプリケーション属性定義のapliholdにアプリケーション単位で閉塞する指定をします。

サービス単位で閉塞するには，アプリケーション属性定義のservholdにサービス単位で閉塞する指定をします。

サービスグループ単位で閉塞するには，アプリケーション属性定義のsrvgholdにサービスグループ単位で閉塞する指定をします。

また，異常終了した回数によって，アプリケーション，サービスまたはサービスグループを閉塞するかどうかを，アプリケーション属性定義で指定します。このとき，連続して異常終了した回数を数えるか，または異常終了した回数の合計を数えるかのどちらかを選択します。異常終了した回数には，MHPからdc_mcf_rollback関数（ノーリターン指定）でロールバックした回数も含めます。ロールバックの関数については，マニュアル「OpenTP1 プログラム作成の手引」を参照してください。

サービスグループ単位でスケジュールだけを閉塞する場合，MHPがサービスを実行中に異常終了したときの受信メッセージを，エラーイベントに切り替えるか，スケジュールキューの先頭に再スケジュールするかを指定できます。スケジュールキューの先頭に再スケジュールするには，アプリケーション属性定義のrecvmsgにrを指定します。

異常終了による自動閉塞でのMHPの閉塞状態は，オンラインシステム停止後の全面回復時に引き継ぎません。

アプリケーション属性定義のaplihold，servholdまたはsrvgholdに，異常終了した場合に閉塞しない指定をした場合には，アプリケーション，サービスまたはサービスグループを閉塞しません。この場合，異常終了が続くときには，コマンドを使って，アプリケーション，サービスまたはサービスグループを閉塞してください。

(c)　MHPの再スケジュール

トランザクション処理を実行しているMHPは，障害発生時に再スケジュールできます。

MCFは，次に示す場合にMHPを再スケジュールします。

MHPからdc_mcf_rollback関数（RETRY指定）でロールバックした場合

アプリケーション属性定義（mcfaalcap）またはUAP共通定義（mcfmuap）のreschedulecntオペランドの指定値が1以上の場合に，MHPがサービス実行中に異常終了してロールバックしたとき

MHPの再スケジュール時の処理の流れを，次の図に示します。

図3‒52　MHPの再スケジュールの処理の流れ

異常終了したMHPを再スケジュールする場合，アプリケーション属性定義（mcfaalcap）またはUAP共通定義（mcfmuap）の次のオペランドで，再スケジュールの回数や間隔などを指定できます。

reschedulecntオペランド

rescheduleintオペランド

reschedulelogオペランド

指定した回数を超えてMHPが異常終了すると，再スケジュールされません。KFCA11163-Eメッセージが出力され，エラーイベントが通知されます。

なお，MHPからdc_mcf_rollback関数（RETRY指定）でロールバックした場合やMHPが異常終了した場合に，MHPを再スケジュールすると，アプリケーション，サービス，またはサービスグループの自動閉塞で使用する，MHPが連続して異常終了した回数には含まれません。

MHPを再スケジュールする場合，受信メッセージを入力キューに再度格納する際に，先頭に格納するか最後に格納するかを選択できます。

先頭に格納する場合の注意事項を次に示します。

システム共通定義のwatch_timeオペランドを省略するか，180以上を指定してください。

プロセスサービス定義のprc_recovery_residentオペランドを省略するか，Yを指定してください。

MHPのユーザサービス定義またはユーザサービスデフォルト定義のscd_process_ctl_optオペランドに1を指定してください。

アプリケーション起動プロセスがなくても，MHPの再スケジュールができます。

ただし，アプリケーション異常終了時の再スケジュール回数（アプリケーション属性定義（mcfaalcap -d）のreschedulecntオペランドまたはUAP共通定義（mcfmuap -r）のreschedulecntオペランド）の指定値に1以上を指定していて，指定値を超えて異常終了したあとにエラーイベントを起動したい場合には，アプリケーション起動プロセスが必要となります。

MHPの多重度が1の場合，MHPの再スケジュールをしたときにあとから受信したメッセージが前に受信したメッセージを追い越すことはありません。このため，繰り返しMHPの再スケジュールをする場合，エラーが解消されて正常に処理されるなどにより再スケジュールをしなくなるまで後続のメッセージを処理できませんので注意してください。

最後に格納する場合の注意事項を次に示します。

MHPを再スケジュールするためには，アプリケーション起動プロセスが必要です。このため，アプリケーション起動プロセス用のMCF通信構成定義を作成する必要があります。

受信メッセージを，入力キューに再度格納してから再スケジュールします。このため，MHPの多重度を1にしていたとしても，再スケジュールするメッセージよりもあとに受信したメッセージが，再スケジュールするメッセージを追い越すことがあります。

何らかの理由によってMHPの再スケジュールに失敗した場合，受信メッセージを破棄します。このとき，エラーイベントは通知されません。

MHPのサービス実行中にエラーが発生して繰り返しMHPの再スケジュールをしているときに，OpenTP1を正常終了，強制正常終了または計画停止Aで終了した場合，エラーが解消されて正常に処理されるなどにより再スケジュールをしなくなるまでOpenTP1の終了処理を待ち合わせます。

このため，MHPを停止するまで回復の見込みがない障害に対して無条件にRETRY指定のロールバックをしないでください。

また，MHPのサービス実行中にエラーが発生して繰り返しMHPの再スケジュールをしているときに，OpenTP1を正常終了，強制正常終了または計画停止Aで終了してしまい，MHPを停止するまで回復の見込みがない場合，OpenTP1を強制停止してください。

(d)　アプリケーション名とMHPの不整合による自動閉塞

MCFはMHPのスケジュール時に，アプリケーション属性定義で指定したアプリケーション名に対応するサービスグループがあるかどうかをチェックします。アプリケーション名に対応するサービスグループがない場合，該当するサービスグループが存在しないというメッセージログを出力して，サービスグループへのスケジュールだけを閉塞します。

アプリケーション名とMHPの不整合による自動閉塞でのMHPの閉塞状態は，オンラインシステム停止後の全面回復時に引き継ぎません。

3.4.3　プロセスの制御

OpenTP1のシステムサービス，またはユーザサーバ（UAP）を実行するときには，OSの作業領域を使います。この作業領域の処理をプロセスといいます。ユーザサーバの実行によって生成されるプロセスを特にユーザサーバプロセス，UAPプロセス，または単にプロセスといいます。

OpenTP1では，システムサービスとユーザサーバのプロセスが必要以上に増えたり減ったりしないように，プロセスサービス定義の指定に従って，使うプロセスの総数を制御しています。

ユーザサーバプロセスを制御するには，ユーザサーバを事前に開始していることが前提です。OpenTP1と一緒に開始させておくか，dcsvstart -uコマンドで開始させておきます。

(1)　マルチサーバ

実行中のユーザサーバに対して，さらにサービス要求が来た場合でも，ユーザサーバの処理を新しい別のプロセスで実行できます。このように，一つのユーザサーバの処理を，別のプロセスで並行して実行する機能をマルチサーバといいます。

マルチサーバを使えるのは，スケジュールキューを使うSPP（キュー受信型サーバ），およびMHPです。ソケット受信型サーバの場合はマルチサーバを使えません。ソケット受信型サーバには，使うプロセスは一つだけと，ユーザサービス定義で指定してください。

(2)　常駐プロセスと非常駐プロセス

ユーザサービス定義でマルチサーバを指定したUAPのプロセスを，OpenTP1の稼働中にいつも確保しておくことも，動的に確保することもできます。いつも確保されているプロセスを常駐プロセスといいます。また，稼働中には確保されていなくて，必要に応じて起動されるプロセスを非常駐プロセスといいます。

マルチサーバを使う場合，使うプロセスの最大値をユーザサービス定義で設定しておきます。常駐プロセスを複数個指定していれば，指定した数だけ並行してプロセスが起動されます。また，非常駐プロセスを複数個指定していれば，指定した数だけ動的にプロセスが起動されます。

プロセスを非常駐プロセスと設定しておくと，OpenTP1システム内のメモリ領域を効率良く使えます。また，プロセスを常駐プロセスと設定しておくと，そのユーザサーバの処理は非常駐プロセスに比べて速くなります。

システムのメモリに空きがない場合，非常駐プロセスは稼働中の非常駐プロセスが終了してから実行されます。

プロセスを常駐とするか非常駐とするかは，ユーザサービス定義でユーザサーバの起動プロセス数を事前に指定しておきます。

(3)　マルチサーバ負荷バランス機能

スケジュールキューにあるサービスの要求数に応じて，非常駐プロセスの数を増やしたり減らしたりする機能をマルチサーバ負荷バランス機能といいます。

非常駐プロセスをいつ起動するかは，ユーザサービス定義のbalance_countオペランドに指定する値で決まります。（balance_countオペランドに指定した値　×　起動中のプロセス）の数を超えてサービス要求が滞留したときに，OpenTP1は非常駐プロセスを起動します。スケジュールキューに滞留しているサービス要求の数が0になると，OpenTP1は非常駐プロセス数分のプロセスをランダムに終了させます。

常駐/非常駐プロセスによるマルチサーバの概要を次の図に示します。

図3‒53　常駐/非常駐プロセスによるマルチサーバの概要

(4)　スケジュールの優先度

一つ一つのユーザサーバには，ユーザサービス定義でスケジュールの優先度（スケジュールプライオリティ）を付けることができます。優先度が高いユーザサーバの非常駐プロセスは，ほかの非常駐プロセスに比べて優先的にスケジュールされます。

スケジュールの優先度の概要を次の図に示します。

図3‒54　スケジュールの優先度の概要

(5)　非常駐UAPプロセスのリフレッシュ機能

非常駐プロセスを使用する場合，一つのサービス要求ごとに実行プロセスを起動し直すことができます。この機能を，非常駐UAPプロセスのリフレッシュ機能といいます。この機能を使用することで，リエントラント構造ではないUAPの実行もできるようになります。この機能は，非常駐プロセスだけで構成されるUAPの場合に使用できます。

この機能を使用するためには，ユーザサービス定義またはユーザサービスデフォルト定義に，scd_refresh_processオペランドを指定します。また，この機能は1プロセスが処理するサービス要求数（ユーザサービス定義のbalance_countオペランドの指定値）が0の場合にだけ使用できます。

非常駐UAPプロセスのリフレッシュ機能の詳細については，マニュアル「OpenTP1 プログラム作成の手引」を参照してください。

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

SPPに要求されたサービスの処理に多くのプロセスが必要な場合，他ノードにある同じサービスグループ名のSPPに処理を分担できます。この機能をノード間負荷バランス機能といいます。ノード間負荷バランス機能を使用するためには，負荷分散の前提として次の条件を満たしている必要があります。

一つのLANの中で，複数のノードに同一のサービスを提供するユーザサーバが起動されていること。

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

サービス要求は，任意に選ばれたノードのユーザサーバに渡されます。さらに，OpenTP1では，スケジュールするノードのサーバ情報を参照して，スケジュール性能が低くなっているノードは選ばれにくいように制御しています。そのため，自ノードにユーザサーバがあり，スケジュールできる状態でも，自ノードのユーザサーバに渡されるとは限りません。自ノードのユーザサーバを優先するには，スケジュールサービス定義のscd_this_node_firstオペランドにYを指定します。これによって，自ノードのユーザサーバのスケジュール性能が低いときだけ，ほかのノードのユーザサーバにスケジュールできます。

ノード間負荷バランス機能は，ノード間でユーザサーバの動作条件が同じであることを前提としています。選択されるノードによって次に示す条件が大きく異なる場合は，ノード間負荷バランス機能に不適当な環境ですので，同じ名前のサービスグループを複数のノードに配置しないでください。

公衆回線の回線料金などの運用コスト

回線速度

回線品質

ノードの単体性能

ユーザサーバにスケジュールするときに参照するサーバ情報は，各ノードから通知されます。同じサービスグループ名のSPPが複数のノードにないシステムでは，サーバ情報を通知する必要がなく，むだな通信となります。特に，公衆回線を使用する場合，不要な回線料金が課金されます。したがって，同じサービスグループ名が複数のノードにないシステムでは，すべてのノードのスケジュールサービス定義のscd_announce_server_statusオペランドにNを指定して，サーバ情報の通知を抑止してください。

ノード間で負荷分散するSPPは，キュー受信型サーバでもソケット受信型サーバでもかまいません。ただし，ソケット受信型サーバの場合は，OpenTP1のスケジュール性能を参照する制御はしていません。

ノード間負荷バランス機能で負荷を分散できるノードの数は，最大128です。

ノード間負荷バランス機能の概要を次の図に示します。

図3‒55　ノード間負荷バランス機能の概要

サービス要求は各ノードの負荷レベルに応じて，スケジュールされます。次に示す負荷レベルがあります。

LEVEL0

小さい負荷です。通常，サービス要求はLEVEL0またはLEVEL1のノードにスケジュールされます。

LEVEL1

やや大きい負荷です。障害などによる再スケジュール時には，サービス要求はLEVEL1のノードにスケジュールされにくくなります。ただし，再スケジュール時にLEVEL1またはLEVEL2のノードしかない場合は，それらのノードにスケジュールされます。

LEVEL2

大きい負荷です。通常，サービス要求はLEVEL2のノードにスケジュールされません。ただし，LEVEL2のノードしかない場合は，LEVEL2のノードにスケジュールされます。

各ノードの負荷レベルは，負荷監視インタバルごとに監視されます。その際，今回の負荷レベルは，前回の負荷レベル，キューイング数，サービス要求滞留数，およびサーバ処理率によって決定されます。

負荷レベルの決定条件について次の表に示します。

表3‒15　負荷レベルの決定条件

前回の負荷レベル

キューイング数：Q

サービス要求滞留数：q

サーバ処理率：X

今回の負荷レベル

LEVEL0

Q ≧ 1

−

X ＜ 50

LEVEL1

LEVEL1

Q ≧ 1

−

75 ≦ X

LEVEL0

50 ≦ X ＜ 75

LEVEL1

X ＜ 50

LEVEL2

LEVEL2

−

q ＝ 0

−

LEVEL0

q ≧ 1

LEVEL2

（凡例）

−：無視します。

キューイング数

負荷監視インタバル間にスケジュールキューにキューイングされたサービス要求数です。

サービス要求滞留数

負荷監視時にスケジュールキューに滞留しているサービス要求数です。

サーバ処理率

次に示す計算式から算出される処理率です。

サーバ処理率＝（サービス処理数／（キューイング数＋サービス要求滞留数））×100

サービス処理数は，負荷監視インタバル間で処理したサービス要求数です。

負荷レベルに変更があった場合は，各ノードのネームサービスにサーバ情報が通知され，サーバ情報が更新されます。また，ユーザサービス定義のloadlevel_messageオペランドを使用すると，負荷レベルの変更を通知するメッセージを出力できます。

(7)　ノード間負荷バランス機能使用時の定義

ノード間負荷バランス機能を使用する場合のTP1/Server Base側，TP1/Client側の関連する定義と処理，およびRPCの処理を説明します。

(a)　サーバ側の判断で負荷分散を行う場合

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

サーバ（TP1/Server Base）側の定義

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

スケジュールサービス定義のオペランドに次の設定をする。

set scd_this_node_first = N （デフォルト）

set scd_announce_server_status = Y （デフォルト）

スケジュールサービス定義を省略する。

クライアント（TP1/Client）側の定義

クライアント環境定義に「dcscddirect=Y（TP1/Client/Pの場合）」を定義します。

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

この場合，スケジュールを依頼するOpenTP1ノードは，dchostオペランドに指定された順番にスケジュールを依頼します。dchostオペランドに書かれた順番ではなく，スケジュールを依頼するOpenTP1ノードをランダムに指定したい場合は，さらに「dchostselect=Y（TP1/Client/Pの場合）」を追加して定義する必要があります。

(b)　サーバからの負荷情報からクライアント側で判断する場合

クライアントがTP1/Clientのとき

サーバ（TP1/Server Base）側の定義

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

スケジュールサービス定義のオペランドに次の設定をする。

set scd_this_node_first = N （デフォルト）

set scd_announce_server_status = Y （デフォルト）

スケジュールサービス定義を省略する。

クライアント（TP1/Client）側の定義

クライアント環境定義で「dccltloadbalance = Y（TP1/Client/Pの場合）」を定義します。

これによって，TP1/Server Baseから得たサーバの負荷レベルを基に，TP1/Clientでサービス要求を行うOpenTP1ノードを決めてからRPCを行います。

この場合，dccltcachetimで指定された時間（秒）だけ，サーバの負荷レベルを含む情報を一時的にdccacheオペランドで指定された大きさの領域に保持します。つまり，dccltcachetimオペランドで指定した値を短くすることで，より新しいサーバの負荷レベルに基づいてRPCの要求先が決まるということになります。

その反面，負荷レベルの取得のために，頻繁にTP1/Server Baseのネームサービスとの通信が発生することを考慮する必要があります。

サーバ，クライアントともTP1/Server Baseのとき

サーバ側，およびクライアント側の両方に，次のどちらかの設定をする必要があります。

スケジュールサービス定義のオペランドに次の設定をする。

set scd_this_node_first = N （デフォルト）

set scd_announce_server_status = Y （デフォルト）

スケジュールサービス定義を省略する。

この形態では，TP1/Server Baseはこれから要求を出そうとしているサーバの負荷レベルをすでに知っているので，最初から負荷レベルが低いノードに対してRPCを行います。この要求を受け取った時点で，スケジュールサービスは，負荷レベルの評価による転送はしないで，自ノードで要求を処理できる状態であれば，自ノードで処理します。サーバが閉塞している場合，または自ノードのサーバの負荷レベルがLEVEL2で，他ノードに自ノードより負荷レベルの低いサーバがある場合だけ，ほかのノードに対して処理要求を転送します。

(c)　ノード間負荷バランス機能と別の機能を組み合わせた場合の動作

ノード間負荷バランス機能と別の機能を組み合わせた場合の動作を，次の表に示します。

表3‒16　ノード間負荷バランス機能と別機能を組み合わせた場合の動作

組み合わせる機能

動作

TP1/Clientで常設コネクションを使用した場合

TP1/Server BaseのCUP実行プロセスが，常設コネクションを張ったノードでRPCを行う。

(b)の「サーバ，クライアントともTP1/Server Baseのとき」と同じ動作になる。

TP1/Clientでトランザクション制御APIを使用した場合

TP1/Server BaseのトランザクショナルRPC実行プロセスがRPCを行う。

(b)の「サーバ，クライアントともTP1/Server Baseのとき」と同じ動作になる。

リモートAPI機能を使用した場合

TP1/Server BaseのrapサーバがRPCを行う。

(b)の「サーバ，クライアントともTP1/Server Baseのとき」と同じ動作になる。

(8)　ノード間負荷バランス拡張機能

ユーザは次に示す指定ができます。

LEVEL0のノードへのスケジュール比率の指定

スケジュールサービス定義のschedule_rateオペランドを指定することによって，LEVEL0のノードにスケジュールする比率（%）を指定できます。

TP1/Clientのクライアント環境定義のDCSCDDIRECTオペランドにYを指定してサービス要求をする場合だけschedule_rateオペランドは有効です。

ただし，スケジュールサービス定義のscd_this_node_firstにYを指定している場合には，自ノードに優先的にスケジュールされます。

次にschedule_rateオペランドに80を指定した場合のスケジュールについて説明します。サービス要求数は10とします。

スケジューラは，ネームサービスから全ノードの負荷情報を取得し，LEVEL0とLEVEL1のノード数をカウントします。

1.でカウントしたノード数をschedule_rateオペランドの指定数で重みづけして，LEVEL0のノードにスケジュールする比率を求めます。

LEVEL0：LEVEL1 ＝ 80×3：20×2 ≒ 85：15

2.で求めた比率でLEVEL0のノードの一つを選択して，サービス要求をスケジュールします。

LEVEL0のノードへのスケジュールについて次の図に示します。

図3‒56　LEVEL0のノードへのスケジュール

負荷監視インタバル時間の指定

ユーザサービス定義およびユーザサービスデフォルト定義のloadcheck_intervalオペランドを指定することによって，サービスグループごとに負荷監視インタバル時間を指定できます。負荷監視時に負荷レベルの変更があった場合は，各ノードのネームサービスにサーバ情報が通知されます。そのため，負荷監視インタバルごとにサーバ情報がネットワーク上に送信される可能性がありますので，必要以上に小さい値を指定しないでください。

loadcheck_intervalオペランドを指定しない場合の負荷監視インタバルは，30秒です。また，負荷監視の要否のチェックなどについて10秒のインタバルで実行されます。つまり，負荷監視の要否のチェックなどの3回目には，負荷監視が実行されます。

しかし，loadcheck_intervalオペランドを指定する場合，負荷監視インタバルはオペランドの指定値となり，負荷監視の要否のチェックなどについては，10と各ユーザサーバのloadcheck_intervalオペランドの指定値との最大公約数から求めたインタバルで実行されます。例えば，SPP1のloadcheck_intervalオペランドに3を，SPP2のloadcheck_intervalオペランドに5を指定する場合，10と3と5の最大公約数の1（秒）が負荷監視の要否のチェックなどを実行するインタバルとなります。負荷監視の要否のチェックなどの3回目には，SPP1の負荷監視が実行されます。5回目には，SPP2の負荷監視が実行されます。

そこで，システムに与える影響を少なくするために，loadcheck_intervalオペランドに指定する値は，5の倍数にすることをお勧めします。

loadcheck_intervalオペランドに0を指定することによって，負荷監視をサービスグループ単位で抑止できます。

負荷レベルのしきい値の指定

ユーザサービス定義およびユーザサービスデフォルト定義のlevelup_queue_countオペランドおよびleveldown_queue_countオペランドを次に示すとおりに指定することによって，サービスグループごとにサービス要求滞留数によって負荷レベルを決定するしきい値を指定できます。

set levelup_queue_count = U1,U2
set leveldown_queue_count = D0,D1

U1：サーバの負荷レベルがLEVEL1に上がったと判断するサービス要求滞留数

U2：サーバの負荷レベルがLEVEL2に上がったと判断するサービス要求滞留数

D0：サーバの負荷レベルがLEVEL0に下がったと判断するサービス要求滞留数

D1：サーバの負荷レベルがLEVEL1に下がったと判断するサービス要求滞留数

今回の負荷レベルは，前回の負荷レベル，およびサービス要求滞留数によって決定されます。

負荷レベルとサービス要求滞留数について次の表に示します。

表3‒17　負荷レベルとサービス要求滞留数

前回の負荷レベル

サービス要求滞留数：q

今回の負荷レベル

LEVEL0

q ＜ U1

LEVEL0

U1 ≦ q ＜ U2

LEVEL1

U2 ≦ q

LEVEL2

LEVEL1

q ≦ D0

LEVEL0

D0 ＜ q ＜ U2

LEVEL1

U2 ≦ q

LEVEL2

LEVEL2

q ≦ D0

LEVEL0

D0 ＜ q ≦ D1

LEVEL1

D1 ＜ q

LEVEL2

通信障害時のリトライ回数の指定

通常，サービス要求のスケジュール時に通信障害が発生すると，再スケジュールしないでエラーリターンします。

スケジュールサービス定義のscd_retry_of_comm_errorオペランドを指定することによって，通信障害が発生したノード以外へスケジュールするリトライ回数を指定できます。

ただし，scd_retry_of_comm_errorオペランドの指定値が，サービス要求の対象となるサービスグループが起動しているノード数を上回っている場合は，サービス要求の対象となるサービスグループが起動しているノード数をリトライ回数の上限値とします。

0を指定した場合には，リトライしません。

なお，この機能は，TP1/Extension 1をインストールしていることが前提です。TP1/Extension 1をインストールしていない場合の動作は保証できませんので，ご了承ください。

(9)　マルチスケジューラ機能

従来のスケジューラデーモン（これ以降マスタスケジューラデーモンといいます）とは別に，サービス要求受信専用デーモン（これ以降マルチスケジューラデーモンといいます）を複数プロセス起動し，サービス要求メッセージ受信処理を並行動作させることによって，受信処理の競合によるスケジューリング遅延を回避できます。この機能をマルチスケジューラ機能といいます。

マルチスケジューラ機能を使用するには，次の定義を指定する必要があります。

RPC受信側

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

ユーザサービス定義　scdmulti

RPC送信側

ユーザサービス定義　multi_schedule

また，幾つかのマルチスケジューラデーモンをキュー受信型サーバごとにグループ化できます。これによって，異なるサーバ間でサービス要求メッセージの受信処理が競合するのを回避できます。マルチスケジューラデーモンをグループ化している場合，サーバ側でユーザサービス定義scdmultiを指定する必要があります。

なお，この機能は，TP1/Extension 1をインストールしていることが前提です。TP1/Extension 1をインストールしていない場合の動作は保証できませんので，ご了承ください。

マルチスケジューラ機能の概要を次の図に示します。

図3‒57　マルチスケジューラ機能の概要

3.4.4　バッファ領域の共用による共用メモリの節約

共用メモリ上にサービス要求を格納する領域（メッセージ格納バッファプール）は，ユーザサーバごとに確保されます。この領域を複数のユーザサーバ間で共用すると，ユーザサーバのスケジュールに使う共用メモリを節約できます。

メッセージ格納バッファプールを共用する場合は，該当するノードに次に示す定義を指定します。

スケジュールサービス定義のscdbufgrpオペランドに，バッファ領域を共用化するユーザサーバのグループの名称（スケジュールバッファグループ名）を指定します。

共用化するそれぞれのユーザサーバのユーザサービス定義に，スケジュールバッファグループ名をscdbufgrpオペランドで指定します。

ユーザサービス定義に指定したスケジュールバッファグループ名に該当する名称がスケジュールサービス定義にない場合は，該当するユーザサーバの開始時にエラーになります。

バッファ領域の共用を次の図に示します。

図3‒58　バッファ領域の共用

(1)　バッファ領域の共用を指定できるユーザサーバ

バッファ領域の共用化の指定は，キュー受信型サーバの場合にだけ有効です。ソケット受信型サーバにバッファ領域を共用する指定をしても無視されて，共用しない状態で実行されます。

(2)　バッファ領域を共用化する場合の注意

共用化を指定した複数のユーザサーバのプロセスが同時に起動されると，バッファ領域の競合が起こってスケジュール性能が落ちる場合があります。

(3)　共有化したバッファの使用サイズの制限

バッファ領域を共用化する場合，共用している一部のユーザサーバの処理が遅延したり，大きなデータのサービス要求が格納されたりすると，バッファ領域が圧迫され，ほかのユーザサーバに対するサービス要求がバッファ不足となることがあります。これを防止するために，ユーザサーバごとにバッファの使用サイズを制限することができます。

バッファの使用サイズを制限するには，ユーザサービス定義のscdbufgrp定義コマンドに-sオプション，または-pオプションを指定します。-sオプションは共用するバッファに対し，そのユーザサーバに対するサービス要求を何バイトまで格納できるかを指定します。また，-pオプションは共用するバッファに対し，そのユーザサーバに対するサービス要求を何％まで格納できるかを指定します。

バッファの使用サイズの制限は，キュー受信型SPPの場合にだけ使用できます。MHPでは使用できません。指定した場合は無視されます。

バッファの使用サイズの制限について，scdbufgrp定義コマンドに指定するオプション別に以降の図に示します。

図3‒59　バッファの使用サイズの制限（scdbufgrp定義コマンドに-sオプションを指定）

この図では，スケジュールサービス定義を指定して，バッファグループBG1に3,072バイトを確保しています。また，ユーザサービス定義を指定して，SPP1，およびSPP2が，それぞれ最大2,048バイトまでバッファを使用できるようにしています。これによって，SPP1向けのサービス要求がバッファに滞留しても最大2,048バイトまでしか使用できないため，SPP2は残り1,024バイトのバッファで動作できます。

図3‒60　バッファの使用サイズ制限（scdbufgrp定義コマンドに-pオプションを指定）

この図では，スケジュールサービス定義を指定して，バッファグループBG1に3,072バイトを確保しています。また，ユーザサービス定義を指定して，SPP1は最大70%まで，SPP2は最大60%までバッファを使用できるようにしています。これによって，SPP1向けのサービス要求がバッファに滞留しても約70%（2,048バイト※）までしか使用できないため，SPP2は残り30%（1,024バイト）のバッファで動作できます。

注※

指定した割合によって，使用できるサイズはセルサイズの倍数に切り下げられます。

バッファグループに属するサーバUAPで一律に使用サイズを制限する場合，スケジュールサービス定義のscdbufgrp定義コマンドに-sオプション，または-pオプションを指定することもできます。この場合は，ユーザサービス定義のscdbufgrp定義コマンドには-sオプション，または-pオプションを指定する必要はありません。

スケジュールサービス定義で一律に使用サイズを制限する場合の例を次に示します。図中の番号と以降の説明の番号は対応しています。

図3‒61　スケジュールサービス定義で一律に使用サイズを制限する場合の例

スケジュールサービス定義を指定して，バッファグループBG1に3,072バイト確保し，一律で制限する使用サイズとして1,024バイトを指定します。

スケジュールサービス定義を指定して，バッファグループBG2に4,096バイト確保し，一律で制限する使用サイズとして25%（1,024バイト）を指定します。

SPP1およびSPP3はバッファグループBG1を使用し，使用サイズはスケジュールサービス定義で一律に指定された1,024バイトに制限されます。

SPP2およびSPP4はバッファグループBG2を使用し，使用サイズはスケジュールサービス定義で一律に指定された25%（1,024バイト）に制限されます。

SPP5はバッファグループBG1を使用しますが，使用サイズはスケジュールサービス定義で一律に指定された1,024バイトではなく，ユーザサービス定義で指定された2,048バイトになります。

SPP6はバッファグループBG2を使用しますが，使用サイズはスケジュールサービス定義で一律に指定された25%（1,024バイト）ではなく，ユーザサービス定義で指定された50%（2,048バイト）になります。

SPP7はバッファグループBG2を使用しますが，使用サイズはスケジュールサービス定義で一律に指定された25%（1,024バイト）ではなく，ユーザサービス定義で指定された2,048バイトになります。

(4)　バッファ領域を共有化する場合の注意

共用化したバッファの使用サイズを制限する，スケジュールサービス定義のscdbufgrp定義コマンドの-sオプション，または-pオプションは，ユーザサービスデフォルト定義にも指定できます。しかし，ユーザサービスデフォルト定義に指定した場合，共用バッファではない通常のバッファプール（ユーザサービス定義のmessage_store_buflenオペランドを指定）を使用するユーザサーバが使用できなくなります。

3.4.5　マルチサーバのプロセス制御の例

マルチサーバを指定したUAP（SPP，またはMHP）のプロセス制御を，例を使って示します。ユーザサービス定義でプロセス制御に関して，次の表のように指定したとします。

表3‒18　ユーザサービス定義での指定

定義項目

サービスグループ名

合計

G1

G2

G3

常駐プロセスの数

2

1

1

4

サービスグループ内のプロセスの最大数

4

2

2

8

スケジュールプライオリティ

1

2

3

該当しない

このとき同時に起動できるSPPとMHPのプロセスの最大数を6とします。サービスグループG1，G2，G3の常駐プロセス数の合計が4なので，動的に起動できるプロセスはあと二つになります。その二つを，サービスグループG1，G2，G3がスケジュールプライオリティに従って利用します。プロセス制御の流れを次の表に示し，時間の経過とともにプロセスの制御の流れを説明します。

表3‒19　プロセス制御の流れ

時間の経過

サービス要求

サービスグループ名

G1

G2

G3

1

オンライン開始

○○

○

○

2

G1，G3にサービス要求

●●

○

●

3

G1，G3のサービス要求増加

●●▲

○

●▲

4

G1のサービス要求さらに増加

●●▲▲

○

●

5

G2にサービス要求

●●▲▲

●

●

6

G2のサービス要求増加

●●▲▲

●

●

7

G1のサービス要求低下

●●▲

●▲

●

（凡例）

○：待機している常駐プロセス（起動済み）

●：サービスを実行中の常駐プロセス

▲：サービスを実行中の非常駐プロセス

経過1

オンライン開始時にサービスグループG1，G2，G3の常駐プロセスを起動します。常駐プロセスの合計が4，起動できるプロセスの最大数が6なので，動的に起動できるプロセス数は2になります。

経過2

G1，G3にサービス要求が来たので，G1，G3の常駐プロセスでサービスを実行します。

経過3

G1，G3のサービス要求が増加したので，G1，G3の非常駐プロセスをサービスグループ内の最大数の範囲内で起動して，サービスを実行します。このとき，プロセス数の合計が6になったので，これ以上動的にプロセスを増やすことはできません。

経過4

G1のサービス要求がさらに増加しても，これ以上動的にプロセスを増やすことができません。そこで，G3よりもG1の方がスケジュールプライオリティが高いので，G3の非常駐プロセスを，実行中のサービスが終了した時点で終了させ，G1の非常駐プロセスを起動します。

経過5

G2にサービス要求が来ると，待機していたG2の常駐プロセスでサービスを実行します。

経過6

G2のサービス要求が増加しても，これ以上動的にプロセスを起動できません。また，G2よりもG1の方がスケジュールプライオリティが高いので，G1の非常駐プロセスを終了させて，G2の非常駐プロセスを起動することはしません。

経過7

G1のサービス要求が低下したので，G1の非常駐プロセスのうちの一つを，実行中のサービスが終了した時点で終了させ，G2の非常駐プロセスを起動します。

以上のようにOpenTP1では，SPPとMHPに対するサービス要求を，プロセスを制御することで効率的に処理しています。

3.5　OpenTP1クライアント機能（TP1/Client）

OpenTP1で構築したサーバシステムへ，クライアント用のWSまたはPCからサービスを要求できる機能（OpenTP1クライアント機能　TP1/Client）について説明します。

なお，TP1/Client/WおよびTP1/Client/Pの詳細については，マニュアル「OpenTP1 クライアント使用の手引 TP1/Client/W，TP1/Client/P編」を参照してください。TP1/Client/Jの詳細については，マニュアル「OpenTP1 クライアント使用の手引 TP1/Client/J編」を参照してください。

TP1/Clientの機能概要

TP1/Clientの機能を次に示します。

TP1/Clientのリモートプロシジャコール

TP1/ClientのUAP（CUP），Javaアプレット，Javaアプリケーション，またはJavaサーブレットからOpenTP1のSPPへサービスを要求します。TP1/Client/WまたはTP1/Client/Pを使用する場合は，CUPからトランザクションを開始して，SPPへサービスを要求することもできます。

TCP/IPプロトコルを使ったメッセージ送受信

（TP1/Client/WおよびTP1/Client/Pでサポートします）

CUPとOpenTP1のMHPで，メッセージを送受信できます。

XDM/DCCM3との通信

CUP，Javaアプレット，Javaアプリケーション，またはJavaサーブレットからOpenTP1へリモートプロシジャコールを発行するのと同様の方法で，XDMなどの従来型システムと通信できます。

TP1/ClientからOpenTP1へサービスを要求する準備

OpenTP1がTP1/Clientからサービスを要求されたときに，その要求を受け付けるかどうかを判定する機能をユーザ認証機能といいます。

ユーザ認証機能を使用するためには，認証を受けるログイン名とパスワードを，OpenTP1が動作するOSにユーザID（ユーザアカウント）としてあらかじめ登録しておく必要があります。なお，パスワードは，TP1/Clientのユーザ認証要求関数（dc_clt_cltin関数またはdc_clt_cltin_s関数）の引数logname，および引数passwdに指定する値です。

ユーザ認証機能の使い方は，製品によって異なります。TP1/Client/W，およびWindows用のTP1/Client/Pの場合，CUPのコーディング時に，ユーザ認証機能の開始と終了を示す関数（dc_clt_cltin関数，dc_clt_cltout関数）を呼び出します。

なお，TP1/Client/Jを使用する場合は上記の準備は不要です。

3.5.1　TP1/Clientのリモートプロシジャコール

CUPから，TP1/Client/WまたはTP1/Client/Pのライブラリ関数を使って，OpenTP1のサーバUAP（SPP）へサービスを要求します。

TP1/Client/WまたはTP1/Client/Pを使用する場合は，CUPからトランザクションを開始することもできます。

TP1/Client/WまたはTP1/Client/PとOpenTP1との通信を次の図に示します。

図3‒62　TP1/Client/WまたはTP1/Client/PとOpenTP1との通信

Javaアプレット，Javaアプリケーション，またはJavaサーブレットからは，TP1/Client/Jのクラスライブラリを使って，OpenTP1のサーバUAP（SPP）へサービスを要求します。

TP1/Client/JとOpenTP1との通信を次の図に示します。

図3‒63　TP1/Client/JとOpenTP1との通信

(1)　OpenTP1の定義が必要なTP1/Clientの機能

TP1/Client/WまたはTP1/Client/Pで次に示す機能を使う場合，サーバとなるOpenTP1にはクライアントサービス定義が必要です。

CUPからトランザクションを開始する場合

クライアントサービス定義を作成したOpenTP1では，TP1/Client/WまたはTP1/Client/Pから開始したトランザクションを管理するシステムサービスが起動します。このシステムサービスを，クライアントサービスといいます。起動したクライアントサービスは，TP1/ClientのCUPが開始したトランザクションを管理します。

常設コネクションを使用する場合

クライアントサービス定義を作成したOpenTP1では，TP1/Client/WまたはTP1/Client/Pとの間に常設コネクションを接続するためのシステムサービスが起動します。このシステムサービスを，クライアント拡張サービスといいます。起動したクライアント拡張サービスは，TP1/ClientのCUPとの間に常設コネクションを確立します。

また，TP1/Client/WまたはTP1/Client/PでリモートAPI機能を使用する場合や，TP1/Client/JでOpenTP1のSPPへサービスを要求する場合には，OpenTP1側にrapリスナーサービス定義が必要です。

(2)　サーバの開始をTP1/Clientへ通知

OpenTP1のサーバUAPから，TP1/Client/WまたはTP1/Client/Pのアプリケーションプログラム（CUP）へUAPが開始したことを通知できます。CUPへは，dc_rpc_cltsend関数でデータを送って，サーバUAPの開始を通知します。この機能を使って，サーバの起動完了を一斉にクライアントへ知らせることができます。

dc_rpc_cltsend関数で通知したデータは，CUPのdc_clt_chained_accept_notification関数，またはdc_clt_accept_notification関数で受け取ります。CUPがデータを受け取ることで，TP1/Client/WまたはTP1/Client/Pはサーバが稼働中であることがわかります。その後，CUPからサーバへサービスを要求します。dc_clt_chained_accept_notification関数，およびdc_clt_accept_notification関数については，マニュアル「OpenTP1 クライアント使用の手引 TP1/Client/W，TP1/Client/P編」を参照してください。

OpenTP1のサーバUAPからTP1/Client/WまたはTP1/Client/PのCUPへの通信を次の図に示します。

図3‒64　OpenTP1のサーバUAPからTP1/Client/WまたはTP1/Client/PのCUPへの通信

(3)　ソケット用ファイル記述子の見積もり計算式

トランザクショナルRPC実行プロセス（clttrnd）のソケット用ファイル記述子の最大数は，ユーザサービスデフォルト定義のmax_socket_descriptorsオペランドに指定します。

トランザクショナルRPC実行プロセスのソケット用ファイル記述子の最大数の計算式を次に示します。

↑（トランザクショナルRPC実行プロセスが通信するUAPプロセス＋1
＋システムサービスプロセス数）／0.8↑

（凡例）

↑↑：小数点以下を切り上げます。

なお，ここに指定した値は，すべてのUAPおよび一部のシステムサーバにも有効になりますので注意してください。

3.5.2　TCP/IPプロトコルを使ったメッセージ送受信

TCP/IPプロトコルで接続したLANを使って，OpenTP1のUAPとメッセージ送受信形態で通信する方法です。CUPからMHPへメッセージを送信することも，MHPから送られたメッセージをCUPで受信することもできます。

TCP/IP通信をする場合は，サービス要求先のOpenTP1システムで TP1/Message Control，TP1/NET/Library，およびTCP/IP用の通信プロトコル対応製品（TP1/NET/TCP/IP）を使っていることが前提となります。

TCP/IPプロトコルを使ったメッセージ送受信の概要を次の図に示します。

図3‒65　TCP/IPプロトコルを使ったメッセージ送受信の概要

3.5.3　XDM/DCCM3との通信

TCP/IPプロトコルで接続したLANを使って，OpenTP1以外のサーバと通信する方法です。OpenTP1へサービスを要求するのと同様の方法で，XDM/DCCM3と通信できます。

次のOpenTP1クライアント製品とXDM/DCCM3が通信する場合，XDM/DCCM3のホストにDCCM3/SERVER/TP1，またはDCCM3/Internet 03-07以降が組み込まれていることが必要です。

TP1/Client/W

TP1/Client/P

TP1/Client for .NET Framework

TP1/Client/JとXDM/DCCM3が通信する場合は，ホストにDCCM3/Internetが組み込まれていることが必要です。

3.6　OSI TPを使ったクライアント/サーバ形態の通信

OpenTP1のクライアント/サーバ形態の通信では，TCP/IPとOSI TPを通信プロトコルに使えます。ここでは，通信プロトコルにOSI TPを使う場合の概要について説明します。通信プロトコルにOSI TPを使う場合には，TP1/NET/Library，TP1/NET/OSI-TP-ExtendedおよびOSI TPの通信管理をする製品が必要です。さらに，OpenTP1のシステムサービス（XATMI通信サービス）が必要です。

OSI TPを使ったクライアント/サーバ形態の通信の形態を次の図に示します。

図3‒66　OSI TPを使ったクライアント/サーバ形態の通信の形態

3.6.1　OpenTP1の通信相手のシステム

OpenTP1の通信相手となるシステムは，OpenTP1，またはXDM（XDM/DF/TP）です。OSI TP通信の場合は，通信相手がOpenTP1以外のシステムの場合でも，自システムのOpenTP1で開始したトランザクションを相手システムに拡張できます。

OSI TPを使ったクライアント/サーバ形態の通信では，XATMIインタフェースのAPIを使います。XATMIインタフェースについては，「3.2.4　XATMIインタフェースの通信」を参照してください。

3.6.2　通信に使う経路

自システムのOpenTP1と相手システムの間に論理的な通信路を確立します。この通信路をアソシエーション※といいます。アソシエーションが確立すると，クライアント/サーバ形態で通信できるようになります。

アソシエーションは，システムとシステムの接点を示すアドレス（PSAPアドレス）の間に確立します。

注※

このマニュアルでは，通信プロトコルにOSI TPを使ったクライアント/サーバ形態の通信をする場合にだけ，論理的な通信路をアソシエーションと表記します。

(1)　発呼側と着呼側

OSI TP通信では，どちらのシステムが確立を要求するかで，確立したアソシエーションの属性が決まります。アソシエーションの確立を要求することを発呼，要求されることを着呼といいます。アソシエーションの確立を要求した方のシステムを発呼側といい，要求された方のシステムを着呼側といいます。

OpenTP1から相手システムにサービスを要求する場合は，OpenTP1システムが発呼側として確立したアソシエーションを使います。OpenTP1システムが着呼側として確立したアソシエーションは，主に障害回復の連絡のために使います。

(2)　アソシエーションの確立

TP1/NET/OSI-TP-Extendedの定義にシステム開始時に確立を要求する指定をしておくと，システム開始時にアソシエーションの確立が実行されます。自システムが発呼側となるか着呼側となるかは，TP1/NET/OSI-TP-Extendedの定義のプロトコル固有定義nettalccnに指定します。

TP1/NET/OSI-TP-Extendedの定義では，システム開始時に確立を要求する指定をしておいてください。

(3)　アソシエーションの解放

OpenTP1システムが正常に終了すると，アソシエーションは正常に解放されます。OpenTP1システムまたは相手システムが異常終了すると，アソシエーションは異常解放されます。

(4)　システム定義の指定

OSI TPを使ったクライアント/サーバ形態の通信をするために必要になるOpenTP1の定義を次に示します。

XATMI通信サービス定義

ネットワークライブラリ定義（TP1/NET/LibraryとTP1/NET/OSI-TP-Extendedの定義）

XATMI通信サービスとTP1/NET/OSI-TP-Extendedを上記の定義で対応づけることで，OSI TP通信ができるようになります。

3.6.3　通信に使うアプリケーションプログラム

OpenTP1のUAPは，相手システムとの通信にXATMIインタフェースを使います。また，相手システムへトランザクション処理を拡張できます。OSI TPを使ったクライアント/サーバ形態の通信で使えるOpenTP1のUAPは，SUPとSPPです。ほかのOpenTP1のUAP（MHP）は使えません。

OSI TPを使ったクライアント/サーバ形態の通信の場合に使えるXATMIインタフェースの通信形態を次に示します。

リクエスト/レスポンス型サービスの通信（同期的に応答を受信する形態，非同期に応答を受信する形態，応答を返さない形態）

会話型サービスの通信は，OSI TPを使ったクライアント/サーバ形態の通信では使えません。

OpenTP1がクライアント，XDM/DF/TPがサーバの場合のアプリケーションプログラムの通信の形態を次の図に示します。

図3‒67　アプリケーションプログラムの通信の形態（OpenTP1がクライアント，XDM/DF/TPがサーバの場合）

XDM/DF/TPがクライアント，OpenTP1がサーバの場合のアプリケーションプログラムの通信の形態を次の図に示します。

図3‒68　アプリケーションプログラムの通信の形態（XDM/DF/TPがクライアント，OpenTP1がサーバの場合）

(1)　トランザクション処理との関係

OpenTP1システムとOpenTP1システムでは，トランザクション処理を相手システム間で拡張できます。OpenTP1とOpenTP1以外のシステムでは，OSI TPを使ってトランザクション処理を相手システム間で拡張できます。

(2)　アソシエーションの状態を認識するSPP（通信イベント処理用SPP）

OSI TPを使ったクライアント/サーバ形態の通信をする場合，アソシエーションの確立と解放を知るためのSPPを作成する必要があります。このSPPを通信イベント処理用SPPといいます。通信イベント処理用SPPを作成すると，アソシエーションの解放の通知イベントをSPPで受信できます。この通信イベントを受信することで，アソシエーションの再確立のきっかけを知ることができます。アソシエーションを再確立するときは，dc_xat_connect関数を使います。

通信イベントは，自システムが発呼側か着呼側かどうかに関係なく通知されます。通信イベント処理用SPPでは，通知イベントの詳細情報からアソシエーションの属性や状態について知ることができます。

通信イベント処理用SPPのサービスグループ名とサービス名は，あらかじめXATMI通信サービス定義に指定しておきます。この指定に従って，通信イベントが通知されます。

通信イベント処理用SPPと受信するイベントについては，マニュアル「OpenTP1 プログラム作成の手引」および「OpenTP1 プログラム作成リファレンス」の該当する言語編を参照してください。

通信イベント処理用SPPの概要を次の図に示します。

図3‒69　通信イベント処理用SPPの概要

3.6.4　環境設定の概要

クライアント/サーバ形態の通信プロトコルにOSI TPを使う場合の，OpenTP1システムの環境設定手順を次に示します。(2)と(3)の手順は，通常のOpenTP1の作業と同じです。

(1)　OpenTP1の製品の組み込み

OSI TP通信に必要な，次に示す製品を組み込みます。

TP1/Server Base，TP1/NET/Library，TP1/NET/OSI-TP-Extended

(2)　TP1/Server Baseの定義の作成

スーパユーザがOpenTP1管理者を決定したあとで，OpenTP1管理者はTP1/Server Baseの定義を作成します。

(3)　OpenTP1の登録

OpenTP1をOSに登録するため，dcsetupコマンドを実行します。

(4)　TP1/NET/OSI-TP-Extendedの定義の作成

TP1/NET/OSI-TP-Extendedの定義を作成します。定義ファイルは，定義を解析するユティリティでオブジェクトファイルにしたあと，OpenTP1のシステム定義を格納するディレクトリの下に次のファイル名で格納します。

$DCCONFPATH/xatcex

OpenTP1でTP1/NET/OSI-TP-Extendedを使う場合，TP1/NET/Libraryを登録するコマンド（netsetupコマンド）を実行する必要はありません。

OpenTP1のシステム設定手順については，「5.1　OpenTP1システムの環境設定手順」を参照してください。また，OpenTP1以外の前提プログラムについては，マニュアル「OpenTP1 プロトコル TP1/NET/OSI-TP-Extended編」を参照してください。

3.6.5　障害が起こった場合

OSI TPを使ったクライアント/サーバ形態の通信で障害が起こった場合，サービスを要求したXATMIインタフェースの関数はエラーリターンします。どのリターン値が返るかについては，「OpenTP1 プログラム作成リファレンス」の該当する言語編にあるXATMIインタフェースの各関数の注意事項を参照してください。

通信プロトコルで障害が起こった場合の処置については，マニュアル「OpenTP1 プロトコル TP1/NET/OSI-TP-Extended編」の障害対策の説明を参照してください。

3.7　リモートAPI機能

リモートAPI機能とは，クライアント側のノードにあるUAPが発行したAPIを，OpenTP1がサーバ側に転送してサーバ側のプロセスで代理実行する機能です。リモートAPI機能を要求するクライアント側のノードにあるUAPをrapクライアントといいます。rapクライアントが発行したAPIを，OpenTP1のrapリスナーが受け付け，rapサーバがサーバ側のノードで実行します。rapリスナー，rapサーバはOpenTP1のユーザサービスとして動作します。

リモートAPI機能を次の図に示します。

図3‒70　リモートAPI機能

rapクライアントとなるUAPを次の表に示します。

表3‒20　rapクライアントとなるUAP

プログラムプロダクト

rapクライアントとなるUAP

TP1/Server Base，TP1/LiNK

SUP，SPP，MHP

TP1/Client

CUP

次に，rapクライアントから代理実行できるAPIをrapクライアントの種類ごとに示します。

TP1/Server Base，TP1/LiNKがrapクライアントとなる場合

C言語ライブラリ

COBOL-UAP作成用プログラム

dc_rpc_call

CBLDCRPC（'CALL '）

TP1/Client/P，TP1/Client/Wがrapクライアントとなる場合

C言語ライブラリ

COBOL-UAP作成用プログラム

dc_rpc_call_s

CBLDCRPS（'CALL '）

dc_trn_begin_s

CBLDCTRS（'BEGIN '）

dc_trn_chained_commit_s

CBLDCTRS（'C-COMMIT'）

dc_trn_chained_rollback_s

CBLDCTRS（'C-ROLL '）

dc_trn_unchained_commit_s

CBLDCTRS（'U-COMMIT'）

dc_trn_unchained_rollback_s

CBLDCTRS（'U-ROLL '）

TP1/Client/Jがrapクライアントとなる場合

メソッド

rpcCall

trnBegin

trnChainedCommit

trnChainedRollback

TrnUnchainedCommit

trnUnchainedRollback

TP1/Client for .NET Frameworkがrapクライアントとなる場合

メソッド

Call

Begin

CommitChained

RollbackChained

Commit

Rollback

3.7.1　リモートAPI機能の使用例

リモートAPI機能を使うと，ファイアウォールの内側にあるUAPに対しても，サービスを要求できます。ファイアウォールの内側へのリモートプロシジャコールを次の図に示します。なお，TP1/Clientを使用する場合については，マニュアル「OpenTP1 クライアント使用の手引」を参照してください。

図3‒71　ファイアウォールの内側にあるUAPへのリモートプロシジャコール

3.7.2　常設コネクション

OpenTP1は，リモートAPIを要求したUAP（rapクライアント）とrapサーバとの間に，論理的な通信路（常設コネクション）を設定します。

常設コネクションのスケジュール方法には，スタティックコネクションスケジュールモードとダイナミックコネクションスケジュールモードがあります。どちらを使用するかは，rapリスナーサービス定義のrap_connection_assign_typeオペランドで指定できます。

(1)　スタティックコネクションスケジュールモード

スタティックコネクションスケジュールモードを使用するには，rap_connection_assign_typeオペランドにstaticを指定します。または指定を省略します。

スタティックコネクションスケジュールモードは，rapクライアントがコネクションの確立を要求すると同時にrapサーバを割り当て，rapクライアントとrapサーバを1対1で関係づける常設コネクションのスケジュール方法です。同時に使用するrapクライアント数が，開始するrapサーバ数以内の場合に適しています。なお，OpenTP1の制限のため，rapサーバの最大数は1024です。

スタティックコネクションスケジュールモードを使用する場合，rapリスナーが管理できる常設コネクションの最大数は1024です。

rapリスナーサービス定義のrap_max_clientオペランドには，rapリスナーに同時接続する最大クライアント数を指定できます。ただし，OpenTP1の制限のため，rap_max_clientオペランドおよびmax_socket_descriptorsオペランドの和が1993以下になるように調整してください。

また，同時に常設コネクションが設定され，実行できるrapクライアント数はrapサーバ数が上限です。残りの常設コネクションは，現在実行中のrapクライアントが常設コネクションを解放するまで常設コネクションの確立はできません。そのため，rapクライアントがrapサーバ数以上の場合には，次に示すどちらかの運用をしてください。

API代理実行を要求する前後で，rapクライアントで常設コネクションの確立および解放を実行してください。

rapリスナーを複数開始して，rapクライアントが常設コネクションを確立するrapサーバ数を増やしてください。

(2)　ダイナミックコネクションスケジュールモード

ダイナミックコネクションスケジュールモードを使用するには，rap_connection_assign_typeオペランドにdynamicを指定します。

ダイナミックコネクションスケジュールモードは，rapクライアントがコネクションの確立を要求するときにrapサーバを割り当てないで，API代理実行の要求が発生したときに動的に未使用のrapサーバを割り当てるコネクションスケジュール方法です。同時に使用するrapクライアント数がrapサーバ数以上あるが，rapサーバに必要な資源を増加させたくない場合に適しています。

ダイナミックコネクションスケジュールモードを使用する場合，rapリスナーが管理できる常設コネクションの最大数は1024です。rapリスナーサービス定義のrap_max_clientオペランドにはrapリスナーに同時接続する最大クライアント数を指定できます。ただし，OpenTP1の制限のため，rap_parallel_serverオペランド，rap_max_clientオペランドおよびmax_socket_descriptorsオペランドの和が1993以下になるように調整してください。

ダイナミックコネクションスケジュールモードでは，rapクライアントからのAPI代理実行の要求を受け取ったときにだけrapサーバを割り当て，API代理実行の終了後にはrapサーバを解放します。このため，スタティックコネクションスケジュールモードでrapクライアントがrapサーバ数以上となった場合に行う次の対策は必要ありません。そのため，rapリスナーを複数開始する必要がないのでファイアウォールを通過させるための通信ポートを増やす必要もありません。

API代理実行の要求をするたびに常設コネクションの確立と解放を実行する

rapリスナーを複数開始して，rapクライアントが常設コネクションを確立するrapサーバ数を増やす

ただし，ダイナミックコネクションスケジュールモードは，rapリスナーへの負荷が高くなるとスタティックコネクションスケジュールモードに比べてレスポンス性能が悪くなります。

3.7.3　コネクトモード

常設コネクションの管理方法は，コネクションの確立・解放方法によって二つに分けられます。コネクションの確立，解放をOpenTP1が管理する形態をオートコネクトモード，ユーザが管理する形態を非オートコネクトモードといいます。ユーザはコネクションをオートコネクトモードで管理するか，非オートコネクトモードで管理するかを，rapクライアントのユーザサービス定義で定義します。

(1)　オートコネクトモード

OpenTP1が常設コネクションの確立・解放を管理する形態です。rapクライアントが，ユーザサービスネットワーク定義に-wオプション付きで定義されているサービスグループ名を指定してdc_rpc_callを発行した場合に，自動的に常設コネクションを確立します。

ユーザサービスネットワーク定義に定義されているサービスグループにdc_rpc_callを発行した時点から，dc_rpc_closeを発行してリモートプロシジャコールを終了するまで常設コネクションを確保します。

(2)　非オートコネクトモード

ユーザが常設コネクションの確立・解放を管理する形態です。ユーザはrapクライアントでコネクションを確立・解放するためのAPI（dc_rap_connect・dc_rap_disconnect）を発行します。rapクライアントが，ユーザサービスネットワーク定義に-wオプション付きで定義されているサービスグループ名を指定してdc_rpc_callを発行したときに，ユーザが常設コネクションを確立していないと，dc_rpc_callがエラーになります。

3.7.4　rapクライアントマネジャ

rapクライアントが常設コネクションを確立していると認識していても，そのコネクションが有効でない場合（rapサーバ側マシンの電源の切断など）があります。この場合，rapクライアントが，dc_rpc_callを発行してrapサーバにサービス要求を送信しても，サービス要求はrapサーバで受信されません。さらに，rapクライアントには，タイムアウトになるまでdc_rpc_callの応答が返ってきません。この現象を回避するために，rapクライアントマネジャサービス定義を定義し，rapクライアントマネジャを起動します。

rapクライアント側で動作するrapクライアントマネジャは，rapリスナーからの起動通知を受信したとき，通知元のrapリスナーを識別する情報と起動通知を受信した時刻をrapクライアントマネジャの管理テーブルに保持します。rapクライアントは，rapリスナーとコネクションを確立するときにこの管理テーブルを参照して起動通知を受信した時刻を保存しておきます。rapクライアントは，dc_rpc_call関数を発行するとき，再度この管理テーブルの起動通知を受信した時刻を参照して，コネクション確立時に保存しておいた値と比較します。比較した結果，起動通知時刻が一致していれば，現在のコネクションが有効であると判断し，不一致であれば現在のコネクションが無効であると判断します。

コネクションが無効と判断した場合の動作は，コネクトモードによって異なります。

オートコネクトモード

不要なコネクションを解放し，再度コネクションを確立したあとで，dc_rpc_call関数を発行してサービス要求を送信します。

非オートコネクトモード

dc_rpc_call関数はDCRPCER_NET_DOWNでエラーリターンします。

rapクライアントマネジャの動作環境を設定するには，rapsetupコマンドを実行してください。rapクライアントマネジャを起動するには，rapdfgenコマンドを実行してrapクライアントマネジャ用ユーザサービス定義を生成してください。

注

rapクライアントマネジャが異常終了したあとに再起動，または正常終了した場合，rapクライアントは現在のコネクションを無効と判断し，強制的にコネクションを切断することがあります。強制的に切断したコネクションが有効であった場合，rapリスナー側で，KFCA26965-Eメッセージ（スタティックコネクションスケジュール機能使用時），またはKFCA26956-Wメッセージ（ダイナミックコネクションスケジュール機能使用時）が出力されます。

KFCA26965-Eメッセージ，KFCA26956-Wメッセージの詳細については，マニュアル「OpenTP1 メッセージ」を参照してください。

3.7.5　リモートAPI機能を使用する場合に設定する必要がある定義

TP1/Server Base間でリモートAPI機能を使用する場合に設定する必要がある定義は次のとおりです。

rapクライアント側

ユーザサービス定義

ユーザサービスネットワーク定義

rapクライアントマネジャサービス定義（任意）

rapサーバ側

rapリスナーサービス定義

3.7.6　XAリソースサービスを使用する場合

XAリソースサービスを使用するためには，リモートAPI機能と，次に示す製品が必要です。

J2EEで動作するアプリケーションサーバと連携する場合

TP1/Client/J

uCosminexus TP1 ConnectorまたはCosminexus TP1 Connector

.NET Frameworkアプリケーションと連携する場合

Client .NET

Connector .NET

XAリソースサービスは，常設コネクションのスケジュール方式の，スタティックコネクションスケジュールモードとダイナミックコネクションスケジュールモードのどちらのモードを使用しても動作します。

XAリソースサービスの詳細については，「3.1.7　XAリソースサービスによるトランザクション制御」を参照してください。

3.8　サービス関数動的ローディング機能

サービス関数動的ローディング機能とは，UAP共用ライブラリ化したサービス関数を，動的にローディングする（読み込む）機能です。定義を変更するだけでサービスを追加または削除できます。なお，UAP共用ライブラリ化とは，UAPのソースファイルを翻訳（コンパイル）して作成したUAPオブジェクトファイルを結合（リンケージ）して，共用ライブラリとしてまとめることです。

サービス関数動的ローディング機能を使うと，サービス関数を追加または削除する場合に，スタブの変更，およびUAPの実行形式ファイルの再生成をしなくても，ユーザサービス定義のserviceオペランドを変更するだけでサービス関数を追加または削除できます。UAP起動時にサービス関数をローディングするため，UAPの実行形式ファイル作成時には，スタブおよびサービス関数は不要です。また，RPCインタフェース定義を使わないため，既存のUAPに新たにサービスを追加または削除する場合，サービスの追加または削除に伴うUAPの実行形式ファイルの再生成は不要です。

このように作業を省略できるため，特に頻繁にサービスを追加または削除するシステムで有効に適用できます。

注意事項

サービス関数動的ローディング機能は，SPPまたはMHPの場合にだけ使用できます。ただし，次の場合は，サービス関数動的ローディング機能を使用できません。

XATMIインタフェースを使ったユーザサーバの場合

TP1/Offline Testerを使用している場合

3.8.1　サービス関数動的ローディング機能の使用例

サービス関数動的ローディング機能を使う場合，サービス関数動的ローディング機能だけを使用したり，サービス関数動的ローディング機能とスタブを併用したりできます。

(1)　サービス関数動的ローディング機能だけを使用する例

サーバ側でクライアントからの要求を受信すると，UAP共用ライブラリから取得したサービス関数を実行します。

サービス関数動的ローディング機能を使ったUAPの例を，SPPの場合とMHPの場合に分けてそれぞれを以降の図に示します。

図3‒72　サービス関数動的ローディング機能を使ったUAP（SPP）の例

図3‒73　サービス関数動的ローディング機能を使ったUAP（MHP）の例

(2)　サービス関数動的ローディング機能とスタブを併用する例

サービス関数動的ローディング機能は，スタブとサービス関数を使ったSPPと併用できます。併用する場合，サービスを追加または削除するときに，スタブとサービス関数を使ったUAPの実行形式ファイルを再生成する必要はありません。

サービス関数動的ローディングとスタブを併用したUAPの例を，SPPの場合とMHPの場合に分けてそれぞれを以降の図に示します。

図3‒74　サービス関数動的ローディング機能とスタブを併用したUAP（SPP）の例

図3‒75　サービス関数動的ローディング機能とスタブを併用したUAP（MHP）の例

3.8.2　サービス関数動的ローディング機能を使用する場合に必要な準備

サービス関数動的ローディング機能を使う場合に必要な事前準備について説明します。

(1)　設定の手順

サービス関数動的ローディング機能を使う場合に必要な作業を次に示します。

サービス関数から，UAP共用ライブラリを作成します。

ユーザサービス定義のserviceオペランドに，サービス名，エントリポイント名，およびUAP共用ライブラリ名を設定します。

serviceオペランドの詳細については，マニュアル「OpenTP1 システム定義」を参照してください。

(2)　再リンケージの実行条件

サービス関数を追加する場合に，UAPオブジェクトの再リンケージが必要かどうかを，次の表に示します。

表3‒21　再リンケージの実行条件

サービスの追加または削除のベースとなるUAPオブジェクト

サービスの追加方法

再リンケージ

RPCインタフェース定義だけを使ったUAPオブジェクト

RPCインタフェース定義を使う場合。

○

サービス関数動的ローディング機能を使う場合。

×

サービス関数動的ローディング機能だけを使ったUAPオブジェクト

RPCインタフェース定義を使う場合。

○

サービス関数動的ローディング機能を使う場合。

×

RPCインタフェース定義およびサービス関数動的ローディング機能を併用したUAPオブジェクト

RPCインタフェース定義を使う場合。

○

サービス関数動的ローディング機能を使う場合。

×

（凡例）

○：再リンケージが必要です。

×：再リンケージは不要です。

3.9　OpenTP1の運用を補助する機能

ここまでに説明したシステムサービス以外で，OpenTP1の運用を補助するための機能について説明します。

OpenTP1提供以外のリソースマネジャを制御する場合は，OpenTP1システムにTP1/Resource Manager Monitorを組み込んでおく必要があります。それ以外は，TP1/Server Baseで標準で提供する機能です。

3.9.1　資源の排他制御

OpenTP1では，複数のユーザがDAMファイルやTAMファイル以外の資源も共用できるようにしています。資源を管理して整合性を保つことができる機能を排他制御といいます。排他資源の占有，および待ち状態はlcklsコマンドで表示できます。

(1)　排他制御の管理単位と有効範囲

OpenTP1は，資源の排他要求時から排他資源の解放要求時まで排他を管理します。排他制御の管理単位は，グローバルトランザクションです。ただし，DAMサービスが使用する排他制御機能の管理単位は，トランザクションブランチです。

排他制御の有効範囲は，一つのOpenTP1システム内だけです。ほかのOpenTP1システム上のUAPとの排他制御はできません。また，複数のノードから構成される一つのOpenTP1システム内でも，ノード間の排他制御はできません。

(2)　資源の排他要求

資源を確保するときは，UAPからdc_lck_get関数を呼び出します。このとき，引数に資源名称と排他制御モードを指定します。排他制御モードとは，同じ資源にアクセスするほかのUAPに対する排他の方式です。

排他制御モードには，資源を参照するだけのUAPとは資源を共用し，資源を更新するUAPだけを排他するPRモードと，一つのUAPが資源を占有し，ほかのUAPをすべて排他するEXモードがあります。

排他制御モードを次の表に示します。

表3‒22　排他制御モード

排他制御モード

資源の処理

排他の内容

PR

参照

ほかのUAPに対して，参照だけを許可します。

EX

更新

ほかのUAPに対しては，参照，更新を許可しません。

排他制御モードの組み合わせによる資源の共用を次の表に示します。

表3‒23　排他制御モードの組み合わせによる資源の共用

使用中の排他制御モード

要求元の排他制御モード

PR

EX

PR

○

×

EX

×

×

（凡例）

○：共用できます。

×：共用できません。

(3)　資源の解放

ユーザは，次に示す方法で資源を解放します。

資源名称ごとの排他解除要求をUAPが出す

全資源の一括排他解除要求をUAPが出す

また，トランザクションの終了時に，システムが全資源を自動的に解放します。

これによって，UAPでの解放漏れや，UAP異常終了が発生した場合でも，資源が不当に占有されることがなくなります。

(4)　排他待ち

資源を排他できない場合，資源を排他できるまで待つかどうか，dc_lck_get関数の引数で指定します。排他待ちするのは，次の場合です。

排他要求したときに，ほかのUAPがすでにEXモードで資源に排他をかけている場合

排他要求したときに，ほかのUAPがすでにPRモードで資源に排他をかけていて，かつ自UAPでEXモードの排他をかける場合

資源が解放されるまで待つと指定した場合には，排他待ちの優先順位に従って，ほかのUAPが資源の排他を解除するまで待ちます。待たないと指定した場合は，すぐにエラーリターンします。排他待ちの優先順位は，ユーザサービス定義でUAPのサービスグループごとに定義します。優先順位を高く設定すれば，排他待ちしている，優先順位の低いほかのUAPよりも先に資源を排他できます。逆に，優先順位を低く設定したUAPは，あとから排他要求した優先順位の高いUAPに追い越されることがあるので，排他待ちの優先順位の設定には注意が必要です。排他待ちの優先順位と排他順序を次の図に示します。

ロックサービス定義で排他待ち限界経過時間を指定すると，排他待ち状態がこの時間を超えたとき，その排他要求をエラーリターンします。

図3‒76　排他待ちの優先順位と排他順序

(5)　デッドロックの対処方法

複数のUAPが複数の資源に対して異なる順番で排他要求を行った場合，それぞれのUAPが相手の占有する資源の排他解除を互いに待ち続けて，処理が止まってしまう場合があります（デッドロック）。

OpenTP1は，デッドロック状態を検出して速やかに解消するため，定期的にデッドロック状態になっているかどうかを監視しています。

同一ノード内のUAP間では，定期的に排他待ち状態を監視してデッドロックを検知します。

異なるノードのUAPにRPCでサービス要求して，そのサービスとの間でデッドロックが起こっても，検知できません。そのため排他待ち時間監視をする必要があります。排他待ち限界経過時間は，ロックサービス定義で指定します。

デッドロックの例を次の図に示します。

図3‒77　デッドロックの例

(a)　デッドロック時のOpenTP1の処置

デッドロックが起こった場合，OpenTP1はUAPの排他待ち優先順位に従って，優先順位の低いUAPプロセスからの排他要求をエラーリターンさせます。UAPの排他待ち優先順位は，ユーザサービス定義のdeadlock_priorityオペランドに指定します。

デッドロックによって，資源を確保しようとした関数がエラーリターンした場合，UAPでは次のように対処してください。

SUP，SPPのデッドロック時の処置

SUP，またはSPPの処理でデッドロックが起こった場合は，dc_trn_unchained_rollback関数，dc_trn_chained_rollback関数などロールバックする関数で，トランザクションをロールバックさせてください。デッドロックでロールバックしたSUP，または SPPは再実行（リトライ）しません。もう一度該当するサービスをクライアントUAPから要求し直してください。

MHPのデッドロック時の処置

MHPの処理でデッドロックが起こった場合は，dc_mcf_rollback関数でロールバックしてください。再実行（リトライ）するかどうかは，dc_mcf_rollback関数の引数に指定します。

(b)　デッドロック情報，タイムアウト情報の出力

デッドロックが起こった場合，デッドロックの原因となったUAPの詳細情報を，ロックサービスがあるノードのディレクトリに出力できます。この情報をデッドロック情報といいます。

資源の解放を待っているUAPが，ロックサービス定義のlck_wait_timeoutオペランドに指定した時間を超えた場合，UAPから呼び出した関数はエラーリターンします。このとき，確保しようとした資源に関する詳細情報を，ロックサービスがあるノードのディレクトリに出力できます。この情報をタイムアウト情報といいます。

デッドロック情報，タイムアウト情報を出力するかどうかは，ロックサービス定義のlck_deadlock_infoオペランドに指定します。

デッドロック情報，タイムアウト情報の出力形式については，マニュアル「OpenTP1 プログラム作成の手引」を参照してください。

取得したデッドロック情報，タイムアウト情報は削除できます。情報を削除する方法を次に示します。

コマンドで削除する方法

lckrminfコマンドを実行します。

OpenTP1の開始時に，前回までのオンラインで作成した情報を削除する方法

ロックサービス定義のlck_deadlock_info_remove_levelオペランドに，削除する条件を指定しておきます。

3.9.2　ユーザジャーナルの取得

UAPの中でUAP履歴情報取得機能を使用して任意の情報をシステムジャーナルファイルに取得できます。ユーザジャーナル（UJ）の取得方法を次の図に示します。

図3‒78　ユーザジャーナルの取得方法

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

3.9.3　ジャーナル維持機能

ジャーナル維持機能とは，アンロードジャーナルファイルにコピーしたジャーナルデータを加工して利用するための機能です。ジャーナル維持機能を使って，複数のアンロードジャーナルファイルをマージしたりします。

ジャーナル維持機能には，ジャーナルの複写，ファイル回復用ジャーナルの集積，ジャーナルの編集，アンロードジャーナルファイルのレコード出力の四つがあります。

(1)　ジャーナルの複写（jnlcopyコマンド）

ジャーナルを複写する機能には，レコードを複写する機能とマージする機能があります。

レコードを複写するときは，アンロードジャーナルファイルの情報を，範囲を区切って標準出力に出力できます。jnlcopyコマンドの引数に次のように範囲を指定して，レコード単位で出力します。

ジャーナルを取得した日時

ジャーナル種別（PJ，HJ，BJ，TJ，DJ，FJ，CJ，MJ，IJ，GJ，OJ，AJ，SJ，UJ）をjnlcopyコマンドの-jオプションに指定して，ジャーナル種別ごとのアンロードジャーナルファイルを作成することもできます。

複数のアンロードジャーナルファイルを一つのファイルにマージして出力することもできます。マージするアンロードジャーナルファイルは，1回のオンライン中に出力した連続する世代番号を持つファイルに限ります。

(2)　ファイル回復用ジャーナルの集積（jnlcolcコマンド）

ファイル回復用ジャーナルを集積するときは，アンロードジャーナルファイルからDAM FRC，またはTAM FRCに必要なデータだけを，標準出力に出力します。複数のアンロードジャーナルファイルを一度に集積して，ファイル回復時の入力用ファイルを作成できます。このファイル回復時の入力用ファイルを，集積ジャーナルファイルといいます。

障害が発生したDAMファイルやTAMファイルは，バックアップファイルとアンロードジャーナルファイルを基に回復します。このとき，OpenTP1はアンロードジャーナルファイルを集積して，回復処理をします。回復処理をするとき，ユーザが作成した最新の集積ジャーナルファイルがあれば，これを利用して回復時間を短縮できます。

アンロードジャーナルファイル内の未決着トランザクションに関する回復用の履歴情報を，次回のジャーナル集積時に引き継ぐため，集積ジャーナルファイルとは別のファイルに格納します。このファイルを引き継ぎファイルといいます。次回のジャーナル集積時には，引き継ぎファイルとアンロードジャーナルファイルから，ファイル回復に必要なデータを集積します。

(3)　ジャーナルの編集（jnleditコマンド）

ジャーナルを編集するときは，アンロードジャーナルファイルごとにファイルの内容をリスト形式にして標準出力に出力します。また，指定したファイルの属性に関する情報も出力できます。ジャーナルレコード，またはジャーナルブロック単位に範囲を限定することで，全ジャーナルのうち必要なジャーナルだけを出力できます。

ジャーナルを編集すると，ジャーナルレコードを16進数，または16進数と文字の形式で確認できます。

アンロードジャーナルファイル内のユーザジャーナルのレコード（UJレコード）を，編集しないでそのまま標準出力に出力できます。

ジャーナルを編集した出力形式については，マニュアル「OpenTP1 運用と操作」を参照してください。

(4)　アンロードジャーナルファイルのレコード出力（jnlrputコマンド）

アンロードジャーナルファイルのレコードは，アンロードジャーナルファイル内のユーザジャーナルレコード情報，またはトランザクションブランチのCPU使用時間情報を編集しないで，そのまま標準出力に出力できます。

出力するとき，出力範囲，ジャーナル種別，およびジャーナル取得モードなどを指定することで，必要な情報を選択できます。

3.9.4　メッセージログの操作

OpenTP1では，システムメッセージを編集し，メッセージログをファイルに取得して，オンラインシステムの監視ができます。メッセージログは，ログサービスで管理します。

メッセージログの取得方法を次の図に示します。

図3‒79　メッセージログの取得方法

メッセージログの運用方法については，マニュアル「OpenTP1 運用と操作」を参照してください。

(1)　システムメッセージを格納するファイル

ログサービスは，各システムサービス，MCF，およびUAPからのメッセージ出力要求を受け付け，メッセージを編集してメッセージログファイルに出力します。メッセージログファイルには，dclog1とdclog2の二つのファイルがあります。二つのファイルは，ラウンドロビン方式で使用され，1世代前のメッセージ情報は保証されます。また，ログサービスからメッセージログファイルに出力されるメッセージを，同時にコンソールへ出力できます。

メッセージログファイルに出力されたシステムメッセージは，logcatコマンドで標準出力へ出力されます。出力するとき，dclog1とdclog2の最終更新時刻を比較して古い情報から順に出力します。出力するときに付ける情報をlogcatコマンドのオプションで選択できます。

OpenTP1のシステムメッセージは，重要なメッセージ（エラーメッセージ，警告メッセージ）に限り，syslogファイルにも出力されます。さらに，OpenTP1のシステムメッセージすべてを強制的にsyslogファイルに出力することもできます。ログサービス定義のlog_syslog_××××オペランドを指定すると，メッセージすべてをsyslogファイルへ出力できます。

(2)　メッセージ通番

付加情報としてメッセージ通番が取得できます。メッセージ通番は，メッセージログ全体の通番です。障害などでメッセージが欠落した場合でも，メッセージ通番を基に，メッセージに抜けがあったことを検知できます。

(3)　メッセージログの抑止

排他エラーが発生すると，OpenTP1はメッセージログを出力します。エラーリターンしたUAPのリトライを繰り返していると，メッセージログ量が多くなってしまいます。このため，DAMファイルの場合，排他によるエラーリターンのメッセージを出力するかどうかを，DAMサービス定義のdam_message_levelオペランドで指定できます。指定しなければ，メッセージを出力しなくて済みます。

(4)　出力するメッセージログの言語種別の指定

メッセージログを，英語で出力するか日本語で出力するかを選べます。システム共通定義のputenv形式でLANG変数に，出力したい言語種別を指定します。指定を省略すると，メッセージログは英語で出力されます。

3.9.5　メッセージログの通知

OpenTP1のメッセージログを，システム内に専用に作成するアプリケーションプログラムへ通知できます。通知を受信したアプリケーションプログラムは，他社のネットワーク管理システムへOpenTP1の状態を知らせることができます。

メッセージログを通知する場合は，OpenTP1のログサービス定義のlog_notify_outオペランドにYを指定しておいてください。

(1)　メッセージログの通知を受信できるアプリケーションプログラム

メッセージログの通知を受信できるのは，受信用に作成したアプリケーションプログラムだけです。OpenTP1のUAP（SUP，SPP，MHP）では，メッセージログ通知を受信できません。

通知を受信するアプリケーションプログラムには，OpenTP1ホームディレクトリを示す環境変数DCDIRを設定しておいてください。この値は，メッセージログを通知するOpenTP1と同じ値にしてください。

OpenTP1のオンライン業務が開始以降のすべてのメッセージログを取得する場合，通知を受信するアプリケーションプログラムはOpenTP1よりも先に開始しておいてください。

(2)　メッセージログの通知の受信手順

通知を受信するアプリケーションプログラムは，受信の開始をdc_log_notify_open関数で宣言します。そして，dc_log_notify_receive関数でメッセージログを受信します。dc_log_notify_receive関数で受信できるメッセージログは一つです。複数のメッセージログを受信するには，dc_log_notify_receive関数を繰り返し呼び出します。

メッセージログの通知の受信を終了するときは，dc_log_notify_close関数を呼び出します。dc_log_notify_close関数を呼び出したあとでdc_log_notify_open関数を呼び出せば，再びメッセージログの通知を受信できます。

通知を受信するアプリケーションプログラムは，OpenTP1が終了したあとでもdc_log_notify_close関数を呼び出すまで待ち続けます。アプリケーションプログラムに受信処理の終了を知らせる場合には，ほかのアプリケーションプログラムからdc_log_notify_send関数でデータを送信します。受信処理の終了を知らせるアプリケーションプログラムでは，dc_log_notify_send関数を呼び出す前にdc_log_notify_open関数を呼び出せません。

メッセージログの通知の受信を次の図に示します。

図3‒80　メッセージログの通知の受信

3.9.6　OpenTP1提供以外のリソースマネジャの制御（TP1/Resource Manager Monitor）

TP1/Resource Manager Monitorを使うと，リソースマネジャの開始と終了を制御できます。

リソースマネジャ制御の概要を次の図に示します。

図3‒81　リソースマネジャ制御の概要

(1)　リソースマネジャを監視する準備

監視する対象のリソースマネジャは，RMMサービス定義のrmm_check_servicesオペランドに指定しておきます。監視する対象のリソースマネジャへの操作は，ユーザがコマンド（シェルファイル）で作ります。そして，作ったコマンドのファイル名を監視対象RM定義に指定します。監視対象RM定義には，次に示すコマンドを指定します。

監視対象RM開始コマンド（rmm_start_commandオペランド）

監視対象RM終了コマンド（rmm_stop_commandオペランド）

監視対象RM強制停止コマンド（rmm_abort_commandオペランド）

監視対象プロセスID取得コマンド（rmm_get_pid_commandオペランド）

上記のコマンドは，サンプルが提供されています。サンプルを業務に合わせて修正すると，コマンドを最初から作成する手間が省けます。サンプルは，$DCDIR/etc/RMmonitor/ ディレクトリの下にあります。

コマンドの作り方については，マニュアル「OpenTP1 運用と操作」を参照してください。定義の方法については，マニュアル「OpenTP1 システム定義」を参照してください。

(2)　監視を開始する時期

リソースマネジャを監視する定義を作成しておくと，OpenTP1を開始するのと一緒にリソースマネジャへの操作が自動的に開始されます。

OpenTP1の開始と参照する定義の関係を次の図に示します。

図3‒82　OpenTP1の開始と参照する定義の関係

3.9.7　稼働統計情報

稼働統計情報は，OpenTP1の稼働状況を表示します。

(1)　稼働統計情報の出力（jnlsttsコマンド，jnlmcstコマンド）

稼働統計情報を出力するときは，アンロードジャーナルファイルから統計用ジャーナルを抽出し，稼働状況を把握できる形式にデータを加工して，リスト形式で標準出力に出力します。稼働統計情報を出力することで，OpenTP1の稼働状況がわかります。

稼働統計情報の出力には，システムサービスとUAPの稼働状況に関するシステム統計情報の出力，トランザクション処理に関するトランザクション統計情報の出力（以上，jnlsttsコマンド），およびメッセージの送受信に関するMCF稼働統計情報の出力（jnlmcstコマンド）があります。

稼働統計情報の出力項目については，マニュアル「OpenTP1 運用と操作」を参照してください。

(2)　MCF稼働統計情報

MCFの稼働統計情報を共用メモリに取得し，統計データとしてUNIXファイルに出力できます。また，出力された統計データを編集して標準出力へ出力できます。

MCF稼働統計情報を使用することによって，MCFの稼働状況を把握できます。

なお，ジャーナルファイルを基にMCFの稼働統計を取得するjnlmcstコマンドとMCF稼働統計情報の機能とは，それぞれ独立した機能です。jnlmcstコマンドで得られる情報は，指定時間間隔内で処理した件数などです。MCF稼働統計情報で得られる情報は，処理が待たされている件数などです。

MCF稼働統計情報の機能は，次の機能から構成されます。番号は下の図中の番号と対応しています。

稼働統計情報取得機能（MCFマネジャ定義のmcfmcomn定義コマンドの-wオプションstatsオペランドにyesを指定）

稼働統計情報出力機能（mcfstatsコマンド）

稼働統計情報編集機能（mcfreportコマンド）

MCF稼働統計情報の機能の概要を次の図に示します。

図3‒83　MCF稼働統計情報の機能の概要

(3)　システム統計情報のリアルタイム出力（dcreportコマンド）

dcreportコマンドを使用すると，システム統計情報を標準出力にリアルタイムに出力したり，メッセージログに出力したりできます。標準出力に出力するシステム統計情報はCSV形式にすることもできます。このコマンドは，システム共通定義のstatisticsオペランドにYを指定した場合，およびdcstatsコマンドでシステム統計情報のジャーナル出力要求を指定した場合に使用できます。

dcreportコマンドを使用してシステム統計情報を取得すると，サービスの実行状況，リソースの負荷状況，障害状況などをリアルタイムに参照できます。

3.9.8　リアルタイム統計情報サービス

リアルタイム統計情報サービスは，システム全体，サーバおよびサービス単位に統計情報を取得します。このリアルタイム統計情報を標準出力やログファイルに出力すると，OpenTP1システムの稼働状況をリアルタイムに把握でき，システムの運用管理や障害復旧を迅速に行えます。

ここでは，リアルタイム統計情報サービスの概要について説明します。リアルタイム統計情報サービスを使用する運用，およびリアルタイム統計情報の取得項目については，マニュアル「OpenTP1 運用と操作」を参照してください。

リアルタイム統計情報サービスでは，次に示すUAPを使用します。

RTSSUP

リアルタイム統計情報サービスを使用する場合に起動させるUAPです。リアルタイム統計情報を取得，出力できます。

RTSSPP

リアルタイム統計情報サービスの拡張機能を使用する場合に起動させるUAPです。拡張機能では，リアルタイム統計情報サービスのオンライン中に，取得する情報の設定を変更できます。

リアルタイム統計情報サービスの概要を次の図に示します。

図3‒84　リアルタイム統計情報サービスの概要

リアルタイム統計情報サービスの機能を次に示します。番号は図中の番号と対応しています。

定義した項目ごとに，システム全体，サーバおよびサービス単位でリアルタイム統計情報を取得します。

リアルタイム統計情報を，RTSサービス用の共用メモリに取得します。リアルタイム統計情報サービスで使用する共用メモリについては，「7.2.2(4)　リアルタイム統計情報サービスで使用する共用メモリ」を参照してください。

UAP内の任意区間の実行時間を，リアルタイム統計情報として取得することもできます。UAP内の任意区間でのリアルタイム統計情報の取得については，マニュアル「OpenTP1 プログラム作成の手引」を参照してください。

RTSサービス用の共用メモリに取得したリアルタイム統計情報を出力します。

標準出力にリアルタイムに出力できます。

RTSログファイルに出力できます。

RTSログファイルに出力した統計情報をCSV形式で編集・出力できます。

リアルタイム統計情報サービスのオンライン中に，取得する情報の設定を変更できます。

3.9.9　OpenTP1の状態確認機能

dcstatusコマンドを使用して，任意のタイミングでオンライン，オフラインなどのOpenTP1の状態を確認できます。

dcstatusコマンドおよびdcstatusコマンドを使用した運用例については，マニュアル「OpenTP1 運用と操作」を参照してください。

3.10　シナリオテンプレートを利用したシステムの運用

OpenTP1の運用手順を，JP1/AJS2 - Scenario Operationが管理するシナリオテンプレートとしてあらかじめ定義できます。シナリオテンプレートを利用すると，システムを自動的に運用できます。シナリオテンプレートは，JP1/AJS2 - Scenario OperationがJP1/AJS - Managerを介して実行します。OpenTP1では，基本的な運用手順を定義したシナリオテンプレートを提供しています。OpenTP1が提供するシナリオテンプレートを使用すると，より簡単にシステムの運用を自動化できます。

JP1/AJS2 - Scenario Operationの詳細説明については，マニュアル「JP1/Automatic Job Management System 2 - Scenario Operation」を参照してください。

シナリオテンプレートを利用したシステムの運用を次の図に示します。

図3‒85　シナリオテンプレートを利用したシステムの運用

注

シナリオテンプレートの入力シナリオ変数を変更することによって，異なるOpenTP1環境にシナリオを実行できます。

（説明）

OpenTP1が提供またはユーザが作成したシナリオテンプレートをJP1/AJS2 - Scenario Operationに登録します。

JP1/AJS2 - Scenario Operationが，JP1/AJSにシナリオを登録します。

JP1/AJSが，OpenTP1にシナリオを実行させます。

OpenTP1がシナリオテンプレートを提供しているシナリオを次に示します。

スケールアウト

新しいOpenTP1ノードを構築して，OpenTP1システムのドメイン構成に新しいノードを追加します。

スケールイン

業務単位またはノード単位で，負荷レベルの低いノードのリソースを解放して，他システムに割り当てます。

ローリングアップデート

システムを停止させることなくOSやUAPのセキュリティ対策パッチを適用します。

シナリオテンプレートの詳細については，マニュアル「OpenTP1 運用と操作」を参照してください。

3.11　監査ログによるシステムの監視

監査ログとは，システム構築者，運用者，および使用者がOpenTP1のプログラムに対して実行した操作，およびその操作に伴うプログラムの動作の履歴が出力されるファイルです。監査者が監査ログを調査することで，「いつ」，「だれが」，「何をしたか」を知ることができます。そのため，システムの使用状況，不正アクセスなどを監査する資料として使用できます。

監査ログには，コマンドなどによる操作を実行したユーザに関する情報，その操作に伴う処理が成功したか失敗したかなどの監査事象に関する情報，操作や処理の対象に関する情報などが出力されます。これらの情報は，システムの監視に役立ちます。

なお，JP1/NETM/Auditと連携すると，監査ログを自動で収集したり，一括管理をしたりすることができるようになります。

監査ログが出力される流れと主な出力項目を次の図に示します。

図3‒86　監査ログが出力される流れと主な出力項目

監査ログが出力される契機になるのは，コマンドの実行など，OpenTP1のプログラムに対する操作です。この操作は，システム管理者，システム運用者など，その作業に応じたユーザが実行します。また，監査ログはOpenTP1の各プロセスで監査事象が発生したタイミングで出力されます。監査事象とは，OpenTP1のプログラムに対して実行した操作，およびその操作に伴うプログラム処理のうち，システムの構築や運用，使用が妥当かどうかを記録する必要がある事象のことです。OpenTP1では，監査事象を次の表に示すとおり分類して定義します。

表3‒24　監査事象の定義

監査事象種別

内容

動作情報

StartStop

ソフトウェアの起動と終了を示す事象です。次の操作が該当します。

OpenTP1の起動・停止

ユーザサーバの起動・停止

Start

開始，起動

Stop

終了，停止

Authentication

クライアントユーザが認証を試みて成功・失敗したことを示す事象です。

Login

ログイン

Logout

ログアウト

Logon

ログオン

Logoff

ログオフ

Disable

アカウントの無効化

AccessControl

管理者やユーザが管理リソースへのアクセスを試みて成功・失敗したことを示す事象です。

Enforce

実施

ConfigurationAccess

管理者やユーザが設定情報に対し変更などの操作を実施して成功・失敗したことを示す事象です。

Refer

参照

Add

追加

Update

更新

Delete

削除

Failure

ソフトウェアの異常を示す事象です。

Occur

発生

LinkStatus

機器間のリンク状態を示す事象です。

Up

リンク活性

Down

リンク非活性

ExternalService

ソフトウェアと外部サービスとの通信結果を示す事象です。

Request

要求

Response

応答

Send

発信

Receive

受信

ContentAccess

重要なデータへのアクセスを試みて成功・失敗したことを示す事象です。

Refer

参照

Add

追加

Update

更新

Delete

削除

Maintenance

管理者や保守員が保守操作を実行して成功・失敗したことを示す事象です。

Install

インストール

Uninstall

アンインストール

Update

更新，アップデート

Backup

バックアップ

Maintain

保守作業

AnomalyEvent

異常な通信の発生を示す事象です。

Occur

発生

ManagementAction

プログラムの重要なアクションの実行を示す事象，またはほかの監査カテゴリを契機として実行するアクションを示す事象です。

Invoke

（管理者の）呼び出し

Notify

（管理者への）通知

監査事象は，監査イベントごとに定義されています。監査イベントの一覧の詳細については，マニュアル「OpenTP1 運用と操作」の監査イベントの出力情報の説明を参照してください。

また，OpenTP1では，UAPから任意に監査ログを出力するAPIを提供します（dc_log_audit_print関数）。このAPIを使用すると，監査イベントのタイミング以外に，UAPの操作の実行，およびUAPによる処理のタイミングで監査ログを出力できます。

UAPから任意に監査ログを出力する実装方法については，マニュアル「OpenTP1 プログラム作成の手引」を参照してください。

3.12　OpenTP1の監視

ハードウェアの障害に起因する一時的なエラーなどによって，ユーザサーバなどを管理するプロセスサービスが無応答になると，ユーザサーバの起動やOpenTP1の停止ができなくなります。この状態を無応答状態と呼びます。この場合，プロセスサービスを強制停止し，OpenTP1を再開始（リラン）する必要があります。

そのため，OpenTP1システムの運用として，プロセスサービスの稼働状態の監視が必要です。監視区間は，ユーザが監視する必要がある区間とシステムが監視する区間に分けられます。プロセスサービスの監視区間を次の図に示します。

図3‒87　プロセスサービスの監視区間

ここでは，システムが監視する区間でOpenTP1（プロセスサービス）を監視する機能について説明します。

3.12.1　HAモニタを使用したOpenTP1の監視

二重化したOpenTP1システムでは，HAモニタでプロセスサービスを監視します。HAモニタのサーバモードでのプロセスサービスの監視では，無応答状態を検知すると，系切り替え機能を使用して無応答状態から復帰させます。系切り替え機能については，「6.1　系切り替え機能」を参照してください。

3.12.2　OpenTP1監視機能を使用したOpenTP1の監視

OpenTP1監視機能とは，OpenTP1監視サービスによってプロセスサービスを監視し，プロセスサービスを無応答状態から自動で復帰させる機能です。HAモニタを使用しないOpenTP1システムでも，無応答状態から復帰できます。

OpenTP1監視機能は，OpenTP1監視サービスの正常稼働が前提となります。そのため，OSパニックやCPUの高負荷状態など，OpenTP1が稼働するマシン全体に影響を及ぼす障害に起因するプロセスサービスの無応答については，ユーザの運用で対処する必要があります。

なお，OpenTP1監視機能は，HAモニタと併用できます。HAモニタ（サーバモード）を使用した系切り替え構成の場合，プロセスサービスの無応答に加え，マシン全体の障害についても監視および系切り替えによって自動復帰できます。そのため，HAモニタを使用したOpenTP1の監視を優先してください。

OpenTP1監視機能の動作（プロセスサービスが無応答状態になった場合）を次の図に示します。

図3‒88　OpenTP1監視機能の動作（プロセスサービスが無応答状態になった場合）

（説明）

プロセスサービスは，OpenTP1監視サービスへ定期的に稼働報告をします。

ハードウェアの障害に起因する一時的なエラーなどによって，プロセスサービスはOpenTP1監視サービスへの稼働報告ができません。

OpenTP1監視サービスは，一定時間（これを無応答監視時間と呼びます）内にプロセスサービスからの稼働報告がないため，無応答状態と判断します。

OpenTP1監視サービスは，プロセスサービスを強制停止します。

再開始（リラン）するため，OpenTP1を強制停止します。

システム環境定義（mode_confオペランド）の指定に従い，手動または自動でOpenTP1を再開始（リラン）します。

プロセスサービスは，OpenTP1監視サービスへの定期的な稼働報告を再開します。

OpenTP1監視機能の運用設計については，マニュアル「OpenTP1 運用と操作」のOpenTP1の監視に関する運用の説明を参照してください。

4　OpenTP1ファイルシステムとファイル

この章では，OpenTP1ファイルシステムの概要と，OpenTP1ファイル（システムで使うファイル，キューを格納するファイル，ユーザデータを格納するファイル），およびISTサービスについて説明します。

4.1　OpenTP1ファイルシステムの概要

OpenTP1は，ファイルの使用効率がよいOSが提供するファイルシステムと，信頼性が高いOpenTP1が提供するファイルシステムを使用しています。OpenTP1で管理するファイルシステムを，OpenTP1ファイルシステムといいます。

4.1.1　ファイルシステム

OSが入出力するディスクは連続領域ごとに分割され，それぞれの領域をパーティションと呼びます。それぞれのパーティションを，OSが提供するファイルシステムまたはOpenTP1ファイルシステムに使用できます。

(1)　OpenTP1ファイルシステムとOpenTP1ファイル

OpenTP1ファイルシステムは，OSが提供するファイルシステムとは独立した，OpenTP1専用のファイルシステムです。キャラクタ型スペシャルファイル，または通常ファイル上にOpenTP1ファイルシステムを作成します。ユーザデータやOpenTP1の回復に必要なジャーナルなど，システムの信頼性に関係する重要な情報を格納するファイルは，OpenTP1ファイルシステム上に作成します。OpenTP1ファイルシステム上に作成するファイルを，OpenTP1ファイルといいます。

系切り替え機能を使用する場合，OpenTP1ファイルシステムはキャラクタ型スペシャルファイル上に作成してください。系切り替え機能については，「6.1.3　系切り替えの手順」を参照してください。

OpenTP1ファイルを次の表に示します。

表4‒1　OpenTP1ファイルの一覧

ファイル名

ファイルの使用方法

ステータスファイル

システムサービスの稼働状態やシステム構成情報を格納して，障害が起こった場合にOpenTP1を回復するときに使います。

システムジャーナルファイル

トランザクション処理の履歴を格納して，障害が起こった場合にOpenTP1を回復するときに使います。また，UAPの履歴（ユーザジャーナル）も格納します。

チェックポイントダンプファイル

回復対象のテーブル情報を格納して，障害が起こった場合にOpenTP1を回復するときに使います。

アーカイブジャーナルファイル

TP1/Multiを使ったクラスタ/並列システムで，各ノードのジャーナルを集積するために使います。

メッセージキューファイル

メッセージ送受信機能（TP1/Message Control）を使ってメッセージをやり取りするときの，待ち行列となるファイルです。TP1/Message Controlをシステムに組み込んでいることが前提です。

ノードリストファイル

ノード自動追加機能を使用する場合，ノードリスト情報を引き継ぐときに，ノードリスト情報を格納し，次回のOpenTP1起動時に使います。

MQAキューファイル

メッセージキューイング機能（TP1/Message Queue）を使うUAPがメッセージを登録したり受け取ったりするときに使用します。TP1/Message Queueをシステムに組み込んでいることが前提です。

DAMファイル

ユーザファイルとして使います。TP1/FS/Direct Accessをシステムに組み込んでいることが前提となります。

TAMファイル

ユーザファイルとして使います。TP1/FS/Table Accessをシステムに組み込んでいることが前提となります。

注

OpenTP1ファイルの運用を支援するため，次に示すファイルも作成できます。

トランザクションリカバリジャーナルファイル（TRF）

処理が長くなるトランザクションのジャーナルを，少なくするために使います。

サーバリカバリジャーナルファイル（SRF）

再開始（リラン）時の回復処理を短縮するために使います。

OpenTP1ファイルシステムとOSが提供するファイルシステムの関係を図4-1に示します。また，OpenTP1ファイルシステムとOSが提供するファイルシステムとの違いを表4-2に，OpenTP1ファイルシステムを作成するファイルの選択方法を図4-2に示します。

図4‒1　OpenTP1ファイルシステムとOSが提供するファイルシステムの関係

表4‒2　OpenTP1ファイルシステムとOSが提供するファイルシステムとの違い

比較項目

OpenTP1ファイルシステム

OSが提供するファイルシステム

キャラクタ型スペシャルファイル上

通常ファイル上

信頼性

OpenTP1が異常終了したとき直前に正常終了した書き込み要求で指定したデータ

同期I/Oのため，書き込み要求が正常終了したデータは保証される

データは保証されない

プロセスが異常終了したとき直前に正常終了した書き込み要求で指定したデータ

電源断などでシステムダウンしたときのディスクファイル

ディスク上の別領域に管理情報を持たないのでファイルの整合性の面で安全性が高い

ディスク上の別領域に管理情報を持つので安全性はキャラクタ型スペシャルファイルよりも低い

ディスク上の別領域に管理情報を持つのでファイルの整合性の面で安全性が低い

ファイル領域の確保

ファイルシステム作成時に領域を事前に確保するのでオンライン中に容量不足となることはない

ファイル増加時にブロックを確保するので，書き込みの延長で容量不足となることがある

性能

ディスク領域の使用効率

OpenTP1ファイル中のレコードが書き込まれていない領域も，そのファイルのために確保済みのため，ほかのファイルに割り当てることはできない

ファイルのサイズが大きくなるときにブロック単位で動的に確保されるので，OpenTP1ファイルと比べて使用効率が良い

読み込みの実行時間（関数がリターンするまでの時間）

バッファキャッシュを経由しないので，それによる効果は得られない

対象データがバッファキャッシュ上でヒットするとディスクから読まないので一般的には速い。ただし，上位でバッファを持って制御するプロセスにとっては二重にバッファリングが行われることになり，逆にオーバヘッドとなるおそれがある

対象データがバッファキャッシュ上でヒットするとディスクから読まないので，一般的には速い

書き込みの実行時間（関数がリターンするまでの時間）

同期I/Oのため，一般的にはOSが提供するファイルシステムより遅いが，バッファキャッシュを経由しない分，書き込み処理のオーバヘッドは小さい

同期I/Oのため，一般的にはOSが提供するファイルシステムより遅い

非同期I/Oのため，一般的には速い

アクセス時間のばらつき

連続領域が確保されるので，ばらつきは小さい

必ずしも連続領域とはならないので，ばらつきがある

ばらつきがある

運用

ファイル容量の見積もり

ファイルの作成時に容量を指定する必要がある

ファイルの容量を指定する必要はない

ファイル容量の動的増分

増分できない

増分できる

ディレクトリによるファイルの分類

できない

できる

図4‒2　OpenTP1ファイルシステムを作成するファイルの選択方法

(2)　通常ファイル

通常ファイルは，柔軟性があり使用効率がよいという特長があります。このため，OpenTP1の定義ファイルなどに使用します。

OpenTP1で使用する通常ファイルを次の表に示します。

表4‒3　OpenTP1で使用する通常ファイル

ファイル名

ファイルの用途

備考

ユーザプログラムファイル

UAPの実行形式プログラムを格納するファイルです。

ユーザが作成します。

各種定義ファイル

OpenTP1の各種システム定義を格納します。OSのテキストエディタを使用して，テキストファイルとして作成します。

マップファイル

XMAP3を使ったクライアントと通信する場合に使用します。物理マップを格納します。

OpenTP1プログラムファイル

OpenTP1のプログラムを格納します。OpenTP1の実行形式ファイルとUAPの作成に使うファイルがあります。

インストール時に自動的に作成されます。

定義解析用ファイル

OpenTP1の内部で，定義解析用に使用します。

メッセージオブジェクトファイル

メッセージテキストを格納します。

コマンドログファイル

OpenTP1のコマンドログを格納します。

メッセージログファイル

OpenTP1が出力したシステムメッセージを格納します。

OpenTP1実行時に作成されます。

MCFトレースファイル

MCFのトレース情報を格納します。

スケジュールキュー情報ファイル

OpenTP1の内部で，スケジュールキュー情報を格納します。

RPCトレースファイル

RPCトレースを格納します。

トレース情報ダンプファイル

OpenTP1内部のトレース情報を格納するファイルです。

共用メモリダンプファイル

OpenTP1が出力した共用メモリの内容を格納します。

退避コアファイル

異常終了したプロセスのコアファイルを退避します。

デッドロック，タイムアウト情報ファイル

デッドロック情報，タイムアウト情報を格納します。

MCFダンプファイル

MCFのダンプを格納します。

未決着トランザクション情報ファイル

障害発生時，未決着のトランザクション情報を格納します。

不正ジャーナル情報ファイル

ジャーナル読み込み時に検知した不正なジャーナル情報を格納します。

入出力キューの内容複写ファイル

入出力キューの内容複写コマンドを実行したときに入出力キューの内容を格納します。

性能検証用トレース情報ファイル

性能検証用のトレース情報を格納するファイルです。

XAR性能検証用トレース情報ファイル

XAリソースサービスを使用したトランザクション連携の各種イベントのトレース情報を格納するファイルです。

JNL性能検証用トレース情報ファイル

ジャーナルサービスのトレース情報を格納するファイルです。

LCK性能検証用トレース情報ファイル

ロックサービスを使用した排他制御の各種イベントのトレース情報を格納するファイルです。

MCF性能検証用トレース情報ファイル

MCFを使用したメッセージ送受信の各種イベントのトレース情報を格納するファイルです。

TRNイベントトレース情報ファイル

トランザクションブランチで呼び出されるXA関数や，トランザクションサービスの各種イベントのトレース情報を格納するファイルです。

NAMイベントトレース情報ファイル

ネームサービスで実行される通信処理，キャッシュへのサービス情報の登録，削除などの各種イベントのトレース情報を格納するファイルです。

プロセスサービスイベントトレース情報ファイル

プロセスサービスのトレース情報を格納するファイルです。

FILイベントトレース情報ファイル

OpenTP1ファイルへのアクセス要求に対して，システム共通定義のfil_prf_trace_delay_timeオペランドの指定値以上の処理時間が掛かった場合に，イベント情報を格納するファイルです。

RTSログファイル

リアルタイム統計情報を格納するファイルです。

UAPトレース編集出力ファイル

UAPが異常終了した場合に，UAPトレースを自動的に編集出力して格納したファイルです。

OpenTP1デバッグ情報ファイル

UAPが異常終了した場合に，OpenTP1の情報を格納するファイルです。

MCF稼働統計情報ファイル

MCFの稼働統計情報を格納するファイルです。

マッピングエラー情報ファイル

マッピング時に発生したエラー情報を格納するファイルです。

4.1.2　OpenTP1ファイルシステムの作成方法

OpenTP1管理者はfilmkfsコマンドを使って，キャラクタ型スペシャルファイルまたは通常ファイル上にOpenTP1ファイルシステム領域を作成します。

OpenTP1ファイルシステム領域を作成したあとに，ジャーナルファイルの種類別に物理ファイルを割り当てます。物理ファイルを割り当てるコマンドを次に示します。

ステータスファイル：stsinitコマンド

システムジャーナルファイル：jnlinitコマンド

チェックポイントダンプファイル：jnlinitコマンド

メッセージキューファイル：queinitコマンド

ノードリストファイル：namnlcreコマンド

MQAキューファイル：mqainitコマンド

DAMファイル：damloadコマンド

TAMファイル：tamcreコマンド

キャラクタ型スペシャルファイル上のOpenTP1ファイルシステムに作成した物理ファイルの完全パス名の例を次に示します。

次に，OpenTP1管理者はシステムサービス定義（システムジャーナルサービス定義など）で，物理ファイルが実際に入出力するOpenTP1ファイル（論理ファイル，ファイルグループなど）として使えるように設定します。OpenTP1ファイルの作成手順については，マニュアル「OpenTP1 運用と操作」を参照してください。

OpenTP1ファイルシステムの構造を次の図に示します。次の図は，キャラクタ型スペシャルファイル上にOpenTP1ファイルシステムを作成する例です。実際には，システムの信頼性や性能などを考慮してOpenTP1ファイルシステムを複数作り，OpenTP1ファイルを分散する必要があります。

図4‒3　キャラクタ型スペシャルファイル上にOpenTP1ファイルシステムを作成する例

4.1.3　OpenTP1ファイルシステムのバックアップとリストア

OpenTP1ファイルには，OpenTP1のプロセスの回復などに使用する重要な情報が入っています。OpenTP1ファイルを破壊から守るため，定期的（OpenTP1の開始前など）にfilbkupコマンドでOpenTP1ファイルシステムごと，またはOpenTP1ファイルごとにOpenTP1ファイルのバックアップを取得しておいてください。バックアップを取得しておけば，OpenTP1ファイルが破壊された場合でも，filrstrコマンドでOpenTP1ファイルをリストアして回復できます。

OpenTP1ファイルシステムのバックアップとリストアを次の図に示します。

図4‒4　OpenTP1ファイルシステムのバックアップとリストア

ユーザファイルを回復するOpenTP1の機能を次に示します。

ユーザファイルをバックアップ，リストアするコマンド

dambkupコマンド，damrstrコマンド

tambkupコマンド，tamrstrコマンド

システムジャーナルファイルを複写したファイルとバックアップしたユーザファイルを基に，ユーザファイルを回復する機能

DAM FRC機能

TAM FRC機能

バックアップとリストアおよびユーザファイルの回復手順については，マニュアル「OpenTP1 運用と操作」を参照してください。

4.1.4　OpenTP1ファイルの保護

操作の誤りでファイルを破壊することは絶対に避けなければなりません。そして，重要なファイル（オンラインを続行するための制御情報，会社の業務情報など）ほど厳重な保護をしなければなりません。ここでは，OpenTP1ファイルの保護について説明します。

(1)　OpenTP1ファイルシステム単位の保護

OpenTP1ファイルシステム単位にファイルの所有者とアクセス権を管理して，不意な破壊からファイルを保護しておきます。ファイルへのアクセス権は，OSのコマンド（例　chmodコマンド）を使って設定します。

ファイル所有者の区別：OpenTP1管理者，OpenTP1グループ

ファイルのアクセス権：読み書きできる，読むことができる

システムジャーナルファイル，チェックポイントダンプファイル，ステータスファイルは，OpenTP1がオンラインを続行するために重要なファイルです。このため，特定のOpenTP1管理者とOpenTP1グループのユーザしか操作できないOpenTP1ファイルシステム（システム用）に割り当てることが必要です。

ユーザファイル，メッセージキューファイル，MQAキューファイルは，上記以外のユーザが操作できた方が使いやすいため，システム用ファイルとは別のOpenTP1ファイルシステム（ユーザ用）にすることが必要です。

このように，OpenTP1ファイルの種類や使い勝手を判断して，システム構築前にOpenTP1ファイルシステムをシステム用とユーザ用に分けておく必要があります。

OpenTP1ファイルシステムをシステム用とユーザ用に分けた場合の保護（所有者とアクセス権）の例を次の表に示します。

表4‒4　OpenTP1ファイルシステムの保護（所有者とアクセス権）の指定例

OpenTP1ファイルシステム

所有者

アクセス権

ユーザID

グループID

所有者

グループ内のユーザ

そのほかのユーザ

システム用

OpenTP1管理者

OpenTP1グループ

rw

r-

r-

ユーザ用

OpenTP1管理者

OpenTP1グループ

rw

rw

r-

（凡例）

rw：読み書きができる。

r- ：読むことができる。

(2)　OpenTP1ファイル単位の保護

OpenTP1管理者は，オンライン中にfilchownコマンドでOpenTP1ファイル単位に所有者とアクセス権を動的に変更できます。これによって，オンライン中にOpenTP1ファイルの使用を特定のユーザに認めたり認めなかったりできます。

OpenTP1ファイルの保護については，マニュアル「OpenTP1 運用と操作」を参照してください。

4.1.5　OpenTP1ファイルシステムの割り当て

ファイルの種類ごとにディスクを分けてOpenTP1ファイルシステムを作成すれば，性能や信頼性を向上できます。しかし，ファイルの種類の数だけディスクを用意しなければならないため，コストが高くなります。

一つのディスクにすべてのファイルシステムを作成すれば，コストを低く抑えられます。しかし，ディスクが破壊された場合にすべてのファイルが使えなくなるため，信頼性は良くありません。

ファイルの構成を決めるときに考慮する，代表的な項目を次に示します。

ハードウェア構成上の考慮

キャラクタ型スペシャルファイル上にOpenTP1ファイルシステムを作成する場合，ディスクの構成が決まっているときには，OpenTP1ファイルシステムに割り当てられるパーティション数とその容量を知っておく必要があります。

システム構成上の考慮

システム構成上の機能から，必要なOpenTP1ファイルの種類を決めます。例えば，TP1/Message Controlを使わない場合は，メッセージキューファイルは必要ありません。

一日のトランザクション発生数などから，システムジャーナルファイルやチェックポイントダンプファイルの容量を決めます。また，メッセージ送受信数やそのメッセージ長などから，メッセージキューファイル容量を決めます。

信頼性の考慮

OpenTP1ファイルシステムを重要度別に分けることが必要です。

例えば，システム用のOpenTP1ファイルシステムとユーザ用のOpenTP1ファイルシステムに分けます。

システム用：システムジャーナルファイル，チェックポイントダンプファイル，ステータスファイル，ノードリストファイル

ユーザ用：メッセージキューファイル，MQAキューファイル，ユーザファイル

性能上の考慮

アクセスが集中する複数のファイルを一つのディスクに割り当てると，データの入出力時間が掛かり性能が悪くなります。これを防ぐため，アクセスが集中するファイル同士はディスクを分ける必要があります。

最適なファイル構成にするためには，上記の項目などを考慮して性能・信頼性・コスト・操作性などを総合的に判断する必要があります。

4.2　システムで使うファイル

障害に備えるため，OpenTP1で各種の内部情報を取得するファイルをシステムファイルといいます。OpenTP1で使うシステムファイルを次に示します。

ステータスファイル

システムジャーナルファイル

チェックポイントダンプファイル

トランザクションリカバリジャーナルファイル（TRF）

サーバリカバリジャーナルファイル（SRF）

アーカイブジャーナルファイル

ノードリストファイル

4.2.1　ステータスファイル

(1)　ステータスファイルの目的

前回のOpenTP1が，dcstopコマンドを入力して終了したか，障害が起こって異常終了したかを判断して，再開始処理を自動化するためのデータを格納します。OpenTP1を開始するために引き継がなければならないシステム制御情報を，状態が変化した時点で格納します。システム制御情報には，次のようなものがあります。

OpenTP1の終了状態

開始処理中，稼働中，終了処理中などシステムサービスやUAPの稼働状況

システムファイルとユーザファイルのオープン・クローズ状態

MCFで接続している各種装置の接続状態

(2)　ステータスファイルの構成

ステータスファイルは，OpenTP1を開始するためのきわめて重要なファイルです。ステータスファイルに何らかの障害が起こった場合でもOpenTP1を開始できるように，二つのステータスファイルを組にして二重化します。組になった二つのステータスファイルを論理ファイルといい，個々のステータスファイルをそれぞれA系，B系と呼んで区別します。ステータスサービス定義で，論理ファイルを7個まで指定し，論理ファイルとステータスファイルの対応関係を定義します。

二つのステータスファイルが同時に障害にならないように，A系のステータスファイルとB系のステータスファイルは，なるべくディスクを分けてください。組になるA系とB系のステータスファイルの容量とレコード長は，同じでなければなりません。

ユーザは，ステータスサービス定義で論理ファイルに任意の名称を指定します。この論理ファイル名を使用することで，A系，B系のステータスファイルを同時にオープン，クローズするなど，論理ファイル単位に運用できます。

(a)　ステータスファイルの片系運転

オンライン中にステータスファイルに障害が発生して，予備ファイルがない場合でも，異常終了しないで正常な系だけで処理を続けられます。これをステータスファイルの片系運転といいます。片系運転をするかどうかは，ステータスサービス定義に指定します。

片系運転中にシステムで障害が発生した場合，再開始のための情報が失われるため，再開始ができません。片系運転に切り替わったことを知らせるメッセージログが出力された場合は，使用できる予備ファイルを早急に用意して，正常な運転に復帰させてください。

(3)　ステータスファイルの状態

ステータスファイルは次の状態に分けられます。

現用

現時点でシステム制御情報の出力対象になっているオープン中の状態です。ファイルの実体が必要です。

予備

現時点でシステム制御情報の出力対象にはなっていないが，現用のステータスファイルが入出力障害などで使用できなくなったときに，現用のステータスファイルと切り替えるためにオープン中の状態です。ファイルの実体が必要です。

無効

ステータスサービス定義に指定されているが，オープンしないとオンラインでは使用できないクローズ中の状態です。また，削除されて実体のない状態を，実体なしの無効ファイルといいます。OpenTP1開始時にファイルの実体がない無効ファイルがあると，OpenTP1は開始できません。

閉塞

オンライン中に障害が発生し，閉塞しているクローズ中の状態です。

OpenTP1は，OpenTP1の開始時に，ステータスサービス定義で指定したすべてのステータスファイルをオープンします。オープンしたステータスファイルのうちステータス情報の出力対象となっているファイルを現用ファイルといい，オープン中のその他のファイルを予備ファイルといいます。ステータスファイルに障害が発生しないかぎり，ステータス情報は常に同じステータスファイルに格納されます。

システム制御情報は，まずA系のステータスファイルに書き込まれ，その後B系のファイルに書き込まれます。このため，A系ファイル書き込み中にOpenTP1が異常終了し，A系ファイルが利用できなくなっても，B系ファイルは元の状態を保っているので，全面回復時にB系ファイルを読み込むことで再開始できます。

(4)　ステータスファイルのスワップ

ステータスファイルは論理ファイル単位で現用ファイルを切り替えます。A系またはB系のステータスファイルに入出力障害が発生すると，OpenTP1は正常な系のステータスファイルからシステム制御情報を予備の論理ファイルに複写します。システム制御情報は，まず正常な系のファイルを予備のA系ファイルに複写し，次に予備のB系ファイルに複写します。複写が終わると，現用と予備を切り替えます。

予備の論理ファイルがない場合には，OpenTP1は異常終了します。OpenTP1が異常終了した場合の処置は，「5.3　障害対策の概要」を参照してください。ただし，ステータスファイルの片系運転をする指定があれば，片系運転となります。

障害の発生によって閉塞したステータスファイルは，stsrmコマンドで削除し，容量を変更して再作成できます。stsrmコマンドで削除できるのは，閉塞・無効状態のファイルです。現用・予備ファイルは削除できません。

ステータスファイル内のシステム制御情報は，スワップすることでステータスファイルの先頭から再編成されます。OpenTP1の開始・終了を繰り返すとステータスファイルにフラグメンテーションが発生することがあります。このため，OpenTP1は必要に応じて自動的にステータスファイルをスワップしてフラグメンテーションを解消します。

ステータスファイルのスワップを次の図に示します。ステータスファイルに障害が発生した場合の処理については，「5.3　障害対策の概要」を参照してください。

図4‒5　ステータスファイルのスワップ

4.2.2　システムジャーナルファイル

(1)　システムジャーナルファイルの目的

オンラインシステムが停止した場合の全面回復や，UAPに障害が発生した場合のUAP部分回復に必要な，回復用の履歴情報を格納します。回復用の履歴情報には，同期点ジャーナルと回復用ジャーナルがあります。全面回復の処理では，最新の世代のチェックポイントダンプと，最新の世代のチェックポイントダンプ取得以降に取得した回復用のジャーナルを基にします。UAPの部分回復ではチェックポイントダンプを使用しないで，回復用のジャーナルだけで処理します。チェックポイントダンプについては，「4.2.3　チェックポイントダンプファイル」を参照してください。

回復用のジャーナルとは別に，システムをチューニングするための統計用ジャーナルや，UAPの任意の履歴情報であるユーザジャーナルも格納します。

(2)　システムジャーナルファイルの構成

OpenTP1は，システムジャーナルファイルをファイルグループという論理的な単位で運用します。これに対して，実際にジャーナルを取得するファイル実体を，物理ファイルといいます。通常一つのファイルグループは，一つの物理ファイルで構成しますが，ジャーナルファイル二重化機能を使用する場合は，一つのファイルグループを二つの物理ファイルで構成します。この場合，一つのファイルグループ中の，二つの物理ファイルをA系，B系と呼んで区別します。

システムジャーナルサービス定義では，ファイルグループを少なくとも二つ以上指定し，ファイルグループと物理ファイルの対応関係を指定してください。さらにシステムジャーナルサービス定義でファイルグループに任意の名称を指定してください。このファイルグループ名を使用することで，A系，B系の物理ファイルを同時にオープン，クローズするなど，ファイルグループ単位に運用できます。

(3)　システムジャーナルファイルの二重化

一つのファイルグループを二つの物理ファイルで構成してシステムジャーナルファイルを運用できます。これをシステムジャーナルファイルの二重化といいます。この場合，OpenTP1はA系，B系に同じジャーナルを取得します。何らかの異常が発生し，その処理のためにジャーナルを読み込むとき，片方の系が障害でも残りの系を読めるため，信頼性を向上できます。

組になるA系とB系の物理ファイルは，同時に障害にならないように，なるべくディスクを分けてください。また，A系とB系の物理ファイルの容量は，一致していなくてもかまいませんが，容量が一致していない場合には，容量の少ないファイルに合わせてジャーナルを取得します。なるべく容量を一致させてください。

システムジャーナルファイルを二重化した場合，片系運転可，片系運転不可を選択できます。ファイルグループを構成する二つの物理ファイルのうち，一つが使用できる状態ならファイルグループを使用可能な状態とすることを片系運転可といいます。ファイルグループを構成する二つの物理ファイルが両方使用できる状態の場合にだけ，ファイルグループを使用可能な状態とすることを片系運転不可といいます。

例えば，ファイルグループfg1，fg2があり，それぞれが物理ファイルfg1a，fg1b，fg2a，fg2bで構成されているとします。物理ファイルの障害は，ディスクデバイス全体の障害である場合が多く，同一ディスク上の物理ファイルがすべて障害になることが多いのです。A系の物理ファイルfg1aとfg2aが障害になった場合，片系運転不可では，使用可能なファイルグループがなくなるので，OpenTP1は異常終了します。このため，障害を対策後，全面回復することになります。片系運転可では，B系の物理ファイルfg1b，fg2bが正常な限りファイルグループは使用可能なので，OpenTP1は続行可能です。

このように片系運転可とは，片方の系が障害になっても，その障害が対策されるまでの間に残りの系で運転を続行させるものです。ただし，片系運転可では，一時的に二重化されない期間が発生するため，この部分は信頼性が低下します。片系運転可，片系運転不可はシステムジャーナルサービス定義で指定します。

片系運転可，片系運転不可を次の図に示します。

図4‒6　片系運転可，片系運転不可

(4)　システムジャーナルファイルの並列アクセス機能

一つのファイルグループを複数の要素ファイルで構成して，システムジャーナルファイルを使えます。この機能をシステムジャーナルファイルの並列アクセス機能といいます。並列アクセス機能で二重化した場合のファイルグループの構成を次の図に示します。

図4‒7　並列アクセス機能使用時のファイルグループの構成図（jnl_max_file_dispersion=3の場合）

並列アクセス機能の概要を次の図に示します。

図4‒8　並列アクセス機能の概要（jnl_max_file_dispersion=3の場合）

ジャーナルの入出力が集中すると，ディスクへの負荷が増大しI/O性能が低下します。このような場合に，ファイルグループを複数の要素ファイルで構成して，システムジャーナルファイルへ並行にアクセスできるようにすると，ジャーナルの入出力の性能を上げることができます。

一つのファイルグループを構成する物理ファイルは，SCSIインタフェースやハードディスクが重なるようになっていてもかまいませんが，これらには並行にアクセスできないため，並列アクセス機能の効果を十分に発揮できません。SCSIインタフェースやハードディスクは，重ならないようにしてください。また，複数の物理ファイルの容量は一致していなくてもかまいませんが，一致していない場合，OpenTP1は最も少ない物理ファイルの容量を要素ファイルの容量と見なします。資源を効率良く使えるように，物理ファイルの容量はできるだけ一致させることをお勧めします。

システムジャーナルファイルの並列アクセス機能では，システムジャーナルファイルの障害などで，並行してアクセスできる要素ファイルの数（以降，並列アクセス数といいます）が減ります。これによるジャーナル入出力性能の低下を防ぐため，最低限保証したい並列アクセス数を指定できます。この最低限保証したい並列アクセス数を，最小分散数といいます。また，最大でどれだけ並列アクセスするかを示す並列アクセス数を，最大分散数といいます。

システムジャーナルサービス定義でファイルグループを指定するときに，要素ファイル名を付けます。さらに，システムジャーナルサービス定義のjnl_max_file_dispersionオペランドに最大分散数を，jnl_min_file_dispersionオペランドに最小分散数を指定しておきます。

(5)　取得するジャーナルの種類

(a)　同期点ジャーナル

全面回復時やUAP部分回復時に，未決着のトランザクションを決着して資源の整合性を回復する必要があります。トランザクションが決着しているかいないか，同期点での処理がどこまで進んでいるのかを判断するために，2相コミットの過程で履歴情報を取得します。資源の回復が必要かどうかを判定するこの履歴情報を，同期点ジャーナルといいます。同期点ジャーナルには，PJ，HJ，BJ，TJ，DJがあります。同期点ジャーナルを次の表に示します。

表4‒5　同期点ジャーナル

種別

内容

PJ

ルートトランザクションブランチ，トランザクションブランチがコミット処理を開始したときに出力されます。

HJ

トランザクションブランチがコミット準備完了の状態になったときに出力されます。

ルートトランザクションブランチからは出力されません。

BJ

トランザクションをロールバックしたときに出力されます。

ルートトランザクションブランチ，トランザクションブランチから出力されます。

TJ

トランザクションの同期点処理を終了したときに出力されます。

ルートトランザクションブランチ，トランザクションブランチから出力されます。

DJ

トランザクションをヒューリスティック決定したときに出力されます。

ルートトランザクションブランチ，トランザクションブランチから出力されます。

(b)　回復用ジャーナル

全面回復時や部分回復時に，同期点ジャーナルによって資源を回復する必要がある場合，直ちにデータベースや回復対象テーブルのデータを回復します。資源の整合性を回復するため，資源の更新情報を取得します。この更新情報を，回復用ジャーナルといいます。回復用ジャーナルには，回復する資源の種類によって，FJとCJがあります。回復用ジャーナルを次の表に示します。

表4‒6　回復用ジャーナル

種別

内容

FJ

DAMファイルの更新情報です。全面回復時とUAP部分回復時に，このジャーナルを基にDAMファイルを回復します。

CJ

MCFサービスとTAMサービスが管理する回復対象テーブルの更新情報です。同期点取得時などに取得します。全面回復時にこのジャーナルを基に回復テーブルを回復します。

トランザクション管理サービスが管理する回復対象テーブルの更新情報です。同期点取得時などに取得します。全面回復時にこのジャーナルを基に回復テーブルを回復します。

(c)　統計用ジャーナル

システムチューニングに必要な統計用の履歴情報です。統計用ジャーナルには，MJ，IJ，GJ，OJ，AJ，SJがあります。

MJ，IJ，GJ，OJ，AJは，MCFを使用して他システムとメッセージ送受信するときにだけ取得します。MJは，mcftactmjコマンドを入力して取得を開始し，mcftdctmjコマンドを入力して取得を終了します。IJ，GJ，OJを取得するかどうかは，MHPのアプリケーションごとにアプリケーション属性定義で指定します。AJを取得するかどうかは，論理端末ごとに論理端末定義で指定します。

SJはOpenTP1システム全体の統計情報です。SJのうちシステム統計情報は，統計取得用の運用コマンドを入力すると，それ以降ユーザの指定した一定間隔で取得します。トランザクション統計情報は，トランザクションサービス定義で取得するかどうかを指定します。統計用ジャーナルを次の表に示します。

表4‒7　統計用ジャーナル

種別

内容

MJ

入力編集前のメッセージ入力情報と，出力編集後のメッセージ出力情報です。

IJ

受信メッセージを入力キューに格納する直前に取得するメッセージ入力情報です。

GJ

MHPが受信メッセージを受け取る直前に取得するMHP受信情報です。

OJ

送信メッセージを出力キューに格納した直後に取得するメッセージ出力情報です。

AJ

メッセージを他システムに送信したあと，他システムからの送信完了報告を受信した直後に取得する送信完了情報です。

SJ

OpenTP1の稼働状態全般を把握するための稼働統計情報です。システム統計情報とトランザクション統計情報があります。システム統計情報は，システムサービスとUAPに関する統計情報です。一定時間ごとにOpenTP1の状態を取得します。トランザクション統計情報は，トランザクション処理に関する統計情報です。トランザクションブランチごとに同期点処理が完了した時点で取得します。

(d)　ユーザジャーナル（UJ）

UAPから関数を呼び出してシステムジャーナルファイルに出力する，ユーザ任意の情報です。ユーザジャーナルは，システムのチューニングやユーザ業務そのものに利用します。ユーザジャーナルは，トランザクション内，またはトランザクション外で出力できます。

(6)　システムジャーナルファイルの状態

システムジャーナルファイルのファイルグループの状態は，次の2種類に分けられます。

使用可能状態

ファイルグループを構成する要素ファイルのうち，最小分散数以上の要素ファイルがオープンされている状態

使用不可能状態

ファイルグループを構成する要素ファイルのうち，最小分散数以上の要素ファイルがオープンされていない状態

使用可能状態のファイルグループは，現用，または待機として，使用不可能状態のファイルグループは予約として，状態を管理します。なお，要素ファイルの必要数は，システムジャーナルサービス定義に指定した値で決まります。

現用

現時点でジャーナルの出力対象になっている使用可能状態のファイルグループです。この状態のファイルグループは，常に一つです。

待機

現時点でジャーナルの出力対象になっていませんが，現用に変更するために待機している使用可能状態のファイルグループです。

待機の状態は，次の二つに分けられます。

次回スワップ先にできる状態

上書きできる（回復に必要なジャーナルがない）状態で，かつアンロード済み状態の待機ファイルグループです。

次回スワップ先にできない状態

上書きできない状態，またはアンロード待ち状態の待機ファイルグループです。

予約

使用不可能状態のファイルグループです。

システムジャーナルファイルには，予約以外のファイルグループが二つ以上必要です。

OpenTP1を正常開始で開始すると，システムジャーナルサービス定義で指定したファイルグループのうち，ONLと指定したファイルグループがすべてオープンされます。オープンされたファイルグループのうち，最初に指定したファイルグループが現用となって，そのほかは待機となります。また，構成する物理ファイルが必要な数に満たなかったファイルグループや，ONLと指定しなかったファイルグループは，予約となります。

システムジャーナルファイルでは，常に現用のファイルグループにジャーナルが出力されます。現用のファイルグループが満杯になると，待機のファイルグループのうち一つを現用に切り替えます。このとき，以前の現用ファイルグループは，待機ファイルグループになります。使用可能状態のすべてのファイルグループが満杯となると，最初のファイルグループに戻ってジャーナルを出力します。

(7)　システムジャーナルファイルのアンロード

待機のシステムジャーナルファイルのジャーナルは，ファイルに複写しておく必要があります。ファイルにジャーナルを複写することを，アンロードといいます。システムジャーナルファイルのアンロードには，jnlunlfgコマンドを使用するか，またはシステムジャーナルサービス定義のjnl_auto_unloadオペランドにYを指定して自動アンロード機能を使用します。ユーザファイルの回復や統計用ジャーナルの編集，ユーザジャーナルの運用は，ファイルにアンロードしたジャーナルを使います。ジャーナルをアンロードしたファイルを，アンロードジャーナルファイルといいます。OpenTP1は，ファイルグループがアンロードされているかどうかチェックして，アンロードされていない待機ファイルグループはスワップ先にしません。ファイルグループがアンロードされているかどうか，チェックすることをアンロードチェックといいます。スワップ先がない場合には，OpenTP1は異常終了します。OpenTP1が異常終了したときの処置は，「5.3　障害対策の概要」を参照してください。

(a)　アンロードチェックの抑止

通常はアンロード待ち状態になる待機のファイルグループを，現用のまま使える指定ができます。これをアンロードチェックの抑止といいます。アンロードチェックを抑止する場合は，システムジャーナルサービス定義のjnl_unload_checkオペランドにNを指定してください。

アンロードチェックを抑止している場合は，OpenTP1の稼働中にジャーナルファイルをコマンドでアンロードしないでください。アンロードチェックの抑止を指定した場合にアンロードを実行するときは，いったんjnlclsfgコマンドで該当するファイルグループをクローズしてから，アンロードしてください。

アンロードチェックを抑止するとアンロードジャーナルファイルは作成されないため，アンロードジャーナルファイルを入力とするジャーナル編集コマンド（jnlcolcコマンド，jnlsttsコマンドなど）は実行できません。

アンロードチェックを抑止した場合は，ファイルグループの状態をjnllsコマンドで確認すると，アンロード待ち状態が出力されることがあります。アンロード待ち状態が出力された場合でも，実際は現用として使われています。

(8)　システムジャーナルファイルのスワップ

待機状態のシステムジャーナルファイルには，スワップ先にできるものとスワップ先にできないものとがあります。スワップ先にできるシステムジャーナルファイルは，アンロード済みで，回復に必要なジャーナルがないファイルグループです。アンロードしていないファイルグループ，または回復に必要なジャーナルがあるファイルグループは，スワップ先にできません。回復に必要なジャーナルがあるかどうかのチェックについては，「4.2.3(4)　複数世代保証機能」を参照してください。システムジャーナルファイルのスワップ先がない場合には，OpenTP1は異常終了します。OpenTP1が異常終了したときの処置は，「5.3　障害対策の概要」を参照してください。システムジャーナルファイルのスワップを次の図に示します。

図4‒9　システムジャーナルファイルのスワップ

(9)　全面回復時の予約状態のファイルのオープン

オンライン障害発生後の全面回復時，OpenTP1はトランザクションを決着するためのジャーナルを出力します。このとき，システムジャーナルファイルにジャーナルを格納しきれなくなった場合には，OpenTP1は再び異常終了します。全面回復時にジャーナルファイルが不足したとき，予約状態のファイルをオープンして，ジャーナルを格納できます。予約状態のファイルをオープンするかどうか，システムジャーナルサービス定義で指定します。なお，アンロードすればスワップ先としてジャーナルを格納できる，上書きできる状態のシステムジャーナルファイルがある場合は，予約状態のファイルをオープンしません。jnlunlfgコマンドでジャーナルファイルをアンロードしてください。

(10)　ジャーナル容量に対する考え方

(a)　理想的なジャーナル容量

理想的なジャーナル容量は，OpenTP1起動から停止までの間に取得されるジャーナルすべてを格納できるだけの容量です。これが実現できると，OpenTP1稼働中にジャーナルをアンロードする運用が不要となり，OpenTP1停止後にジャーナルファイルのメンテナンスができます。

理想となる目安：
（トランザクション当たりの平均ジャーナル量）
×（オンライン開始から終了までの総トランザクション数）
＋オンライン開始から終了までにdcstatsコマンドによって取得する統計情報のジャーナル量
＋（UAPのOpenTP1のRPC，1回当たりのジャーナル量）
×（オンライン開始から終了までのUAPから発行するOpenTP1のRPCの回数の総和）

ジャーナルの容量の計算式の詳細は，マニュアル「OpenTP1 運用と操作」のシステムジャーナルファイルのサイズの見積もり式の記述を参照してください。

(b)　現実的なジャーナル容量の見積もり

実際の運用では，24時間稼働，ディスク容量を確保できないなどの理由で理想どおりのジャーナル容量を用意できないことがあります。

OpenTP1は，ジャーナルをアンロード，またはステータスを変更することでジャーナルファイルを再利用可能としており，この機能を使用することで理想とする容量より小さいジャーナル容量で運用を行えます。

ジャーナルのアンロードを行う場合，アンロードするタイミングをどのようにするかのシステム運用設計が必要です。例えば，次のような運用が考えられます。

ジャーナルファイルがスワップした時点のメッセージ（KFCA01222-I）をトリガーにアンロードする。

OpenTP1が提供する自動アンロード機能を使用することでアンロードさせる。

運用でまとめてアンロードする（例えば，午前と午後の間にアンロードするなど）。

ジャーナルのアンロードを行わないで，ジャーナルを捨てる運用を行う場合，jnlchgfgコマンドで強制的にアンロード済みの状態に変更したり，システムジャーナルサービス定義のjnl_unload_checkオペランドにNを指定したりすることで，ジャーナルファイルを再利用可能にできます。

上記運用で，アンロードまたはジャーナルを捨てることで，ジャーナルファイルの再利用が可能となり，ジャーナル容量を減らせます。

(c)　ジャーナル容量見積もりの注意事項

ジャーナル容量を減らす場合，ジャーナルの総容量が小さすぎるとアンロード処理中にジャーナルファイルを使いきり，OpenTP1ダウンとなるおそれがあります。このため次の点に注意してください。

ジャーナルファイルが一周するまでの時間 ＞ ジャーナルアンロード処理時間
（ジャーナルアンロードする時間に対して，ジャーナルファイル出力に追いつかれないようにすることが必要です）

(d)　ジャーナルとチェックポイントダンプの関係

チェックポイントダンプを取得すると，その時点より過去のジャーナルファイルについては再利用できます。

チェックポイントダンプは，次の契機で取得されます。

システムジャーナルファイルがスワップしたとき。

システムジャーナルサービス定義で指定した数のジャーナルブロックをシステムジャーナルファイルに格納したとき。

システムサービスの開始・終了時。

チェックポイントダンプ取得中にスキップが発生し，その取得が完了したとき。

ただし，チェックポイントダンプは取得してもすぐに有効にはなりません。チェックポイントダンプを取得するタイミングで動作していたトランザクションがすべて完了するまで有効化を待ち合わせています。

次のケースでは，(1)のチェックポイントダンプ取得時点で動作していたTRN1，TRN2，TRN3がすべて完了するまで有効になりません。(5)のタイミングで有効化できるかチェックした時点でTRN1，TRN2，TRN3がすべて完了していることが確認できるため，このタイミングで(1)で取得したチェックポイントダンプが有効となります（(1)より後に発生したTRN5は，(1)のタイミングのチェックポイントダンプ対象とはならないで，次のチェックポイントダンプの対象となります）。

チェックポイントダンプの有効化に時間が掛かるようなケースでは，ジャーナルファイルが再利用可能となるまでの時間も遅れることになるため，OpenTP1ダウンとなるおそれがあります。

このような事態を想定し，ジャーナルとチェックポイントダンプの関係は次のようになるよう設計してください。

チェックポイント取得時間 ≪ ジャーナルファイルが一周するまでの時間

（チェックポイント取得時間に対して，ジャーナルファイル出力に追いつかれないようにすることが必要です）

チェックポイントの有効化に要した時間は，OpenTP1のシステム統計情報から求められます。「チェックポイント有効化（取得時間）」が上記の(1)から(5)の時間を示しています。この時間を目安にし，さらに十分な余裕を持った時間を見込んでジャーナルファイルの容量を見積もってください。

(e)　運用監視

OpenTP1のシステムダウンを未然防止するため，次のようなシステムメッセージを監視し，マニュアル「OpenTP1　メッセージ」に従った運用対処を行うようシステム設計してください。

(i) 再利用可能なジャーナル不足の監視

再利用可能なジャーナルがなくなると，KFCA01220-Eメッセージを出力し，OpenTP1は緊急停止（システムダウン）します。この状態になる前に，警告として次のメッセージを出力します。

KFCA01224-I aaaa(xx....xx)ジャーナルには，次のスワップ要因の発生時に交代先として使用できるファイルグループがありません。

再利用可能なジャーナルファイルが1つしか残っていない状態です。このまま放置するとOpenTP1ダウンとなる危険性があります。至急ジャーナルファイルを追加するか，再利用可能になっていないファイルに対して対処をしてください。

(ii) チェックポイントダンプ有効化遅れの監視

チェックポイントダンプ取得契機に，長時間有効化できない状態の場合は，警告として次のメッセージを出力します。

KFCA02179-I aa....aaサービスのチェックポイントダンプ取得契機をスキップしました。　スキップ回数＝bb....bb　ジャーナル世代番号cc....cc　要因コード＝ddd-ee

チェックポイント取得契機になりましたが，処理をスキップしています。チェックポイントダンプ取得処理が走行中のため，再利用可能なジャーナルファイルが減少しています。ジャーナルファイルの状態およびトランザクション状態を確認して対処してください。

(iii) 自動アンロード機能停止の監視

自動アンロード機能使用時に障害が発生した場合，警告として次のメッセージを出力して，自動アンロード機能を停止します。

KFCA01173-W aaaa(xx....xx)ジャーナルファイルの自動アンロード機能を停止しました。理由コード=bbbb

KFCA01174-W aaaa(xx....xx)自動アンロード処理中ですが，処理を中断します。理由コード=bbbb

KFCA01178-E aaaa(xx....xx)自動アンロードの処理中に障害が発生しました。理由コード=bbbb

自動アンロード機能を停止します。障害要因を取り除いたあと，自動アンロード機能を再開始してください。

KFCA01179-W aaaa(xx....xx)自動アンロード先ディレクトリを切り替えることができません。切り替え先:bb....bb, 理由コード=cccc

定義されているディレクトリに自動アンロード先ディレクトリを切り替えます。定義されているすべての自動アンロード先ディレクトリが使用できない場合は，自動アンロード機能を停止します。障害要因を取り除いたあと，自動アンロード機能を再開始してください。

4.2.3　チェックポイントダンプファイル

(1)　チェックポイントダンプファイルの目的

オンラインシステムが停止した場合，回復用のジャーナルだけで回復すると，オンライン開始からのすべてのジャーナルが必要となり，回復に膨大な時間が掛かります。そこでオンライン運転中に一定の間隔でポイントを設け，そのポイントで回復する必要のあるテーブルの状態を保存することで，ポイント以前の回復用ジャーナルの必要をなくして，回復時間の短縮を図ります。このポイントをチェックポイントといい，チェックポイントで取得するテーブル情報をチェックポイントダンプといいます。オンラインシステムの全面回復には，最新のチェックポイントダンプの取得からオンラインシステム停止までの間で取得した，回復用のジャーナル全部が必要です。

OpenTP1は，システムサービスごとに回復処理しているため，メモリ上のテーブルを回復する必要があるシステムサービスごとに，チェックポイントダンプを取得しています。チェックポイントダンプを格納するファイルは，システムサービスごとに割り当てます。このファイルをチェックポイントダンプファイルといいます。

チェックポイントダンプは，次のタイミングで取得します。

システムジャーナルファイルがスワップしたとき

システムジャーナルサービス定義で指定した数のジャーナルをシステムジャーナルファイルに格納したとき

システムサービスの開始・終了時

(2)　チェックポイントダンプファイルの構成

チェックポイントダンプファイルは，ファイルグループという論理的な単位で管理されます。これに対して，実際にチェックポイントダンプを取得するファイルの実体を，物理ファイルといいます。一つのファイルグループは，一つまたは二つの物理ファイルで構成されます。

一つのファイルグループを二つの物理ファイルで構成する形態をチェックポイントダンプファイルの二重化といいます。二重化する場合は，それぞれの物理ファイルをA系，B系と区別します。

チェックポイントダンプファイルが必要なシステムサービスは，チェックポイントダンプサービス定義にシステムサービス名，ファイルグループ，および物理ファイルの対応関係を指定します。

チェックポイントダンプサービス定義では，ファイルグループに任意の名称を指定します。このファイルグループ名を使用してチェックポイントダンプファイルを運用します。

チェックポイントダンプファイルのファイルグループは次のような状態に分けられます。

上書きできる，または書き込み中の状態：

OpenTP1システムの全面回復時に使用するチェックポイントを含まないので上書きできるオープン中の状態，またはチェックポイントダンプを取得中の状態です。

上書きできない状態：

OpenTP1システムの全面回復時に使用するチェックポイントダンプを含んでいるために，上書きを抑止しているオープン中の状態です。

予約：

オープンしないとオンラインで使用できない，クローズ中の状態です。定義しただけで実体がない場合にもこの状態になります。

チェックポイントダンプサービス定義で，OpenTP1の開始と同時にオープンするファイルグループを定義します。オープンすると定義しなかったファイルグループは，開始時に予約の状態になります。

1回に取得するチェックポイントダンプを世代といいます。一つの世代を一つのチェックポイントダンプファイルグループに取得するため，ファイルグループを世代ごとに切り替えます。用意したファイルグループすべてにチェックポイントダンプを取得すると，最初のファイルグループに戻ってデータを上書きします。このように，上書きしながら複数のファイルグループにデータを格納していく方式を，ラウンドロビン方式といいます。通常，最新の世代を取得したファイルグループを上書きできない状態にし，そのほかのファイルグループを上書きできる状態にしますが，複数世代保証機能を使用する場合は，二世代のファイルグループを上書きできない状態にします。

ラウンドロビン方式によるチェックポイントダンプの取得を次の図に示します。

図4‒10　ラウンドロビン方式によるチェックポイントダンプの取得

(3)　チェックポイントダンプファイルの物理ファイルを追加

オンライン中にチェックポイントダンプファイルに障害が起こり，運用に必要なファイル数に足りなくなった場合，物理ファイルを動的に追加できます。動的に追加する方法は，事前に予約ファイルを定義しておくかどうかで異なります。

(a)　定義していない物理ファイルをオンライン中に追加する方法

チェックポイントダンプサービス定義に指定していない物理ファイルでも，運用コマンドでオンライン中に追加できます。まず，jnladdpfコマンドで追加する物理ファイルをファイルグループに割り当てます。そして，jnlopnfgコマンドでファイルグループをオープンします。これでチェックポイントダンプファイルのオンライン中の追加が完了します。

(b)　予約ファイルを事前に定義しておく方法

チェックポイントダンプサービス定義に事前に予約ファイルを定義してある場合は，jnlopnfgコマンドでオープンする方法と，OpenTP1が自動的にオープンする方法（自動オープン機能）で，ファイルを割り当てられます。

自動オープン機能を使うと，オンライン中に物理ファイルが有効保証世代数にまで減った場合，予約ファイルを現用ファイルとして自動的に割り当てることができます。自動オープン機能を使用する場合は，チェックポイントダンプサービス定義に自動オープンを指定します。

(c)　チェックポイントダンプファイルの物理ファイルを削除

動的に追加した物理ファイルに限り，ファイルグループが予約状態であれば，jnldelpfコマンドで削除できます。

(4)　複数世代保証機能

何らかの異常が発生し，最新世代のファイルグループを読み込めない場合でも，一世代前のファイルグループを読み込んで回復処理をすることで，信頼性を向上させることができます。回復処理に備えて，一世代前のファイルグループを上書きできない状態にして保存しておく機能を，複数世代保証機能といいます。最新世代も含めて，上書きできない状態にした世代を有効保証世代といい，上書きできない状態の世代の数を有効保証世代数といいます。複数世代保証機能を使用した場合の有効保証世代数は2，使用しない場合は1になります。

OpenTP1は，有効保証世代での回復に必要なジャーナルを持つシステムジャーナルファイルのファイルグループを，上書きできない状態にします。有効保証世代に基づくシステムジャーナルファイルの上書きチェックを，オーバライトチェックといいます。

(a)　複数世代保証機能を使用した場合の回復手順

複数世代保証機能を使用した場合，まず最新世代のファイルグループを読み込みます。そして，最新世代のチェックポイント以降に取得した全ジャーナルを使用して回復処理をします。何らかの異常が発生して最新世代のファイルグループが読み込めないときには，一世代前のチェックポイントダンプファイルを読み込みます。このときには，一世代前のチェックポイント以降に取得した全ジャーナルを使用して回復処理をします。有効保証世代のファイルグループがすべて読み込めないときには，さらに世代をさかのぼりますが，有効保証世代以前のジャーナルが上書きされて回復できないことがあります。オンライン中に予備以外の状態のチェックポイントダンプファイルのファイルグループ数は，「有効保証世代数+1」以上，必要です。有効保証世代とシステムジャーナルファイルの関係を次の図に示します。

図4‒11　有効保証世代とシステムジャーナルファイル

(b)　縮退運転機能を使用した場合の有効保証世代数

オンライン中，または再開始処理中に，運用に必要なファイル数「有効保証世代数+1」を下回った場合でも，最低二つのファイルが使用できれば，処理を続けられる指定もできます。これをチェックポイントダンプの縮退運転といいます。縮退運転をするかどうかは，チェックポイントダンプサービス定義で指定します。

縮退運転中にOpenTP1システムで障害が発生した場合は，再開始のための情報が一つのファイルでしか保証されていないことになります。縮退運転となったときには，通常の運転から縮退運転に切り替わった旨を伝えるメッセージログが出力されます。このメッセージログが出力された場合は，有効保証世代として使用するファイルを早急に準備してください。

有効保証世代として使用できるファイルが確立できた場合，縮退運転の状態から通常の運転に切り替わった旨を伝えるメッセージログが出力されます。

(5)　有効保証世代とジャーナル容量の関連

システムジャーナルファイルの容量は，チェックポイントダンプファイルの有効保証世代数に比例して，必要になります。システムジャーナルファイル全体でのジャーナルブロック数の目安は，次のとおりです。

チェックポイントダンプを取得する間隔となるジャーナルブロック数×（有効保証世代数＋1）

(6)　チェックポイントダンプファイルを二重化したときの運用

チェックポイントダンプファイルを二重化してファイルグループを運用した場合，OpenTP1はA系，B系に同じチェックポイントダンプを取得します。二重化しておくと，チェックポイントダンプの読み込み時に片方の系で障害が起こっても，残った系からデータを読み込めるため，信頼性が上がります。

(a)　チェックポイントダンプサービス定義の指定

チェックポイントダンプファイルを二重化する場合は，チェックポイントダンプサービス定義のjnl_dualオプションにYを指定します。このとき，一つのファイルグループに二つの物理ファイル（A系，B系）を指定しておきます。

A系とB系の物理ファイルは，同時に障害にならないようにディスクを分けることをお勧めします。また，A系とB系の物理ファイルの容量は，一致していなくてもかまいませんが，一致していない場合OpenTP1は少ない容量の方をチェックポイントダンプの容量と見なします。資源を効率良く使えるように，容量はできるだけ一致させておいてください。

(b)　チェックポイントダンプファイルの片系運転

チェックポイントダンプファイルを二重化するとき，一方の物理ファイルに障害が発生した場合，次のどちらかの運用を選択できます。

片系運転可

A系とB系のどちらかの系の物理ファイルがオープン状態であれば，ファイルグループをオープン状態とするものです。どちらかの系の物理ファイルに障害が発生しても，正常な系で，処理を続行できます。これによって，正常な系のチェックポイントダンプを有効にできます。

片系運転不可

A系とB系の両方の物理ファイルがオープン状態でなければ，ファイルグループを予約状態とするものです。どちらかの系の物理ファイルに障害が発生した場合，ファイルグループも予約状態となります。なお，A系からの読み込み時に障害が発生した場合，B系から読み込んだあとにファイルグループを予約状態にします。

(c)　二重化した場合の運用上の注意

片系運転不可の場合，片方の系だけに対するオープン，クローズなどの操作はできません。

片系運転可の場合，片方の系だけに対する操作はできます。ただし，上書きできないファイルグループに対するクローズは，どちらの場合もできません。

片系運転可と片系運転不可の場合の相違点を次の表に示します。

表4‒8　片系運転可と片系運転不可の場合の相違点

操作内容

運用方法

片系運転可

片系運転不可

一方の系だけをオンライン中に割り当てる

割り当てられます。

割り当てられます。

一方の系だけをオンライン中に削除する

削除できます。

削除できます。

一方の系だけをオープンする

両方の系が割り当てられていれば，オープンできます。

オープンできません。

一方の系だけをクローズする（上書きできない状態）

クローズできません。

クローズできません。

一方の系だけをクローズする（上書きできる状態）

クローズできます。

クローズできません。

(7)　チェックポイントダンプ取得契機のスキップ回数の監視

UAPの無限ループなどが発生すると，チェックポイントダンプの取得処理が連続してできない（チェックポイントダンプ取得契機がスキップされる）ことがあります。チェックポイントダンプが取得できないままオンライン処理を続行すると，回復に必要なシステムジャーナルファイルが多くなり，最終的には使用できるシステムジャーナルファイルが不足して，システムダウンすることがあります。

チェックポイントダンプ取得契機のスキップ回数を監視することで，このようなシステムダウンを防止できます。これによって，チェックポイントダンプ取得契機のスキップが一定の回数に達した場合に，トランザクションの実行プロセスを強制的に停止して，トランザクションを決着（コミットまたはロールバック）します。チェックポイントダンプ取得契機のスキップ回数を監視するためには，チェックポイントダンプサービス定義にjnl_cdskip_limitオペランドを指定します。

また，チェックポイントダンプサービス定義にjnl_cdskip_msgオペランドを指定すれば，チェックポイントダンプ取得契機がスキップされた場合に，スキップ要因となっているトランザクションの情報をKFCA32550-Iメッセージで表示することもできます。

4.2.4　トランザクションリカバリジャーナルファイル

(1)　トランザクションリカバリジャーナルファイルの目的

トランザクションリカバリジャーナルファイル（TRF）とは，システムジャーナルファイルとは別に，トランザクションに関する各種のジャーナル情報を，トランザクションブランチ（UAPプロセス）ごとに取得するファイルです。TRFは$DCDIR/spool/dctjlinf/ディレクトリ下に，trfXXXXXXXX（Xは任意の整数）というファイル名でUNIXファイルとして作成されます。そのため，系切り替え構成ではTRFを使用できません。

トランザクション処理では，一つの処理が長時間掛かることが原因で，トランザクションで更新した資源のジャーナル情報が，複数のシステムジャーナルファイルにわたって取得されることがあります。トランザクション処理の途中でオンラインが停止した場合，この資源を回復するためには複数のシステムジャーナルファイルを読み込む必要があります。このため，回復に時間が掛かります。

また，使用中のシステムジャーナルファイルはスワップ先にできないため，システムジャーナルファイルの容量や数によっては，トランザクション処理が終了するまでの間に，システムジャーナルファイルのスワップ先がなくなってしまうことがあります。システムジャーナルファイルのスワップ先がなくなると，OpenTP1は異常終了します。

このような事態を避けるため，長時間掛かるトランザクション処理のジャーナルを，システムジャーナルファイルとは別のファイル（TRF）に格納します。TRFを作成することで，回復時に読み込むジャーナルの量を削減できます。また，長時間のトランザクションの実行中でも，使用中のシステムジャーナルファイルをスワップ先にでき，チェックポイントダンプを有効化できます。そのため，再開始時の回復時間を短縮できます。さらに，長時間掛かるトランザクション処理のために，ジャーナル情報のオーバフローによるOpenTP1システムの異常終了を防げます。処理が長時間となるUAPでは，TRFを取得することをお勧めします。ただし，TRFを取得した場合，システムジャーナルファイルとTRFに同じジャーナルを取得するため，トランザクション性能が悪くなります。

TRFを取得するかどうかは，サービスグループごとに，ユーザサービス定義で指定します。

(2)　トランザクションリカバリジャーナルファイルの障害時の回復方法

再開始処理中にTRFに障害が発生した場合には，その旨を伝えるメッセージログが出力されます。このメッセージログが出力された場合は，jnlmkrfコマンドでTRFを回復してください。TRFの回復にはアンロードジャーナルファイルを使用します。

4.2.5　サーバリカバリジャーナルファイル

(1)　サーバリカバリジャーナルファイルの目的

サーバリカバリジャーナルファイル（SRF）とは，システムジャーナルファイルとは別に，各種のジャーナル情報を，システムサービスごとに取得するファイルです。SRFを使用することで，再開始時のジャーナル読み込みをシステムサービスごとにできます。そのため，再開始時の回復時間を短縮できます。

(2)　サーバリカバリジャーナルファイルの作成方法

SRFは，$DCDIR/spool/dcsjl/ディレクトリの下に，xxx_nn（xxxはシステムサービスの名称，nnは任意の整数）というファイル名で，OpenTP1で自動的に取得されます。

(3)　サーバリカバリジャーナルファイルの障害時の回復方法

再開始処理中にSRFに障害が発生した場合には，その旨を伝えるメッセージログが出力されます。このメッセージログが出力された場合は，jnlmkrfコマンドでSRFを回復してください。SRFの回復にはアンロードジャーナルファイルを使用します。

4.2.6　アーカイブジャーナルファイル

(1)　アーカイブジャーナルファイルの目的

クラスタ/並列システム形態でOpenTP1を使用する場合，システムジャーナルファイルを各ノードにアンロードする必要があります。この負担を軽減するために，各OpenTP1ノードのシステムジャーナルファイルを，専用のOpenTP1ノードにアーカイブできます。アーカイブしたファイルをアンロードするだけで，ほかのOpenTP1ノードのシステムジャーナルファイルをアンロードする必要がなくなります（グローバルアーカイブジャーナル機能）。アーカイブ専用のOpenTP1ノードで使用するファイルをアーカイブジャーナルファイルといいます。グローバルアーカイブジャーナル機能を使用すると，ノードごとにジャーナルをアンロードする必要がなくなります。

グローバルアーカイブジャーナルでは，アーカイブするジャーナルの種類を選択できます。選択するジャーナルの種類は，システムジャーナル定義のjnl_arc_rec_kindに選択するジャーナルレコード種別を指定します。ジャーナルの種類については，「4.2.2　システムジャーナルファイル」を参照してください。

グローバルアーカイブジャーナル機能については，「6.2.3　グローバルアーカイブジャーナル機能」を参照してください。

(2)　アーカイブジャーナルファイルの種類

アーカイブジャーナルファイルは，最大16種類を作成できます。複数作成したファイルは，アーカイブするノードの範囲で分けられます。個々のアーカイブジャーナルファイルは，システムジャーナルファイルと同様に，物理ファイルとファイルグループ単位で管理されます。

使用目的別に分けたアーカイブジャーナルファイルのまとまりをリソースグループといいます。グローバルアーカイブジャーナルサービスは，リソースグループ名を使ってアーカイブジャーナルファイルを管理します。一つのリソースグループにアーカイブできるノードは，20ノードまでです。

リソースグループは，アーカイブジャーナルサービス定義のファイル名を示します。アーカイブジャーナルノードでリソースグループを幾つ使うかは，グローバルアーカイブジャーナルサービス定義で指定します。

(3)　アーカイブジャーナルファイルの作成

アーカイブジャーナルファイル作成するときは，jnlinitコマンドでOpenTP1ファイルシステム上に物理ファイルを作成して，アーカイブジャーナルサービス定義で指定します。

リソースグループを定義するアーカイブジャーナルサービス定義では，ファイルグループ名と要素ファイル名，および物理ファイル名を指定します。

物理ファイル名

OpenTP1ファイルの実体を表すパス名

要素ファイル名

アーカイブジャーナルファイルの並列アクセス機能を使うときに，物理ファイルに対応して任意に付ける名称

要素ファイルは，二重化できます。ファイルグループ名は，一つ以上の要素ファイルのまとまりに対応して任意に付ける名称です。アーカイブジャーナルファイルの並列アクセス機能を使わない（ファイルグループを構成する要素ファイルが一つだけ）場合は，要素ファイル名を省略できます。なお，ファイルグループを構成する要素ファイルの数は，最大8個です。

アーカイブジャーナルファイルを使う前に，ファイルグループごとにOpenTP1の開始と同時にオープンするかを事前に指定しておきます。また，コマンドの引数にファイルグループ名を指定して，アーカイブジャーナルファイルをファイルグループ単位で操作できます。なお，一つのリソースグループには，二つ以上のファイルグループが必要です。

(4)　アーカイブジャーナルファイルの並列アクセス機能

一つのファイルグループを複数の要素ファイルで構成して，アーカイブジャーナルファイルを使えます。この機能をアーカイブジャーナルファイルの並列アクセス機能といいます。

アーカイブジャーナルファイルでは，複数のノードのジャーナルをアーカイブする入出力が集中します。このため，アーカイブジャーナルファイルの入出力がアーカイブするジャーナルの発生に追い付けなくなる場合があります。このような場合に，ファイルグループを複数の要素ファイルで構成してアーカイブジャーナルファイルへ並行にアクセスできるようにすると，アーカイブの性能を上げることができます。

一つのファイルグループを構成する物理ファイルは，SCSIインタフェースやハードディスクが重なるようになっていてもかまいませんが，これらには並行にアクセスできないため，並列アクセス機能の効果を十分に発揮できません。SCSIインタフェースやハードディスクは，重ならないようにしてください。また，複数の物理ファイルの容量は，一致していなくてもかまいませんが，一致していない場合OpenTP1は少ない容量の方をファイルグループの容量と見なします。資源を効率良く使えるように，容量はできるだけ一致させておいてください。

アーカイブジャーナルファイルの並列アクセス機能では，アーカイブジャーナルファイルの障害などで，並行してアクセスできる要素ファイルの数（以降，並列アクセス数といいます）が減ります。これによって，アーカイブするジャーナルの発生にアーカイブジャーナルファイルの入出力が追い付けなくなることを防ぐため，最低限保証したい並列アクセス数を指定できます。この最低限保証したい並列アクセス数を，最小分散数といいます。また，最大でどれだけ並行してアクセスするかを示す値を，最大分散数といいます。

アーカイブジャーナルサービス定義でファイルグループを指定するときに，要素ファイル名を付けます。さらに，アーカイブジャーナルサービス定義のjnl_max_file_dispersionオペランドに最大分散数を，jnl_min_file_dispersionオペランドに最小分散数を指定しておきます。

(5)　アーカイブジャーナルファイルの二重化

一つの要素ファイルを二つの物理ファイルから構成して，アーカイブジャーナルファイルを二重化して使えます。二重化してファイルグループを運用した場合，OpenTP1はA系，B系に同じジャーナルを取得します。二重化しておくと，障害発生によるジャーナルの読み込み時に片方の系で障害が起こっても，残った系からデータを読み込めるため，信頼性が上がります。

(a)　アーカイブジャーナルファイル定義の指定

アーカイブジャーナルファイルを二重化する場合は，アーカイブジャーナルファイル定義のjnl_dualオプションにYを指定します。このとき，一つのファイルグループに二つの物理ファイル（A系，B系）を指定しておきます。

A系とB系の物理ファイルは，同時に障害にならないようにディスクを分けることをお勧めします。また，A系とB系の物理ファイルの容量は，一致していなくてもかまいませんが，一致していない場合OpenTP1は少ない容量の方をジャーナルの容量と見なします。資源を効率良く使えるように，容量はできるだけ一致させておいてください。

(b)　片系運転可と片系運転不可

アーカイブジャーナルファイルを二重化した場合には，片系運転可または片系運転不可のどちらかを選べます。

片系運転可

要素ファイルを構成する二つの物理ファイルのうち，一つが使用できる状態であれば，要素ファイルを使える状態にします。

片系運転不可

要素ファイルを構成する二つの物理ファイルが両方とも使える状態のときだけ，要素ファイルを使える状態にします。

片系運転可とするかどうかは，アーカイブジャーナルサービス定義で指定します。

片系運転可では，片方の系が障害になっても，その障害が対策されるまでの間，残りの系で運転を続けます。ただし，この場合，一時的に二重化されない時期が起こるため，この期間は信頼性が下がります。

(6)　アーカイブジャーナルファイルの状態

アーカイブジャーナルファイルの状態は，システムジャーナルファイルと同様に，次の2種類に分けられます。

使用可能状態

ファイルグループを構成する要素ファイルのうち，必要な数以上，使用できる要素ファイルがある状態

使用不可能状態

ファイルグループを構成する要素ファイルのうち，必要な数以上，使用できる要素ファイルがない状態

使用できる要素ファイルとは，その要素ファイルを構成する物理ファイルが必要な数だけオープンされていることを意味します。逆に，要素ファイルを構成する物理ファイルが必要な数だけオープンされていない場合は，その要素ファイルは使用できません。

使用可能状態のファイルグループは，現用または待機として，使用不可能状態のファイルグループは予約として，状態を管理します。なお，要素ファイルの必要数と物理ファイルの必要数は，アーカイブジャーナルサービス定義に指定した値で決まります。

現用

現時点でジャーナルの出力対象になっている使用可能状態のファイルグループです。この状態のファイルグループは，常に一つです。

待機

現時点でジャーナルの出力対象になっていませんが，現用に変更するために待機している使用可能状態のファイルグループです。

待機の状態は，次の二つに分けられます。

次回スワップ先にできる状態

上書きできる（回復に必要なジャーナルがない）状態で，かつアンロード済み状態の待機ファイルグループです。

次回スワップ先にできない状態

上書きできない状態，またはアンロード待ち状態の待機ファイルグループです。

予約

使用不可能状態のファイルグループです。

アーカイブジャーナルファイルには，予約以外のファイルグループが二つ以上必要です。

(7)　アーカイブジャーナルファイルのアンロード

アーカイブジャーナルファイルがアンロード待ち状態になった場合は，jnlunlfgコマンドでアンロードしてください。アーカイブジャーナルファイルのファイルグループがアンロードされていない状態でスワップ先がなくなった場合，グローバルアーカイブジャーナルサービスは異常終了します。

アンロードした通常ファイルは，システムジャーナルファイルの場合と同様に，DAMファイルの回復や稼働統計情報ファイルの編集ができます。また，ユーザジャーナルをオフラインのプログラムへ引き継げます。

グローバルアーカイブアンロードジャーナルファイルには，複数のOpenTP1ノードのシステムジャーナル情報が入っています。このジャーナルをマージした稼働統計情報の編集，および複数のOpenTP1ノードのジャーナルを時系列にソートするなど，各種のジャーナル編集ができます。

(a)　アンロードチェックの抑止

通常はアンロード待ち状態になる待機のファイルグループを，現用のまま使える指定ができます。これをアンロードチェックの抑止といいます。アンロードチェックを抑止する場合は，アーカイブジャーナルサービス定義のjnl_unload_checkオペランドにNを指定してください。

アンロードチェックを抑止している場合は，OpenTP1の稼働中にジャーナルファイルをコマンドでアンロードしないでください。アンロードチェックの抑止を指定した場合にアンロードを実行するときは，いったんjnlclsfgコマンドで該当するファイルグループをクローズしてから，アンロードしてください。

アンロードチェックを抑止するとグローバルアーカイブアンロードジャーナルファイルは作成されないため，グローバルアーカイブアンロードジャーナルファイルを入力とするジャーナル編集コマンド（jnlcolcコマンド，jnlsttsコマンドなど）は実行できません。

アンロードチェックを抑止した場合は，ファイルグループの状態をjnllsコマンドで確認すると，アンロード待ち状態が出力されることがあります。アンロード待ち状態が出力された場合でも，実際は現用として使われています。

(8)　システムジャーナルファイルの状態

グローバルアーカイブジャーナルサービスを使っているOpenTP1のシステムジャーナルサービスでは，次に示すジャーナルファイルの状態が追加となります。

アーカイブ済み/未アーカイブ

アーカイブジャーナルファイルに転送，または出力されたファイルグループかどうかの状態

該当するノードでアンロードが済んでいなくても，アーカイブ済みで上書きできる状態のファイルグループであれば，次回のスワップ先にできるファイルグループとなります。

(9)　アーカイブジャーナルファイルのスワップ

待機のアーカイブジャーナルファイルには，スワップ先にできるものとできないものがあります。スワップ先にできるアーカイブジャーナルは，アンロード済みのファイルグループです。アンロードしていないファイルグループは，スワップ先にできません。アーカイブジャーナルファイルのスワップ先がない場合，OpenTP1は異常終了します。OpenTP1が異常終了した場合の処置は，「5.3.3　ファイル障害の対策」を参照してください。

アーカイブジャーナルファイルのスワップを次の図に示します。

図4‒12　アーカイブジャーナルファイルのスワップ

4.2.7　ノードリストファイル

(1)　ノードリストファイルの目的

ノード自動追加機能でノードリストを引き継ぐ場合に必要なファイルです。ノードリストを引き継ぐと，オンライン中にノードリストの情報を一定間隔でノードリストファイルへ書き込みます。

次のOpenTP1の開始時には，ノードリストファイルからノードリストの情報を引き継いでOpenTP1を開始します。これによりオンライン後すぐに，前回起動時と同等のOpenTP1システム構成でRPC要求ができます。

ノードリストファイルがない場合は，ノードリストの整合性が確保されるまでの間，RPCのサービス要求先が制限されます。この制限を解除するために，ノード自動追加機能を使用する場合は，ノードリストファイルを作成し，ノードリストを引き継ぐことをお勧めします。

(2)　ノードリストファイルに格納する情報

ノードリストファイルには，動作モード，マネジャノード情報，ノードリスト情報などを格納します。nammstrコマンドで変更した動作モードを格納し，次回OpenTP1開始時にこれらの情報を引き継げます。

ノードリストファイルに格納する情報について，次の表に示します。

表4‒9　ノードリストファイルに格納する情報

情報の種類

内容

動作モード

ノードの動作モード（マネジャノード，またはエージェントノード）を格納します。

この情報によって，OpenTP1起動時の動作モードを決定します。

動作モードの取得に失敗した場合は，システム共通定義のname_service_modeの指定に従って，動作モードを決定します。

マネジャノード情報

エージェントノードの場合，マネジャノードに関するノード情報を格納します。

マネジャノードの場合は，格納されません。

エージェントノードの場合，このマネジャノード情報を基にノードリストの取得要求をします。

マネジャノード情報の取得に失敗した場合は，ネームサービス定義のname_start_errorオペランドの指定値に従います。

ノードリスト情報

そのノードがオンライン中に保持しているノード情報の一覧を格納します。

(3)　ノードリストファイルの作成

ノードリストファイルは，namnlcreコマンドを実行して作成します。OpenTP1ファイルシステム上に物理ファイルが作成されます。作成後は，OpenTP1のオンライン中に一定間隔でノード情報が書き込まれます。

4.3　キューを格納するファイル

メッセージ送受信機能およびメッセージキューイング機能で使うOpenTP1ファイルを，次に示します。

メッセージキューファイル

メッセージ送受信機能（TP1/Message Controlを使った通信）で使います。

MQAキューファイル

メッセージキューイング機能（TP1/Message Queueを使った通信）で使います。

4.3.1　メッセージキューファイル

(1)　メッセージキューファイルの目的

メッセージキューファイルは，MCFを使って相手システムとメッセージを送受信するときに使用する，OpenTP1ファイルシステム上のファイルです。入出力メッセージ用のディスクキューとして使用します。

入力キューは，入力メッセージを管理する待ち行列です。出力キューは，出力メッセージを管理する待ち行列です。

(2)　メッセージキューファイルの構成

OpenTP1は，メッセージキューファイルを，キューグループという論理的な単位で運用します。これに対して，実際に入出力メッセージを取得するファイル実体を物理ファイルといいます。一つのキューグループは，一つの物理ファイルで構成します。メッセージキューファイルは，入力キュー用と出力キュー用に2種類作成します。ネットワークコミュニケーション定義の入出力キュー定義で，キューグループを入力キュー用と出力キュー用に対応づけます。また，入力キュー用と出力キュー用それぞれにメッセージキューサービス定義を作成し，キューグループと物理ファイルの対応関係を指定します。

ユーザは，メッセージキューサービス定義でキューグループに任意の名称（ID）を指定します。このキューグループIDを使用して，物理ファイルの使用率を監視するなど，メッセージキューファイルをキューグループ単位で運用します。

一つのキューグループをサービスグループ，または論理端末対応に分割して利用します。キューグループをサービスグループ，または論理端末ごとに分割した単位を，キューファイルといいます。対応するサービスグループ名，または論理端末名称がキューファイル名になります。

入力メッセージはサービスグループごと，出力メッセージは論理端末ごとにスケジュールされます。キューグループをサービスグループごと，論理端末ごとに分割して使用することで，同一資源にアクセスする場合の性能が向上します。

キューグループとキューファイルの関係を，次の図に示します。

図4‒13　キューグループとキューファイルの関係

メッセージキューファイルを使用したメッセージ送受信については，「3.3.9　アプリケーションプログラムのメッセージ送受信」を参照してください。

4.3.2　MQAキューファイル

(1)　MQAキューファイルの目的

MQAキューファイルとは，メッセージキューイング機能（TP1/Message Queue）を使う場合にキューを格納するファイルです。メッセージキューイング機能のキューとは，UAPから登録されたメッセージを格納する待ち行列です。

MQAキューファイルに登録したメッセージは，キューマネジャ（TP1/Message Queue）が通信相手に送信します。MQAサービス定義，およびMQIの設定によって，必要なメッセージを受信した順序に関係なく取り出すこともできます。さらに，MQAキューファイルにメッセージを格納して，データ処理をほかのUAPに引き継ぐこともできます。

MQAキューファイルの構成，キューの種類，および操作方法については，マニュアル「TP1/Message Queue 使用の手引」を参照してください。

4.4　ユーザデータを格納するファイル

OpenTP1の業務処理で使用する，ユーザデータを格納するファイル（ユーザファイル）について説明します。OpenTP1で使用できるユーザファイルには，次の3種類があります。

DAMファイル

OpenTP1専用の直接編成ファイルとして使用します。

TAMファイル

テーブルアクセス法で高速にアクセスできる，OpenTP1専用の直接編成ファイルとして使用します。

ISAMファイル

X/OpenのISAMモデルに準拠した索引順編成ファイルとして使用します。ISAMファイルについては，マニュアル「索引順編成ファイル管理 ISAM」を参照してください。

OpenTP1のユーザファイルは，すべてOpenTP1ファイル上に作成します。

上記のほかに，共用メモリ上のテーブルにアクセスする機能（ISTサービス）や，データベースマネジメントシステム（DBMS）で管理するユーザファイルも，OpenTP1で使えます。

4.4.1　DAMファイル（TP1/FS/Direct Access）

DAMファイルサービスを使うと，OpenTP1ファイルシステム上のOpenTP1ファイルに直接編成ファイルとしてアクセスでき，トランザクションと同期してOpenTP1ファイルの状態を管理できます。OpenTP1でDAMファイルを使う場合には，TP1/FS/Direct Accessが必要です。

DAMファイルは，DAMサービス定義で，物理ファイル名と論理ファイル名を指定します。物理ファイル名とは，OpenTP1ファイルを示す完全パス名のことです。論理ファイル名とは，物理ファイルと対応した論理的な名称です。論理ファイル名は，UAPからAPIでDAMファイルにアクセスするときや，コマンドで物理ファイル名と論理ファイル名の対応を変更するときに使います。論理ファイル名を使うことで，物理的な構造を意識しないでDAMファイルへアクセスできます。論理ファイル名と物理ファイル名は，1対1で対応づけます。

DAMファイルの構造を次の図に示します。

図4‒14　DAMファイルの構造

(1)　DAMファイルの特長

DAMファイルの特長を次の表に示します。

表4‒10　DAMファイルの特長

説明する内容

特長

ファイル構成とレコード形式

DAMファイルは，直接編成ファイルです。事前にOpenTP1ファイルとして割り当てたファイルを使います。

レコード形式は固定長の非ブロック形式です。

アクセス形態

相対ブロック番号を使った直接アクセス法で，ブロックを参照または更新します。

連続した複数のブロックを一括して入出力することもできます。

トランザクションとの関係

トランザクション処理中に更新したブロックの内容は，次に示す場合にファイルに出力されます。

トランザクションがコミットしたとき

DAMサービス定義に指定した最大ブロック数に達したとき

トランザクションがロールバックした場合は，トランザクションを開始する以前の状態に回復されます。

ファイルのバックアップとリストア

DAMファイルのバックアップとリストアには，次のコマンドを使います。

dambkupコマンド

damrstrコマンド

バックアップファイルとバックアップ取得時点以降の回復用ジャーナルを基にDAMファイルの内容を最新の状態に回復できます。DAMファイルを回復する機能をDAM FRCといいます。

オンライン中のファイルの追加

オンライン中にファイルを追加する場合は，追加する物理ファイルを作成してから，damaddコマンドを使います。

オンライン中のファイルの削除

オンラインで使っているファイルを切り離す場合はdamrmコマンドを，切り離したDAMファイルの物理ファイルを削除する場合はdamdelコマンドを使います。オンライン中にファイルを削除する場合は，damrmコマンドで論理ファイルを切り離してから，物理ファイルをdamdelコマンドで削除します。

(2)　DAMファイルの作成方法

OpenTP1ファイルシステム上に割り当てられたOpenTP1ファイルを物理ファイルといいます。オフラインでのDAMファイルへのアクセスは物理ファイルに対して行います。オンライン中のDAMファイルへのアクセスは，物理ファイルと1対1に対応した論理ファイルに対して行います。

OpenTP1ファイルシステムを作成したあと，DAMファイルを作成します。作成方法には，OpenTP1のコマンドによる方法と，OpenTP1で提供する関数による方法があります。

コマンドを使ったDAMファイルの作成

damloadコマンドで，物理ファイルを割り当てたあと，物理ファイルへ初期データを出力します。

UAPを使ったDAMファイルの作成

オフライン環境でdc_dam_create関数（ファイルの割り当て，初期データの出力）をUAPから呼び出して，DAMファイルを作成できます。

(3)　DAMファイルの入出力関数

OpenTP1のUAPでは，DAMファイルにアクセスする関数（dc_dam_××××関数）を使用できます。UAPで使用できるDAMファイルサービスについては，マニュアル「OpenTP1 プログラム作成の手引」を参照してください。

(4)　DAMファイルの排他制御

(a)　排他の単位

DAMファイルの排他には，ファイル単位で排他をかけるファイル排他と，ブロック単位で排他をかけるブロック排他があります。DAMファイルにファイル排他をかけるか，ブロック排他をかけるかを，DAMファイルをオープンするときに関数（dc_dam_open関数）の引数に指定します。通常は，ブロック単位で排他します。実際にファイルやブロックに排他をかけるのは，オープンしたDAMファイルのブロックを，更新したり，更新するために参照しようとしたときです。

DAMファイルをオープンしようとしたとき，そのファイルがすでにほかのトランザクションからファイル排他をかけられていた場合には，DAMファイルをオープンできないで，エラーリターンします。

(b)　トランザクションと排他の単位

DAMファイルにアクセスするときは，トランザクションブランチ単位で排他制御します。また，グローバルトランザクション単位で排他制御することもできます。グローバルトランザクション単位で排他制御すると，同一グローバルトランザクションに属する複数のトランザクションブランチから同一ブロック，または同一ファイルにアクセスしても，排他エラーになりません。排他制御の単位は，DAMサービス定義の指定で変更できます。

グローバルトランザクション単位で排他制御する場合，トランザクションブランチごとにDAMファイルへアクセスしても，並列にアクセスできないで順次アクセスとなります。そのため，トランザクションの性能が下がる場合があります。トランザクションブランチごとのDAMファイルへのアクセスを並列に処理させる場合は，トランザクションブランチ単位で排他制御する指定をしてください。

排他制御の単位については，マニュアル「OpenTP1 プログラム作成の手引」および「OpenTP1 システム定義」を参照してください。

(c)　資源の排他解除待ちの設定

オープンしたDAMファイルのブロックを，更新したり，更新するために参照したりしようとしたとき，そのブロックがすでに排他をかけられていた場合に，排他が解放されるのを待つかどうかを，関数のパラメタで指定します。排他解除を待つ時間（排他待ち限界経過時間）を，ロックサービス定義で指定します。この排他待ち限界経過時間が経過しても排他が解放されない場合には，エラーリターンします。

(5)　DAMファイルのディファード更新

トランザクションで更新したDAMファイルのブロックを，同期点の取得とは非同期に更新できます。この機能をディファード更新といいます。ディファード更新指定のDAMファイルは，トランザクションの同期点取得時には更新されないで，一定間隔で起動される出力専用プロセスから実更新されます。DAMファイルにディファード更新をする指定をしておくと，トランザクションの入出力回数を削減できるので，単位時間当たりのトランザクションのスループットを向上できます。

ディファード更新指定のDAMファイルと通常更新のDAMファイルを，一つのトランザクションから更新出力した場合には，どちらのDAMファイルも同期点で実更新します。

(a)　ディファード更新するDAMファイルの指定方法

DAMファイルをディファード更新するかどうかは，DAMファイルごとに，DAMサービス定義で指定します。

出力専用プロセスが実行されるまでの間，ブロックを退避しておくバッファ領域と，出力専用プロセスから更新を実行する時間間隔を指定します。この実行間隔時間が長過ぎたり，バッファ領域の値が小さ過ぎる場合は，バッファ領域のオーバフローや，領域の空き待ち時間が発生する場合があります。ディファード更新の指定では，DAMサービス定義に指定するバッファ領域，および時間間隔の値の算出に注意してください。

(b)　ディファード更新指定のDAMファイルを使用するときの注意

システム障害によるOpenTP1の異常終了が発生した場合，ディファード更新指定のDAMファイルでは，障害前に完了していたトランザクションのアクセスがDAMファイル上に反映されていないことがあります。この場合，トランザクションとDAMファイルの更新内容を保証するために，OpenTP1の再開始処理（全面回復処理）をしたあと，必ず正常に終了させてください。

また，障害以前に完了したトランザクションでも，出力専用プロセスの処理が障害前に完了していないと，全面回復後にロールバックとなることがあります。障害以前に完了済みのトランザクションをロールバックさせたくない場合には，アクセスするDAMファイルにディファード更新を指定しないでください。

ディファード更新指定のDAMファイルにディスク障害が発生した場合は，ファイル回復機能（DAM FRC）を必ず実行してください。

(6)　DAMファイルのオンラインバックアップ

DAMファイルのバックアップを，OpenTP1のオンライン中に取得できます。これをオンラインバックアップといいます。DAMファイルのバックアップを取得するコマンド（dambkupコマンド）に-oオプション指定して実行すると，オンライン中にDAMファイルをバックアップできます。

オンラインバックアップしたファイルでDAMファイルを回復すると，回復に使用するアンロードジャーナルファイルの量が少なくて済みます。そのため，-oオプションを指定しないでバックアップしたファイルを使用してDAMファイルを回復する場合と比べて，DAMファイルの回復処理に掛かる時間が少なくて済みます。

なお，DAMファイルの回復処理は，対象となるDAMファイルをUAPが使用していると実行できません。その場合，対象となるDAMファイルをオープンしているUAPをいったん停止するか，またはOpenTP1を停止してください。

-oオプションを指定しない場合は，オフライン状態でバックアップすることになります。この場合，次の手順でバックアップしてください。

damholdコマンドを実行して，論理ファイルを論理閉塞します。

damrmコマンドを実行して，論理閉塞した論理ファイルをオンラインから切り離します。

-oオプションを指定しないdambkupコマンドを実行して，DAMファイルをバックアップします。

(7)　ユーザデータの抽出

DAMファイルの管理情報を除いたユーザデータだけを抽出できます。抽出したユーザデータをDAMファイルの初期データとして，damloadコマンドで割り当てることができます。ただし，抽出したユーザデータをdamrstrコマンドでリストアすることはできません。ユーザデータを抽出するには，dambkupコマンドに-dオプションを指定して実行します。

(8)　ブロック長拡張機能

dambkupコマンドでバックアップしたファイルをリストアするとき，ブロック長を拡張してリストアできます。これをブロック長拡張機能といいます。ブロック長拡張機能を使うことで，ブロック長の異なるDAMファイルにデータを移行できます。

ブロック長拡張機能の方式には，バックアップ元DAMファイルのブロック構成を維持する方式とブロック構成を維持しない方式があります。各方式について次に示します。

ブロック構成を維持する方式

バックアップ元DAMファイルのブロック構成を，リストア先DAMファイルでも維持するブロック長拡張方式です。拡張後のブロック長は，damrstrコマンドの-eオプションで指定します。

1ブロック長504バイトのDAMファイルを，1ブロック長1,016バイトのDAMファイルにリストアする例を，次の図に示します。

図4‒15　ブロック構成を維持するブロック長拡張方式

ブロック構成を維持しない方式

バックアップ元DAMファイルのデータを，リストア先DAMファイルの先頭ブロックから詰めて格納する方式です。拡張後のブロック長は，damrstrコマンドの-pオプションで指定します。

1ブロック長504バイトのDAMファイルを，1ブロック長1,016バイトのDAMファイルにリストアする例を，次の図に示します。

図4‒16　ブロック構成を維持しないブロック長拡張方式

ブロック長拡張機能を使用する場合は，次の点に注意してください。

damfrcコマンドで指定する回復対象定義ファイルに，ブロック長を拡張したDAMファイルを指定できません。

オンライン中に取得したバックアップファイルを使用して，ブロック長を拡張できません。

(9)　標準入出力を使ったDAMファイルのバックアップとリストア

DAMファイルのバックアップ先に標準出力を，リストアの入力ファイルに標準入力を使えます。標準入出力を使うことで，コマンドのリダイレクトができるようになります。

標準入出力を使う場合には，dambkupコマンドおよびdamrstrコマンドに-sオプションを指定して実行します。

(10)　回復対象外のDAMファイルへのアクセス

トランザクションによる整合性の管理や障害時の回復を保証しないDAMファイルを作成できます。このようなDAMファイルを回復対象外のDAMファイルといいます。回復対象外のDAMファイルへは，トランザクションでない処理からブロックを更新したり出力したりできます。

回復対象外にするDAMファイルには，DAMサービス定義の定義コマンドdamfileに-nオプションを付けて指定します。

回復対象外のDAMファイルへのアクセスでエラーが起こった場合，ファイルデータの障害は回復できません。

(11)　キャッシュブロックの処理

DAMサービスは一度読み込んだDAMファイルのブロックデータをDAMサービス専用共用メモリにためます。同じブロックに対して参照要求がある場合，DAMサービス専用共用メモリ上にあるブロックデータをUAPへ返すことによって，ファイルI/Oの実行回数を削減しています。

DAMサービス専用共用メモリ内では，DAMファイルごとにブロックデータをチェイン管理しています。このブロックデータが格納されているDAMサービス専用共用メモリ中の領域をキャッシュブロックといいます。

UAPがDAMファイルにアクセスするとき，DAMサービスは次に示す処理順序でキャッシュブロックを確保します。この処理をキャッシュブロック確保処理といいます。

キャッシュブロック確保処理の流れを次に示します。

アクセスされたDAMファイルのキャッシュブロックチェインに，該当するブロックに対応するキャッシュブロックがつながれているか検索します。つながれている場合は，そのキャッシュブロックのデータをUAPへリターンします。

キャッシュブロックチェインにつながれていない場合は，キャッシュブロック用領域からキャッシュブロックを確保します。

キャッシュブロック用領域に空き領域がない場合は，アクセスしたDAMファイルのキャッシュブロックチェインの中で，実行中トランザクションで参照されていないキャッシュブロックを再利用します。このとき，キャッシュブロックチェインの末尾，つまり最も古くキャッシュブロックチェインにつながれたキャッシュブロックから再利用します。なお，再利用するキャッシュブロックは，DAMサービス定義のdam_cache_reuse_fromオペランド指定値によって決まります。デフォルトは，末尾から再利用します。

2.および3.でキャッシュブロックを確保できない場合は，ほかのDAMファイルのキャッシュブロックチェインの中で，実行中トランザクションで使用されていないすべてのキャッシュブロックをいったん解放し，再度，キャッシュブロック用領域からキャッシュブロックを確保します。ここでキャッシュブロックを解放する処理をクリーンアップ処理といいます。

確保したキャッシュブロックにDAMファイルのブロックデータをコピーし，キャッシュブロックチェインの先頭につなぎます。

キャッシュブロックチェインにつながれているキャッシュブロック数や，DAMサービス専用共用メモリの全体使用率は，damchinfコマンドで取得できます。

キャッシュブロックチェインの概要を次の図に示します。

図中の番号は上記の番号に対応します。

図4‒17　キャッシュブロックチェインの概要

(12)　キャッシュブロック数しきい値指定機能

特定のDAMファイルに対してアクセスが集中する場合，そのDAMファイルが管理するキャッシュブロック数は増大します。その結果，「4.4.1(12)(b)　適用例」に示すとおり，しきい値を適切に指定していないと，該当するキャッシュブロックの検索や解放に時間が掛かるようになり，トランザクション性能が大幅に低下するおそれがあります。

DAMサービス定義のdamchlmt定義コマンドを指定すると，一つのDAMファイルで管理するキャッシュブロック数に上限を設けることができます。この上限となる値をしきい値といいます。しきい値に達するまではキャッシュブロックが確保され，しきい値に達すると，新たにキャッシュブロックを確保しないで，該当するDAMファイルの未使用状態のキャッシュブロックが再利用されます。しきい値を指定しない場合は，共用メモリ資源がなくなるまで，キャッシュブロックが確保されます。

DAMサービス定義のdamchlmt定義コマンドの指定値は，オンライン中にdamchdefコマンドを使用して動的に変更できます。

(a)　キャッシュブロックの計算式

キャッシュブロック用に使用できる領域のサイズは次に示す計算式で求めます。

キャッシュブロック用領域サイズ
＝ M−（M / 576）×34　（単位：バイト）

個々のキャッシュブロックのサイズは次に示す計算式で求めます。

キャッシュブロックサイズ
＝ （Ab ＋ 8）＋ 64　（単位：バイト）

（凡例）

M：DAMサービス専用共用メモリサイズ

Ab：アクセスするDAMファイルのブロック長

(b)　適用例

この機能は，特定のDAMファイルに集中してアクセスするような形態で効果があります。適用例の前提となる条件を次に示します。

DAMサービスが確保するキャッシュメモリには，100,000個のキャッシュブロックを確保できます。

オンライン開始後，damfileAだけを集中的にアクセスします。

damfileAのブロック数は100,000ブロックです。

キャッシュブロック一つの検索時間を0.1ミリ秒※とします。

1ブロックのファイルI/O時間を500ミリ秒※とします。

注※

ハードウェアやプロセスの状態によって異なります。説明のため，単純な値を使用しています。

適用例1：キャッシュブロック数しきい値を指定しない場合

キャッシュブロック数しきい値を指定しない場合，damfileAのキャッシュブロックチェインには，キャッシュブロック用領域に空き領域がある範囲で，キャッシュブロックがつながれます。ここでは，100,000個のキャッシュブロックがdamfileAのキャッシュブロックチェインにつながれます。

この状態で，キャッシュブロックチェインの末尾にあるブロックデータを検出するのに必要なチェイン走査時間は0.1ミリ秒×100,000ブロック＝10秒となり，直接ファイルI/Oした方が相対的なトランザクション性能は良くなります。また，キャッシュメモリ内に確保できる全キャッシュブロックをdamfileAが占有していることから，ほかのDAMファイルへアクセスする場合，damfileAに対してクリーンアップ処理が実行されます。クリーンアップ処理が実行されると，100,000個のキャッシュブロックの解放処理を実行することから，さらにトランザクション性能を低下させてしまいます。

適用例2：キャッシュブロック数しきい値として4000を指定する場合

キャッシュブロック数しきい値に4000を指定すると，damfileAのキャッシュブロックチェインには，最大4,000個のキャッシュブロックがつながれます（DAMサービス定義の各指定値によっては，4,000個以上のキャッシュブロックがつながれることがあります）。

この状態で，キャッシュブロックチェインの末尾にあるブロックデータを検出するのに必要なチェイン走査時間は，0.1ミリ秒×4,000ブロック=400ミリ秒となり，直接ファイルI/Oした場合よりもトランザクション性能が良くなります。また，4,000個のキャッシュブロックチェインになるため，残り96,000個のキャッシュブロックは未確保状態となり，ほかのDAMファイルへアクセスした場合にクリーンアップ処理が実行されません。

ただし，各DAMファイルのキャッシュブロックチェインにつながれるキャッシュブロック数に制限があることから，キャッシュブロック用領域に対するキャッシュブロック数が減少し，DAMサービス専用共用メモリ内に使われない領域が発生することがあります。

適用例3：キャッシュブロック数しきい値として0を指定する場合

キャッシュブロック数しきい値に0を指定する場合，damfileAのキャッシュブロックチェインにつながれるキャッシュブロック数は，トランザクションブランチ内でアクセスするブロック数，およびDAMサービス定義の設定値に依存します。

ここではDAMサービス定義の設定値を次に示すとおりとします。

set dam_update_block = 10
set dam_tran_process_count = 5

すべてのトランザクションブランチでdamfileAだけをアクセスする場合

アクセスするブロックに重複がないとすると，10×5=50個のキャッシュブロックがdamfileAのキャッシュブロックチェインにつながれます。これは，トランザクション実行中にほかのプロセスから，最新のブロックデータおよびトランザクション決着前の更新後データを参照されないようにするため，キャッシュメモリ中にデータをスタックしているからです。

一つのトランザクションブランチだけがdamfileAをアクセスする場合

アクセスするブロックに重複がないとすると，上記の場合同様に，キャッシュメモリ中にスタックしておくために，10個のキャッシュブロックがdamfileAのキャッシュブロックチェインにつながれます。

上記のとおり，キャッシュブロック数しきい値として0を指定する場合では，キャッシュブロックチェインにつながれるキャッシュブロック数は，UAPでのアクセス形態やDAMサービス定義の設定値に依存します。この現象は，キャッシュブロック数しきい値に小さな値を指定する場合も発生します。小さな値とは，UAPで実行するトランザクション内でアクセスするブロック数よりも小さな値を意味します。

このときも，適用例2の場合と同様にDAMサービス専用共用メモリ内に使われない領域が発生します。

(c)　UAPのアクセス形態に応じた設定

damchinfコマンドを実行した結果，次に示す情報が出力されたとします。

CleanUP Count:1  Next CleanUP FILE-No:1  Using Rate:80%
FileNo FileName BlkLen BlkNum CchBlkNum PreservNum LimitNum ReUse
     1 damfile1    504  10000      7900          0       -1 Exist
     0 damfile0    504  10000       100          0       -1 Exist
     2 damfile2    504  10000         0          0       -1  None

UAPのアクセス形態ごとに，この状況でキャッシュブロック数しきい値にどのような値を指定するとよいか説明します。

damfile1には，以降ほとんどアクセスしない場合

"Using Rate:80%"と出力されているので，damfile0およびdamfile2に割り当てることのできるキャッシュブロック領域は20%しかありません。damfile1には以降ほとんどアクセスしないので，damfile1のキャッシュブロックチェインにつながれている7,900個分のキャッシュブロック用領域は，確保されたままの状態になります。そこで，damfile1のしきい値に小さな値を指定することによって，確保されたままの状態のキャッシュブロック用領域を小さくし，damfile0およびdamfile2に割り当てるキャッシュブロック領域を大きくできます。

また，damfile1のキャッシュブロックチェインにキャッシュブロックが多数つながれているため，キャッシュブロック用領域が不足するとクリーンアップ処理が実行されます。ここでは"Next CleanUP FILE-No:1"と出力されていることから，damfile1のキャッシュブロックチェインがクリーンアップ対象となります。7,900個のキャッシュブロック解放処理が実行されると，急激に性能が劣化します。この現象を抑止するためにも，damfile1にしきい値を指定することが重要になります。

damfile1に頻繁にアクセスする場合

damfile1に頻繁にアクセスすると，damfile1のキャッシュブロックチェインの検索処理が頻繁に実行されます。この場合，しきい値を指定することで，キャッシュブロックチェインを短くでき，その結果，チェイン検索時間が短縮されます。ただし，しきい値が小さ過ぎる場合，キャッシュ効率が悪化するため，かえって性能が劣化します。しきい値設定値を変更しながら最適な値を決定してください。

すべてのDAMファイルに平均的にアクセスする場合

すべてのDAMファイルに平均的にアクセスするため，各DAMファイルに割り当てられるキャッシュブロック用領域は平均化していることが望まれます。各DAMファイルのしきい値に同等の値を設定すると，各DAMファイルが使用するキャッシュブロック用領域は平均化されます。

(d)　注意事項

この機能を使用するときの注意事項を次に示します。

キャッシュブロック数しきい値を指定しない場合は，DAMサービス専用共用メモリが満杯になるまでキャッシュブロックが確保されます。しかし，しきい値を指定すると途中でキャッシュブロック確保処理は抑止されます。そのため，使用されない共用メモリ領域が発生します。

各DAMファイルのキャッシュブロックチェインにつながれるキャッシュブロック数は，しきい値に設定した値を超えることがあります。

DAMサービス定義のdamchlmt定義コマンドに指定範囲外のしきい値を指定した場合，不正な指定のある個所がKFCA00219-Eメッセージに出力されます。また，省略値の採用がKFCA01644-Iメッセージに出力されます。この場合，該当するDAMファイルで管理するしきい値は設定されないで，共用メモリ資源のある限りキャッシュブロックが確保されます。

(13)　キャッシュブロック再利用時の検索順序指定機能

DAMサービス定義のdam_cache_reuse_fromオペランドを指定すると，DAMファイルをアクセスするトランザクションで新しくキャッシュブロックが必要となった場合に，キャッシュブロックチェインのどのキャッシュブロックから優先的に再利用対象として検索するか指定できます。

lastを指定すると最も古くキャッシュブロックチェインにつながれたキャッシュブロックから再利用します。

firstを指定すると最も新しくキャッシュブロックチェインにつながれたキャッシュブロックから再利用します。

デフォルトはlastです。

(14)　キャッシュブロック再利用境界値指定機能

DAMサービス定義のdamcache定義コマンドには，キャッシュブロック再利用境界値を指定できます。指定すると，キャッシュブロック確保処理で新しくキャッシュブロックを確保するときに，キャッシュブロック再利用境界値にキャッシュブロック数が達していない間は，アクセスするDAMファイルのキャッシュブロックではなく，ほかのDAMファイルのキャッシュブロックが優先して再利用されます。

なお，キャッシュブロック数がキャッシュブロック再利用境界値を超えている場合は，アクセスするDAMファイルのキャッシュブロックが再利用されます。したがって，キャッシュブロック再利用境界値に0を指定すると，通常の処理と同じように，アクセスするDAMファイルのキャッシュブロックから再利用されます。

DAMサービス定義のdam_default_cache_numオペランドには，damcache定義コマンドを指定しない論理ファイルのキャッシュブロック再利用境界値を指定できます。

この機能は，あるDAMファイルの多数ブロックを集中してアクセスしたあと，別のDAMファイルを頻繁にアクセスする場合，つまり少数のDAMファイルがキャッシュブロックを占有してしまい，ほかの頻繁にアクセスするDAMファイルに割り当てられるキャッシュブロックが少なくなってしまう場合に有効です。

これに対して，複数のDAMファイルをランダムにアクセスする場合，つまり各DAMファイルにキャッシュブロックが均等に使用されている場合には，キャッシュブロック再利用境界値に小さな値を指定するとキャッシュブロックの解放処理が頻繁に実行され，メモリ確保およびファイルからのデータ読み込み処理が従来よりも増加することによって，性能が劣化することがあります。

(a)　性能向上が見込まれる例

説明のため，使用するDAMファイルは2ファイルとし，同一ブロック長であるとします。また，システム全体で確保可能な最大キャッシュブロック数を100個とし，DAMファイルAを98ブロック参照したあと，DAMファイルBのアクセスが実行されるとします。

DAMファイルBのアクセスは，次に示すとおり回数が増えるたびに1ブロックずつ参照するブロックが増加し，50ブロックまで参照するとします。

1回目：ブロック1および2を参照

2回目：ブロック1，2，および3を参照

3回目：ブロック1，2，3，および4を参照

　　　　　　　　：

49回目：ブロック1，2，3，…および50を参照

この条件のとき，damcache定義コマンドを指定しない場合と，指定する場合の処理の違いを次に示します。

damcache定義コマンドを指定しない場合

DAMファイルBを最初にアクセスするとき，共用メモリからキャッシュブロック用領域を確保します。このとき，DAMファイルAで98個のキャッシュブロックが確保されているため，二つだけ確保できます。そのキャッシュブロックに，ブロック1および2のデータを読み込み，DAMファイルBのキャッシュブロックチェインにつなぎます。

ブロック1，2，および3を参照するとき，ブロック1および2はキャッシュヒットするため，ファイルI/Oが実行されません。しかし，ブロック3は初めてのアクセスであるため，キャッシュブロックを確保し，データを読み込もうとしますが，1.の段階で共用メモリ中の空き領域がなくなっているため，DAMファイルBのキャッシュブロックの再利用処理が実行されます。再利用処理では，ブロック1のデータが設定されているキャッシュブロックをキャッシュブロックチェインから切り離し，ブロック3のデータを読み込み，キャッシュブロックチェインの先頭につなぎます。

ブロック1，2，3，および4を参照するとき，2.と同様にキャッシュブロックの再利用処理が実行され，ブロック2のキャッシュブロックを解放し，ブロック1を読み込み，キャッシュブロックチェインの先頭につなぎます。さらに，ブロック2のデータを読み込むため，ブロック3のキャッシュブロックを再利用し，ブロック2を読み込みます。この処理をブロック3および4のときにも繰り返します。

3.を繰り返すと，DAMファイルBのキャッシュブロックの再利用処理，つまり，チェインからの解放，およびデータ読み込みのためのファイルI/Oが頻繁に実行されます。チェインからの解放処理，およびファイルI/Oの回数は，約1275回ずつ実行されます。

damcache定義コマンドを指定する場合

DAMファイルAのキャッシュブロック再利用境界値を50とし，DAMファイルBのキャッシュブロック再利用境界値を90とします。

damcache定義コマンドを指定しない場合の1.と同様に，余っているキャッシュブロックを二つ確保し，ブロック1および2のデータを読み込み，キャッシュブロックチェインにつなぎます。

ブロック1，2，および3を参照するとき，ブロック1および2はキャッシュヒットするため，ファイルI/Oが実行されません。また，ブロック3のデータを読み込むためのキャッシュブロックは，DAMファイルBのキャッシュブロック数がキャッシュブロック再利用境界値を超えていないため，ほかのDAMファイルの内，キャッシュブロック数がキャッシュブロック再利用境界値を超えているDAMファイル（この場合はDAMファイルA）のキャッシュブロックを解放し確保します。確保したキャッシュブロックにブロック3のデータを読み込みキャッシュブロックチェインにつなげます。これによって，DAMファイルBのキャッシュブロックチェインには，三つのキャッシュブロックがつながることになります。

ブロック1，2，3，および4を参照するとき，ブロック1，2，および3はキャッシュヒットするため，ファイルI/Oは実行されません。また，ブロック4のデータ読み込み時には，DAMファイルAの未使用キャッシュブロックを再利用するため，ファイルI/Oが1回だけ実行されます。

3.をDAMファイルAのキャッシュブロック数がキャッシュブロック再利用境界値を超えるまで繰り返します。キャッシュブロックチェインからの解放処理，およびファイルI/Oの回数は，約50回ずつとなり性能が向上します。

(b)　性能が劣化する例

DAMファイルのブロック長などの条件は上記と同じとします。ただし，各ファイルのアクセス形態を次に示すとおりとします。

1回目：DAMファイルAの1〜50ブロックを参照

2回目：DAMファイルBの1〜50ブロックを参照

3回目：DAMファイルAの51〜100ブロックを参照

4回目：DAMファイルBの1〜50ブロックを参照

　　　　　　　　：

以降，DAMファイルAのブロックを50ブロックずつずらしながら，DAMファイルAとBを交互に参照します。

キャッシュブロックの最大が100個であるため，2回目でDAMファイルAとBともに，50個のキャッシュブロックがつながります。3回目以降の処理で，damcache定義コマンドを指定しない場合と，指定する場合の処理の違いを次に示します。

damcache定義コマンドを指定しない場合

3回目では，ブロック1〜50のキャッシュブロックを解放し，ブロック51〜100のデータに置き換えたあとチェインにつなげます。

4回目では，すべてのブロックがキャッシュヒットするため，キャッシュブロックの解放処理，およびファイルI/Oは実行されません。

以降，DAMファイルAでは，3回目のときと同様にすべてのキャッシュブロックの解放とファイルI/Oが実行されますが，DAMファイルBについては，キャッシュブロックの解放，およびファイルI/Oは実行されません。DAMファイルAの参照ブロックが1,000ブロックまでとすると，キャッシュブロックの解放処理回数は950回，ファイルI/Oの回数はDAMファイルAとB合わせて1050回です。

damcache定義コマンドを指定する場合

DAMファイルAのキャッシュブロック再利用境界値を100，DAMファイルBのキャッシュブロック再利用境界値を50とします。

3回目では，DAMファイルAのブロック51〜100を参照するとき，50個分のキャッシュブロックを確保する必要があります。このとき，DAMファイルAのキャッシュブロック数がキャッシュブロック再利用境界値を超えていないため，ほかのDAMファイルのキャッシュブロックを再利用します。このとき，DAMファイルBのキャッシュブロック数はキャッシュブロック再利用境界値を超えていなくても，共用メモリ内の空き領域がないため，強制的に再利用します。そのため，DAMファイルBのブロック1〜50のデータが設定されているキャッシュブロックが解放され，DAMファイルAのブロック51〜100までのデータに置き換えられ，DAMファイルAのキャッシュブロックチェインの先頭につながれます。このため，3回目が終了した時点では，DAMファイルAのキャッシュブロックチェインには，ブロック1〜100までのキャッシュブロックがつながれ，DAMファイルBのキャッシュブロックはなくなります。

4回目では，DAMファイルBのブロック1〜50を参照するとき，50個分のキャッシュブロックを確保する必要があります。3回目と同様にDAMファイルAのキャッシュブロックを強制的に再利用し，DAMファイルAのブロック1〜50のデータが設定されているキャッシュブロックを解放し，DAMファイルBのブロック1〜50のデータを設定したあと，DAMファイルBのキャッシュブロックチェインにつなぎます。

以降，3回目および4回目と同様の処理を繰り返し，DAMファイルAの参照ブロックが1,000ブロックまでとすると，キャッシュブロックの解放処理回数は1900回，ファイルI/Oの回数はDAMファイルAとB合わせて2000回となり，damcache定義コマンドを指定しない場合と比較して性能が劣化します。

(c)　注意事項

この機能を使用するときの注意事項を次に示します。

アクセスするDAMファイルのキャッシュブロック数がキャッシュブロック再利用境界値を超えていない場合，ほかのDAMファイルのキャッシュブロックを優先して再利用します。このとき，ほかのDAMファイルの全キャッシュブロックがアクセス中の場合，アクセスするDAMファイルのキャッシュブロックに対して再利用処理を実行します。そのため，キャッシュブロック再利用境界値を超えていなくても，再利用されることがあります。

damaddコマンドに-lオプションを指定しないで実行すると，そのDAMファイルのキャッシュブロック再利用境界値は，DAMサービス定義のdam_default_cache_numオペランドの指定値に依存しないで0となります。

DAMサービス定義の各キャッシュブロック再利用境界値に指定範囲外の値を指定した場合，次に示すとおり動作します。

dam_default_cache_numオペランドに指定範囲外の値を指定するとき

KFCA00216-Eメッセージを出力して，指定の不正な個所を表示します。さらに，KFCA01644-Iメッセージを出力して省略値の採用を表示します。この場合，damcache定義コマンドでキャッシュブロック再利用境界値を指定していないDAMファイルのキャッシュブロック再利用境界値として0を使用します。

damcache定義コマンドに指定範囲外の値を指定するとき

KFCA02529-Eメッセージを出力して，指定の不正な個所を表示します。さらに，KFCA01644-Iメッセージを出力して省略値の採用を表示します。この場合，該当するDAMファイルのキャッシュブロック再利用境界値として，dam_default_cache_numオペランドで指定した値を使用します。dam_default_cache_numオペランドの指定がない場合，または指定範囲外の値を指定した場合は，0を使用します。

(15)　回復対象外DAMファイルのキャッシュレスアクセス

「4.4.1(11)　キャッシュブロックの処理」で説明したように，DAMサービスは，一度読み込んだDAMファイルのブロックデータをDAMサービス専用共用メモリにため，ファイルI/Oの実行回数を削減しています。

回復対象外のDAMファイルに限り，直接ファイルI/Oを実行してディスク上のブロックデータをUAPへ返せます。この方式をキャッシュレスアクセスといいます。回復対象外のDAMファイルをキャッシュレスアクセスにする場合は，DAMサービス定義のdamfile定義コマンドの-fオプションで指定します。

キャッシュレスアクセスを指定すると，参照，更新ごとにファイルI/Oが実行されます。

キャッシュレスアクセスで性能向上が見込まれる例

複数のブロックデータに1回だけアクセスする処理

キャッシュレスアクセスで性能が劣化する例

同じブロックデータに複数回アクセスする処理

キャッシュレスアクセス指定のDAMファイルを使用する場合，最適なDAMサービス専用共用メモリサイズを算出し，DAMサービス定義のdam_cache_size_fixオペランドに指定すると，不要なメモリを削減できます。詳細については，マニュアル「OpenTP1 システム定義」のDAMサービス定義のdam_cache_size_fixオペランドの説明を参照してください。

4.4.2　TAMファイル（TP1/FS/Table Access）

TAMファイルサービスを使うと，OpenTP1ファイルシステム上のOpenTP1ファイル（直接編成ファイル）のデータに，メモリ上のテーブルからアクセスできます。そのため，データへのアクセス処理を高速にできます。また，トランザクションと同期して，OpenTP1ファイルの状態を管理できます。OpenTP1でTAMファイルを使う場合には，TP1/FS/Table Accessが必要です。

TAMファイルは，ユーザデータを格納するファイルです。DAMファイルがディスクのデータに直接アクセスするのに対して，TAMファイルはデータを単純構造テーブルとしてメモリにロードして，メモリ上のテーブルにアクセスします。TAMサービスが提供するこの単純構造テーブルをTAMテーブルといい，TAMテーブルを格納するファイルの実体をTAMファイルといいます。

TAMファイルを使うときは，TAMサービス定義を作成し，TAMテーブルとTAMファイルを対応づけます。TAMテーブルとTAMファイルは1対1に対応します。さらに，TAMサービス定義でTAMテーブルに任意の名称を指定します。このTAMテーブル名を使用して，TAMテーブルを運用します。

TAMテーブルとTAMファイルの関係を次の図に示します。

図4‒18　TAMテーブルとTAMファイルの関係

(1)　TAMテーブルの特長

TAMテーブルは，レコードのアドレスを管理する方式の違いで，ツリー形式とハッシュ形式に分けられます。TAMテーブルはレコードごとに，検索用のキー値で管理しています。ツリー形式とは，レコードごとに割り当てられたキー値の大小を基にアドレスを管理する形式です。ハッシュ形式とは，レコードごとに割り当てられたキー値をTAMサービス内部のハッシュ関数を用いて変換し，変換後の値を基にアドレスを管理する形式です。この変換後の値をハッシュ値といいます。

ハッシュ形式はメモリ効率が悪くなりますが，ツリー形式よりも高速にアクセスできます。メモリ量に余裕がある場合には，ハッシュ形式，余裕がない場合にはツリー形式でTAMテーブルを作成してください。ツリー形式とハッシュ形式については，「4.4.2(2)　TAMテーブルの形式」を参照してください。

TAMテーブルおよびTAMファイルの概要を次の表に示します。

表4‒11　TAMテーブルおよびTAMファイルの特長

説明する内容

特長

ファイル構成とレコード形式

TAMファイルは，直接編成ファイルです。事前にOpenTP1ファイルとして割り当てたファイルを使います。

レコード形式は固定長の非ブロック形式です。

アクセス形態

キー値を使ったテーブルアクセス法で，ブロックを参照または更新します。TAMファイルには，次に示す3種類があります。

参照するだけの参照型ファイル

レコードを追加・削除できない更新型ファイル

レコードを追加・削除できる更新型ファイル

連続した複数のレコードを一括して入出力することもできます。

トランザクションとの関係

トランザクション処理中に仮更新したレコードの内容は，トランザクションがコミットした時点で，メモリ上で実更新されます。トランザクションがロールバックした場合は，仮更新した内容は廃棄されます。

メモリ上で実更新されたレコードは，TAMファイルに反映されます。TAMサービスは，メモリ上で実更新されたレコードだけを，一定の間隔でTAMファイルへ書き込みます。

ファイルのバックアップとリストア

TAMファイルのバックアップとリストアには，次のコマンドを使います。

tambkupコマンド

tamrstrコマンド

バックアップファイルとバックアップ取得時点以降の回復用ジャーナルを基にTAMファイルの内容を最新の状態に回復できます。TAMファイルを回復する機能をTAM FRC（Table Access Method File Recovery）といいます。

tambkupコマンドでは，オンライン中にTAMファイルをバックアップすることもできます。

オンライン中のテーブルの追加

オンライン中にTAMテーブルを追加する場合は，追加する物理ファイルを作成してから，tamaddコマンドを使います。tamaddコマンドでファイルを追加したあとで，tamrlesコマンドを実行すると，オンラインで使えるようになります。

オンライン中のファイルの削除

オンラインで使っているファイルを切り離す場合はtamrmコマンドを，切り離したTAMファイルの物理ファイルを削除する場合はtamdelコマンドを使います。オンライン中にファイルを削除する場合は，tamrmコマンドで論理ファイルを切り離してから，物理ファイルをtamdelコマンドで削除します。

ユーザデータの抽出とTAMファイルの再作成

TAMファイルからのユーザデータの抽出とTAMファイルの再作成には，次のコマンドを使います。

tambkupコマンド（-dオプション指定）

tamcreコマンド

TAMファイルの再作成は，ファイル容量の拡張やデータ移行を行う場合にも有効な手段となります。

メモリが十分にある場合には，TAMファイルを使用すれば性能面で優れたシステムを構築できます。利用できるメモリ量が限られている場合には，DAMファイルを使用してください。

DAMファイルに入出力する関数で，TAMテーブルにアクセスできます。このため，使用できるメモリを増やした場合は，それまで使用していたUAPを変更しないで，ユーザデータをDAMファイルからTAMファイルに移せます。ユーザデータの一部をTAMファイルに移し，一部をDAMファイルに残すような場合にも有効です。

(2)　TAMテーブルの形式

TAMサービスは，TAMテーブルのレコードとキー値の対応関係を基に，レコードのアドレスを管理します。通常，キー値はレコードの中にも含まれています。レコードにキー値を含めたくない場合は，tamcreコマンドで，レコードからキー値を削除できます。

ツリー形式では，中間の値を持つキー値をツリーのルートとして，それよりも大きな値を持つか小さな値を持つかによって，レコードをツリー構造で管理しています。ツリー形式は，ツリー構造に管理されたキー値の大小を順々に比較していくことでアドレスを求めるため，検索に時間が掛かります。

ハッシュ形式では，キー値をハッシュ値に変換し，ハッシュ値とレコードアドレスを対応づけることによって，レコードを管理しています。TAMテーブルの全レコードのうち，ハッシュ値とレコードアドレスを対応づけた領域をハッシュ域といいます。同じハッシュ値を持つレコードは，リスト構造で管理されます。リストで管理されたキー値を順々に比較していくことで，同じハッシュ値を持つレコードのアドレスを求めます。

ツリー形式とハッシュ形式で，アクセス時のキー値の指定方法が異なります。

TAMテーブルアクセス時のキー値の指定方法を次の表に示します。

表4‒12　TAMテーブルアクセス時のキー値の指定方法

検索種別

ツリー形式

ハッシュ形式

キー値=n

指定されたキー値を持つレコードを検索します。指定されたキー値を持つレコードがない場合，エラーリターンします。

キー値<n

キー値>n

キー値≦n

キー値≧n

指定されたキー値に最も近いキー値を持つ最初のレコードを検索します。

エラーリターンします。

先頭検索※

エラーリターンします。

キー値を無視して，TAMファイルの先頭レコードを検索します。

NEXT検索※

エラーリターンします。

指定されたキー値を持つレコードの，次のレコードを検索します。

注※

ハッシュ形式の場合，ユーザは先頭検索とNEXT検索を組み合わせて，TAMテーブル上の全レコードを検索できます。ただし，レコードからキー値を削除した場合には，NEXT検索時に指定するキー値がユーザにわからないため，全レコードの検索ができません。

ハッシュ形式の場合，全レコードのうちどれだけハッシュ域として使用するかを，TAMファイル作成時，tamcreコマンドの引数で指定します。ハッシュ域を大きく取った場合，ハッシュ値の重複が発生する確率が小さくなり，リストの検索が不要になる割合が増すため，検索が速くなります。ただし，リストの領域が小さくなり，リストが満杯になったとき，それ以上ハッシュ値の重複が発生すると，ハッシュ域に空きがあってもレコードを追加できないので，メモリ効率が悪くなります。ハッシュ域を小さく取った場合，ハッシュ値の重複が起きる確率が高まります。このため，リストを検索する割合が増して，検索が遅くなります。その代わり，メモリ効率は良くなります。

ハッシュ域を大きく取った場合と，小さく取った場合を次の図に示します。

図4‒19　ハッシュ域を大きく取った場合と小さく取った場合

(3)　TAMファイルの作成方法

OpenTP1ファイルシステムを作成したあと，tamcreコマンドでTAMファイルを初期作成します。TAMファイルの作成と同時に初期データをTAMファイルに格納する場合には，まずファイルに初期データを格納しておきます。TAMファイルの初期作成時にtamcreコマンドの引数でファイルを指定すれば，OpenTP1が初期データをファイルからTAMファイルに複写します。TAMファイルの初期データを格納するこのファイルを，TAMデータファイルといいます。

(4)　TAMテーブルのアクセス形態

TAMテーブルは，UAPからTAMテーブルのレコードにどのようにアクセスするかによって，参照型，追加・削除できない更新型，追加・削除できる更新型に分類できます。UAPからのレコードに対するアクセスを制限するために設定する，TAMテーブルの属性をアクセス形態といいます。アクセス形態を設定することで，TAMファイルを目的に応じて使い分けることができ，TAMテーブルのレコードを管理できます。

参照型は，レコードを参照することだけができるTAMテーブルです。オンライン中にレコードを追加したり，削除したり，更新したりすることはできません。

追加・削除できない更新型は，レコードを更新できますが，オンライン中にレコードを追加したり，レコードを削除したりすることはできません。追加・削除できる更新型は，オンライン中にレコードを追加したり，削除したり，更新したりできます。

OpenTP1の開始と同時にオンラインに組み込むTAMテーブルのアクセス形態は，TAMサービス定義で指定します。また，OpenTP1稼働中にオンラインに追加するTAMテーブルのアクセス形態は，tamaddコマンドの-aオプションで指定します。

(5)　TAMテーブルのロードとアンロード

TAMサービスは，ユーザが指定したタイミングで，TAMファイルに格納されているTAMテーブルをメモリにロードします。TAMテーブルをメモリにロードするタイミングを，ローディング契機といいます。OpenTP1の開始と同時にオンラインに組み込むTAMテーブルは，ローディング契機をTAMサービス定義で指定します。また，OpenTP1の稼働中にオンラインに追加するTAMテーブルの場合には，ローディング契機をtamaddコマンドの-oオプションで指定します。

tamloadコマンドでローディングしたTAMテーブルは，tamunloadコマンドでアンロードします。OpenTP1の開始と同時，またはオンラインへの追加と同時にローディングしたTAMファイルは，OpenTP1の終了時点で自動的にアンロードします。また，UAPからdc_tam_open関数を使ってローディングしたTAMファイルは，dc_tam_close関数を使った時点で自動的にアンロードします。

TAMテーブルのローディング契機とアンロードの方法を次の表に示します。

表4‒13　TAMテーブルのローディング契機とアンロードの方法

TAMテーブルをオンラインに登録する時期

ローディング契機（三つのローディング契機のうち一つを選択）

アンロードの方法※1

OpenTP1の開始と同時※2

OpenTP1の開始に伴ってTAMサービスが開始したとき

TAM終了時に自動

tamloadコマンドを入力したとき

コマンド入力

dc_tam_open関数を使ってTAMテーブルをオープンしたとき

クローズ時に自動

OpenTP1稼働中※3

オンラインに登録されたとき

TAM終了時に自動

tamloadコマンドを入力したとき

コマンド入力

dc_tam_open関数でTAMテーブルをオープンしたとき

クローズ時に自動

注※1

TAM終了時はローディング契機にかかわらずアンロードします。

注※2

TAMサービス定義でローディング契機を指定します。

注※3

TAMテーブルを追加するTAMテーブル管理コマンドの引数でローディング契機を指定します。

(6)　TAMテーブルの排他制御

TAMテーブルの排他には，テーブル単位で排他をかけるテーブル排他と，レコード単位で排他をかけるレコード排他があります。

TAMテーブルやレコードがすでにほかのUAPから排他をかけられていた場合に，排他が解放されるのを待つかどうかを，dc_tam_open関数，dc_tam_read関数，dc_tam_write関数，dc_tam_delete関数の引数で指定します。排他の解除を待つ時間は，ロックサービス定義で指定します。この排他待ち限界経過時間が経過しても排他が解放されない場合には，エラーリターンします。

TAMテーブルは，グローバルトランザクション単位に排他をかけます。

(7)　TAMテーブルとDAMファイルのデッドロックの対処方法

TAMテーブルとDAMファイルの両方にアクセスするUAPを複数作成した場合に，UAP間でデッドロックが起こることがあります。デッドロックが起こった場合には，ユーザサービス定義で指定した，デッドロックを解消するための優先順位に従ってデッドロックを解消します。

TAMテーブルとDAMファイルの両方にアクセスした場合のデッドロックの例を，次の図に示します。

図4‒20　TAMテーブルとDAMファイルの両方にアクセスした場合のデッドロックの例

(8)　TAMファイルのオンラインバックアップ

TAMファイルのバックアップを，OpenTP1の業務中に取得できます。これをオンラインバックアップといいます。TAMファイルのバックアップを取得するコマンド（tambkupコマンド）に-oオプション指定して実行すると，オンライン中にTAMファイルをバックアップできます。

オンラインバックアップしたファイルでTAMファイルを回復すると，回復に使うアンロードジャーナルファイルの量が少なくて済みます。そのため，-oオプションを指定しないでバックアップしたファイルを使ってTAMファイルを回復する場合と比べて，TAMファイルの回復処理に掛かる時間が少なくて済みます。

-oオプションを指定しない場合は，オフライン状態でバックアップすることになります。この場合，次の手順でバックアップしてください。

tamholdコマンドを実行して，論理ファイルを論理閉塞します。

tamrmコマンドを実行して，論理閉塞した論理ファイルをオンラインから切り離します。

-oオプションを指定しないtambkupコマンドを実行して，TAMファイルをバックアップします。

(9)　標準入出力を使ったTAMファイルのバックアップとリストア

TAMファイルのバックアップ先に標準出力を，リストアの入力ファイルに標準入力を使うことができます。標準入出力を使うことで，コマンドのリダイレクトができるようになります。

標準入出力を使う場合には，tambkupコマンドおよびtamrstrコマンドに-sオプションを指定して実行します。

(10)　ユーザデータの抽出とTAMファイルの再作成

TAMファイルからユーザデータを抽出できます。抽出したユーザデータをTAMデータファイルとしてtamcreコマンドに再度入力することで，TAMファイルを再作成できます。

TAMファイルの再作成は，ファイル容量を拡張したり，ほかのディスク媒体やほかのシステムにデータを移行する場合にも必要な手段となります。抽出したデータに対してデータの追加，削除や更新を行った上でTAMファイルを再作成することもできます。

ユーザデータを抽出するには，tambkupコマンドに-dオプションを指定して実行します。

なお，-dオプションを指定して抽出したユーザデータをtamrstrコマンドでリストアすることはできません。

4.4.3　ISTサービス（TP1/Shared Table Access）

複数のOpenTP1システムが，ノードをわたってテーブルを共用できる機能をISTサービスといいます。ISTサービスで使えるテーブルをISTテーブルといいます。ISTサービスを使うと，テーブルの実体がどのノードにあるかを意識しないで，UAPからデータを参照，更新できます。また，各ノードの業務状態を管理するために，メールとしてISTテーブルを使うこともできます。ただし，複数のノードにわたってデータを配布させる場合，次に示す条件の業務にはISTサービスはお勧めできません。

データを即時に配布する必要がある業務

大量のデータを扱う必要がある業務

頻繁にデータを更新する業務

ISTテーブルを使う場合，各ノードのシステムにTP1/Shared Table Accessが組み込まれていることが前提となります。

ISTサービスの構成を次の図に示します。

図4‒21　ISTサービスの構成

ISTサービスを使用するには，ノード間のISTテーブル定義の指定を合わせてください。この図の場合，ノードA，ノードB，およびノードCでISTテーブル定義に指定したテーブル名が合っていないため，予期しないテーブル情報を受信したとして，ノードAおよびノードBで，OpenTP1が終了するまで定期的にKFCA25533-Wメッセージを出力し続けます。

(1)　ISTテーブルへのアクセス環境

ISTテーブルは，各ノードの共用メモリ上にあるテーブルです。テーブルの実体にあたるファイルはありません。そのため，UAPからISTテーブルへアクセスできるのは，オンライン中だけです。オフライン環境ではISTテーブルにはアクセスできません。

(2)　ISTテーブルの構造

UAPからISTテーブルのデータを参照，更新するときは，レコード単位でアクセスします。ISTテーブルは，複数のレコードから構成されます。UAPの処理では，一つのレコードへアクセスすることも，複数のレコードを一括して指定してアクセスすることもできます。

(3)　ISTテーブルへのアクセス

UAPからISTテーブルへアクセスする手順については，マニュアル「OpenTP1 プログラム作成の手引」を参照してください。

ISTテーブルへのアクセスは，トランザクションの関数でコミット，ロールバックできません。

ISTテーブルでは，UAPから呼び出した関数ごとに排他制御しています。データの入力から更新まで，ISTテーブルを占有する制御はしていません。そのため，一つのテーブルに複数のUAPからアクセスした場合でも，デッドロックが起こることはありません。

(4)　ISTサービスの運用例

ISTサービスの効果的な運用例を次の図に示します。

図4‒22　ISTサービスの効果的な運用例

この図では，ISTテーブルAはノードAだけが更新し，ISTテーブルBはノードBだけが更新します。それぞれのノードで更新したデータは，ISTサービスが各ノードに通知および反映するので，更新されたISTテーブルは，どのノードでも参照できます。このように，ISTテーブルを更新するノードを一つに限定した運用が効果的です。

例えば，ISTテーブルAには，ノードAのステータス情報を書き込み，ISTテーブルBには，ノードBのステータス情報を書き込みます。ノードCが更新できるISTテーブルCを作成し，ISTテーブルCにノードCのステータス情報を書き込めば，各ノードで，全ノードのステータス情報を参照できます。ただし，自ノードで更新したISTテーブルの他ノードへの通知が完了するまでに必要な通信時間があります。この通信時間内は最新の情報が未反映のため，古い情報を参照することがあります。

(5)　ISTサービスの利用時の注意事項

複数のノードでISTサービスを使う場合には，各ノードの時刻を合わせておく必要があります。ノード間で時刻が一致していないと，あるノードで更新したデータに対して，別のノードからの更新が反映されないことがあります。ISTサービスで複数のノードのISTレコード（ISTテーブル中のレコード）を更新する処理の流れを次の図に示します。

図4‒23　ISTレコードの更新処理

ノードAのISTテーブルAのISTレコード（レコード番号1）を更新するレコード更新データを作成します。

現在の時刻（マシン時刻：マイクロ秒精度）を取得し，レコード更新データにタイムスタンプとして付与します。

ノードAの共用メモリ上の該当するISTレコードに設定されているタイムスタンプとレコード更新データに付与したタイムスタンプとを比較します。

レコード更新データの方が新しい場合は，共用メモリ上のISTレコードを更新します。レコード更新データの方が古い場合は，共用メモリ上のISTレコードを更新しません。なお，ISTレコードを更新しない場合も，dc_ist_write関数は正常にリターンします。

共用メモリ上のISTレコードを更新した場合，ノードAでISTレコードを更新したことをノードBのISTサービスへ通知します。このとき，ISTレコードとISTレコードに付与したタイムスタンプも通知します。

更新されたISTレコードを受信したノードBのISTサービスは，ノード内の該当するISTレコードに設定されているタイムスタンプと受信したISTレコードのタイムスタンプとを比較します。

5.の結果，受信したISTレコードのタイムスタンプの方が新しいと判断した場合だけ，ノードBの該当するISTレコードを，受信したISTレコードの情報に更新します。

上記のように，ISTサービスでは，ISTレコードを更新するか，またはそのままとするかを，タイムスタンプを基に判断しています。次のような場合は，最新の更新データがISTレコードに反映されないことがあります。

ノードAのマシン時刻がノードBのマシン時刻よりも進んでいる場合

ノードAでISTレコードを更新したあとに，ノードBから同一のISTレコードの更新を通知されても，ノードAのISTレコードに設定されたタイムスタンプの方が新しいと判断します。そのため，ノードBで更新されたISTレコードの情報がノードAのISTレコードに反映されません。

また，ノードAで更新したISTレコードをノードBへ通知したときに，通知したISTレコードのタイムスタンプの方が新しいと判断されるため，ノードBの該当するISTレコードは，実際には最新の情報であっても，通知したISTレコードの情報に更新されてしまいます。

ノードAのマシン時刻がノードBのマシン時刻よりも遅れている場合

ノードBがISTレコードを更新して，そのISTレコードの情報がすでにノードAに通知されているとき

ノードBでISTレコードを更新したあとに，ノードAで同一のISTレコードを更新しても，更新処理をしないでdc_ist_write関数が正常リターンします。

ノードBがISTレコードを更新したが，そのISTレコードの情報がまだノードAに通知されていないとき

ノードBでISTレコードを更新したあとに，ノードAで同一のISTレコードを更新すると，ノードAの更新情報で，いったんISTレコードを更新しますが，そのあとにノードBから通知されたISTレコードのタイムスタンプの方が新しいと判断するため，ノードBから通知されたISTレコードの情報を，ノードAのISTレコードに反映してしまいます。

4.4.4　ISAMファイル（ISAM，ISAM/B）

索引順編成ファイルを管理する，ISAMファイルサービスについて説明します。機能については，マニュアル「索引順編成ファイル管理 ISAM」を参照してください。

(1)　ISAMファイルの概要

索引順編成ファイルは，キーを管理するインデクス部と，データを格納するデータファイル部から構成されます。キーを使用して，順処理（シーケンシャルアクセス）や乱処理（ランダムアクセス）ができます。

ISAMファイルの操作には，ライブラリ関数をUAPから呼び出す方法と，ユティリティコマンドを実行して管理する方法があります。

(2)　ISAMサービスの種類

OpenTP1のUAPから処理できるISAMを次に示します。

(a)　ISAM

ISAMファイルを，通常のファイルとして使います。OpenTP1のトランザクション処理とは同期しません。

(b)　ISAM/B

ISAMファイルをOpenTP1トランザクション処理と同期して使う機能です。ISAM/Bを使用すると，トランザクション処理のコミット，またはロールバックで，ファイルの整合性が保てるようになります。

ISAM/Bの前提となる製品

ISAMファイルをISAM/Bとして使用する場合は，ISAMに加えて，ISAMトランザクション機能（ISAM/B）が前提となります。

ファイルを作成する領域

ISAM/Bで使用するISAMファイルは，OpenTP1ファイルシステムとして割り当てた領域に作成します。

OpenTP1のファイルサービス（TP1/FS/xxx）との違い

ISAM/Bでは，ロックサービスを使用しません。そのため，デッドロックが起こっても，OpenTP1のロックサービス機能（優先順位による縮退やデッドロック情報の出力）は使用できません。

4.4.5　データベースにアクセスする場合

OpenTP1のUAPで使うユーザファイルに，DBMSを使用した場合について説明します。

(1)　OpenTP1のトランザクション処理との関係

DBMSを使用する場合，X/Openで規定したDTPモデルのXAインタフェースをサポートしたDBMSかどうかで，OpenTP1のトランザクションと連携できるかどうか決まります。

(a)　XAインタフェースをサポートしたDBMSの場合

XAインタフェースをサポートしたDBMSの場合は，OpenTP1のトランザクションと同期を取って更新できます。同期を取る場合は，OpenTP1の同期点を制御する関数（dc_trn_begin関数，dc_trn_unchained_commit関数，tx_begin()，tx_commit()など）を使います。DBMSが提供するトランザクションを制御する機能などは使えません。OpenTP1のトランザクション処理で制御できるDBMSは，XAインタフェースをサポートした製品（例　Oracle7など）に限ります。

XAインタフェースをサポートしている複数のデータベースへアクセスするUAPでは，整合性を保ちながら複数のデータベースを更新できます。次に示すOpenTP1のリソースマネジャは，XAインタフェースをサポートしています。

TP1/FS/Direct Access（DAMファイルサービス）

TP1/FS/Table Access（TAMファイルサービス）

ISAM，ISAM/B（ISAMファイルサービス）

TP1/Message Control（メッセージ送受信機能）

TP1/Message Queue（メッセージキューイング機能）

XAインタフェースに準拠したDBMSと，OpenTP1のリソースマネジャの両方にアクセスするUAPでも，OpenTP1のトランザクションとして処理できます。障害が原因でUAPが異常終了した場合や，OpenTP1を再開始（リラン）した場合でも，DBMSとOpenTP1のリソースマネジャの両方のトランザクションを，OpenTP1で決着します。

(b)　XAインタフェースをサポートしていない，またはXAインタフェースでOpenTP1と連携していないDBMSの場合

XAインタフェースをサポートしていないDBMSの場合，DBMSへのアクセスはできますが，OpenTP1のトランザクションとは同期を取れません。

XAインタフェースでOpenTP1と連携していないため，DBMSへのアクセス中に，障害が原因でUAPが異常終了した場合や，OpenTP1を再開始（リラン）した場合には，OpenTP1からDBMSへトランザクションの決着を指示しません。そのため，DBMS独自の機能でトランザクションを回復する必要があります。

(2)　XAインタフェースでデータベースへアクセスする場合の準備

XAインタフェースをサポートしたDBMSを，OpenTP1とXAインタフェースで連携して使う場合に準備する項目を次に示します。この準備は，OpenTP1提供以外のリソースマネジャを使う場合に必要です。

(a)　OpenTP1への登録

OpenTP1提供以外のリソースマネジャの各種名称を登録します。OpenTP1へは，次に示すどちらかの方法で登録します。

dcsetupコマンドでOpenTP1をセットアップ後，trnlnkrmコマンドを実行する。

拡張RM登録定義を作成する。

拡張RM登録定義を作成しておくと，dcsetupコマンドでOpenTP1をセットアップしたあとにtrnlnkrmコマンドを実行しなくても良くなります。trnlnkrmコマンドの使い方については，マニュアル「OpenTP1 運用と操作」を参照してください。拡張RM登録定義の指定方法については，マニュアル「OpenTP1 システム定義」を参照してください。

(b)　UAPのリンケージ

UAPの実行形式ファイルを作成するときに，トランザクション制御用オブジェクトファイル，およびDBMSのライブラリとオブジェクトモジュールをリンケージする必要があります。

トランザクション制御用オブジェクトファイルは，trnmkobjコマンドを実行して作成します。trnmkobjコマンドの使い方については，マニュアル「OpenTP1 運用と操作」を参照してください。

(c)　システム定義

DBMSを使用する場合，トランザクションサービス定義にtrnstring形式の定義を，必要に応じて，ユーザサービス定義，またはユーザサービスデフォルト定義に，trnrmid形式の定義をする必要があります。指定する内容には，DBMS固有の項目もあります。このような項目は，使用するDBMSのマニュアルを参照してください。

trnstring，trnrmid形式の定義を指定すると，一つのリソースマネジャを複数の制御単位に分け，接続するユーザ名称などを変更してリソースマネジャに接続することもできます（リソースマネジャ接続先選択機能）。リソースマネジャ接続先選択機能については，マニュアル「OpenTP1 プログラム作成の手引」を参照してください。

trnstring，trnrmid形式の定義については，マニュアル「OpenTP1 システム定義」を参照してください。

(d)　環境変数

DBMSを使用する場合，特定の環境変数が必要になる場合があります。その場合，トランザクションサービス定義，ユーザサービス定義，またはユーザサービスデフォルト定義に，putenv形式の定義をする必要があります。

putenv形式の定義については，マニュアル「OpenTP1 システム定義」を参照してください。

(e)　OpenTP1内部スレッドスタック領域の拡張

DBMSを使用する場合，トランザクションサービス定義で，thread_stack_sizeオペランドにOpenTP1内部で使用するスレッドスタック領域のサイズを設定する必要があります。

定義の詳細については，マニュアル「OpenTP1 システム定義」を参照してください。

5　環境設定手順と運用の概要

この章では，OpenTP1システムを開始するまでの手順と運用方法の概要，および障害対策について説明します。

5.1　OpenTP1システムの環境設定手順

OpenTP1の環境設定は，OSの管理者であるスーパユーザの作業から始まります。その後，スーパユーザが登録したOpenTP1管理者が，OpenTP1の環境設定を引き継ぎます。

ここでは，OpenTP1開始直前までの環境設定手順を示します。

次に示すOpenTP1の機能を使う場合には，OpenTP1の環境設定手順に加えて，該当するOpenTP1の機能を実現するための専用の手順が必要になります。

メッセージ送受信機能を使う場合

メッセージ制御機能を使う場合

メッセージキューイング機能を使う場合

通信プロトコルにOSI TPを使ったクライアント/サーバ形態の通信をする場合

5.1.1　環境設定手順の概要

(1)　OpenTP1の環境設定手順

OpenTP1の環境設定手順を次の図に示します。

図5‒1　OpenTP1の環境設定手順

JP1/Base，JP1/AJS，およびJP1/AJS2 - Scenario Operationと連携して，スケールアウトのシナリオテンプレートを利用すると，OpenTP1の環境設定手順の一部を自動化できます。シナリオテンプレートを利用した環境設定については，マニュアル「OpenTP1 運用と操作」のスケールアウトのシナリオテンプレートについての説明を参照してください。

(2)　メッセージ送受信機能を使う場合の環境設定手順

メッセージ送受信機能を使う場合の環境設定手順を次の図に示します。

図5‒2　メッセージ送受信機能を使う場合の環境設定手順

(3)　メッセージ制御機能を使う場合の環境設定手順

TP1/Messagingを使用する場合の環境設定手順については，マニュアル「TP1/Messaging 使用の手引」を参照してください。

(4)　メッセージキューイング機能を使う場合の環境設定手順

メッセージキューイング機能を使う場合の環境設定手順を次の図に示します。

図5‒3　メッセージキューイング機能を使う場合の環境設定手順

(5)　通信プロトコルにOSI TPを使ったクライアント/サーバ形態の通信をする場合の環境設定手順

通信プロトコルにOSI TPを使ったクライアント/サーバ形態の通信をする場合の環境設定手順を次の図に示します。

図5‒4　通信プロトコルにOSI TPを使ったクライアント/サーバ形態の通信をする場合の環境設定手順

5.1.2　環境設定の作業

OpenTP1の環境設定で実行する作業について説明します。ここに示す作業の詳細については，マニュアル「OpenTP1 運用と操作」を参照してください。

(1)　スーパユーザの環境設定作業

(a)　OpenTP1管理者の登録

OpenTP1管理者のユーザIDを設定します。ユーザIDには必ずパスワードを設定しておいてください。

(b)　OpenTP1グループの設定

OpenTP1管理者のグループIDに，OpenTP1専用の管理者グループを設定します。

(c)　OpenTP1のインストール

構築するOpenTP1システムに必要な製品を，インストールします。

(d)　OpenTP1ホームディレクトリの設定

OpenTP1をインストールするディレクトリを設定します。このディレクトリの所有者はOpenTP1管理者を，所有者グループにはOpenTP1専用の管理者グループを設定します。

(e)　OpenTP1をOSへ登録

OpenTP1のコマンド（dcsetupコマンド）で，OpenTP1をOSに登録します。

(f)　OpenTP1ファイルシステム用のディスクパーティションの確保

OpenTP1ファイルシステムとして使用する領域を作成します。キャラクタ型スペシャルファイル上にOpenTP1ファイルシステムを作成するときに，ディスクパーティションを確保します。通常ファイル上にOpenTP1ファイルシステムを作成する場合は必要ありません。

(2)　OpenTP1管理者の環境設定作業

(a)　OpenTP1のシステム定義情報の作成

OpenTP1のシステムサービス定義の定義ファイルを作成します。作成したシステム定義は，dcdefchkコマンドでチェックできます。

(b)　OpenTP1管理者の環境設定

OpenTP1の運用コマンド実行に必要な環境変数を，OpenTP1管理者のログイン環境に設定します。環境変数DCDIRのディレクトリ名は，50バイト以内で設定してください。

(c)　OpenTP1の内部制御用資源の確保

OpenTP1で使う資源を確保します。資源を確保するときはdcmakeupコマンドを実行します。dcmakeupコマンドで確保する資源の量は，システムサービス定義の内容から自動的に解析されます。

(d)　OpenTP1ファイルシステムの初期設定

OpenTP1ファイルシステムとして使用する領域を，OpenTP1のコマンド（filmkfsコマンド）で初期化します。OpenTP1ファイルシステム領域名は，49文字以内で指定してください。

(e)　OpenTP1ファイルの作成

OpenTP1のコマンド（filmkfsコマンド）で初期化済みの領域を，使用するOpenTP1ファイル固有のコマンド（jnlinit，stsinitなど）で初期化します。その後，必要な初期データを作成します。

(f)　OpenTP1ファイル以外のファイルの作成

UAPの実行形式ファイルやOpenTP1の各種定義ファイルなど，通常ファイル上で使用するファイルを作成します。

(g)　リソースマネジャの登録

OpenTP1で提供している製品以外のリソースマネジャを使う場合には，trnlnkrmコマンドで該当するRMを登録します。拡張RM登録定義を作成してある場合は，trnlnkrmコマンドを実行する必要はありません。

(h)　トランザクション制御用オブジェクトファイルの作成

trnmkobjコマンドで，トランザクション処理をするUAPに必要な，トランザクション制御用オブジェクトファイルを作成します。

(i)　OpenTP1で使用するUAPの作成

OpenTP1で使用するUAPを作成します。メッセージ送受信機能を使う場合にはTP1/Message Controlの，メッセージキューイング機能を使う場合にはTP1/Message Queueの環境設定が完了してから，UAPを作成してください。

(3)　メッセージ送受信機能を使う場合の環境設定手順

メッセージ送受信機能（TP1/Message Control）を使う場合には，次に示す作業をします。

MCFメイン関数の作成とディレクトリへの組み込み

MCFサービス名の登録

システムサービス情報定義ファイルの作成

定義オブジェクトファイルの作成

(4)　メッセージキューイング機能を使う場合の環境設定手順

メッセージキューイング機能（TP1/Message Queue）を使う場合には，次に示す作業をします。

システムサービス情報定義ファイルの作成

定義オブジェクトファイルの作成

(5)　通信プロトコルにOSI TPを使ったクライアント/サーバ形態の通信をする場合の環境設定手順

TP1/NET/OSI-TP-Extendedを使ったOSI TP通信をする場合には，次に示す作業をします。

システムサービス情報定義ファイルの作成

定義オブジェクトファイルの作成

5.2　OpenTP1システムの運用

OpenTP1には，日常的にしなければならない運用と，システム変更のための運用，そのほかの運用があります。システム運用の詳細については，マニュアル「OpenTP1 運用と操作」を参照してください。OpenTP1の日常的な運用を表5-1に，システム変更のための運用を表5-2に，そのほかの運用を表5-3に示します。

表5‒1　OpenTP1の日常的な運用

運用項目

運用の目的

運用方法

OpenTP1の開始

業務を開始するため。

前回の終了状態を引き継ぐ再開始と，引き継がない正常開始があります。

dcstartコマンドで開始するか，OS起動時に自動的に開始するかのどちらかを，システム環境定義で指定します。

OpenTP1の正常終了

業務を正常に終了するため。

dcstopコマンドで終了させます。

OpenTP1の強制正常終了

オンラインシステムを正常に終了するため。

UAPがオンライン中に異常終了していた場合でも，オンラインシステムを正常終了します。

dcstop -nコマンドで終了させます。

OpenTP1の計画停止A

MCFの管理する端末に障害が発生した場合などオンラインシステムを一時的に中断させるため。

出力キューにメッセージを残したまま終了します。

dcstop -aコマンドで終了させます。

OpenTP1の計画停止B

オンラインシステムを直ちに停止させるため。

実行中のサービスの完了後，直ちにOpenTP1を終了します。

dcstop -bコマンドで終了させます。

OpenTP1のMCF構成変更準備停止

システムの構成を変更した上で，前回の終了状態を引き継ぐMCF構成変更再開始をするため。

実行中のサービスの完了後，直ちにOpenTP1を終了します。

dcstop -b -qコマンドで終了させます。

OpenTP1の強制停止

オンラインシステムを緊急に停止させるため。

実行中のサービスの完了を待たないで，直ちにOpenTP1を終了します。

dcstop -fコマンドで終了させます。

UAPの開始

UAP単位で業務を開始するため。

OpenTP1開始時に自動的に開始するUAPはユーザサービス構成定義で指定します。

UAPの終了

UAP単位で業務を終了するため。

正常終了と強制停止があります。

dcsvstopコマンドで終了させるか，OpenTP1終了時に自動的に終了させます。

ジャーナルのアンロード

ジャーナル維持機能を利用するため。

DAMファイル，TAMファイルの障害発生に備えるため。

システムジャーナルファイルをファイルにコピーします。

DAM，TAMのバックアップ

DAMファイル，TAMファイルの障害発生に備えるため。

DAMファイル，TAMファイルをファイルにコピーします。

メッセージログのファイルへの出力

OpenTP1やUAPから出力されたメッセージログを利用するため。

メッセージログファイルに蓄積されたメッセージログを標準出力に出力します。

表5‒2　OpenTP1のシステム変更のための運用

運用項目

運用の目的

運用方法

OpenTP1

停止中

稼働中

定義の変更

OpenTP1システムの構成や実行環境を変更するため。

定義ファイルの内容を変更します。

スーパユーザが定義を変更する場合

定義内容を変更して，OpenTP1を正常終了したあとで，dcsetup -dコマンドでOpenTP1をOSから削除します。その後dcsetupコマンドを実行して，OpenTP1をOSに再登録します。

OpenTP1管理者が定義を変更する場合

定義内容を変更して，OpenTP1を正常終了したあとで，dcresetコマンドを実行します。dcresetコマンドはOpenTP1稼働中には実行できないので注意してください。

○

×

OpenTP1稼働中のUAPの変更

UAPをOpenTP1稼働中に変更するため。（OpenTP1の終了後，再開したときにも変更したまま）

UAPを終了させたあと，UAPを入れ替えます。必要ならUAPを正常終了させたあとでユーザサービス定義も入れ替えます。入れ替え後にUAPを開始します。

正常終了させないで定義を入れ替えた場合，そのUAPの動作は保証できません。

−

○

OpenTP1稼働中のUAPの変更（異なるディレクトリ下のUAPに変更）

UAPをOpenTP1稼働中に一時的に変更するため。（OpenTP1の終了後再開始したときには，定義されたディレクトリ下のUAPが有効です）

UAPを終了させたあと，運用コマンドでサーチパスを変更します。サーチパスの変更後，UAPを開始します。

−

○

ファイルの変更

ファイルの容量を変更するため。（ファイルの容量はOpenTP1停止中に変更します。ただし，ステータスファイルは，OpenTP1稼働中に容量を変更できます）

物理ファイルを確保してファイルの定義を変更し容量を変えるか，新たなファイルを作成して定義します。

ステータスファイルは，運用コマンドで容量を変えられます。

○

△

オンライン中にネットワークの構成を変更

OpenTP1システムを構成するネットワークのノードを，オンライン中に追加したり削除したりするため。

次の二つの方法があります。

●システム共通定義の内容で変更

システム共通定義のall_nodeオペランドの内容を変更します。

namndchgコマンドを実行します。

現在のall_nodeオペランドの内容を標準出力に出力するときは，namndchgコマンドに-lオプションを付けて実行します。

●ドメイン定義ファイルの内容で変更

all_nodeおよびall_node_exのドメイン定義ファイルを作成します。

namchgflコマンドを実行します。

×

○

OpenTP1稼働中のMCF通信サービスのメイン関数，UOC，ライブラリの変更

OpenTP1を停止しないでMCF通信サービスの運用を変更するため。

運用コマンドで，MCF通信サービスを部分停止させ，該当するメイン関数，UOC，およびライブラリを入れ替えます。

×

○

（凡例）

○：可能な作業

×：不可能な作業

△：一部可能な作業

−：該当しません

表5‒3　そのほかのOpenTP1の運用

運用項目

運用の目的

運用方法

状態監視

OpenTP1の状態を監視するため。

各種の状態監視の運用コマンドでOpenTP1の状態に関する情報を標準出力に出力します。

マルチOpenTP1

OpenTP1とUAPをテストするため。

同じノードに二つのOpenTP1を起動して本番用とテスト用に分けて使用します。

二つのOpenTP1を区別するため，それぞれのOpenTP1に名称（OpenTP1識別子）を設定します。

5.3　障害対策の概要

システムの一部に障害が発生しても，OpenTP1では，部分回復処理をしてシステムが全面停止しないようにしています。また，重大な障害が原因で全面停止した場合でも，全面回復処理をして，システムの状態やユーザの資源を回復できます。ここでは，障害時の回復方法について説明します。障害対策については，マニュアル「OpenTP1 運用と操作」を参照してください。

5.3.1　OpenTP1システム障害の対策

OpenTP1システムに障害が発生した場合，前回のオンラインの状態を引き継いで，履歴情報を基にOpenTP1システムを障害発生直前の状態に回復できます。この開始モードを再開始（リラン）といいます。OpenTP1は，再開始（リラン）に備えて，ジャーナルファイルに履歴情報を取得しています。

(1)　全面回復による再開始（リラン）の手順

OpenTP1は，全面回復によって再開始（リラン）します。再開始（リラン）は，システム回復処理，サービス回復処理，トランザクション回復処理の順で実行されます。

システム回復処理

ステータスファイルにはシステム制御情報として，システムサービスやUAPの構成情報，システムファイルの情報などが格納されています。まず，システム制御情報を基に，トランザクションの同期点処理と関係のない，システムの状態を回復します。OpenTP1は，システム制御情報を基に，回復に使用するチェックポイントダンプファイルやシステムジャーナルファイルを決定します。

サービス回復処理

システム制御情報を基に，システムの状態が回復すると，システムサービスの回復を開始します。システムサービスは，チェックポイントダンプファイルとシステムジャーナルファイルに格納したデータを基に回復します。回復は最新世代のチェックポイントダンプと，最新世代のチェックポイントダンプ取得以降に取得したすべての回復用のジャーナルが必要です。最新世代のチェックポイントダンプが使用できないときには，一世代前のチェックポイントダンプを使用して回復を試みます。この場合，一世代前のチェックポイントダンプ取得以降に取得したすべてのジャーナルが必要です。なお，有効保証世代は二世代までです。有効保証世代のチェックポイントダンプ以降に取得したジャーナルが保証されます。ここまでの処理で，OpenTP1はオンライン業務を再開できる状態になります。

トランザクション回復処理

新たなオンライン処理と並行して，システム障害でOpenTP1が停止したときに実行中だった，UAPのトランザクション処理を回復してロールバックまたはコミットします。トランザクションをロールバックするか，コミットするかはトランザクション処理がどこまで進んでいたかで決まります。トランザクション処理が同期点の1相目以前にあった場合には，OpenTP1がグローバルトランザクションをロールバックします。2相目以降にあった場合には，OpenTP1がルートトランザクションブランチでの決定に従ってグローバルトランザクションをロールバック，またはコミットします。システム停止時にトランザクション処理がどこまで進んでいたのかは，OpenTP1がシステムジャーナルファイルの同期点ジャーナルを基に判断します。

全面回復によって復元されるトランザクションの状態を，次の図に示します。

図5‒5　全面回復処理によって復元されるトランザクション

(2)　OpenTP1システム終了中にシステム停止した場合の全面回復処理時のユーザサーバの状態

dcstopコマンドを入力してOpenTP1システムを終了しているときにシステム停止した場合，終了処理中にユーザサーバのステータス変化を反映しないでdcstopコマンド入力時の状態に戻すか，ステータス変化を反映して障害発生時の状態に戻すかを，ユーザサービス定義およびユーザサービスデフォルト定義で選択できます。ユーザサービス定義のstatus_change_when_termingオペランドにYを指定したユーザサーバは，最終的なステータスの変化を反映して，システム停止時の状態に戻ります。このオペランドにNを指定したときは，最終的なステータスの変化を反映しないで，dcstopコマンド入力時の状態に戻ります。

OpenTP1システム終了中にシステム停止した場合の全面回復処理時のユーザサーバの状態を次の図に示します。

図5‒6　システム終了中にシステム停止した場合の全面回復処理時のユーザサーバの状態

5.3.2　アプリケーションプログラム障害の対策

UAPに障害が起こった場合，OpenTP1はUAP単位の回復処理（部分回復）をして，システム全体に影響がないようにします。UAPに障害が起こった場合の処置について説明します。

(1)　システム定義が間違っている場合の処置

システム定義に適切でない値が設定されている場合は，OpenTP1はエラーメッセージを出力して該当するUAPを停止させます。この場合は，システム定義を修正してUAPを再び開始させてください。

メモリ容量が不足したことが原因でUAPを開始できない場合は，必要ないUAPのプロセスを停止させるか，または不要なファイルを削除してからOpenTP1を再開始させてください。

(2)　プログラムがループした場合の処置

UAPが終了できなかったり，サービス要求の結果が戻ってこなかったりした場合に備えて，OpenTP1は次に示す時間を監視しています。

トランザクション経過時間の監視

トランザクションの開始から終了までの経過時間を監視します。トランザクション経過時間を超えると，OpenTP1は該当するUAPプロセスを強制的に終了させて，トランザクションをロールバックさせます。経過時間を監視するのはトランザクションの処理にだけ有効です。経過時間に0を指定した場合は，時間監視をしません。

RPC応答時間監視

サーバUAPにサービスを要求してから応答が返るまでの時間を監視します。指定した経過時間を超えた場合，サービスを要求した関数はエラーリターンします。トランザクションの処理の場合は，同期点処理でロールバックします。応答待ち時間に0を指定したときは，応答が返るまで待ち続けます。

CPU時間の監視

トランザクション処理を開始してから同期点を取得するまでに，トランザクションブランチが使うCPU時間を監視します。指定した時間を過ぎてもトランザクションが完了しない場合は，該当するトランザクションブランチを終了させて，トランザクションをロールバックさせます。

(3)　UAPのリンケージの不良で異常終了する場合の処置

OSがHP-UXの場合，リンケージ時のバインドモードには必ず"immediate"を指定してください。UAPを"immediate"以外のバインドモードで作成した場合，UAPが異常終了する場合があります。作成したUAPのバインドモードが"immediate"かどうかは，OSのchatrコマンドで確認してください。

(4)　異常終了したUAPの部分回復処理の場合の処置

UAPが異常終了した場合，OpenTP1はUAPの部分回復処理をします。UAPの部分回復には，次のものがあります。

(a)　UAPプロセスの再起動および閉塞処理

SPPが異常終了した場合

サービスグループを閉塞するか，またはプロセスを再起動するかをユーザサービス定義に指定します。ただし，ユーザサービス定義の連続異常終了限界経過時間に指定した時間内に3回異常終了すると，OpenTP1はSPPを強制的に閉塞します。閉塞されたSPPにサービスを要求しても，エラーリターンします。

MHPが異常終了した場合

アプリケーションまたはサービスを閉塞するか，またはプロセスを再起動するかをアプリケーション属性定義に指定します。MHPが閉塞された場合，そのMHPに対してメッセージ送信されると，ERREVT2のMCFイベントが通知されます。

SUPが異常終了した場合

異常終了したときにプロセスを再起動するかどうかは，ユーザサービス定義のauto_restartオペランドの指定に従います。

(b)　トランザクションの部分回復処理

異常終了したUAPがトランザクション処理中の場合は，トランザクション部分回復をします。

UAPで障害が起こった場合，トランザクション内のUAPプロセスが異常終了したことをOpenTP1が検知して，トランザクション回復サービスは該当するトランザクションを回復して，決着させます。このとき，トランザクションのプロセスの回復処理を並行させて，効率を上げることができます。並行させて回復するプロセスの数は，トランザクションサービス定義に指定しておきます。

回復依頼をスケジュールしているときにシステムが使用する領域が不足してトランザクションを回復できない場合があります。これを防ぐため，OpenTP1は一定間隔で回復していないトランザクションを検索して，再び回復する処理をします。

(5)　UAPのデッドロックが起こった場合の処置

複数のUAPから同じ資源にアクセスすると，デッドロックが起こる場合があります。OpenTP1がデッドロックを検知すると，UAPのデッドロックプライオリティを比較して，優先度が低い方のUAPの関数をエラーリターンさせます。

デッドロック時のOpenTP1の処置については，「3.9.1(5)　デッドロックの対処方法」を参照してください。

5.3.3　ファイル障害の対策

次に示すOpenTP1ファイルに障害が起こったときの対処について説明します。

システムで使うファイル

キューを格納するファイル

ユーザデータを格納するファイル

ファイル障害の対策の詳細については，マニュアル「OpenTP1 運用と操作」の障害対策を参照してください。

(1)　システムで使うファイルの障害の対策

システムファイルに障害が起こった場合の処置について説明します。

(a)　ステータスファイルの障害

オンライン中に障害が起こった場合，使用可能な予備ファイルがあるときは，予備ファイルを現用に切り替えて，OpenTP1は処理を続けます。予備ファイルがないときは，ステータスサービスが停止して，OpenTP1は停止します。ただし，ステータスファイルの片系運転可を指定しているときは，予備ファイルがなくても正常な系だけで処理を続けます。停止した場合は，OpenTP1管理者はエラーの原因に対処したあとで，OpenTP1を再開始してください。

OpenTP1の開始時に障害が起こった場合は，ステータスサービス定義のsts_initial_error_switchオペランドの指定によって，OpenTP1の開始処理を続けるかまたは停止するかが決まります。

(b)　システムジャーナルファイルの障害

スワップ先にできるファイルグループがある場合は，OpenTP1は待機のファイルグループを現用に切り替えます。そして，障害が起こったファイルグループを予約状態にして，OpenTP1は処理を続けます。

システムジャーナルファイルにスワップ先にできるファイルグループがない場合は，OpenTP1は停止します。停止した場合は，OpenTP1管理者はエラーの原因に対処してから，OpenTP1を再開始してください。

(c)　チェックポイントダンプファイルの障害

上書きできるほかのファイルグループがある場合は，OpenTP1はそのファイルグループを現用に切り替えます。そして，障害が起こったファイルグループを予約状態にして，OpenTP1は処理を続けます。

上書きできるほかのファイルグループがない場合は，OpenTP1は停止します。ただし，チェックポイントダンプファイルを二重化して片系運転可を指定しているときは，予備ファイルがなくても正常なファイルグループだけで処理を続けます。停止した場合は，OpenTP1管理者はエラーの原因に対処してから，OpenTP1を再開始してください。

(d)　アーカイブジャーナルファイルの障害

スワップ先にできるファイルグループがある場合は，OpenTP1はそのファイルグループを現用に切り替えます。そして，障害が起こったファイルグループを予約状態にして，OpenTP1は処理を続けます。

スワップ先にできるファイルグループがない場合は，OpenTP1は停止します。停止した場合は，OpenTP1管理者はエラーの原因に対処してから，OpenTP1を再開始してください。

(e)　トランザクションリカバリジャーナルファイルまたはサーバリカバリジャーナルファイルの障害

TRF，またはSRFで障害が起こると，そのことを知らせるエラーメッセージが出力されます。OpenTP1管理者は，出力されたエラーメッセージを参照して，リカバリジャーナルファイルを回復するコマンド（jnlmkrfコマンド）を実行してください。

jnlmkrfコマンドを実行してもファイルを回復できない場合は，OpenTP1管理者はコマンド（damfrc，tamfrcコマンドなど）でリソースマネジャを回復したあとで，OpenTP1を強制的に正常開始してください。

(f)　メッセージログファイルの障害

メッセージログファイルは二つのファイルを使っています（dclog1，dclog2）。どちらか一つのファイルに障害が起こった場合，OpenTP1は障害のファイルを切り離して正常なファイルだけでメッセージログを取得します。両方のファイルに障害が起こった場合は，メッセージログをファイルに出力しないでOpenTP1は処理を続けます。

(g)　ノードリストファイルの障害

オンライン中に障害が起こった場合，OpenTP1はノードリストファイルへの書き込みをしないで，処理を継続します。したがって，次回オンライン時にノード情報を引き継げません。OpenTP1管理者はエラーの原因に対処してからノードリストファイルを作成し直し，OpenTP1を再開始してください。

(2)　キューを格納するファイルの障害の対策

キューを格納するファイルに障害が起こった場合の処置について説明します。

(a)　メッセージキューファイルの障害

メッセージキューファイルをオープンできない場合は，そのことを知らせるエラーメッセージが出力されます。エラーメッセージが出力された場合は，OpenTP1管理者は出力されたエラーメッセージを参照して，その指示に従って対処してください。

(b)　MQAキューファイルの障害

TP1/Message Queueのキューファイルに障害が起こった場合の処置については，マニュアル「TP1/Message Queue 使用の手引」の障害対策を参照してください。

(3)　ユーザデータを格納するファイルの障害の対策

ユーザファイルに障害が起こった場合の処置について説明します。

(a)　DAMファイルの障害

DAMサービスは，DAMファイルにアクセスしたUAPにエラーを返します。その後DAMファイルは障害閉塞されます。DAMファイルを回復する必要がある場合は，OpenTP1管理者はDAMファイルをOpenTP1から切り離して，エラーの原因に対処してください。

(b)　TAMファイルの障害

TAMサービスは，TAMテーブルにアクセスしたUAPにエラーを報告します。その後TAMテーブルは障害閉塞されます。TAMファイルを回復する必要がある場合は，OpenTP1管理者はTAMテーブルをOpenTP1から切り離して，エラーの原因に対処してください。

(c)　ISAMファイルの障害

ISAMファイルに障害が起こった場合の処置については，マニュアル「索引順編成ファイル管理 ISAM」の障害対策を参照してください。

(d)　データベースマネジメントシステムの障害

DBMSに障害が起こった場合の処置については，該当するDBMSのマニュアルの障害対策を参照してください。

5.3.4　ネットワーク障害の対策

(1)　通信制御装置，端末，回線の障害

コネクションに障害が起こった場合，エラーメッセージが出力されます。OpenTP1管理者は，エラーメッセージの内容を参照してエラーの原因に対処してください。対処後，コマンドを実行してコネクションを再び確立してください。

障害時の処置は，通信プロトコル対応製品で異なります。障害が起こったときの処置については，マニュアル「OpenTP1 プロトコル」の該当するプロトコル編を参照してください。

(2)　LANの障害

LANに障害が起こると，ノードをわたるRPCの関数はクライアントUAPにエラーリターンします。各システムの管理者は，OS，およびハードウェアの障害時の処置に従って対処したあとに，システムを再実行してください。

(3)　マルチノード機能の構成での通信障害

グローバルアーカイブジャーナルサービスと被アーカイブジャーナルノードのジャーナルサービスとの間で通信障害が起こった場合は，エラーメッセージが出力されます。OpenTP1管理者は，エラーメッセージの内容を参照してエラーの原因に対処してください。

上記の通信障害が起こった場合，アーカイブは実行されません。障害が対処されない状態のときにアンロードする必要がある場合は，被アーカイブジャーナルノードで個別にアンロードしてください。

(4)　ノードリストファイル障害

ノード自動追加機能使用時に，ノードリストファイル障害が発生した場合，KFCA33615-Eメッセージまたは，KFCA33622-Eメッセージを出力後，ノードリストファイルへのアクセスを停止し，オンライン処理を続行します。

ノードリストファイルへのアクセスを停止後，OpenTP1再起動時※に障害が回復し，正常にノードリストファイルを引き継げた場合，障害中に共用メモリ上で更新されたノード情報は，ノードリストファイルへ反映されていないため，前回終了時のノード情報を正しく引き継げないことがあります。

このような場合，OpenTP1では，オンライン後にノードリストの整合性確保によって，最新のノードリスト情報でノードリストを再構築します。

注※

OpenTP1管理者はエラーの原因に対処してから，OpenTP1を再開始してください。

5.3.5　OpenTP1の内部監視

OpenTP1は，システムの障害を検知するため，次の表に示す項目を監視しています。

表5‒4　OpenTP1監視項目一覧

監視項目

監視内容

関連するシステム定義

システム初期化時間

dcstartコマンドを入力してからシステム初期化処理が終わるまでの待ち時間を監視します。指定時間を過ぎてもシステム初期化処理が終わらない場合には，user_commandなどの不良と見なしてシステム開始処理を中止します。

システム環境定義

RPC応答時間

RPCのサービス要求に対して，応答が返るまでの待ち時間を監視します。指定時間を過ぎても応答がない場合，サーバUAPのループなどによる送受信タイムアウトとして要求元にエラーリターンします。

システム共通定義

連鎖RPC間隔

サーバUAPがサービス要求元にリターンしてから，次のRPCかトランザクション決着指示が来るまでの時間を監視します。指定時間を過ぎてもRPCや決着指示が来ない場合，サービス要求元の不良と見なして，サーバUAPのプロセスを異常終了させます。

ユーザサービス定義

ユーザサービス

デフォルト定義

デッドロック

排他要求が待ち状態になってから解除されるまでの待ち時間を監視します。指定時間を過ぎても待ち状態が解除されない場合，デッドロックと見なして，要求元にエラーリターンします。

ロックサービス定義

トランザクションブランチ限界経過時間

トランザクションブランチの処理時間を監視します。

指定時間を過ぎても処理が終わらない場合，サーバUAPの不良と見なして，このトランザクションブランチのプロセスを異常終了させて，ロールバックします。

ユーザサービス定義

ユーザサービス

デフォルト定義

トランザクションサービス定義

CPU時間

トランザクション処理を開始してから同期点処理をするまでにトランザクションブランチが使用できるCPU時間を監視します。指定した時間を過ぎてもトランザクションが完了しない場合は，該当するトランザクションブランチのプロセスを異常終了させてロールバックします。

ユーザサービス定義

ユーザサービスデフォルト定義

トランザクションサービス定義

UAP連続異常終了限界経過時間

UAPの連続異常終了の時間を監視します。

ユーザサービス定義での閉塞指定にかかわらずUAPが指定時間内に3回続けて異常終了した場合，該当するサービスグループまたはサービスを閉塞します。

ユーザサービス定義

ユーザサービスデフォルト定義

サービス要求滞留値

スケジュールキュー内に滞留しているサービス要求数を監視します。（この指定値×起動プロセス数）を超えると，非常駐プロセスを起動してサービスを処理します。

ユーザサービス定義

ユーザサービスデフォルト定義

入出力キュー使用率

入出力キューのキューグループごとに，物理ファイルの使用率を監視します。指定した使用率を超えた場合，警告メッセージを出力します。

メッセージキューサービス定義

通信関数発行回数

UAPの暴走監視のためトランザクション内で発行する通信関数の発行回数を監視します。指定値を超えて通信関数を発行した場合，UAPを異常終了させてロールバックします。

MCFマネジャ定義

未処理送信メッセージ滞留時間

正常終了処理が長時間終了しないのを防止するため，出力キュー中の未処理送信メッセージの滞留時間を監視します。指定値を超えても未処理送信メッセージが残っている場合，ERREVTAを通知したあとで未処理送信メッセージを破棄して，正常終了処理を続行します。

MCF通信構成定義

5.3.6　障害の原因解析

ここでは，OpenTP1システムで障害の原因を解析するための機能について説明します。

なお，次に示す機能は，TP1/Extension 1をインストールしていることが前提です。TP1/Extension 1をインストールしていない場合の動作は保証できません。

性能検証用トレース

XAR性能検証用トレース

JNL性能検証用トレース

LCK性能検証用トレース

MCF性能検証用トレース

TRNイベントトレース

NAMイベントトレース

プロセスサービスのイベントトレース

FILイベントトレース

(1)　MCFトレース

MCFのプロセスごとに，発生したイベントや送受信データの情報を取得しています。これをMCFトレースといいます。MCFトレース情報は，共用メモリ中のトレース領域（トレースバッファ）に取得されます。MCF通信構成定義でMCFトレースのディスク出力機能を使うことを指定しておくと，トレース領域に空きがなくなった場合に，ディスク上のMCFトレースファイルに出力されます。MCFトレースのディスク出力機能を使用しない場合で，一時的にMCFトレース情報が必要になったときは，MCFトレース取得開始コマンド（mcftstrtr），およびMCFトレース取得終了コマンド（mcftstptr）を使用すると，MCFトレース情報をMCFトレースファイルに出力できます。コマンドの詳細については，マニュアル「OpenTP1 運用と操作」を参照してください。

MCFトレースは，障害発生までのプロセス内での制御関数と各イベントの制御の流れを解析するために利用します。

(2)　UAPトレース

OpenTP1のUAP（SUP，SPP，MHP）が異常終了すると，UAPから呼び出したAPIのトレース情報が出力されます。この機能をUAPトレースといい，取得した情報をUAPトレース情報といいます。OpenTP1では，UAPプロセス単位にUAPトレース情報を取得しています。

UAPトレース情報は，$DCDIR/spool/save/ディレクトリの下に，ファイル名"サーバ名n.uat"（nはUAPプロセスの退避コアファイルに付けられる通番を示します）で取得されます。このファイルを，UAPトレース編集出力ファイルといいます。

任意の退避コアファイルを基にUAPトレース情報を出力する場合は，UAPが異常終了したときに生成した退避コアファイルをuatdumpコマンドに指定して実行します。uatdumpコマンドの出力先をリダイレクトすると，任意のファイルにUAPトレース情報を取得できます。

UAPトレース情報を格納する件数の最大数は，ユーザサービス定義のuap_trace_maxオペランドに指定します。ここに指定した値を超えた場合は，ラップアラウンドして取得します。

UAPトレース情報は，異常終了したUAPのプロセス単位に取得されます。RPCでノードをわたるトランザクション処理が異常終了した場合は，UAPトレース情報はノードで実行したUAPプロセスごとに取得されます。

UAPトレースについては，マニュアル「OpenTP1 テスタ・UAPトレース使用の手引」のUAPトレースの説明を参照してください。

(3)　RPCトレース

RPCのサービス要求情報をファイルにトレースとして取得できます。これをRPCトレースといいます。RPCトレースは，RPC管理コマンドでダンプ出力できます。RPCトレースは，次の目的に利用できます。

どのクライアントUAPとどのサーバUAPが，RPCでプロセス間通信をしたか調査します。

特定のサーバUAPで，どの順番にサービスを処理したか調査します。

RPCに障害が発生した場合に，障害発生までのサービス要求の流れを解析します。

RPCトレースファイルを編集出力する場合は，rpcdumpコマンドを実行します。

RPCトレースファイルは，システムサービスごとに取得できます。該当するシステムサービスの定義に，RPCトレースファイルを取得する指定をします。これらのRPCトレースファイルは，マージして時系列に出力できます。この場合は，rpcmrgコマンドを実行します。

(4)　性能検証用トレース

OpenTP1で動作する各種サービスの主なイベントでOpenTP1識別子などのトレース情報を取得しています。これを性能検証用トレースといいます。

性能検証用トレースには次の特長があります。

ノードおよびプロセスにわたる場合でもトレースを追うことができます。

API単位ではなく内部のイベント単位でトレースを取得するので，どの処理が性能のボトルネックであるか検証できます。

性能検証用トレースに関係するシステム定義は，次の表に示すとおりです。

表5‒5　性能検証用トレースに関係するシステム定義

定義名

形式

オペランド

定義内容

システム共通定義

set

prf_trace

性能検証用トレース情報を取得するかどうかを指定

set

trn_prf_trace_level

トレースの取得レベル

性能検証用トレース定義

set

prf_file_size

トレースファイルのサイズ

それぞれの定義の詳細については，マニュアル「OpenTP1 システム定義」を参照してください。

なお，性能検証用トレースはprfgetコマンドによってバイナリ形式で取り出したあと，prfedコマンド，またはdcalzprfコマンドによってキャラクタ形式で出力できます。

また，ユーザ固有のトレース情報をdc_prf_utrace_put関数によってトレースファイルに取得したり，直前に取得したトレースのプロセス内取得通番をdc_prf_get_trace_num関数によって取得したりできます。

注意事項

通常のOpenTP1再開始，およびホットスタンバイでは，トレース情報は引き継ぎません。

性能検証用トレース取得機能では，オンラインの性能に影響がないように，トレース取得での排他を行いません。そのため，トレース取得の競合が発生した場合，トレース情報が抜けたり，不正なトレース情報が取得されたりすることがあります。

(5)　XAR性能検証用トレース

XAリソースサービスを使用したトランザクション連携の各種イベント（アプリケーションサーバからのトランザクション要求，OpenTP1のトランザクション処理）のトレース情報を取得しています。これをXAR性能検証用トレースといいます。

XAR性能検証用トレースは，$DCDIR/spool/dcxarinfディレクトリの下に，"_xr_001"，"_xr_002"，"_xr_003"…というファイル名で取得されます。これらのファイルをXAR性能検証用トレース情報ファイルといいます。XAR性能検証用トレース情報ファイルの出力先およびファイル名は変更できませんが，取得サイズおよび取得ファイル数は変更できます。詳細については，マニュアル「OpenTP1 システム定義」のXAR性能検証用トレース定義の説明を参照してください。

XAR性能検証用トレースを取得するには，次の手順で定義を設定します。

システム共通定義のprf_traceオペランドにYを指定します。

XAリソースサービス定義のxar_prf_trace_levelオペランドでXAR性能検証用トレースの取得レベルを指定します。

次の表にxar_prf_trace_levelオペランドの指定値とXAR性能検証用トレースの取得情報の関係を示します。

表5‒6　xar_prf_trace_levelオペランドの指定値とXAR性能検証用トレースの取得情報の関係

xar_prf_trace_levelオペランドの指定値

XAR性能検証用トレースの取得情報

イベントID

トレースデータ長（単位：バイト）

取得タイミング

00000001

アプリケーションサーバからのトランザクション要求

0x4a00

128

トランザクションブランチの開始要求

呼び出し直後

0x4a01

128

リターン直前

0x4a02

128

トランザクションブランチ内からのRPC実行要求

呼び出し直後

0x4a03

128

リターン直前

0x4a04

128

トランザクションブランチの終了要求

呼び出し直後

0x4a05

128

リターン直前

0x4a06

128

トランザクションブランチのコミット準備要求

呼び出し直後

0x4a07

128

リターン直前

0x4a08

128

トランザクションブランチのコミット要求

呼び出し直後

0x4a09

128

リターン直前

0x4a0a

128

トランザクションブランチのロールバック要求

呼び出し直後

0x4a0b

128

リターン直前

0x4a0c

64

Prepared状態，Heuristically Completed状態のトランザクションブランチ通知要求

呼び出し直後

0x4a0d

64

リターン直前

0x4a0e

128

Heuristically Completed状態のトランザクションブランチ破棄要求

呼び出し直後

0x4a0f

128

リターン直前

00000002

OpenTP1のトランザクション処理

0x4b00

64

トランザクションブランチ開始

直前

0x4b01

64

直後

0x4b02

64

トランザクションブランチ内からのRPC実行

直前

0x4b03

64

直後

0x4b04

64

トランザクションブランチの終了

直前

0x4b05

64

直後

0x4b06

64

トランザクションブランチのコミット準備

直前

0x4b07

64

直後

0x4b08

64

トランザクションブランチのコミット

直前

0x4b09

64

直後

0x4b0a

64

トランザクションブランチのロールバック

直前

0x4b0b

64

直後

0x4b0c

64

Prepared，Heuristically Completed状態のトランザクションブランチの通知

直前

0x4b0d

64

直後

0x4b0e

64

Heuristically Completed状態のトランザクションブランチの破棄

直前

0x4b0f

64

直後

xar_prf_trace_levelオペランドの詳細については，マニュアル「OpenTP1 システム定義」のXAリソースサービス定義の説明を参照してください。

XAR性能検証用トレース情報ファイルの取得，編集出力には，prfgetコマンド，prfedコマンド，またはdcalzprfコマンドを使用します。取得方法，および編集出力方法を次に示します。

XAR性能検証用トレース情報ファイルの取得方法

最新のランIDで取得されていないトレース情報だけ取得する場合

$DCDIR/bin/prfget -f _xr | $DCDIR/bin/prfed -d

または

$DCDIR/bin/prfget -f _xr | $DCDIR/bin/dcalzprf

すべてのトレース情報を取得する場合

$DCDIR/bin/prfget -a -f _xr | $DCDIR/bin/prfed -d

または

$DCDIR/bin/prfget -a -f _xr | $DCDIR/bin/dcalzprf

XAR性能検証用トレース情報ファイルの編集出力方法

XAR性能検証用トレース情報ファイルからトレース情報を編集出力する場合，prfedコマンド，またはdcalzprfコマンドを実行してください。オプションは必要に応じて指定してください。

XAR性能検証用トレース情報の出力形式は，性能検証用トレースと同じです。出力形式の詳細については，マニュアル「OpenTP1 運用と操作」のprfedコマンド，またはdcalzprfコマンドを参照してください。

(6)　JNL性能検証用トレース

ジャーナルサービスで実行されるジャーナルバッファリング，およびジャーナル出力の各種イベントトレース情報を取得しています。これをJNL性能検証用トレースといいます。

JNL性能検証用トレースは，$DCDIR/spool/dcjnlinf/prfinfディレクトリの下に，"_jl_001"，"_jl_002"，"_jl_003"…というファイル名で取得されます。これらのファイルをJNL性能検証用トレース情報ファイルといいます。JNL性能検証用トレース情報ファイルの出力先およびファイル名は，変更できません。

JNL性能検証用トレースを取得するには，次の手順で定義を設定します。

システム共通定義のprf_traceオペランドにYを指定します。

システム共通定義のjnl_prf_event_trace_levelオペランドでJNL性能検証用トレースの取得レベルを指定します。

次の表にjnl_prf_event_trace_levelオペランドの指定値と取得するトレース情報の関係を示します。各イベントの取得タイミングについては，マニュアル「OpenTP1 運用と操作」の性能検証用トレース情報の取得の説明を参照してください。

表5‒7　jnl_prf_event_trace_levelオペランドの指定値と取得するトレース情報の関係

jnl_prf_event_trace_levelオペランドの指定値

トレース情報のイベントID

0xc202，0xc203，0xc401，0xc402

0xc001〜0xc201，0xc204〜0xc400

00000000

×

×

00000001

○

×

00000002

○

○

その他

○

○

（凡例）

○：トレース情報を取得します。

×：トレース情報を取得しません。

JNL性能検証用トレース情報ファイルの取得，編集出力には，prfgetコマンド，prfedコマンド，またはdcalzprfコマンドを使用します。取得方法を次に示します。

JNL性能検証用トレース情報ファイルの取得方法

最新のランIDで取得されていないトレース情報だけ取得する場合

$DCDIR/bin/prfget -f _jl | $DCDIR/bin/prfed -d

または

$DCDIR/bin/prfget -f _jl | $DCDIR/bin/dcalzprf

すべてのトレース情報を取得する場合

$DCDIR/bin/prfget -a -f _jl | $DCDIR/bin/prfed -d

または

$DCDIR/bin/prfget -a -f _jl | $DCDIR/bin/dcalzprf

(7)　LCK性能検証用トレース

トランザクション処理に伴う各種排他制御のトレース情報を取得しています。これをLCK性能検証用トレースといいます。

LCK性能検証用トレースは，$DCDIR/spool/dclckinf/prfディレクトリの下に，"_lk_001"，"_lk_002"，"_lk_003"…というファイル名で取得されます。これらのファイルをLCK性能検証用トレース情報ファイルといいます。LCK性能検証用トレース情報ファイルの出力先およびファイル名は変更できませんが，取得サイズおよび取得ファイル数は変更できます。詳細については，マニュアル「OpenTP1 システム定義」のLCK性能検証用トレース定義の説明を参照してください。

LCK性能検証用トレースを取得するには，次の手順で定義を設定します。

システム共通定義のprf_traceオペランドにYを指定します。

ロックサービス定義のlck_prf_trace_levelオペランドでLCK性能検証用トレースの取得レベルを指定します。

次の表にlck_prf_trace_levelオペランドの指定値とLCK性能検証用トレースの取得情報の関係を示します。

表5‒8　lck_prf_trace_levelオペランドの指定値とLCK性能検証用トレースの取得情報の関係

lck_prf_trace_levelオペランドの指定値

LCK性能検証用トレースの取得情報

イベントID

トレースデータ長（単位：バイト）

取得タイミング

00000000

排他制御についてのトレースを取得しない

−

−

−

00000001

排他制御についてのトレースを取得する

0x6400

128

資源の排他

呼び出し直後

0x6401

128

リターン直前

0x6410

128

排他待ち合せ

開始直前

0x6411

128

終了直後

0x6420

128

全資源の排他の解除

呼び出し直後

0x6421

128

リターン直前

0x6430

128

資源名称を指定した排他の解除

呼び出し直後

0x6431

128

リターン直前

（凡例）

−：該当しません。

lck_prf_trace_levelオペランドの詳細については，マニュアル「OpenTP1 システム定義」のロックサービス定義の説明を参照してください。

LCK性能検証用トレース情報ファイルの取得，編集出力には，prfgetコマンド，prfedコマンド，またはdcalzprfコマンドを使用します。取得方法，および編集出力方法を次に示します。

LCK性能検証用トレース情報ファイルの取得方法

最新のランIDで取得されていないトレース情報だけ取得する場合

$DCDIR/bin/prfget -f _lk | $DCDIR/bin/prfed -d

または

$DCDIR/bin/prfget -f _lk | $DCDIR/bin/dcalzprf

すべてのトレース情報を取得する場合

$DCDIR/bin/prfget -a -f _lk | $DCDIR/bin/prfed -d

または

$DCDIR/bin/prfget -a -f _lk | $DCDIR/bin/dcalzprf

LCK性能検証用トレース情報ファイルの編集出力方法

LCK性能検証用トレース情報ファイルからトレース情報を編集出力する場合，prfedコマンド，またはdcalzprfコマンドを実行してください。オプションは必要に応じて指定してください。

LCK性能検証用トレース情報の出力形式は，性能検証用トレースと同じです。出力形式の詳細については，マニュアル「OpenTP1 運用と操作」のprfedコマンド，またはdcalzprfコマンドを参照してください。

(8)　MCF性能検証用トレース

TP1/Message Controlを使用したメッセージ送受信での主なイベントで，MCF識別子などのトレース情報を取得しています。これをMCF性能検証用トレースといいます。

MCF性能検証用トレースには次の特長があります。

スレッドIDや論理端末名称，API名称など，MCF固有の詳細情報を出力できます。

出力した詳細情報をキーとしてMCF性能検証用トレースを分析することで，一連のメッセージ送受信処理やUAPの性能検証ができます。

MCF性能検証用トレースに関係するシステム定義は，次の表に示すとおりです。

表5‒9　MCF性能検証用トレースに関係するシステム定義

定義名

形式

オペランド

定義内容

ユーザサービス定義

set

mcf_prf_trace

ユーザサーバごとに，MCF性能検証用トレース情報を取得するかどうかを指定

MCF性能検証用トレース定義

set

prf_file_size

MCF性能検証用トレース情報のトレースファイルサイズ

set

prf_file_count

MCF性能検証用トレース情報のトレースファイル世代数

システムサービス情報定義

set

mcf_prf_trace

MCF通信サービスごとにMCF性能検証用トレース情報を取得するかどうかを指定

システムサービス共通情報定義

set

mcf_prf_trace_level

MCF性能検証用トレース情報の取得レベル

それぞれの定義の詳細については，マニュアル「OpenTP1 システム定義」を参照してください。

なお，MCF性能検証用トレースはprfgetコマンドによってバイナリ形式で取り出したあと，prfedコマンド，またはdcalzprfコマンドによってキャラクタ形式で出力できます。

注意事項

メッセージ送受信時（イベントID：0xa000，0xa001）にMCF性能検証用トレースを取得できるのは，次のどれかのプロトコル製品を使用した通信だけです。

・TP1/NET/TCP/IP

・TP1/NET/XMAP3

・TP1/NET/OSAS-NIF

メッセージ送受信（イベントID：0xa000，0xa001）以外のイベントについては，通信プロトコル種別に関係なく，MCF性能検証用トレースを取得できます。

(9)　XARイベントトレース

XAリソースサービスを使用したアプリケーションサーバからのトランザクション要求種別を，イベントトレース情報として取得します。この機能をXARイベントトレースといい，取得した情報をXARイベントトレース情報といいます。

アプリケーションサーバからのトランザクション要求種別，要求コードおよび要求コードの意味を次の表に示します。

表5‒10　トランザクション要求種別と要求コードの一覧

要求種別※

要求コード

要求コードの意味

Start()

xar_start

トランザクションブランチの開始処理

Call()

xar_call

トランザクションブランチ内からのRPCの実行

End()

xar_end

トランザクションブランチの終了処理

Prepare()

xar_prepare

トランザクションブランチのコミット準備処理（2相コミットの1相目）

Commit()

xar_commit

トランザクションブランチのコミット処理（2相コミットの2相目）

Rollback()

xar_rollback

トランザクションブランチのロールバック処理

Recover()

xar_recover

Prepared状態，Heuristically Completed状態のトランザクションブランチを通知

Forget()

xar_forget

Heuristically Completed状態のトランザクションブランチを破棄

注※

トランザクション要求種別は，OpenTP1の内部関数です。

XARイベントトレース情報は，$DCDIR/spool/dcxarinf/trace/ディレクトリの下に，ファイル名"xarevtr1"および"xarevtr2"で取得されます。これらのファイルを，XARイベントトレース情報ファイルといいます。XARイベントトレース情報ファイルの出力先およびファイル名は，変更できません。

XAリソースサービス開始時に，XARイベントトレース情報ファイルがすでに存在する場合は，バックアップファイルが作成され，新規に出力ファイルが作成されます。例えば，xarevtr1というXARイベントトレース情報ファイルが存在した場合，XAリソースサービス開始時に，xarevtr1をxarevtr1.bk1というファイルにリネームします。xarevtr1という名前のファイルは，リネームされて存在しなくなるため，新規にxarevtr1というXARイベントトレース情報ファイルが作成されます。

バックアップファイルは3世代まで保存されます。バックアップファイルが作成されるのは，XAリソースサービス開始時に，XARイベントトレース情報ファイルがすでに存在する場合だけです。オンライン中に，1ファイルへの書き込みレコード数が，XARイベントトレース情報ファイルの最大出力レコード数（XAリソースサービス定義のxar_eventtrace_recordオペランドで指定）を超えた場合には，バックアップファイルは作成されません。オンライン中に，1ファイルへの書き込みレコード数が，XARイベントトレース情報ファイルの最大出力レコード数を超えると，出力先ファイルを切り替え，XARイベントトレース情報ファイルを順次上書きしていきます。オンライン中はXARイベントトレース情報ファイルを削除しないでください。

XARイベントトレース情報の出力レベルは，XAリソースサービス定義のxar_eventtrace_levelオペランドで指定できます。デフォルトは，エラーが発生した場合だけXARイベントトレースを取得する出力レベルに指定されています。すべてのXARイベントトレース情報を取得することもできますが，その場合オンライン性能に影響を与えるため，デバッグ時以外は，デフォルトの出力レベルで運用することをお勧めします。

出力ファイルに取得されたXARイベントトレース情報は，xarevtrコマンドによって編集，表示できます。

XARイベントトレース情報の出力レベルおよび出力レコード数の指定方法についてはマニュアル「OpenTP1 システム定義」を，編集・表示方法についてはマニュアル「OpenTP1 運用と操作」を参照してください。

(10)　TRNイベントトレース

トランザクションブランチで発行されるXA関数や，トランザクションサービス（トランザクション管理サービス，トランザクション回復サービス，リソースマネジャ監視サービス）の各種イベントのトレース情報を取得しています。これをTRNイベントトレースといいます。

TRNイベントトレースは，$DCDIR/spool/dctrninf/trace/prf/ディレクトリの下に，"_tr_001"，"_tr_002"，"_tr_003"…というファイル名で取得されます。これらのファイルを，TRNイベントトレース情報ファイルといいます。TRNイベントトレース情報ファイルの出力先およびファイル名は，変更できません。

TRNイベントトレース情報ファイルは，取得サイズおよび取得ファイル数を変更できます。詳細については，マニュアル「OpenTP1 システム定義」のTRNイベントトレース定義を参照してください。

TRNイベントトレースを取得するには，次の手順で定義を設定します。

システム共通定義のprf_traceオペランドにYを指定します。

トランザクションサービス定義のtrn_prf_event_trace_levelオペランドでTRNイベントトレースの取得レベルを指定します。

トランザクションサービス定義のtrn_prf_event_trace_conditionオペランドで，TRNイベントトレースの取得種別を指定します。

次の表にtrn_prf_event_trace_conditionオペランドの指定値とTRNイベントトレースの取得情報の関係を示します。

表5‒11　trn_prf_event_trace_conditionオペランドの指定値とTRNイベントトレースの取得情報の関係

trn_prf_event_trace_conditionオペランドの指定値

TRNイベントトレースの取得情報

イベントID

トレースデータ長（単位：バイト）

取得タイミング

xafunc

XA関数に関するトレース

0x4500

320（xa_open関数，xa_close関数の場合は192）

トランザクション処理中※

trnservice

トランザクションサービスの動作状況に関するトレース

0x4501

192

トランザクションサービスの起動，停止または回復処理時

注※

2相コミットのトランザクションの場合，1トランザクションブランチ当たりに取得するトレース量は「12×リソースマネジャ数」となります。ただし，トレース量は，ユーザサーバにリンケージされているXAインタフェースオブジェクトファイルや，トランザクションの最適化などの条件によって異なります。

このオペランドの詳細については，マニュアル「OpenTP1 システム定義」のシステムサービス定義を参照してください。

TRNイベントトレース情報ファイルの取得，編集出力には，prfget，prfed，またはdcalzprfコマンドを使用します。取得方法，および編集出力方法を次に示します。

TRNイベントトレース情報ファイルの取得方法

最新のランIDで取得されていないトレース情報だけ取得する場合

$DCDIR/bin/prfget -f _tr | $DCDIR/bin/prfed -d

または

$DCDIR/bin/prfget -f _tr | $DCDIR/bin/dcalzprf

すべてのトレース情報を取得する場合

$DCDIR/bin/prfget -a -f _tr | $DCDIR/bin/prfed -d

または

$DCDIR/bin/prfget -a -f _tr | $DCDIR/bin/dcalzprf

TRNイベントトレース情報ファイルの編集出力方法

TRNイベントトレース情報を出力する場合，prfedコマンドに-dオプションを指定してください。dcalzprfコマンドには-dオプションの指定は必要ありません。そのほかのオプションは，必要に応じて指定してください。

TRNイベントトレース情報の出力形式は，性能検証用トレースと同じです。出力形式の詳細については，マニュアル「OpenTP1 運用と操作」のprfedコマンドを参照してください。

trn_prf_event_trace_conditionオペランドにxafuncを指定した場合のprfedコマンドのTRNイベントトレース情報の出力例を次に示します。

PRF: Rec Node: trn1 Run-ID: 0x4046b806 Process: 26264      Trace: 10
Event: 0x4500 Time: 2004/01/01 12:34:56 678.123.000 Server-name: Sup
Rc:   0      Client: **** - ********** Server: **** Root: trn1 - ********
Svc-Grp: *************************** Svc: ****************************
Trn: 78d0trn100000001trn1trn100000001
    xa_commit                       (IN)  OpenTP1_TAM
    axid:010000000000000c00000010
         3738643074726e330000000174726e3374726e330000000100000000
  Internal code1:0x2007       Internal code2:   0
  Internal code3:0

(11)　NAMイベントトレース

ネームサービスで実行される通信処理，キャッシュへのサービス情報の登録，削除などの各種イベントのトレース情報を取得しています。これをNAMイベントトレースといいます。

NAMイベントトレースは，$DCDIR/spool/dcnaminf/ディレクトリの下に，"_nm_001"，"_nm_002"，"_nm_003"…というファイル名で取得されます。これらのファイルを，NAMイベントトレース情報ファイルといいます。NAMイベントトレース情報ファイルの出力先およびファイル名は，変更できません。

NAMイベントトレースを取得するには，次の手順で定義を設定します。

システム共通定義のprf_traceオペランドにYを指定します。

システム共通定義のnam_prf_trace_levelオペランドでNAMイベントトレースの取得レベルを指定します。

次の表にnam_prf_trace_levelオペランドの指定値と取得するトレース情報の関係を示します。各イベントの取得タイミングについては，マニュアル「OpenTP1 運用と操作」の性能検証用トレース情報の取得の説明を参照してください。

表5‒12　nam_prf_trace_levelオペランドの指定値と取得するトレース情報の関係

nam_prf_trace_levelオペランドの指定値

トレース情報のイベントID

0xf000〜0xf035

0xf100〜0xf114

0xf200〜0xf220

00000000

×

×

×

00000001

×

○

×

00000002

○

×

×

00000003

○

○

×

00000004

×

×

○

00000005

×

○

○

00000006

○

×

○

00000007

○

○

○

その他

○

○

×

（凡例）

○：トレース情報を取得します。

×：トレース情報を取得しません。

NAMイベントトレース情報ファイルの取得，編集出力には，prfget，prfedコマンド，またはdcalzprfコマンドを使用します。取得方法を次に示します。

NAMイベントトレース情報ファイルの取得方法

$DCDIR/bin/prfget -a -f _nm | $DCDIR/bin/prfed -d

または

$DCDIR/bin/prfget -a -f _nm | $DCDIR/bin/dcalzprf

(12)　プロセスサービスのイベントトレース

プロセスの生成，消滅，起動，完了などのプロセスイベント情報を取得します。これをプロセスサービスのイベントトレースといいます。

プロセスサービスのイベントトレースは，$DCDIR/spool/dcprcinf/ディレクトリの下に，"_pr_001"，"_pr_002"，"_pr_003"…というファイル名で取得されます。これらのファイルを，プロセスサービスイベントトレース情報ファイルといいます。プロセスサービスイベントトレース情報ファイルの出力先およびファイル名は，変更できません。

プロセスサービスのイベントトレースを取得するには，プロセスサービス定義のprc_prf_traceオペランドにYを指定します。

各イベントの取得タイミングについては，マニュアル「OpenTP1 運用と操作」の性能検証用トレース情報の取得の説明を参照してください。

プロセスサービスイベントトレース情報ファイルの取得，編集出力には，prfget，prfed，またはdcalzprfコマンドを使用します。取得方法を次に示します。

プロセスサービスイベントトレース情報ファイルの取得方法

$DCDIR/bin/prfget -a -f _pr | $DCDIR/bin/prfed -d

または

$DCDIR/bin/prfget -a -f _pr | $DCDIR/bin/dcalzprf

(13)　FILイベントトレース

OpenTP1制御下のプロセスから内部的に発行されるOpenTP1ファイルへのアクセス要求に対して，処理完了までに，システム共通定義のfil_prf_trace_delay_timeオペランドの指定値以上の処理時間が掛かった場合，イベント情報を取得します。これをFILイベントトレースといいます。

FILイベントトレースを分析することで，OpenTP1ファイルアクセスに関する処理の遅延状況を確認できます。

FILイベントトレースは，$DCDIR/spool/dcfilinf/ディレクトリの下に，"_fl_001"，"_fl_002"，"_fl_003"というファイル名で取得されます。これらのファイルをFILイベントトレース情報ファイルといいます。FILイベントトレース情報ファイルの出力先およびファイル名は，変更できません。

FILイベントトレース情報ファイルの取得，編集出力には，prfgetコマンド，prfedコマンド，またはdcalzprfコマンドを使用します。取得方法を次に示します。

FILイベントトレース情報ファイルの取得方法

$DCDIR/bin/prfget -a -f _fl | $DCDIR/bin/prfed -d

または

$DCDIR/bin/prfget -a -f _fl | $DCDIR/bin/dcalzprf

(14)　コマンドログ

OpenTP1の運用コマンドを実行した場合に，コマンド実行時刻や終了時刻などの情報を$DCDIR/spool/cmdlogのcmdlog1，およびcmdlog2に出力します。

cmdlog1，およびcmdlog2は，viエディタなどで参照できます。コマンドログにはコマンドの開始，終了時刻が出力されるので，コマンドの実行に必要な時間（レスポンスタイム）の測定などができます。

6　複数のOpenTP1を使用する場合の機能

この章では，OpenTP1を大規模システムに適用するための機能（系切り替え機能，マルチノード機能），マルチOpenTP1，およびマルチホームドホスト形態を使うときの対応について説明します。

6.1　系切り替え機能

OpenTP1システムの稼働率を上げるため，OpenTP1システムを二重化できます。

OpenTP1を二重化するためには，HAモニタまたはHitachi HA Toolkit Extensionが必要です。HAモニタについては，マニュアル「高信頼化システム監視機能 HAモニタ」を，Hitachi HA Toolkit Extensionについては，マニュアル「Hitachi HA Toolkit」を参照してください。

以降，「HAモニタ」にはHitachi HA Toolkit Extensionを含みます。

6.1.1　系切り替え機能の概要

OpenTP1（TP1/Server Base），CPU，およびカーネルなどから構成されるサーバシステム（系）を二つ準備して，一つの系に障害が発生したときに，準備しておいた系に業務処理を速やかに切り替える機能を系切り替え機能といいます。この切り替えには，オペレータの操作を必要としません。

系切り替え後には，障害が発生した系のOpenTP1を再開始させて，次の切り替えに備えることができます。

オンライン中に業務処理をしている系を実行系，待機している系を待機系といいます。オンライン中は，系切り替えが発生するたびに，実行系と待機系が入れ替わります。

OpenTP1でメッセージ制御機能（MCF）またはメッセージキューイング機能（TP1/Message Queue）を組み込んでいるOpenTP1システムでも，系切り替え構成にできます。

(1)　系切り替えの種類

系切り替えには，次の2種類があります。※

自動系切り替え

実行系に障害が発生した場合に，自動的に待機系に処理を切り替えます。

計画系切り替え

実行系でHAモニタのコマンドを実行して，意図的に待機系に切り替えます。

注※

系切り替え機能には，上記以外に連動系切り替えという形態があります。連動系切り替えとは，系にある複数の製品をグループ化して，一括して切り替えるようにした系切り替えです。連動系切り替えを使うと，グループ化した製品を常に同じ実行系で稼働させることができます。連動系切り替えでは，系が切り替わるタイミングが自動系切り替えおよび計画系切り替えの場合と異なる場合があります。連動系切り替えを使った場合の系切り替えについては，マニュアル「高信頼化システム監視機能 HAモニタ」を参照してください。

(2)　系を識別する指定

HAモニタの環境設定では，二つの系を区別するため，オンライン開始時にどちらの系を最初に実行系とするかを決めておきます。最初に業務を開始する系を現用系，現用系の障害に備えて待機する系を予備系といいます。現用系と予備系はオンライン開始時の属性を示す用語です。この定義は，系切り替えが起こっても変わりません。

系切り替えの機能の概要を次の図に示します。

図6‒1　系切り替え機能の概要

6.1.2　系切り替え機能を使うOpenTP1のシステム構成

系切り替え機能を使う場合，現用系と予備系のOpenTP1システム（TP1/Server Base）に必要なソフトウェアを次に示します。

HAモニタ，TP1/High Availability

系切り替え機能を使う場合に，必ず前提となる製品です。

TP1/NET/High Availability

系切り替え機能とメッセージ制御機能（MCF）を使う場合に前提となる製品です。

現用系と予備系で共通して使うハードウェアを次に示します。

共有ディスク装置

系切り替え後に，実行系のOpenTP1から待機系のOpenTP1へ情報を引き継ぐために使う，ディスク（キャラクタ型スペシャルファイル）です。OpenTP1ファイルなど，系と系の間で引き継ぐ必要がある情報を格納します。

共有できる装置はディスク装置などです。

LAN

OpenTP1のネームサービスで使うためのLANです。OpenTP1の通信で使います。

このLAN以外にも，複数の系を保守するためのLAN（保守用LAN）が必要です。保守用LANは，OpenTP1の通信には使いません。主に，待機系へのリモートアクセスに使います。

監視パス

互いの系の状態をやり取りするためのインタフェースです。HAモニタで使います。監視パスには監視リンクと監視専用LANがあります。現用系と予備系がそれぞれ一つずつのときは監視リンクを，現用系と予備系の合計が三つ以上のときは監視専用LANを使います。

系切り替え機能を使う場合の構成を次の図に示します。次の図に示す以外にも，互いの系を監視するためのハードウェアとソフトウェアが必要になります。必要となる資源については，マニュアル「高信頼化システム監視機能 HAモニタ」を参照してください。

図6‒2　系切り替え機能を使う場合の構成

6.1.3　系切り替えの手順

(1)　系切り替えをするための準備

(a)　共有ディスク装置の割り当て

OpenTP1ファイルシステムを作成するキャラクタ型スペシャルファイルを共有指定します。共有するファイルは，互いのOpenTP1システムから同じパス名で参照できるように設定します。

共有できるのは，キャラクタ型スペシャルファイルに作成したファイルだけです。通常ファイルの内容（例　$DCDIR/spool/ 下のファイル，$DCDIR/tmp/ 下のファイルなど）は引き継げません。

(b)　IPアドレスの設定

共有するIPアドレスを，システム共通定義のmy_hostオペランドに設定します。互いのOpenTP1システムには，同じIPアドレスを設定します。

(c)　HAモニタの環境設定

HAモニタの定義を設定します。HAモニタの環境設定については，マニュアル「高信頼化システム監視機能 HAモニタ」を参照してください。

(2)　HAモニタに定義する内容

HAモニタのサーバに関する定義（server定義文）で，OpenTP1の動作環境を指定します。server定義文のnameオペランドには，OpenTP1ホームディレクトリの完全パス名を指定します。そのほかの環境設定については，マニュアル「高信頼化システム監視機能 HAモニタ」を参照してください。

(3)　OpenTP1に定義する内容

現用系と予備系では，次の内容をすべて一致させてください。

OpenTP1のシステム定義

ユーザサーバ（UAP）の実行形式ファイル

トランザクションサービス制御用実行形式ファイル（trnlnkrmコマンドで再作成した場合）※

OpenTP1システムを構成する製品のバージョン

OpenTP1管理者の環境（ユーザID，グループID，環境変数）

OpenTP1ホームディレクトリの完全パス名

OpenTP1ファイル（キャラクタ型スペシャルファイル）の設定

注※

trnlnkrmコマンドを実行してOpenTP1に登録するリソースマネジャの登録順序も一致させる必要があります。

現用系と予備系の定義で一致していない項目があっても，チェックはしていません。一致させていない場合の動作は保証しません。

(a)　システム定義の指定

系切り替え機能を使用する場合は，次に示すシステム定義を指定してください。

システム構成定義には，系切り替え機能を使用する指定（ha_conf = Y）をしてください。指定しないと系切り替えはしません。

系切り替え時に，実行系の代替として待機系を起動する場合と，実行系の後処理だけ行わせるために待機系を起動する場合とで，システム環境定義のシステム開始方法（mode_confの指定）は次のとおり指定内容が異なります。

実行系の代替として待機系を起動する場合

AUTO，またはMANUAL1を指定してください。AUTOとMANUAL1では，OS起動後の開始方法が異なるので，運用形態を基に選択してください。

MANUAL2を指定すると，実行系／待機系のどちらかが異常終了したあとに，自動開始しません。再び系切り替えするためには，異常終了したOpenTP1を運用コマンドで開始させておく必要があります。

実行系の後処理だけ行わせるために待機系を起動する場合

未決着トランザクションの決着やDBの整合性の確保などの，実行系の後処理だけを行わせるために待機系を起動する場合は，MANUAL2を指定してください。この場合，待機系に縮退運転ができれば問題ないと判断できることが前提となります。系切り替え後に，待機系に実行系の後処理だけを行わせる方法については，「6.1.4(1)　OpenTP1の開始と終了」を参照してください。

系が切り替わったあとの待機系の再開始（リラン）時間を短縮するため，OpenTP1が起動する前に，ユーザサーバを起動することを指定できます。この場合，システム環境定義のuser_server_haオペランドにYを指定してください。

(4)　系切り替え機能を使用するときの注意

(a)　使用するLAN

系切り替え機能を使用する場合，OpenTP1を運用しているLAN，および回線は，実行系ではオンライン状態にして，待機系ではオフライン状態にしておく必要があります。また，実行系で障害を検知して系切り替えをした場合には，障害が起こった系のLAN，および回線は自動的にオフライン状態となります。したがって，系切り替えに使用するLANは，障害が起こって待機系になった系の保守や運用には使用できません。

障害が起こって待機系になった系の保守や運用には，コンソールを使用するか，系切り替えに使用しないLAN（保守用LAN）を別に準備してください。

(b)　使用するファイルシステム

系切り替え機能を使う場合は，OpenTP1ファイルシステムを使ってください。通常のUNIXファイルシステムを使った場合，OpenTP1を起動できない場合があります。

(c)　ミラーディスク機能を使用する場合

共有ディスク装置にミラーディスク機能を使用できるかどうかは，OSおよびハードウェアによって決まります。OSおよびハードウェアのミラーディスク機能，クラスタ機能などの仕様に基づいて使用してください。

ミラーディスク機能で二つのディスク装置に書き込んでいる最中に系切り替えが発生した場合，二つのディスク装置の間に書き込みの遅れなどによる状態の不一致が発生することがあります。系切り替え先のディスク装置に正しく書き込まれていないと，系切り替えをしてもOpenTP1は正しく動作できません。

次のOpenTP1ファイルは，OpenTP1を動作させるために重要なファイルです。

ステータスファイル

システムジャーナルファイル

チェックポイントダンプファイル

これらのOpenTP1ファイルをミラーディスク機能で使用する場合は，OSおよびハードウェアで，共有ディスク装置にミラーディスク機能を利用できること，また，系切り替え機能を使用した場合でもディスク装置の内容が正しいことを確認した上で使用してください。

ミラーディスク装置を使えないOpenTP1ファイルは，次に示す方法でファイルの信頼性を上げてください。

ステータスファイル

二重化してください。

システムジャーナルファイル

二重化してください。

チェックポイントダンプファイル

二重化するか，複数世代保証機能を使用してください。

(d)　OpenTP1のトレースファイルやログファイルの出力先

OpenTP1のトレースファイルやログファイルの出力先を，共有ディスク装置上に指定しないでください。系切り替え発生時にアクセス不可となり，情報が欠けたり，エラーメッセージが出力されたりすることがあります。

6.1.4　系切り替え機能を使う場合の運用方法

系切り替え機能を使う場合の運用方法について説明します。

(1)　OpenTP1の開始と終了

(a)　OpenTP1の開始

系切り替え機能を使用するOpenTP1は，両方の系をそれぞれOpenTP1の開始コマンド（dcstartコマンド）で開始します。自動起動モードの場合は，コマンドを実行しなくても開始します。

自動起動か手動起動かの決定

定義内容と，前回の終了形態の組み合わせで決まります。

実行系か待機系かの決定

HAモニタの環境設定（server定義文）で，現用系を指定（initialオペランドにonlineを指定，またはinitialオペランドを省略）した方が，オンライン開始時に実行系になります。予備系を指定（initialオペランドにstandbyを指定）した方が，オンライン開始時に待機系になります。

正常開始か再開始かの決定

系切り替え機能を使用しない場合と同様に決まります。

系切り替え後に，待機系に実行系の後処理だけを行わせる方法

系切り替え後に，待機系に実行系の後処理だけを行わせるには，dcstart -Uで待機系を開始します。

dcstart -Uで待機系を開始すると，系切り替えが発生したときにユーザサーバが起動されません。これによって，実行系で障害が発生したときに，実行系の未決着トランザクションの決着や，DBの整合性の確保などの後処理を行うだけのものとして，待機系を使用できます。つまり，待機系のマシンに実行系と同等のリソースを必要としなくて済みます。

待機系の開始にはdcstartコマンドを実行する必要があります。したがって，待機系を後処理用として使用する場合，手動起動の状態である必要があります。

次に，一つのノードを複数のOpenTP1の待機系にした場合で，系切り替え後に，待機系に実行系の後処理だけを行わせるときの運用について説明します。

なお，一つのノードを複数のOpenTP1の待機系にする場合は，それぞれの実行系に対応する待機系のOpenTP1をそれぞれセットアップする必要があります。

図6‒3　系切り替え後に待機系に実行系の後処理だけを行わせるときの運用

説明

実行系のOpenTP1 Dに，障害が起こる。

待機系のOpenTP1 D'が起動する。

OpenTP1 D'は未決着トランザクションの決着やDBの整合性の確保を行います。オンライン処理は，OpenTP1 A，OpenTP1 BおよびOpenTP1 Cが行うため，25%ダウンの縮退運転となります。

注

次の場合は，待機系は実行系の後処理だけ行うためには開始されません。

システム環境定義のシステム開始方法（mode_confの指定）にAUTOを指定した場合で，OpenTP1が異常終了したとき，または前回の終了モードが異常終了以外でOSが起動したとき。

システム環境定義のシステム開始方法（mode_confの指定）にMANUAL1を指定した場合でOpenTP1が異常終了したとき。

系切り替え後に，待機系に実行系の後処理だけを行わせる運用をしていたとしても，上記の指定内容と前回終了状態の条件を満たしていた場合，dcstartコマンドが自動的に実行され，OpenTP1が自動起動されます。これによって，待機系は実行系の代替用として待機状態になります。

待機系を再び後処理用のOpenTP1として待機させたいときには，いったんOpenTP1を停止したあと，再度dcstart -Uで開始してください。

(b)　OpenTP1の終了

系切り替え機能を使用しているOpenTP1システムの終了方法を以降の表に示します。

表6‒1　実行系のOpenTP1に対する終了コマンド

実行する終了コマンド

コマンドの実行結果

dcstopコマンドを実行

オプション指定なし

正常終了します。待機系のOpenTP1も終了します。

-n オプションを指定

強制正常終了します。待機系のOpenTP1も終了します。

-a オプションを指定

計画停止Aで終了します。待機系のOpenTP1も終了します。

-b オプションを指定

計画停止Bで終了します。待機系のOpenTP1も終了します。

-f オプションを指定

強制停止します。待機系のOpenTP1も終了します。

HAモニタの計画系切り替えコマンド（monswapコマンド）を実行

強制停止で終了します。実行系のOpenTP1が終了後，待機系のOpenTP1に系切り替えをします。

HAモニタの待機サーバの停止コマンド（monsbystpコマンド）を実行

実行できません。

表6‒2　待機系のOpenTP1に対する終了コマンド

実行する終了コマンド

コマンドの実行結果

dcstopコマンドを実行

オプション指定なし

実行できません。

-n オプションを指定

-a オプションを指定

-b オプションを指定

-f オプションを指定

強制停止します。

HAモニタの計画系切り替えコマンド（monswapコマンド）を実行

実行できません。

HAモニタの待機サーバの停止コマンド（monsbystpコマンド）を実行

待機系のOpenTP1は終了します。OpenTP1は再起動しません。

(2)　コマンド実行の制限

(a)　オフライン環境で実行するコマンドの注意

オフライン環境で実行するコマンドは，系切り替え形態を構成する両方のOpenTP1システムを停止してから実行します。

dcstartコマンドは，もう一方の系が停止しているかどうかに関係なく，その系のOpenTP1システムが停止していれば実行できます。ただし，待機系のOpenTP1では，dcstart -nコマンドを実行しても-nオプションは無視されます。

(b)　オンライン環境で実行するコマンドの注意

オンライン環境で実行するコマンドは，実行系のOpenTP1でだけ実行できます。待機系のOpenTP1には，オンライン環境で実行するコマンドは実行できません。ただし，OpenTP1の強制停止コマンド（dcstop -f）に限り，待機系のOpenTP1でも実行できます。また，実行系のアンロードの負担を軽くするため，待機系のシステムジャーナルファイルをアンロードすることもできます。ただし，アンロードするコマンド（jnlunlfgコマンド）の実行には各種の留意点があります。待機系のアンロードについては，マニュアル「OpenTP1 運用と操作」のjnlunlfgコマンドの説明を参照してください。

(c)　共有ディスク装置へのアクセス

待機系のOpenTP1に，共有ディスク装置上の共有ファイルを操作するコマンドを実行しても，ファイル書き込みはできません。そのため，共有ファイルは破壊されません。ただし，予備系を開始させないで現用系だけで運用している場合は，予備系のOpenTP1からファイル書き込みができるので，コマンドを実行するとファイルが破壊されることがあります。コマンドでOpenTP1ファイル（キャラクタ型スペシャルファイル）を操作するときは，共有する両方の系のOpenTP1を停止させてからにしてください。

6.1.5　強制停止処理中の系切り替え抑止機能

サーバモード※による系切り替え構成のシステムで，dcstop -f（-fd）コマンドで強制停止した場合，終了処理が途中で異常終了することがあります。

この場合，タイミングによってHAモニタはOpenTP1の異常を検知し，系切り替えを実行してしまうことがあります。

系切り替え抑止機能を使用すると，OpenTP1システムの強制停止処理中に異常終了しても，系切り替えを抑止できます。

注※ サーバモードの詳細については，HAモニタおよびHitachi HA Toolkit Extensionのマニュアルを参照してください。

(1)　使用方法

この機能を使用するにはシステム共通定義のdc_deter_restart_on_stop_failオペランドに"Y"を指定してください。

このオペランドはOpenTP1システムの再開始時に変更できます。

(2)　注意事項

強制停止（dcstop -f（-fd）コマンド）実行後，実行系OpenTP1システムはHAモニタに対して，待機系OpenTP1への停止指示をしますが，停止指示前の処理で異常終了した場合は系切り替えが発生します。

6.2　マルチノード機能（TP1/Multi）

マルチノード機能とは，OpenTP1をクラスタ/並列システムに適用した場合に，OpenTP1の運用を支援して，効率良くシステムを管理するための機能です。

6.2.1　マルチノード機能の概要

クラスタ/並列システムとは，LANで接続した複数のサーバマシンを並行に処理させて，大規模システムを構築する形態です。このクラスタ/並列システム形態で，一つのノードからすべてのOpenTP1システムを運用できるようにする機能をマルチノード機能といいます。マルチノード機能を使うと，ノードごとにOpenTP1システムを管理する必要がなくなります。

マルチノード機能を使う場合には，すべてのOpenTP1システムにTP1/Multiが必要です。

マルチノード機能を使ったOpenTP1のソフトウェア構成を次の図に示します。

図6‒4　マルチノード機能を使ったOpenTP1のソフトウェア構成

(1)　マルチノード機能を使用する前提条件

マルチノード機能を使用する場合は，次のことが前提となります。

マルチノード機能で管理するOpenTP1のノードすべてに，TP1/Multiが組み込まれていること

マルチノード機能で管理するOpenTP1のノードすべてに，OpenTP1のノードのシステム共通定義にmulti_node_option=Yと指定してあり，かつマルチノード構成定義とマルチノード物理定義が作成してあること

(2)　マルチノード機能とOpenTP1の機能の関係

クラスタ/並列システム形態でOpenTP1を使用した場合の機能を，次に示します。

(a)　単一のOpenTP1の場合

通常のOpenTP1の機能で運用できます。UAPも，各OpenTP1のノードで設定した環境で起動します。複数のUAPプロセスを並行して起動すること（マルチサーバ機能）も，複数のノード間でユーザサーバのサービスグループ単位で処理を振り分けること（ノード間負荷バランス機能）もできます。

(b)　系切り替え機能を使用したOpenTP1の場合

系切り替え構成のOpenTP1の場合，系切り替えの組み合わせの単位を一つのノード（現用系と待機系が同じノード）と見なして処理します。系切り替えが起こっても，ノードが切り替わったことを意識しません。

系切り替え機能を使う場合は，保守用LAN（系切り替えとは関係ない，OpenTP1の通信に使わないLAN）が必要です。また，マルチノード物理定義のホスト名には，保守用LANのホスト名を指定してください。

メッセージキューイング機能（TP1/Message Queue）を使ったOpenTP1システムでも，マルチノード機能を使えます。

(3)　クラスタ/並列システムを構成する要素

クラスタ/並列システムのOpenTP1では，各ノードを管理するため，複数システムで構成される領域を，次のように管理しています。

クラスタ/並列システムにOpenTP1を使用した形態を次の図に示します。

図6‒5　クラスタ/並列システムにOpenTP1を使用した形態

(a)　マルチノードエリア

クラスタ/並列システムを構成しているOpenTP1のまとまりを，マルチノードエリアといいます。クラスタ/並列システム内で一元的に管理したい範囲のOpenTP1ノードを，すべてマルチノードエリアとします。

一つのクラスタ/並列システム内には，マルチノードエリアは一つだけです。

(b)　マルチノードサブエリア

マルチノードエリアを論理的に分割したまとまりをマルチノードサブエリアといいます。マルチノードエリアに属するOpenTP1のノードを，共通する業務ごとにサブエリアに分割します。マルチノードサブエリアとして分割する例を次に示します。

業務サブエリア

ユーザファイル（DAMファイル，TAMファイルなど）を管理するOpenTP1ノードのまとまりです。

広域網との通信サブエリア

TP1/Message Controlを使用して広域網と通信するOpenTP1ノードのまとまりです。

ジャーナル運用サブエリア

アーカイブジャーナルファイルを取得するOpenTP1ノードのまとまりです。グローバルアーカイブジャーナル機能を使う場合に必要です。

グローバルアーカイブジャーナル機能については，「6.2.3　グローバルアーカイブジャーナル機能」を参照してください。

(c)　OpenTP1ノード

マルチノードエリア，またはマルチノードサブエリアを構成する個々のOpenTP1システムをOpenTP1ノードといいます。それぞれのOpenTP1ノードは，OpenTP1のシステム共通定義で指定したノード識別子で区別されます。

(d)　システム定義の指定

マルチノード構成定義で，それぞれのエリアに属するOpenTP1ノードを指定します。OpenTP1ノードのノード識別子として指定する値は，システム共通定義に指定したノード識別子です。

6.2.2　マルチノード機能でできる操作

クラスタ/並列システム形態にマルチノード機能を使うと，次のような操作ができます。コマンドについてはマニュアル「OpenTP1 運用と操作」を，関数についてはマニュアル「OpenTP1 プログラム作成の手引」を参照してください。

(1)　クラスタ/並列システム内にあるOpenTP1の開始と終了を管理

一つのOpenTP1ノードから，コマンドを入力して，複数のOpenTP1システムをマルチノードサブエリア単位に開始させたり終了させたりできます。マルチノードサブエリアを開始させる場合はdcmstartコマンドを，終了させる場合はdcmstopコマンドを実行します。

(2)　OpenTP1ノードの状態を取得

一つのOpenTP1ノードから，マルチノードエリアにあるOpenTP1ノードの状態を知ることができます。OpenTP1ノードの状態を知りたい場合は，dcndlsコマンドを実行します。

OpenTP1ノードの状態はUAPから関数（dc_adm_get_nd_status_××××関数）を使って知ることもできます。

(3)　OpenTP1ノードにあるユーザサーバの状態を取得

一つのOpenTP1ノードから，OpenTP1ノードにあるユーザサーバの状態を知ることができます。OpenTP1ノードの状態を知りたい場合は，UAPから関数（dc_adm_get_sv_status_××××関数）を呼び出します。

(4)　マルチノードエリアの構成情報の取得

一つのOpenTP1ノードから，マルチノードエリアを構成するすべてのOpenTP1ノードのノード識別子，または指定したマルチノードサブエリアに属するOpenTP1ノードのノード識別子を知ることができます。OpenTP1ノードのノード識別子を知りたい場合は，UAPから関数（dc_adm_get_nodeconf_××××関数，dc_adm_get_node_id関数）を呼び出します。

6.2.3　グローバルアーカイブジャーナル機能

クラスタ/並列システム形態でOpenTP1を使う場合でも，システムジャーナルファイルをOpenTP1ノードごとにアンロードする必要があります。この負担を軽減するために，マルチノード機能のオプションとして，専用のOpenTP1ノードに各OpenTP1ノードのシステムジャーナルをアーカイブできます。この機能をグローバルアーカイブジャーナル機能といいます。グローバルアーカイブジャーナル機能でアーカイブしたジャーナルをアンロードすると，ノードごとにジャーナルをアンロードする必要がなくなるため，OpenTP1ノードの運用の負担を軽減できます。

グローバルアーカイブジャーナルでは，アーカイブするジャーナルの種類を選択できます。選択するジャーナルの種類は，システムジャーナル定義のjnl_arc_rec_kindオペランドに選択するジャーナルレコード種別を指定します。ジャーナルの種類については，「4.2.2　システムジャーナルファイル」を参照してください。

グローバルアーカイブジャーナル機能でアーカイブしたジャーナルファイルをアーカイブジャーナルファイルといいます。アーカイブジャーナルファイルについては，「4.2.6　アーカイブジャーナルファイル」を参照してください。

グローバルアーカイブジャーナル機能を使用した場合でも，各OpenTP1ノードの回復時はシステムジャーナルファイルを使用します。そのため，回復の性能に影響はありません。

ファイルの運用方法や障害時の対策については，マニュアル「OpenTP1 運用と操作」を参照してください。

(1)　グローバルアーカイブジャーナル機能を使用するノードの種類

マルチノードエリアの任意のOpenTP1ノードを，アーカイブジャーナルファイル専用のノードとします。このノードをアーカイブジャーナルノードといいます。このノードのアーカイブジャーナルファイルへ，各OpenTP1ノードからシステムジャーナルファイルをアーカイブします。アーカイブジャーナルノードへシステムジャーナルファイルをアーカイブするOpenTP1ノードを被アーカイブジャーナルノードといいます。

アーカイブジャーナルノードと，ほかのOpenTP1ノード（被アーカイブジャーナルノード，またはグローバルアーカイブジャーナル機能を使用しないノード）と異なる点を次に示します。

ユーザサーバを起動できません。

マルチノードエリアのOpenTP1ノードをノードごとに開始する場合，最初に起動します。

グローバルアーカイブジャーナルサービスの概要を次の図に示します。

図6‒6　グローバルアーカイブジャーナルサービスの概要

(2)　リソースグループ

アーカイブジャーナルノードには，1から16種類までのアーカイブジャーナルファイルを作成できます。それぞれのファイルは使用目的で分けられるので，マルチノードのあるエリアをAアーカイブジャーナルとして取得，あるエリアをBアーカイブジャーナルとして取得，などの運用ができます。

使う目的別に分けたアーカイブジャーナルファイルのまとまりをリソースグループといいます。グローバルアーカイブジャーナルサービスは，リソースグループ名を使ってアーカイブジャーナルファイルを管理します。

一つのリソースグループに属せる被アーカイブジャーナルノードは，20ノードまでです。

リソースグループは，アーカイブジャーナルサービス定義のファイル名を示します。アーカイブジャーナルノードでリソースグループを幾つ使用するかは，グローバルアーカイブジャーナルサービス定義で指定します。

(3)　グローバルアーカイブジャーナル機能を使用するOpenTP1ノードに指定する内容

グローバルアーカイブジャーナル機能を使用するノードには，次に示すシステム定義を指定しておきます。このことで，グローバルアーカイブジャーナルサービスと各ノードのジャーナルサービスを関連づけられます。

アーカイブジャーナルノードに指定する定義

グローバルアーカイブジャーナルサービス定義とアーカイブジャーナルサービス定義を作成しておきます。

被アーカイブジャーナルノードに指定する定義

システムジャーナルサービス定義のjnl_arc_nameオペランドに，アーカイブジャーナルノードのノード識別子と，アーカイブジャーナルファイルのリソースグループ名を指定しておきます。

システムジャーナルファイルをアーカイブしないOpenTP1ノードでは，個別にジャーナルをアンロードしてください。

グローバルアーカイブジャーナルサービスとリソースグループの関係を次の図に示します。

図6‒7　グローバルアーカイブジャーナルサービスとリソースグループの関係

(4)　アーカイブジャーナルファイルのアンロード

アンロード待ちのファイルグループは，OpenTP1のコマンドで，通常ファイルに複写（アンロード）する必要があります。アーカイブジャーナルファイルをアンロードしたファイルを，グローバルアーカイブアンロードジャーナルファイルといいます。

すべてのファイルグループがアンロードされていない状態でスワップ先がなくなった場合，グローバルアーカイブジャーナルサービスは異常終了します。

(a)　グローバルアーカイブアンロードジャーナルファイルのジャーナル維持機能

アンロードした通常ファイルは，システムジャーナルファイルの場合と同様に，DAMファイルの回復や稼働統計情報ファイルの編集ができます。また，ユーザジャーナルをオフラインのプログラムへ引き継げます。

グローバルアーカイブアンロードジャーナルファイルには，複数のOpenTP1ノードのシステムジャーナル情報が入っています。このジャーナルをマージした稼働統計情報の編集，および複数のOpenTP1ノードのジャーナルを時系列にソートするなど，各種のジャーナル編集ができます。

(5)　システムジャーナルファイルの状態

被アーカイブジャーナルノードのOpenTP1ノードでは，次に示すシステムジャーナルファイルの状態が追加となります。

アーカイブ済み/未アーカイブ

アーカイブジャーナルファイルに転送，または出力されたファイルグループかどうかの状態

該当する被アーカイブジャーナルノードでアンロードが済んでいなくても，アーカイブ済みで上書きできる状態のファイルグループであれば，次回のスワップ先にできるファイルグループとなります。

6.3　マルチOpenTP1

一つのノードに二つのOpenTP1システムを置く形態をマルチOpenTP1といいます。一つのノードで実際の業務用とテスト用の二つのOpenTP1を稼働したりするときに使います。

個々のOpenTP1は，独立して運用できます。マルチOpenTP1の場合，ノードアドレスを複数のOpenTP1で共有することも，それぞれ異なるアドレスを使うこともできます。

6.3.1　マルチOpenTP1の形態

マルチOpenTP1では，複数のTP1/Server Baseをそれぞれ異なるOpenTP1ホームディレクトリにインストールします。

OpenTP1管理者は，それぞれのOpenTP1に必要です。この場合，OpenTP1管理者を同じ利用者としても，異なる利用者としてもかまいません。

マルチOpenTP1の形態の場合，それぞれのOpenTP1はOpenTP1識別子で区別されます。さらに，ネームサービスとプロセスサービスのポート番号は，OpenTP1ごとに異なる番号を指定してください。OpenTP1識別子とポート番号は，システム共通定義で指定します。マルチOpenTP1の環境設定については，マニュアル「OpenTP1 運用と操作」を参照してください。

マルチOpenTP1を次の図に示します。

図6‒8　マルチOpenTP1

(1)　マルチOpenTP1のコマンドを振り分けるサンプル

マルチOpenTP1のノードにrshなどを使ってほかのノードからコマンドを実行する場合，どちらのOpenTP1でコマンドが実行されるかわかりません。そのため，ノード名を指定してコマンドを実行する必要があります。ノード名を指定してコマンドを実行するコマンド（シェルファイル）として，TP1/Server Baseのサンプルにdelvcmdコマンドが組み込んであります。

delvcmdコマンドの使い方については，マニュアル「OpenTP1 プログラム作成の手引」にあるOpenTP1のサンプルの説明を参照してください。

6.4　マルチホームドホストの形態での注意事項

二つ以上の物理ネットワークに接続しているTCP/IPを使っているホストを，マルチホームドホストといいます。このようなホストで稼働するOpenTP1と通信するときは，そのホストにつながっている任意のLANのアドレス（IPアドレス）を基にして通信します。通常の通信では，OpenTP1でIPアドレス（ホスト名）を意識する必要はありません。

ただし，一つのホストでOpenTP1を複数稼働させていて，そのうち一つを系切り替え機能で使っている場合，系の切り替えが起こることで，該当するホストのOpenTP1と通信できない場合があります。このようなことが起こらないように，どのIPアドレス（ホスト名）がどのOpenTP1に対応しているかを定義する必要があります。

6.4.1　系切り替えをするマルチホームドホスト形態に必要な定義

一つのホストにある複数のOpenTP1のうち，どちらかを系切り替え形態で使う場合は，システム共通定義のmy_hostオペランドにホスト名を指定した上で，dcbindht定義コマンドに次に示す項目を指定します。

使うホスト名（/etc/hostsファイル，またはDNSなどでIPアドレスとマッピングできるホスト名）

使うネットワーク名（/etc/networksファイル，またはNISなどでネットワーク番号とマッピングできるネットワーク名）

6.4.2　OpenTP1とIPアドレス（ホスト名）を対応づける必要がある形態の例

OpenTP1とIPアドレス（ホスト名）を対応づける必要がある形態とは，系切り替えでIPアドレスを引き継ぐ方法です。

この方法は，RPCでサービスのアドレス情報を取得したあとで系切り替えが起こった場合でも，そのアドレスをそのまま使用してサービスが使えます。

一つのホストで複数のOpenTP1が稼働することがある系切り替え構成を使うときは，dcbindht定義コマンドで，常に同じアドレスを使うことを定義してください。

(1)　1：1の系切り替え構成の場合の例

OpenTP1とIPアドレス（ホスト名）を対応づける必要がある形態例（1：1の系切り替え構成の場合）を次の図に示します。

図6‒9　OpenTP1とIPアドレス（ホスト名）を対応づける必要がある形態例（系切り替え構成が一つの場合）

RPCでサービスを要求されたOpenTP1は，サービスのアドレス情報を取得するために使ったIPアドレスを保持します。

上の図に示す構成で，OpenTP1-BからOpenTP1-Aへサービスを要求するときには，IPアドレス「a」または「x」のどちらかを使います。

IPアドレスxを使ってサービスのアドレス情報を取得したあとで系切り替えが起こった場合，IPアドレスxはOpenTP1-X2に引き継がれます。このとき，OpenTP1-BからOpenTP1-Aへのサービス要求では，アドレス情報を取得したときのIPアドレスxを使って通信しようとします。IPアドレスxは，系切り替えによってホスト3に移っているため，OpenTP1-Bは目的のOpenTP1-Aと通信できなくなってしまいます。

このようなことを防ぐため，システム共通定義のdcbindht定義コマンドで，OpenTP1-Aは常にIPアドレスaを使うことを定義しておきます。

同様に，OpenTP1-Xと通信するOpenTP1-YがIPアドレスaを使わないように，dcbindht定義コマンドで，OpenTP1-Xは常にIPアドレスxを使うように定義しておきます。

(2)　相互系切り替え構成の場合の例

OpenTP1とIPアドレス（ホスト名）を対応づける必要がある形態例（相互系切り替え構成の場合）を次の図に示します。

図6‒10　OpenTP1とIPアドレス（ホスト名）を対応づける必要がある形態例（相互系切り替え構成の場合）

上の図に示す構成では，ホスト1とホスト3にあるOpenTP1は，相互に実行系と待機系を配置しています。

この場合，OpenTP1-Aには，系切り替えによって通信できたりできなかったりするip=bのIPアドレスに影響されないように，dcbindht定義コマンドの-hオプションにip=aのIPアドレスを指定しておきます。同様に，OpenTP1-Xにも，dcbindht定義コマンドの-hオプションにip=xのIPアドレスを指定しておきます。

7　OpenTP1で使用するシステムの資源

OpenTP1を使用したオンライントランザクション処理システムを設計したり，運用管理したりするためには，システムのプロセス構造，およびメモリ構造を知っておく必要があります。

この章では，OpenTP1で使用するシステムの資源について説明します。

7.1　OpenTP1のプロセス構造

システムサービスプロセスを次の表に示します。

表7‒1　システムサービスプロセス

実行形式ファイル名

稼働数

サービス

関連するシステム定義

親プロセス

プロセスダウン後の動作※1

server_countの見積もりに加算する値

prcd

1※2

プロセスサービス（スーパユーザプロセス）

プロセスサービス定義

initまたはsystemd

#3

1

dcmond

1

OpenTP1監視サービス

システム共通定義

prcd

#1

0

prctee

1※3

プロセスサービス（OpenTP1の標準出力，標準エラー出力のリダイレクト機能）

なし

initまたはsystemd

#1

0

namd

1

ネームサービス

ネームサービス定義

prcd

#3

1

namaudtd

0または1※4

ネームサービス（監視機能）

ネームサービス定義

prcd

#3

0または1※4

scdd

1

スケジュールサービス

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

prcd

#3

1

scdmltd

≧0〜n※5

スケジュールサービス（マルチスケジューラ機能）

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

prcd

#1

≧0※6

trnd

1

トランザクションサービス（トランザクション管理）

トランザクションサービス定義

prcd

#3

1

trnrvd

1〜128※7

トランザクションサービス（トランザクション回復<並行回復プロセス数>）

トランザクションサービス定義

prcd

#1

1

trnrmd

1

トランザクションサービス（リソースマネジャ監視）

トランザクションサービス定義

prcd

#3

1

jnld

1

ジャーナルサービス（ジャーナル管理）

ジャーナルサービス定義

prcd

#3

1

jnlswd

0または1※8

ジャーナルサービス（ジャーナルファイル管理）

システムジャーナルサービス定義

prcd

#3

0または1※8

jnliod

0〜16※8，※9

ジャーナルサービス（ジャーナルファイル入出力）

なし

prcd

#3

0〜16※8，※9

1〜256※10

ジャーナルサービス（アーカイブジャーナルファイル入出力）※11

なし

prcd

#3

1〜256※10

jnlutld

0または1※12

ジャーナルユティリティサービス

システムジャーナルサービス定義

prcd

#3

0または1※12

jnlsdd

1

グローバルアーカイブジャーナルサービス※13

システムサービス構成定義

prcd

#3

1

jard

1

グローバルアーカイブジャーナルサービス（グローバルジャーナル管理）※11

グローバルアーカイブジャーナルサービス定義

prcd

#3

1

jarswd

1〜16

グローバルアーカイブジャーナルサービス（アーカイブジャーナルファイル管理）※11

アーカイブジャーナルサービス定義

prcd

#3

1

jarrvd

1〜320※14

グローバルアーカイブジャーナルサービス（ジャーナルデータアーカイブ）※11

なし

prcd

#3

1〜320※14

itvd

1

インタバルサービス

インタバルサービス定義

prcd

#3

1

stsd

1

ステータスサービス

ステータスサービス定義

prcd

#3

1

cpdd

≧0※8，※15

チェックポイントダンプサービス

ジャーナルサービス定義

チェックポイントダンプサービス定義

prcd

#3

≧0※8，※15

tjld

0または1※8

トランザクションジャーナルサービス

なし

prcd

#3

0または1※8

qued

0または1※16

メッセージキューサービス

メッセージキューサービス定義

prcd

#3

0または1※16

damd

0または1※17

DAMサービス

DAMサービス定義

prcd

#3

0または1※17

tamd

0または1※18

TAMサービス

TAMサービス定義

prcd

#3

0または1※18

tamiod

0または1※18

TAMサービス（TAMファイル入出力）

TAMサービス定義

prcd

#3

0または1※18

istd

0または1※19

ISTサービス

ISTサービス定義

prcd

#3

0または1※19

logd

1

ログサービス

ログサービス定義

prcd

#3

1

prfiop※20

0，8，または9※21

性能検証用トレース取得サービス

システム共通定義

dcstart→initまたはsystemd※22

#2

0

cltcond

0または1※23

クライアントサービス（CUP実行プロセス）

クライアントサービス定義

prcd

#1

0または1※23

cltd

0または1※24

クライアントサービス

クライアントサービス定義

prcd

#3

0または1※24

clttrnd

0または1※25

クライアントサービス（トランザクショナルRPC実行プロセス）

クライアントサービス定義

prcd

#1

0または1※25

xatd

0または1※26

XATMIサービス

なし

prcd

#3

0または1※26

xatcd

0または1※26

XATMI通信サービス

XATMI通信サービス定義

prcd

#3

0または1※26

rmmd

0または1※27

リソースマネジャモニタサービス

RMMサービス定義

prcd

#3

0または1※27

admrsvre

0または1

プロセスサービス（部分回復）

プロセスサービス定義

prcd

#3

0

mcfmngrd

0または1※28

MCFサービス（MCFマネジャ）

MCFマネジャ定義

prcd

#1

0または1※28

mapsmgrd

0または1※28，※29

マッピングサービス

マッピングサービス定義

マッピングサービス属性定義

prcd

#3

0または1※28，※29

mcfcmdsv

0または1※28，※30

MCFサービス（MCFオンラインコマンド）

なし

prcd

#3

0または1※28，※30

ユーザ指定※30

0〜239※28，※32

MCFサービス（MCF通信）

MCF通信構成定義

MCFアプリケーション定義

prcd

#3

0から239※28，※32

mqad

0または1※33

MQAサービス（MQAサーバ）

MQAサービス定義

prcd

#3

0または1※33

mqaiod

0または1以上※33，※34

MQAサービス（MQA入出力サーバ）

MQAサービス定義

prcd

#3

0または1以上※33，※34

mqcdtcp

0または1※33，※35

MQAサービス（MQCリスナサーバ）

MQAサービス定義

MQCサービス定義

prcd

#3

0または1※33，※35

mqacmd

0または1※33

MQAサービス（MQAコマンドサーバ）

MQAサービス定義

prcd

#3

0または1※33

mqamnd

0または1※33

MQAサービス（MQA監視サーバ）

MQAサービス定義

prcd

#3

0または1※33

mqtdtcp

0または1以上※33，※36

MQAサービス（MQTサーバ）

MQT通信構成定義

MQTサービス定義

prcd

#3

0または1以上※33，※36

mqtmngd

0または1※33

MQAサービス（MQTマネジャサーバ）

MQAサービス定義

prcd

#3

0または1※33

mqcgwp

0または1以上※33，※37

MQAサービス（MQCゲートウェイサーバ）

MQCゲートウェイサーバユーザサービス定義

prcd

#3

0または1以上※33，※37

mqrsup

0または1※33，※38

MQAサービス（リポジトリ管理サーバ（mqrsup））

リポジトリ管理サーバユーザサービス定義「$DCCONFPATH/mqrsup」

prcd

#1

0または1※33，※38

mqrspp

0または1※33，※38

MQAサービス（リポジトリ管理サーバ（mqrspp））

リポジトリ管理サーバユーザサービス定義「$DCCONFPATH/mqrspp」

prcd

#1

0または1※33，※38

rapclman

0または1※39

リモートAPIサービス（rapクライアントマネジャ）

rapクライアントマネジャサービス定義

prcd

#3

0または1※39

raplisnr

0〜1024※40

リモートAPIサービス（rapリスナー）

rapリスナーサービス定義

prcd

#1

0〜1024※40

rapservr

0〜1024※40

リモートAPIサービス（rapサーバ）

rapリスナーサービス定義

prcd

#1

0〜1024※40

rtsspp

0または1※41

リアルタイム統計情報サービス

リアルタイム取得項目定義

prcd

#1

0または1※41

rtssup

0または1※42

リアルタイム統計情報サービス

リアルタイム取得項目定義

prcd

#1

0または1※42

utod

0または1※43

テスタサービス

テスタサービス定義

prcd

#3

0または1※43

注

「稼働数」は，一つのノード内でOpenTP1が一つ稼働する場合の，一つのノード当たりのシステムサービスプロセス数です。

注※1

#1：プロセスは自動で再起動します。操作は不要です。ただし，クリティカルセクション内でダウンした場合はOpenTP1システムがシステムダウンします。

#2：プロセスは再起動しないでOpenTP1システムは縮退運転します。なお，手動でプロセスの再起動はできません。

#3：プロセスは再起動しないでOpenTP1システムがシステムダウンします。OpenTP1システムを再起動してください。

注※2

通常，稼働時のプロセス数は一つですが，このプロセスはOpenTP1プロセスの起動処理を行っているため，主に次に示すようなタイミングで一時的に複数のプロセスが存在しているように見えることがあります。

・dcstartコマンドによるOpenTP1開始時

・dcsvstartコマンドによるユーザサーバ起動時

・非常駐サーバのプロセス起動時

注※3

標準出力，標準エラー出力のリダイレクト用のプロセスです。このプロセスは，dcsetupコマンド，prcdの延長で作成されますが，このプロセスで取得した情報は，OpenTP1のコマンド（prclsコマンド）では表示できません。内容を表示する場合は，OSのコマンド（psコマンドなど）を実行してください。

注※4

次のどちらかの場合，稼働数が1になります。

・ネームサービス定義のname_audit_confオペランドに1または2を指定している

・システム共通定義のname_service_modeオペランドにmanagerまたはagentを指定している

注※5

n：スケジュールサービス定義のscdmulti定義コマンドの-mオプション指定値の総数です。

注※6

マルチスケジューラ機能使用時のマルチスケジューラグループ数です。

注※7

トランザクションサービス定義のtrn_recovery_process_countオペランド指定値です。

注※8

システム共通定義のjnl_fileless_optionオペランドにYを指定している場合，稼働数が0になります。

注※9

この値は，次に示す計算式で算出されます。

a×b

a：ジャーナルを二重化しているときは2，二重化していないときは1。

b：システムジャーナルファイルの並列アクセス機能での最大分散数（システムジャーナルサービス定義のjnl_max_file_dispersionオペランド指定値）。

注※10

この値は，次に示す計算式で算出されます。

a×b×c

a：ジャーナルを二重化しているときは2，二重化していないときは1。

b：アーカイブジャーナルファイルの並列アクセス機能での最大分散数（アーカイブジャーナルサービス定義のjnl_max_file_dispersionオペランド指定値）。

c：グローバルアーカイブジャーナルサービス定義で指定したリソース数（jnldfsv -aに指定するリソースグループ名の数）。

注※11

グローバルアーカイブジャーナルサービスがあるノードで稼働するプロセスです。

注※12

システムジャーナルサービス定義のjnl_auto_unloadオペランドにYを指定している場合，1になります。

注※13

被アーカイブジャーナルノードで稼働するプロセスです。

注※14

アーカイブジャーナルノードに転送中の被アーカイブジャーナルノードの数と同じです。

注※15

ジャーナルサービス定義のjnldfsv -cで指定するチェックポイントダンプサービス定義数です。

注※16

システムサービス構成定義のque_confオペランドにYを指定している場合，1になります。

注※17

システムサービス構成定義のdam_confオペランドにYを指定している場合，1になります。

注※18

システムサービス構成定義のtam_confオペランドにYを指定している場合，1になります。

注※19

システムサービス構成定義のist_confオペランドにYを指定している場合，1になります。

注※20

トレース取得用のプロセスです。このプロセスは，prcdの延長で作成されますが，このプロセスは，OpenTP1のコマンド（prclsコマンド）では表示できません。状態を表示する場合は，OSのコマンド（psコマンドなど）を実行してください。

注※21

システムの稼働数は，次のとおりです。

・システム共通定義のprf_traceオペランドにNを指定した場合

　稼働数は0になります。

・システム共通定義のprf_traceオペランドにYを指定した場合

　MCFを使用しないとき，稼働数は8になります。

　MCFを使用するとき，稼働数は9になります。

なお，これらの稼働数はプロセスサービス定義のprc_process_countオペランドに加算する必要はありません。

注※22

親プロセスは，dcstartプロセス終了後，initまたはsystemdに遷移します。

注※23

クライアントサービス定義のclt_cup_confオペランドにYを指定した場合，1になります。

注※24

システムサービス構成定義のclt_confオペランドにYを指定している場合，1になります。

注※25

クライアントサービス定義のclt_trn_confオペランドを省略，またはYを指定している場合，1になります。

注※26

システムサービス構成定義のxat_confオペランドにYを指定した場合，1になります。

注※27

システムサービス構成定義のrmm_confオペランドにYを指定した場合，1になります。

注※28

MCFを使用しない（システムサービス構成定義にdcsvstart -m システムサービス名の記載がない）場合，0になります。

注※29

MCFマネジャ定義のmcfmcomn -m mapsvnameに指定がある場合，1になります。

注※30

MCFマネジャ定義のmcfmcomn -o cmdsvnameに指定がある場合，1になります。

注※31

TP1/Messagingを使用した場合，"mcfutcpd"および"mcfupsvd"で固定となります。

注※32

MCFマネジャ定義のmcfmcname -s mcfsvnameの指定数です。

注※33

MQを使用しない（システムサービス構成定義のmqa_confオペランドを省略，またはNを指定している）場合，0になります。

注※34

MQAサービス定義のmqa_ioproc_numオペランド（mqaiod）の指定値については，定義内で指定しているキューファイル数に依存します（ただし，二重化定義のバックアップのキューファイル数は除外となります）。

・mqa_ioproc_numの指定値≦キューファイル数の場合：サーバ数＝mqa_ioproc_numの指定値

・mqa_ioproc_numの指定値＞キューファイル数の場合：サーバ数＝キューファイル数

注※35

・MQAサービス定義でmqa_mqc_confオペランドを省略，またはNを指定している場合，0になります。

・MQAサービス定義でmqa_mqc_confオペランドにYを指定している場合，1になります。

注※36

この値は，次に示す計算式で算出されます。

a＋b＋c

a：MQAサービス定義のmqamqtnam定義コマンドで，プロトコル名称にmqttcpと指定している定義数

b：

　・MQTサーバでUOCを使用していない場合，0になります。

　・MQTサーバでUOCを使用している場合，次の指定の合計値です。

　　・MQAサービス定義のmqamqtnam定義コマンドで，プロトコル名称がmqtuで始まるシステムサービス定義名と指定している定義数

　　・MQAサービス定義のmqamqtnam定義コマンドで，プロトコル名称がmqttcpcsuで始まるシステムサービス定義名と指定している定義数

　　・MQAサービス定義のmqamqtnam定義コマンドで，プロトコル名称がmqttcpcruで始まるシステムサービス定義名と指定している定義数

c：

　・MQAサービス定義でmqa_mqr_confオペランドを省略，またはNを指定している場合，0になります。

　・MQAサービス定義でmqa_mqr_confオペランドにYを指定している場合，MQA サービス定義のmqamqtnam定義コマンドで，プロトコル名称がmqttcpcrおよびmqttcpcsと指定している定義数です。

注※37

・MQAサービス定義でmqa_mqc_confオペランドを省略，またはNを指定している場合，0になります。

・MQAサービス定義でmqa_mqc_confオペランドにYを指定している場合，MQCサービス定義（$DCCONFPATH/mqc）の中のmqcgwpnam定義コマンドの指定数になります。

注※38

・MQAサービス定義でmqa_mqr_confオペランドを省略，またはNを指定している場合，0になります。

・MQAサービス定義でmqa_mqr_confオペランドにYを指定している場合，1になります。

注※39

リモートAPIクライアントマネジャ機能を使用する場合，1になります。

注※40

リモートAPI機能未使用時は0になります。

リモートAPI機能使用時に起動するrapリスナーサービス定義数です。

注※41

リアルタイム統計情報サービスを起動する場合，1になります。

注※42

リアルタイム統計情報サービスの拡張機能を起動する場合，1になります。

注※43

システムサービス構成定義のuto_confオペランドにYを指定している場合，1になります。

7.2　OpenTP1のメモリ構造

OpenTP1で使うメモリには，ローカルメモリと共用メモリがあります。

7.2.1　ローカルメモリ

ローカルメモリとは，一つのプロセスだけからアクセスできる仮想記憶領域です。この領域には，OpenTP1のプロセス固有情報やバッファが取られます。大部分はUAPがRPCでサービス要求したとき動的に確保されますが，一部はライブラリオブジェクトのデータセクションに含まれます。

7.2.2　共用メモリ

共用メモリとは，複数のプロセスで共有して参照・更新するメモリです。主に，OpenTP1の制御テーブルと共用バッファが取られます。OpenTP1の共用メモリは，OSの共用メモリ機能を利用していて，プロセス間通信のオーバヘッドを削減するために使われます。

(1)　OpenTP1が使う共用メモリ

OpenTP1が使う共用メモリの量は，システム環境定義のstatic_shmpool_sizeオペランドに静的共用メモリの総量を，dynamic_shmpool_sizeオペランドに動的共用メモリの総量を指定します。OpenTP1はこの二つを合わせた量の共用メモリを使います。通常は，OpenTP1の稼働中に常に使うデータは静的共用メモリに，サービス処理の実行時にオンデマンドで占有するデータを動的共用メモリに設定します。

共用メモリのバッファ領域をユーザサーバ間で共用する指定をすると，共用メモリの量を節約できます。バッファテーブルの共用については，「3.4.4　バッファ領域の共用による共用メモリの節約」を参照してください。

(2)　DAMサービス，TAMサービス，ISTサービスで使用する共用メモリ

動的共用メモリの一部は，DAMファイルの更新に使用します。動的共用メモリを効率良く利用するため，同時に起動するDAMファイルを更新するトランザクションブランチの数を，DAMサービス定義で指定します。トランザクションブランチの数を指定することで，DAMファイル更新用の動的共用メモリを，OpenTP1の開始時に確保します。定義した数を超えるトランザクションブランチが同時に，DAMファイルを更新しようとした場合には，トランザクション実行時に新たな動的共用メモリを一時的に確保します。一時的に確保した動的共用メモリは，トランザクション終了後に解放します。

DAMサービスを使う場合，システム環境定義で指定した共用メモリとは別に，DAMブロックを退避するためのバッファ領域用に共用メモリを確保します。DAMサービス用の共用メモリ領域は，DAMサービス定義で指定します。

TAMサービスを使用する場合，システム環境定義で指定した共用メモリとは別に，TAMテーブル用に共用メモリを確保します。TAMサービス用の共用メモリ領域は，TAMサービス定義で指定します。

ISTサービスを使う場合，システム環境定義で指定した共用メモリとは別に，ISTテーブル用の共用メモリを確保します。ISTテーブルに使う共用メモリ領域は，ISTサービス定義で指定します。

(3)　MCFサービスで使用する共用メモリ

MCFサービスは，静的共用メモリおよび動的共用メモリを使用します。

静的共用メモリについては，次に示す二つの指定を両方とも行ってください。

MCFマネジャ共通定義の-pオプションに静的共用メモリの使用量を指定してください。

システム環境定義のstatic_shmpool_sizeオペランドに，次の値を含めて指定してください。

MCFマネジャ共通定義のコマンドの-pオプションの指定値
＋すべてのMCF通信サービスのMCFトレースバッファサイズ※
＋すべてのアプリケーション起動サービスのMCFトレースバッファサイズ※

注※

MCFトレースバッファサイズの計算式を次に示します。

mcfttrc定義コマンドの-tオプションのsizeオペランドの指定値×2

MCF静的共用メモリが不足した場合，静的共用メモリ（システム環境定義のstatic_shmpool_sizeオペランドの指定値）の未使用領域から，MCFマネジャ共通定義（mcfmcomn）の-pオプションで指定したサイズの1/2のサイズ分を自動的に追加確保します。メモリの自動確保は最大254回まで行います。それでもメモリが不足した場合は，ログメッセージとしてKFCA10230-Eを出力し，障害情報を出力します。ただし，メモリの自動確保回数が254回以内であっても，メモリの自動確保時に静的共用メモリ不足を検出した場合は，ログメッセージとしてKFCA10240-Eを出力して，障害情報を出力します。

メモリ追加確保時に，ログメッセージとしてKFCA10242-Iを出力するかどうかは，MCFマネジャ共通定義（mcfmcomn）の-iオプションで指定します。静的共用メモリ不足の発生を検知したい場合は，-iオプションにmsgを指定し，メッセージを出力するように指定してください。

(4)　リアルタイム統計情報サービスで使用する共用メモリ

リアルタイム統計情報サービスは，システム環境定義に定義した共用メモリのほかに，取得した統計情報を格納するためのRTSサービス用の共用メモリを使用します。

RTSサービス用の共用メモリのサイズは，リアルタイム統計情報サービス定義のrts_service_maxオペランド，およびrts_item_maxオペランドの指定値によって決定されます。

(5)　OpenTP1監視サービスで使用する共用メモリ

OpenTP1監視サービスは，OpenTP1監視機能用の共用メモリを使用します。

OpenTP1監視機能用の共用メモリの所要量は固定です。詳細については，マニュアル「OpenTP1 システム定義」の共用メモリの見積もり式を参照してください。

7.3　OpenTP1が使用するTCP/IP資源

OpenTP1のRPC（dc_rpc_call関数，dc_rpc_call_to関数，およびTCP/IPを使用するXATMIインタフェースなど）を使用して大規模なシステムを構築する場合，TCP/IPのポート数の不足や通信エラーが発生することがあります。

使用ポート数の制限方法やネットワーク環境のチューニング方法などについて説明します。

7.3.1　OpenTP1で使用しているポート番号

TCP/IPでプロセス間通信をする場合，プロセス間でコネクションを確立してからデータを送受信します。ここでは，OpenTP1で使用しているポート番号について説明します。

(1)　送信用ポート番号

送信用ポート番号は，OSの自動割り当てポート（短命ポート）の範囲でOSに割り当てられて決定します。送信用ポート番号は固定できません。

(2)　受信用ポート番号

受信用ポート番号は，OSの自動割り当てポート（短命ポート）の範囲でOSに割り当てられて決定しますが，OpenTP1の一部のシステムサービスでは，受信用ポート番号を指定することができます。

OpenTP1で使用している受信用ポート番号について次に示します。

OSが自動割り当てする範囲の受信用ポート番号

この値はOSで決まっています。値の確認方法や変更方法については，使用しているOSのマニュアルを参照してください。

システム共通定義でrpc_port_baseオペランドを指定している場合は，OSが自動割り当てする受信用ポート番号の範囲内で，「rpc_port_baseオペランドの指定値」から「rpc_port_baseオペランドの指定値＋プロセスサービス定義のprc_process_countオペランドの指定値＋128」までの範囲の番号を優先的に使用します。ただし，これらの範囲から任意に選択された受信用ポート番号が使用中だった場合，このオペランドの指定は無視されます。

OpenTP1が制御するウェルノウンポート化されていないプロセスの受信用ポート番号は，OSが任意に割り当てた番号になります。

個別に指定する受信用ポート番号

例えば，次に示すオペランドの指定値です。

システム共通定義のname_portオペランドおよびprc_portオペランド

スケジュールサービス定義のscd_portオペランド

rapリスナーサービス定義のrap_listen_portオペランド

システム共通定義の「rpc_port_baseオペランドの指定値」から「rpc_port_baseオペランドの指定値＋プロセスサービス定義のprc_process_countオペランドの指定値＋128」までの受信用ポート番号

受信用ポート番号を指定できるシステム定義のオペランドを，次の表に示します。

表7‒2　受信用ポート番号を指定できるシステム定義のオペランド

使用する機能

定義名

オペランド名／

定義コマンド名

指定できる範囲

デフォルト値

対象システムサービス

−

システム共通定義

name_port

5001〜65535

10000

ネームサービス

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

scd_port

自動割り当てポートの範囲

スケジュールサービス

マルチスケジューラ機能

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

scdmulti定義コマンドの-pオプション

5001〜65535

自動割り当てポートの範囲

マルチスケジューラ

クライアント拡張機能

クライアントサービス定義

clt_port

5001〜65535

自動割り当てポートの範囲

クライアント拡張サービス

clttrn_port

トランザクショナルRPC実行プロセス

cltcon_port

トランザクショナルRPC実行プロセス

リモートAPI機能

rapリスナーサービス定義

rap_listen_port

5001〜65535

自動割り当てポートの範囲

rapリスナーサービス

rapクライアントマネジャサービス定義

rap_client_manager_port

rapクライアントマネジャサービス

マルチノード連携制御機能（TP1/Multi）

システム共通定義

prc_port

5001〜49999

自動割り当てポートの範囲

マルチノード連携制御機能のサービス

−

システム共通定義

rpc_port_base

5001〜65535

自動割り当てポートの範囲

OpenTP1制御下のウェルノウンポート化されていないシステムサーバ，ユーザサーバ（prfiop，運用コマンドは除く）。

（凡例）

−：該当しません。

各オペランドの詳細については，マニュアル「OpenTP1 システム定義」を参照してください。

7.3.2　RPCによるポートの使用方法

RPCによるポートの使用方法について次の図に示します。

図7‒1　RPCによるポートの使用方法

OpenTP1の各プロセス（システムプロセスおよびユーザプロセス）は，プロセス初期化処理で受信用ポートを一つ確保します。

RPCの発行時，クライアントUAPプロセスで送信用ポートを確保し，スケジューラデーモンの受信用ポートとコネクションを確立し，RPCを送信します。すでにコネクションが確立されている場合は，それを使用します。送信用ポートには，あて先プロセス（各ノードのスケジューラデーモン）ごとに異なる番号が割り当てられます。

OSのメッセージキューの機能で，サーバUAPに連絡します。

RPCへの応答時に，サーバUAPプロセスは送信用ポートを確保し，クライアントUAPの受信用ポートとコネクションを確立し，応答を送信します。すでにコネクションが確立されている場合はそれを使用します。送信用ポートはあて先プロセス（クライアントUAPプロセス）ごとに異なる番号が割り当てられます。

その後のコミット処理での送信では，すでにクライアントUAPとサーバUAPとの間にすでにコネクションが確立されているため，それを使用します。

7.3.3　ポート数の計算式

OpenTP1で使用するポート数の計算式について次の表に示します。

表7‒3　OpenTP1で使用するポート数の計算式

種類

計算式

TCP/IP通信受付

（受信用ポート）

OpenTP1システムプロセス数＋ユーザプロセス数

システムプロセス間通信用

（送信用ポート）

他ノードと通信するシステムプロセス数※1×他ノード数

RPC送信用

（送信用ポート）

 m　　 n
 ΣAi＋ΣBj
i=1　 j=1

m：他ノードにRPCを実行するUAPプロセス数

n：他ノードにRPCを実行するrapサーバ数

A：該当するUAP iからRPCする他ノード数

B：該当するrapサーバ jからRPCする他ノード数

RPC応答用

（送信用ポート）

 n
 ΣAi×2※3
i=1

n：RPCを受け付けるUAPプロセス数

A：該当するUAP iにRPC要求を行ったクライアントプロセス数※2

注※1

次に示すプロセスの総数です。

namd

namaudtd（ノード監視機能を使用する場合）

scdd

scdmltd×（スケジュールサービス定義のscdmulti定義コマンドの-mオプション指定値の総数）（マルチスケジューラ機能を使用する場合）

istd（TP1/Shared Table Accessを使用する場合）

trnrmd

trnrvd×（トランザクションサービス定義のtrn_recovery_process_countオペランドの指定値）

注※2

応答送信先がTP1/EEの場合は，TP1/EEのクライアントプロセス（EEプロセス）数です。

注※3

RPCを受け付けたUAPプロセスがダウンした場合，admrsvreプロセスが代理でエラー応答を送信するため，admrsvreプロセスの応答送信用ポートとして計上します。

7.3.4　ポート数の制限方法

OpenTP1を使用して大規模なシステムを構築する場合，TCP/IPが管理するポートが不足する可能性があります。このような場合に，OpenTP1で使用するポートを制限する方法について説明します。

OpenTP1は，コネクション確立時のオーバヘッドを削減するために，確立したコネクションを切断しないで保持し，同じプロセス間通信に再利用します。保持するコネクション数が上限になった場合，コネクションを確立したプロセス間の合意によって，コネクションを切断します。これを一時クローズ処理といいます。

ユーザは，システム共通定義，ユーザサービス定義，およびユーザサービスデフォルト定義で次に示すオペランドを指定できます。

set ipc_sockctl_highwater = a,b
set ipc_sockctl_watchtime = ソケット再利用可能監視時間

a：ソケットの一時クローズ処理開始数パーセンテージ

b：ソケットの一時クローズ処理非対象数パーセンテージ

ソケットの一時クローズ処理開始数パーセンテージの指定

OpenTP1は，プロセス内のソケット用に使用しているファイル記述子の数が，次の値を超えた時点で，一時クローズ処理を開始します。

max_socket_descriptorsオペランドの指定値
×（ipc_sockctl_highwaterオペランドの指定値a／100）

ソケットの一時クローズ処理非対象数パーセンテージの指定

一時クローズ処理の対象外とするコネクション数のパーセンテージを指定できます。一時クローズ処理の対象外となるコネクション数は，次の値です。

max_socket_descriptorsオペランドの指定値
×（ipc_sockctl_highwaterオペランドの指定値b／100）

ソケット再利用可能監視時間の指定

ipc_sockctl_watchtimeオペランドには，プロセス内のソケット用に使用しているファイル記述子の数が，max_socket_descriptorsオペランドの指定値になった時点から，一時クローズ処理によってソケットが再利用できるようになるまでの監視時間（秒）を指定します。

同じプロセスとの間の通信が多く発生しない運用や，通信する相手プロセスが非常に多いシステムでは，保持しているコネクション数がある程度増えてきたところで，一時クローズ処理によって，適度にコネクションを解放して，1プロセスで使用するソケット数を調整し，再利用できます。

また，OpenTP1のプロセスから送信する場合は，コネクションを確立するときに送信用ポートを確保しますが，送信用ポートの個数は，一つのコンピュータで上限があるため，システム全体の合計が上限を超えないように，UAPプロセスが保持するコネクション数を調整する必要があります。

これらのオペランドの指定値が適切でないと，1プロセス内で使用できるソケット数が上限に達してしまい，一時クローズ処理によるソケットの再利用が新たなコネクション確立要求に追いつかなかったり，システム全体で使用するポート数がTCP/IPの上限を超えてしまい，プロセスが異常終了することがあります。

7.3.5　一時クローズ処理とユーザ業務との関係

一時クローズ処理要求の送信は，1コネクションに対して1回だけです。

一時クローズ処理要求の送信と応答の受信は，非同期に処理されるため，一時クローズ処理要求に対する応答がない状態が続いても，新しいRPCを受け付けたり，RPCに対する応答を送信することができるので，一時クローズ処理がユーザ業務に影響を与えることはありません。

7.3.6　一時クローズ処理要求の監視

一時クローズ処理要求監視機能を使用すると，一時クローズ処理要求が到着したかどうかを定期的に検査できます。この機能によって，OpenTP1のSPPやMHPがサービス要求受信待ち状態でも，一時クローズ処理要求を受信できます。

一時クローズ処理では，コネクションを確立したプロセス間で，一時クローズ処理要求の送信，および一時クローズ処理要求の受信／応答の送信のやり取りがあって初めてコネクションを切断します。

つまり，コネクションの一方のプロセスで使用中のソケット数が最大数※に達して，一時クローズ処理要求を送信したとしても，もう一方のプロセスがこれを受信して応答を送信するまでは，コネクションを切断できません。OpenTP1のSPPやMHPは，サービス要求の受信を待つ際にmsgrcvシステムコールを使用しています。そのため，いったんmsgrcvシステムコールで待ち状態に入ってしまうと，相手プロセスから一時クローズ処理要求が送信されたとしても，これを受信できず，コネクションを切断できません。

一時クローズ処理要求監視機能は，使用中のソケット数が最大数に達したプロセスが一時クローズ処理要求を送信した場合，相手プロセスがmsgrcvシステムコールでサービス要求受信待ちの状態でも，相手プロセスが一時クローズ処理要求の受信／応答の送信をできるようにするものです。ソケット用ファイル記述子の最大数は，max_socket_descriptorsオペランドで設定します。

ユーザは，ユーザサービス定義，およびユーザサービスデフォルト定義で次に示すオペランドを指定できます。

set polling_control_data = ソケットの再利用指示（一時クローズ処理要求）の到着を検査するかどうか
set thread_yield_interval = ソケットの再利用指示（一時クローズ処理要求）を受信する契機を与えるインタバル時間

7.3.7　一時クローズ処理の実行状態の確認

一時クローズ処理の実行状態の情報を取得すると，一時クローズ処理が，ソケットを適度に再利用しながら実行されているかどうかを確認できます。この情報を基に，システムの規模，環境に合わせて，max_socket_descriptorsオペランド，および，ipc_sockctl_highwaterオペランドに最適な値を指定することで，オーバヘッドを削減できます。

一時クローズ処理の実行状態の情報を取得するには，rpcstatコマンドを使用します。このコマンドを実行すると，データ送受信処理を実行したあとに，一時クローズ処理の実行状態の情報を取得できます。一時クローズ処理の実行状態の情報は，データ送受信処理が実行されるごとには取得できません。データ送信，またはデータ受信処理が10回実行された場合，1回の割合で取得できます。

rpcstatコマンドで取得できる情報を次の表に示します。

表7‒4　一時クローズ処理の実行状態の確認コマンドで取得できる情報

取得項目

説明

max_socket_descriptorsオペランドの設定値

ソケット用ファイル記述子の最大数。

ipc_sockctl_highwater=a,bのaの値

ソケットの一時クローズ処理開始数パーセンテージ。

ipc_sockctl_highwater=a,bのbの値

ソケットの一時クローズ処理非対象数パーセンテージ。

プロセス間通信で使用中のソケット数

プロセス間通信で使用している，受け付け用，接続中，および接続済み状態のソケットの総数。

一時クローズ処理要求中のソケット数

該当プロセスが使用しているソケット数が一時クローズ処理開始数パーセンテージに達し，コネクションを確立しているプロセスとの一時クローズ処理の合意を待っている状態のソケットの総数。

一時クローズ処理済みのソケット数

該当プロセス，または，コネクション確立プロセスが使用しているソケット数が一時クローズ処理開始数パーセンテージに達し，コネクションを確立しているプロセスとの合意によって一時クローズが完了したソケットの総数。

一時クローズ処理送信拒否のソケット数

コネクションを確立しているプロセスと一時クローズ処理の合意が行えないソケットの総数。

受信用ポート番号

該当プロセスが使用している受信用ポート番号。

7.3.8　ノード間通信時の毎回コネクション断機能

ノード間通信時の毎回コネクション断機能は，ノードをわたったOpenTP1プロセス間のTCP/IP通信の場合に限り，通信処理を終了した時点で毎回コネクションを切断するものです。

OpenTP1は，次の処理でノード間のTCP/IP通信をします。

dc_rpc_call関数の通信

dc_rpc_call_to関数の通信

UAPとシステムサーバ間の通信

OpenTP1のシステムサーバ間の通信

ノード間通信時の毎回コネクション断機能は，ユーザサービス定義，ユーザサービスデフォルト定義，またはシステム共通定義のrpc_close_after_sendオペランドに指定できます。

なお，次に示す機能では，ノード間のTCP/IP通信であっても，ノード間通信時の毎回コネクション断機能は適用されません。

OpenTP1クライアント製品とTP1/Server Base間の通信

リモートAPI機能を使用し，rapクライアントからTP1/Server Baseのrapリスナー，rapサーバへの通信

XAリソースサービスを使用したトランザクション連携機能

TP1/Message Queueのチャネルを使用した，他のMQシステム（メッセージキューイング機能のキューマネジャがあるシステム）とTP1/Message Queueとのチャネル通信

TP1/Message Queueのクライアント製品（TP1/Message Queue Access）であるMQCクライアント機能とTP1/Message QueueのMQCサーバ機能との通信

メッセージ制御機能（TP1/Message Control）を使用した，相手システムとの通信

(1)　機能概要

ノードAのOpenTP1のUAPから，dc_rpc_callによってノードBのOpenTP1の提供するサービスを実行したあと，次の状態になった場合，ノードAのUAPはノードBのSPPやスケジューラデーモンとの間のコネクションが切断されたことを検知できません。

ノードBのOpenTP1がハード障害によってダウンした

ノードAとノードB間に無通信監視をする通信機器によってコネクションが切断された

それは，ノードBのOSがコネクションの切断を通知できないからです。この状態でノードAのUAPがノードBのサービスを要求した場合，dc_rpc_callの送信処理は正常に完了しますが，実際に電文は送出されません。その結果，ノードAのUAPはタイムアウトによって異常を検知します。

このようにOSがコネクションの切断を通知できないような障害を即時に検知するには，電文の送受信が終了するたびにコネクションを切断し，毎回新たにコネクションを確立する操作を実行する必要があります。

ノード間通信時の毎回コネクション断機能は，通信が終了した時点で毎回コネクションを切断する機能であり，コネクションを切断するのはノードをわたったプロセス間の通信の場合だけです。

ノード間通信時の毎回コネクション断機能は，他ノード上のプロセスと通信するたびにコネクションの確立／解放処理を実行するため，このオーバヘッドによって性能が低下することが考えられます。また，ノードをわたったプロセス間通信を行うたびに，コネクションを確立するため，OSの資源であるポートを消費します。一度使用したポートは，OSによって一定時間経過後に，再利用できます。ただし，再利用できるまでの時間はOSの設定に依存します。ポートの再利用間隔時間を長く設定していると，ポート不足が発生し，OpenTP1だけでなく，他製品にも影響が出ます。ポートに関する設定などを十分に検討し，この機能を使用してください。ポートに関するOSの設定の詳細は，OSのマニュアルを参照してください。

(2)　一時クローズ処理とノード間通信時の毎回コネクション断機能との比較

一時クローズ処理は，保持するコネクション数が設定（ipc_sockctl_highwater定義オペランド）の上限になった場合，コネクションを確立したプロセス間の合意によって，コネクションを切断します。一時クローズ処理は，自ノード内通信およびノード間通信で，すべてのコネクションに対して有効です。

OpenTP1制御下のプロセスにipc_sockctl_highwater=0,0を設定すると，ノード間通信時の毎回コネクション断機能と同様に，通信ごとにコネクションを切断できます。しかし，ユーザ処理中やOpenTP1のライブラリ関数実行中でも電文受信処理を実施していない場合は，一時クローズ処理が実行できません。これは，一時クローズ要求電文が受信できないため，プロセス間の合意が取れないからです。

OpenTP1プロセスAにipc_sockctl_highwater=0,0を設定した場合の処理概要を次の図に示します。

図7‒2　一時クローズ処理概要

プロセスAからOpenTP1プロセスBへコネクション確立要求。

プロセスBでコネクション確立要求受付。

プロセスAからプロセスBに対して，電文送信。

プロセスBにおいて，電文受信。

プロセスAにおいて，ipc_sockctl_highwater定義オペランドの条件を満たしたため，プロセスBに対して，一時クローズ要求を送信。

プロセスBにおいて，一時クローズ要求を受信。※1

プロセスBから一時クローズ要求の応答送信。

プロセスAにおいて，一時クローズ要求応答受信。※1

プロセスBにおいて，コネクションの切断。※2

プロセスAにおいて，コネクションの切断。※2

注※1

一時クローズ要求および一時クローズ要求応答受信は，プロセスの処理がOpenTP1のライブラリ関数を実行し，かつ，電文を受信できる状態にいる場合に受信します。ユーザ処理中やOpenTP1のライブラリ関数実行中であっても電文受信処理を実施していない場合は，受信できません。

注※2

コネクションの切断の順序は，プロセスAとプロセスB間で同期を取らずに行うため，順序が逆転するおそれがあります。

コネクションを切断時に，一時クローズ処理は，コネクションを確立したプロセス間で合意を取りますが，ノード間通信時の毎回コネクション断機能は，プロセス間の合意を取りません。そのため，一時クローズ処理と比較して，即時（電文送信直後，または電文受信直後）にコネクションの切断を実施できます。ノード間通信時の毎回コネクション断機能を実施できるのは，ノード間のコネクションだけです。

この機能の処理概要を次の図に示します。

図7‒3　ノード間通信時の毎回コネクション断オプション機能概要

プロセスAからOpenTP1プロセスBへコネクション確立要求。

プロセスBでコネクション確立要求受付。

プロセスAからプロセスBに対して，電文送信。

プロセスBにおいて，電文受信。

プロセスAにおいて，コネクションの切断。※

プロセスBにおいて，コネクションの切断。※

注※

コネクションの切断の順序は，プロセスAとプロセスB間で同期を取らずに行うため，順序が逆転する可能性があります。

一時クローズ処理（ipc_sockctl_highwater=0,0を設定）とノード間通信時の毎回コネクション断機能を適用した場合の機能比較を次の表に示します。

比較項目

一時クローズ処理

ipc_sockctl_highwater=0,0

ノード間通信時の毎回コネクション断オプション機能

OpenTP1の通信性能

×

○

コネクション切断検知の即時性

×

○

コネクション切断の範囲

○

×

使用するポート数

△

△

（凡例）

○：優位

×：劣位

△：同等

コネクション切断検知の即時性を重視する場合はノード間通信時の毎回コネクション断オプション機能を使用してください。

コネクション切断の範囲を重視する場合は，一時クローズ処理を使用してください。

(3)　ノード間通信時の毎回コネクション断機能適用の注意事項

コネクションには，TCPのポートがくくりついています。TCPのポートの状態遷移には，TIME_WAITの状態があります。OSは，ネットワーク上で遅れていたパケットが到着する可能性があるので，切断したコネクションで使用されていたポートを一定時間，再利用しないようにします。一定時間，再利用されないポートの状態をTIME_WAIT状態といいます。詳細は，TCP/IPの文献を参照してください。

ノード間通信時の毎回コネクション断機能を使用すると，コネクションの切断が頻繁に行われ，短命ポート（Ephemeral port）が一定時間，TIME_WAIT状態で残ります。TIME_WAIT状態のポートは，再利用できないため，ポート不足が発生するおそれがあります。ポート不足が発生すると，通信障害が発生し，OpenTP1がダウンする場合があります。

OSのコマンド（netstatなど）で，ノードのポートの状態を確認し，ノード間通信時の毎回コネクション断オプション機能を使用しても，システムで使用できるポート数の上限値を超えない場合に適用してください。

7.3.9　ソケット数増加による資源の増減

OpenTP1は，max_socket_descriptorsオペランドの指定値に対応して，内部管理テーブルを確保します。max_socket_descriptorsオペランドの指定値を増やすとOpenTP1が確保するmallocエリアが増加します。

また，一時クローズ処理を開始すると，一時クローズ処理中のソケットを管理するためにも，mallocエリアが確保されます。ただし，一時クローズ処理要求に対する応答を受信してソケットがクローズされたあと，他コネクションに再利用される時点で解放されます。

7.3.10　ネットワーク環境のチューニング方法

大規模システムを構築する場合に，ネットワーク環境によって発生しやすい障害を防止する方法について説明します。

OpenTP1のRPCは，TCP/IPのタイマ監視値をOSが実装しているタイマ値よりも小さい値で動作するように制御します。WANを経由した遠隔地との通信など，伝送効率の悪いネットワークを使用した場合，通信障害が発生することがあります。

このような場合，ユーザは，システム共通定義，ユーザサービス定義，およびユーザサービスデフォルト定義で次に示すオペランドを指定することで，問題を解消できます。

set ipc_conn_interval = コネクション確立監視時間
set ipc_send_interval = データ送信監視間隔
set ipc_send_count = データ送信監視回数
set ipc_header_recv_time = 通信制御データの受信監視時間
set ipc_backlog_count = コネクション確立要求を格納するキューの長さ

コネクション確立監視時間の指定

送信先プロセスとのコネクションが未確立の場合，OpenTP1は，TCP/IPのconnect()システムコールを呼び出します。このとき，ソケットをノンブロッキングモードで使用しているため，すぐにコネクションが確立できない場合，select()システムコールを使用してTCP/IPからのコネクション確立完了のイベントを受信するまで監視します。

ipc_conn_intervalオペランドを指定することによって，select()システムコールを使用してTCP/IPからのコネクション確立完了のイベントを受信するまでの監視時間を指定できます。

データ送信監視間隔およびデータ送信監視回数の指定

コネクション確立後，OpenTP1は，write()システムコールを使用してTCP/IP通信バッファに送信データを書き込みます。

WANを経由する通信などでネットワークの伝送品質が悪くパケットの消失が繰り返し発生する場合や，TCP/IP通信バッファ以上のデータを送信する場合は，TCP/IP通信バッファに送信データを書き込めないでwrite()システムコールのリトライが発生する可能性があります。

ipc_send_intervalオペランドを指定することによって，write()システムコールのデータ送信監視間隔を指定できます。

ipc_send_countオペランドを指定することによって，write()システムコールのデータ送信監視回数を指定できます。

通信制御データの受信監視時間の指定

データ受信の開始後に，ネットワークの障害などによってOpenTP1の通信制御データを正しく受信できない状態になると，他プロセスからのコネクション設定要求や新しいデータ受信処理を開始できない状態が続いてしまいます。

ipc_header_recv_timeオペランドを指定することによって，通信制御データを受信するまでの時間を監視できます。

コネクション確立要求を格納するキュー（リッスンキュー）の長さの指定

OpenTP1は，コネクション接続要求を受信するソケットに対し，listen()システムコールを発行します。listen()システムコールに指定するリッスンキューの長さには，OpenTP1をコンパイルした環境のOSが定義しているSOMAXCONNを指定しています。SOMAXCONNの値については，「リリースノート」を参照してください。一度に大量のコネクション接続要求を受信すると，リッスンキューが不足し，コネクション接続元のコネクション接続要求はエラーリターンする可能性があります。システム共通定義のipc_backlog_countオペランドを指定すると，リッスンキューの長さを変更できます。リッスンキューに指定できる最大値，およびSOMAXCONNの値は動作環境のOSによって異なります。そのため，ipc_backlog_countオペランドに動作環境のSOMAXCONN以上の値を指定する場合，動作環境のOSのマニュアルを参照してこれらの値を確認し，指定する値を決定してください。

7.3.11　DNS，NIS使用時の注意事項

OpenTP1は，定義されたホスト名からIPアドレスを変換したり，RPC通信先を求めたりするために，DNSやNISを使用することがあります。これらの機能を使用するかどうかはOpenTP1を使用するOS環境の設定によって決定します。

DNS，NISが障害になると，トランザクション処理時間が長くなったり，OpenTP1が開始できなくなったり，またはUAPが開始できなくなったりする障害が発生する可能性があります。

障害発生を防ぐために，次の観点からシステム設計をしてください。

高信頼性に対する観点

DNSサーバ，NISサーバ障害時について設計する必要があります。

交代先の設計や，自サーバ内での解決方法を設計して信頼性を高めてください。

性能面に対する観点

DNS，NISを使用する場合，ホスト名からアドレスを求めるときに通信が発生することがあります。

そのオーバヘッドを考慮してシステムを設計してください。

8　コンテナオーケストレーションツールを使用したOpenTP1の構成と構築

この章では，コンテナオーケストレーションツールを使用したOpenTP1の構成と構築について説明します。

なお，コンテナオーケストレーションツールを使用したOpenTP1のシステム構築の詳細については，取扱説明書を参照してください。

8.1　この章を読む際の留意事項

この章を読む際の留意事項を次に示します。

この章は，Docker，Kubernetesの基本的な製品知識がある読者を対象としています。この章をお読みになる前に，各製品のマニュアルなどで各製品の基本知識を習得いただきますよう，お願いいたします。

TP1/Server BaseおよびTP1/Client/Jをコンテナで動作させるためには，次のソフトウェアを前提とします。

表8‒1　Linux版 TP1/Server Baseの前提ソフトウェア

TP1/Server Baseのバージョン

コンテナプラットフォーム

オーケストレーションツール

07-56〜07-57

Docker

Kubernetes

07-60以降

Podman

OpenShift

（OpenShiftがサポートするKubernetes）

表8‒2　TP1/Client/Jの前提ソフトウェア

TP1/Client/Jのバージョン

コンテナプラットフォーム

オーケストレーションツール

07-52〜07-53

Docker

Kubernetes

この章では，Dockerコンテナを前提としたOpenTP1の運用手順について解説しています。

この章では，Dockerイメージや，PodなどのKubernetesに関する各種オブジェクトの作成方法など，環境構築方法については記載していません。TP1/Server Baseに添付されている取扱説明書「Docker，Kubernetesを使用したOpenTP1システムの構築」または「OpenShiftを使用したOpenTP1システムの構築」を参照してください。

この章では，KubernetesのServiceオブジェクトをServiceと表記しています。また，「スケジューラダイレクト機能を使用したRPC」および「通信先指定RPC」を合わせて，「スケジューラダイレクト機能を使用したRPC」と表記しています。

この章では，各機能をC言語の関数名で説明します。C言語の関数名に対応するCOBOL言語のAPIは，関数名を最初に使用する個所に【 】で囲んで表記します。それ以降は，C言語の関数名に統一して説明します。

8.2　概要

DockerおよびKubernetesを使用したOpenTP1の概要を説明します。

8.2.1　コンテナサポート

次に示す製品は，Docker，Kubernetesを使用したコンテナ環境でも動作できるため，コンテナ内のTP1/Server BaseとRPC通信できます。

Linux版 TP1/Server Base 07-56以降

TP1/Client/J 07-53以降

次に示す製品は，Docker，Kubernetesを使用したコンテナ環境では動作できませんが，応答電文受信用IPアドレス通知機能を使用することでコンテナ内の上記製品とRPC通信できます。

Windows版 TP1/Server Base 07-60以降

8.2.2　前提

次のソフトウェアを前提とします。

(1)　前提ソフトウェア

(a)　コンテナ

DockerまたはPodman

(b)　オーケストレーションツール

Kubernetes

(c)　コンテナOS

Dockerを使用する場合

Red Hat Enterprise Linux Server

Podmanを使用する場合

Universal Base Images(UBI) 9.1

(2)　前提条件

コンテナ内でOpenTP1を使用する場合の前提条件を次に示します。

(a)　Dockerに関する前提条件

1つのPodに配置できるTP1/Server Base，TP1/Client/Jが動作するコンテナは1つだけです。

TP1/Server BaseとTP1/Client/Jを1つのコンテナにインストールできません。

コンテナ内で使用可能なネットワークアダプタは1つだけです。

(b)　Kubernetesに関する前提条件

Kubernetesのスケール制御に関する機能は使用できません。Deploymentなどのワークロードコントローラを使用したスケールイン・スケールアウト機能を使用しないでください。

8.3　システム構成

Docker，Kubernetesを使用したOpenTP1の構成例を次に示します。

OpenShiftを使用する場合のシステム構成例については，付属の取扱説明書を参照してください。

図8‒1　システム構成

リモートAPI機能以外のRPCを使用する場合，次に示すバージョンを使用する必要があります。

Linux版 TP1/Server Base 07-56以降

Windows版 TP1/Server Base 07-60以降

TP1/Client/J 07-53以降

上記以外のOpenTP1間で通信可能なバージョンの詳細については，「8.3.2　旧バージョンとのRPC連携」を参照してください。

8.3.1　トランザクション連携

TP1/Server Base間やTP1/Client/JからのRPCにより，XAインタフェースに準拠したDBMSとトランザクション連携ができます。コンテナ環境でのトランザクション連携可否を次に示します。

OpenShiftを使用する場合，サポートするDBMSはHiRDBだけです。

表8‒3　トランザクション連携可否

#

TP1/Server Base

DBMS※

連携可否

1

コンテナ内

コンテナ内

×

2

コンテナ外

○

3

コンテナ外

コンテナ内

×

4

コンテナ外

○

（凡例）

○：連携可能

×：連携不可能

注※

DBMSはOracleとHiRDBをサポート。

APサーバからコンテナ内のTP1/Server Baseに接続し，DBMS（コンテナ内のOracle）とトランザクション連携する場合のシステム構成例を次の図に示します。

図8‒2　Oracleとのトランザクション連携

(1)　サポートバージョン

コンテナ外のAPサーバ上のTP1/Connector経由でコンテナ内のOpenTP1に接続し，XAリソースサービスを使用してトランザクション制御を行う場合は，次のバージョンを使用してください。

表8‒4　サポートバージョン

#

RPC通信区間

TP1/Client/Jのバージョン

TP1/Server Baseのバージョン

1

RPC①

07-50以降

Linux版の場合：07-56以降

Windows版の場合：07-60以降

8.3.2　旧バージョンとのRPC連携

旧バージョン（応答電文受信用IPアドレス通知機能をサポートしていないバージョン）のTP1/Server Base，TP1/Client/Jについて，RPC通信可否を次に示します。

(1)　応答電文受信用IPアドレス通知機能をサポートしているTP1/Server Baseと旧バージョンとのRPC通信可否

表8‒5　旧バージョンのTP1/Server BaseからのRPC通信可否

#

旧バージョンからのRPC種別

RPC要求先

（コンテナ内）

ipc_notify_response_host

（コンテナ外）

ipc_notify_response_host

Y

N

Y

N

1

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

×

×

×

○

2

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

×

×

×

○

3

リモートAPIを使用したRPC

○

○

○

○

（凡例）

○：通信可能

×：通信不可能

表8‒6　旧バージョンのTP1/Client/JからのRPC通信可否

#

旧バージョンからのRPC種別

RPC要求先

（コンテナ内）

ipc_notify_response_host

（コンテナ外）

ipc_notify_response_host

Y

N

Y

N

1

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

×

×

×

○

2

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

×

×

×

○

3

リモートAPIを使用したRPC

○

○

○

○

（凡例）

○：通信可能

×：通信不可能

表8‒7　旧バージョンのTP1/Server BaseへのRPC通信可否

#

RPC要求元

旧バージョンへのRPC種別

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

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

リモートAPIを使用したRPC

1

コンテナ内

ipc_notify_response_host

Y

×

×

○

2

N

○

○

○

3

コンテナ外

ipc_notify_response_host

Y

×

×

○

4

N

○

○

○

（凡例）

○：通信可能

×：通信不可能

(2)　応答電文受信用IPアドレス通知機能をサポートしているTP1/Client/Jと旧バージョンとのRPC通信可否

表8‒8　TP1/Client/Jから旧バージョンのTP1/Server BaseへのRPC通信可否

#

RPC要求元

旧バージョンへのRPC種別

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

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

リモートAPIを使用したRPC

1

コンテナ内

dcnotifyreshost

Y

×

×

○

2

N

×

○

○

3

コンテナ外

dcnotifyreshost

Y

×

×

○

4

N

×

○

○

（凡例）

○：通信可能

×：通信不可能

8.3.3　他製品とのRPC連携

RPCインタフェースを持つ他製品とのRPC通信可否を次に示します。

(1)　コンテナ内のTP1/Server Baseに対しRPC要求を行う製品

表8‒9　他製品からTP1/Server BaseへのRPC

#

RPCインタフェースを持つ他製品

（コンテナ外）

RPC要求先

コンテナ内（ipc_notify_response_host=Y）

コンテナ内（ipc_notify_response_host=N）

1

TP1/LiNK

△

△

2

TP1/Client/J

07-51以前

△

△

3

07-52以降（dcnotifyreshost=N）

△

△

4

07-52以降（dcnotifyreshost=Y）

○

△

5

TP1/Client/P

△

△

6

TP1/Client/W

△

△

7

TP1/Client/J for .NET Framework

△

△

8

TP1/Server Base Enterprise Option

×

×

9

Hitachi System Information Capture（HSIC）

×

×

（凡例）

○：通信可能

△：リモートAPI機能だけサポート

×：通信不可能

(2)　コンテナ内のTP1/Server BaseからRPC要求を受ける製品

表8‒10　TP1/Server Baseから他製品へのRPC

#

RPCインタフェースを持つ他製品

（コンテナ外）

RPC要求先

コンテナ内

（ipc_notify_response_host=Y）

コンテナ内

（ipc_notify_response_host=N）

1

TP1/LiNK

×

○

2

TP1/Server Base Enterprise Option

○

○

3

Hitachi System Information Capture（HSIC）

×

○

4

TMS-4V/SP/Server※1

○

○

5

TMS-4V/SP/RemoteProcedureCall※1

○

○

6

DCCM3/SERVER/TP1※1

（VOS3 XDM/DCCM3,VOS1 DCCM3）

○

○

7

uCosminexus Application Server※2

（TP1インバウンドアダプタ）

×

○

（凡例）

○：通信可能

×：通信不可能

注※1

該当製品がサポートしているのはリモートAPI機能だけです。

注※2

該当製品がサポートしているのはスケジューラダイレクト機能だけです。

8.4　サポート機能

コンテナ内のOpenTP1では，未サポート機能や，制限付きでサポートする機能があります。次に示す機能制限内での運用をお願いいたします。

8.4.1　サポート機能の詳細

コンテナ内のOpenTP1でサポートする機能を次の表に示します。

表8‒11　 TP1/Server Baseのサポート機能

#

機能名

サポート

特記事項

1

統合システム運用管理機能JP1

×

−

2

トランザクション制御

分散トランザクション

○

−

3

XAリソースサービスによるトランザクション制御

×

−

4

リソースマネジャ連携

○

次のリソースマネジャが使用できます。

TP1/FS/Direct Access

TP1/FS/Table Access

HiRDB

Oracle

5

クライアント/サーバ形態の通信

OpenTP1のリモートプロシジャコール（RPC）通信

○

詳細は，「8.4.2　RPC通信」を参照してください。

6

サービス情報検索の付加機能

グローバル検索機能

○

−

7

サービス情報優先度指定機能

○

TP1/Server Base 07-57以降でサポートしています。

8

OpenTP1のノード管理

起動通知機能

○

−

9

ノード監視機能

○

−

10

ノード自動追加機能

○

TP1/Server Base 07-57以降でサポートしています。

11

XATMIインタフェースの通信

×

−

12

TxRPCインタフェースの通信

×

−

13

メッセージ制御

メッセージ制御機能

×

−

14

アプリケーションプログラムのスケジュール

プロセスの制御

マルチサーバ負荷バランス機能

○

−

15

スケジュールの優先度制御

○

−

16

非常駐UAPプロセスのリフレッシュ機能

○

−

17

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

○

−

18

マルチスケジューラ機能

○

−

19

バッファ領域の共用による共用メモリの節約

○

−

20

OpenTP1クライアント機能

（TP1/Client/J）

CUPへの一方通知機能

○

コンテナ内のCUPへの一方通知機能は，TP1/Client/Jだけをサポートしています。

21

サービス関数動的ローディング機能

○

−

22

OpenTP1の運用を補助する機能

資源の排他制御

○

−

23

ユーザジャーナルの取得

○

−

24

ジャーナル維持機能

○

−

25

メッセージログの操作

○

−

26

メッセージログの通知

○

−

27

稼働統計情報

○

−

28

リアルタイム統計情報サービス

○

−

29

OpenTP1の状態確認機能

○

−

30

監査ログによるシステムの監視

×

−

31

OpenTP1の監視

○

−

32

OpenTP1ファイルシステム

△

次のファイルシステムをサポートします。

ステータスファイル

システムジャーナルファイル

チェックポイントダンプ

ファイル

TAMファイル

DAMファイル

上記以外のファイルシステムはサポートしていません。

33

障害の原因解析

（各種トレースファイルの取得）

○

−

34

複数のOpenTP1を使用する場合の機能

系切り替え機能

（HAモニタを使用した系切り替え）

×

−

35

系切り替え機能

（Kubernetesの機能を使用した系切り替えおよび再開始）

×

取扱説明書の「5.　TP1サーバの系切り替え構成」に記載している機能はサポートしていません。

36

マルチノード機能

×

−

37

グローバルアーカイブジャーナル機能

×

−

38

マルチOpenTP1

×

−

39

TCPコネクション管理

一時クローズ機能

○

−

40

ノード間通信時の毎回コネクション断機能

○

−

（凡例）

○：サポート

△：制限付サポート

×：未サポート

−：該当しません

表8‒12　TP1/Client/Jのサポート機能

#

機能名

サポート

1

トランザクション制御

分散トランザクション

○

2

XAリソースサービスによるトランザクション制御

×

3

クライアント/サーバ形態の通信

リモートプロシジャコール（RPC）通信

リモートAPI機能（RAP）を使用したRPC

○

4

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

○

（TP1/Client/J 07-53以降）

5

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

○

6

スケジュール機能

マルチスケジューラ機能

○

7

スケジュールの優先度制御

○

8

データ圧縮機能

○

9

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

○

10

TCP/IP通信機能

×

11

サーバからの一方通知受信機能

○

12

TP1/Web接続機能

○

13

DCCM3との接続機能

○

14

その他の機能

動的定義変更機能

○

15

障害の原因解析（各種トレースファイルの取得）

○

（凡例）

○：サポート

×：未サポート

8.4.2　RPC通信

コンテナ内のTP1/Client/J，TP1/Server BaseとRPC通信する場合のサポート構成を次の表に示します。

(1)　サポートするRPC通信種別

次の表にサポートするRPC通信種別を示します。

表8‒13　サポートするRPC通信種別（TP1/Server Base-TP1/Server Base）

#

RPCの種別

TP1/Server Baseの配置

サポート

特記事項

送信元TP1/Server Base

送信先TP1/Server Base

1

リモートAPI機能（rap）を使用したRPC

コンテナ内

コンテナ内

○

−

2

コンテナ外

コンテナ内

○

−

3

コンテナ内

コンテナ外

○

−

4

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

コンテナ内

コンテナ内

○

−

5

コンテナ外

コンテナ内

○

−

6

コンテナ内

コンテナ外

○

−

7

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

コンテナ内

コンテナ内

○

詳細は，「8.4.3　RPC通信の注意事項」を参照してください。

8

コンテナ外

コンテナ内

○

9

コンテナ内

コンテナ外

○

−

（凡例）

○：サポート

×：未サポート

−：該当しません

表8‒14　サポートするRPC通信種別（TP1/Client/J-TP1/Server Base）

#

RPCの種別

TP1/Client/J，TP1/Server Baseの配置

サポート

特記事項

送信元TP1/Client/J

送信先TP1/Server Base

1

リモートAPI機能（rap）を使用したRPC

コンテナ内

コンテナ内

○

−

2

コンテナ外

コンテナ内

○

−

3

コンテナ内

コンテナ外

○

−

4

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

コンテナ内

コンテナ内

○

TP1/Client/J 07-53以降

5

コンテナ外

コンテナ内

○

TP1/Client/J 07-53以降

6

コンテナ内

コンテナ外

○

TP1/Client/J 07-53以降

7

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

コンテナ内

コンテナ内

○

−

8

コンテナ外

コンテナ内

○

−

9

コンテナ内

コンテナ外

○

−

（凡例）

○：サポート

×：未サポート

−：該当しません

8.4.3　RPC通信の注意事項

TP1/Server Baseが次のシステム条件に該当する場合は，次に示す対応が必要です。

(1)　システム条件（AND条件）

条件1.

TP1/Server Baseが稼働するサーバマシンにホスト名（IPアドレス）が複数存在する。

条件2.

TP1/Server Baseが使用するホスト名（IPアドレス）のどれかが，TP1/Client/Jが使用するIPアドレスと接続されていない（通信できない）構成である。

(2)　対応方法

TP1/Client/JとTP1/Server Base間で通信するIPアドレスは，1つに固定してください。

TP1/Server Baseのシステム定義で，システム共通定義のmy_hostオペランドとdcbindht定義コマンドには，TP1/Client/Jと接続可能なホスト名（IPアドレス）を指定してください。

8.4.4　コンテナ内のTP1/Server Baseに関する注意事項

(1)　システム定義に関する注意事項

コンテナ内では，システム共通定義のmy_hostオペランドは指定できません。

(2)　namsvinfコマンドに関する注意事項

コンテナ内でnamsvinfコマンドを実行する場合，次の点に注意してください。

(a)　システム共通定義のrpc_close_after_sendにYを指定する場合

namsvinfコマンドは，-bオプション以外のオプションを指定しないでください。

-bオプション以外を指定した場合，起動確認に失敗するためノードが起動中の場合でもノード稼働状況（STATに表示される値）に'S'（送信可能）が表示されます。

(b)　システム共通定義のrpc_close_after_sendにNを指定，または省略する場合

namsvinfコマンドは-bオプション以外のオプションも指定できます。

ただし，コネクション障害や一時クローズ処理によって，(a)と同様にノード稼働状況が'S'と表示される場合があります。その場合は，時間を置いて再度コマンドを実行してください。

8.5　システム構成と環境設定

コンテナ内のTP1/Server BaseへRPCする場合，通信先にはコンテナが動作するワーカーノード，またはマスターノードを設定します。

通信先とは，システム定義やTP1/Client/J環境定義，および通信先を指定するAPIで設定するホスト名またはIPアドレスと，ポート番号のことです。

通信先のポート番号については，マニュアル「OpenTP1 システム定義」またはマニュアル「OpenTP1 クライアント使用の手引 TP1/Client/J編」を参照してください。

ただし，Kubernetesクラスタ内の同一ホスト上で，ホストOS上のTP1/Server Baseと，コンテナ内のTP1/Server Baseを連携する場合，コンテナが動作するワーカーノードを設定しても通信できません。その場合，次のとおりマスターノードを設定してください。

なお，マスターノードを設定したとしても，マスターノードのホストOS上のTP1/Server Baseとコンテナ内のTP1/Server Base間の通信はできません。

（例）

コンテナが動作するワーカーノードをhostA，マスターノードをhostBとします。

同一ホスト上（hostA）でTP1-A（コンテナ外）とTP1-B（コンテナ内）を連携する場合の設定

注※

TP1-Aのall_nodeオペランド，およびTP1-Bのipc_response_hostオペランドにマスターノードを設定してください。

ほかにKubernetesクラスタ内で連携するコンテナ内のTP1/Server Baseがある場合は，上記TP1-A，TP1-Bの設定と同様にマスターノードを設定してください。

システム構成とRPC種別によって，OpenTP1の定義に設定する内容が異なります。RPC種別ごとの定義設定について次に示します。

8.5.1　リモートAPI機能を使用したRPC

TP1/Client/J，TP1/Server Baseからコンテナ内外のTP1/Server BaseへリモートAPI機能を使用したRPCができます。システム形態に応じてTP1/Client/J，TP1/Server Baseの定義設定，およびServiceの設定を行ってください。

(1)　リモートAPI機能を使用したRPCの構成例

コンテナ外のTP1/Server BaseへRPCを発行する場合は，マニュアル「OpenTP1 システム定義」またはマニュアル「OpenTP1 クライアント使用の手引 TP1/Client/J編」に記載の定義設定方法で使用できます。

コンテナ内のTP1/Server BaseへRPCを発行する場合，RPC先のTP1/Server BaseにServiceを作成する必要があります。

図8‒3　リモートAPIを使用したRPCの構成例

(a)　TP1/Client/J環境定義の設定【①TP1/Client/J】

次のTP1/Client/J環境定義を設定してください。

表8‒15　TP1/Client/J環境定義の設定

#

オペランド名

設定内容

補足

1

dchost=ホスト名:ポート番号

ホスト名：rapリスナー用のServiceが存在するホスト名

ポート番号：④Serviceに設定したspec.ports.targetPortに対応するspec.ports.nodePort

コンテナ外のrapリスナーへ送信する場合は，特に制限はありません。

OpenTP1マニュアルの説明に従い設定してください。

(b)　システム定義の設定【②TP1/Server Base】

次のシステム定義を設定してください。

表8‒16　システム定義の設定【②TP1/Server Base】

#

定義名

コマンド名

設定内容

補足

1

ユーザサービスネットワーク定義

dcsvgdef -hホスト名:ポート番号 -w

ホスト名：rapリスナー用のServiceが存在するホスト名

ポート番号：④Serviceのspec.ports.targetPortに対応するspec.ports.nodePort

コンテナ外のrapリスナーへ送信する場合は，特に制限はありません。

OpenTP1マニュアルの説明に従い設定してください。

(c)　システム定義の設定【③TP1/Server Base】

次のシステム定義を設定してください。

表8‒17　システム定義の設定【③TP1/Server Base】

#

定義名

コマンド名

設定内容

補足

1

rapリスナーサービス定義

rap_listen_port

rapリスナーおよびrapサーバが使用するポート番号

OpenTP1マニュアルの説明に従い設定してください。

(d)　図中④Serviceの設定

コンテナ内の③TP1/Server BaseへRPCする場合は，Serviceを作成してください。

コンテナ内の③TP1/Server Baseでrap_listen_portオペランドに設定したポート番号と同じポート番号をServiceのspec.ports.targetPortに設定してください。

TP1/Client/Jや③TP1/Server BaseからリモートAPI機能を使用する場合は，Serviceのspec.ports.targetPortに対応するspec.ports.nodePortに対し接続してください。

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

all_nodeオペランドに指定するホスト名には，Kubernetesのマスターノードまたは，ワーカーノードを指定できます。マスターノードを指定する場合は，OpenTP1システム内のすべてのTP1/Server Baseの設定をマスターノードで統一してください。

ワーカーノードを指定する場合は，各TP1/Server BaseでKubernetesクラスタ内の任意のワーカーノードを設定してください。

また，all_nodeオペランドに指定するホスト名は，ほかのTP1/Server Baseに指定するipc_response_hostオペランドの値と一致させる必要があります。

(1)　コンテナ内のTP1/Server Base間のRPC

図8‒4　コンテナ内のTP1/Server Base間のRPC

(a)　システム定義の設定【①TP1/Server Base】

次のシステム定義を設定してください。

表8‒18　システム定義の設定【①TP1/Server Base】

#

定義名

オペランド名

設定内容

補足

1

システム共通定義

rpc_port_base

30000以降のポート番号

「8.6.4　Serviceの作成」を参照し，ほかのPodの使用範囲と重複しないポート番号をrpc_port_baseに設定してください。

2

ipc_notify_response_host

Y

詳細は，マニュアル「OpenTP1 システム定義」を参照してください。

3

ipc_response_host

通信先ノードのTP1/Server Baseに通知する，応答電文受信用のホスト名

4

all_node=ホスト名:ポート番号

ホスト名：ネームサービス用のServiceが存在するホスト名

ポート番号：③Serviceのspec.ports.targetPortに対応するspec.ports.nodePort

Kubernetesクラスタ内のどれかのKubernetesノードのホスト名を設定してください。

また，ホスト名は②TP1/Server Baseのipc_response_hostオペランドの値と一致させてください。

(b)　システム定義の設定【②TP1/Server Base】

「表8-18　システム定義の設定【①TP1/Server Base】」に示すオペランドを設定してください。all_nodeオペランドに指定するポート番号（相手ノードのname_portオペランドに指定したポート番号）はOpenTP1システム内でユニークな値に設定する必要があります。

(c)　図中③Serviceの設定

コンテナ内のTP1/Server BaseへRPCする場合は，Serviceを作成してください。

コンテナ内の②TP1/Server Baseでname_portオペランドに設定したポート番号と同じポート番号をServiceのspec.ports.targetPortに設定してください。

(d)　図中④Serviceの設定

コンテナ内の①TP1/Server Baseでname_portオペランドに設定したポート番号と同じポート番号をServiceのspec.ports.targetPortに設定してください。

また，コンテナ内のTP1/Server Baseからコンテナ内のTP1/Server BaseにRPCする場合は，応答電文を受信するためのServiceを作成してください。

コンテナ内の①TP1/Server Baseで，応答電文を受信するためのポート番号をServiceのspec.ports.targetPortに設定してください。

応答電文の受信にはエフェメラルポートを使用するため，「8.6.4　Serviceの作成」で求めたエフェメラルポート数分のポートをServiceに設定する必要があります。

Serviceへ設定が必要なポート番号の見積方法については，「8.6.4　Serviceの作成」を参照してください。

(2)　TP1/Server Baseとコンテナ内のTP1/Server Base間のRPC

図8‒5　TP1/Server Baseとコンテナ内のTP1/Server Base間のRPC

(a)　システム定義の設定【①TP1/Server Base】

次のシステム定義を設定してください。

表8‒19　システム定義の設定【①TP1/Server Base】

#

定義名

オペランド名

設定内容

補足

1

システム共通定義

ipc_notify_response_host

Y

詳細は，マニュアル「OpenTP1 システム定義」を参照してください。

2

ipc_response_host

通信先ノードのTP1/Server Baseに通知する，応答電文受信用のホスト名

3

all_node=ホスト名:ポート番号

ホスト名：ネームサービス用のServiceが存在するホスト名

ポート番号：③Serviceのspec.ports.targetPortに対応するspec.ports.nodePort

図①TP1/Server Base：

Kubernetesクラスタ内のどれかのKubernetesノードのホスト名を設定してください。

また，ホスト名は②TP1/Server Baseのipc_response_hostオペランドの値と一致させてください。

なお，指定するホスト名には①TP1/Server Baseが起動するホストのホスト名を指定しないでください。指定した場合dc_rpc_call関数が失敗します。

図②TP1/Server Base：

①TP1/Server Baseが起動するホストのホスト名を設定してください。

また，ホスト名は①TP1/Server Baseのipc_response_hostオペランドの値と一致させてください。

(b)　システム定義の設定【②TP1/Server Base】

「表8-19　システム定義の設定【①TP1/Server Base】」に示すオペランドを設定してください。all_nodeオペランドに指定するポート番号（相手ノードのname_portオペランドに指定したポート番号）はOpenTP1システム内でユニークな値に設定する必要があります。

(c)　図中③Serviceの設定

コンテナ内のTP1/Server BaseへRPCする場合は，Serviceを作成してください。

コンテナ内の②TP1/Server Baseでname_portオペランドに設定したポート番号と同じポート番号をServiceのspec.ports.targetPortに設定してください。

(3)　コンテナ内のTP1/Server BaseとTP1/Server Base間のRPC

図8‒6　コンテナ内のTP1/Server BaseとTP1/Server Base間のRPC

(a)　システム定義の設定【①TP1/Server Base】

次のシステム定義を設定してください。

表8‒20　システム定義の設定【①TP1/Server Base】

#

定義名

オペランド名

設定内容

補足

1

システム共通定義

rpc_port_base

30000以降のポート番号

「8.6.4　Serviceの作成」を参照し，ほかのPodの使用範囲と重複しないポート番号をrpc_port_baseに設定してください。

2

ipc_notify_response_host

Y

詳細は，マニュアル「OpenTP1 システム定義」を参照してください。

3

ipc_response_host

通信先ノードのTP1/Server Baseに通知する，応答電文受信用のホスト名

4

all_node=ホスト名:ポート番号

図①TP1/Server Base：

ホスト名：②TP1/Server Baseが起動するホストのホスト名

ポート番号：②TP1/Server Baseのname_port

図②TP1/Server Base：

ホスト名：ネームサービス用のServiceが存在するホスト名

ポート番号：③Serviceのpec.ports.targetPortに対応するspec.ports.nodePort

図②TP1/Server Baseで指定するホスト名はKubernetesクラスタ内のどれかのKubernetesノードのホスト名を設定してください。

また，ホスト名は①TP1/Server Baseのipc_response_hostオペランドの値と一致させてください。

(b)　システム定義の設定【②TP1/Server Base】

「表8-20　システム定義の設定【①TP1/Server Base】」に示すオペランドを設定してください。all_nodeオペランドに指定するポート番号（相手ノードのname_portオペランドに指定したポート番号）はOpenTP1システム内でユニークな値に設定する必要があります。

(c)　図中③Serviceの設定

コンテナ内の①TP1/Server Baseでname_portオペランドに設定したポート番号と同じポート番号をServiceのspec.ports.targetPortに設定してください。

また，コンテナ内のTP1/Server Baseからコンテナ外のTP1/Server BaseにRPCする場合は，応答電文を受信するためのServiceを作成してください。

コンテナ内の①TP1/Server Baseで，応答電文を受信するためのポート番号をServiceのspec.ports.targetPortに設定してください。

応答電文の受信にはエフェメラルポートを使用するため，「8.6.4　Serviceの作成」で求めた数のエフェメラルポートをServiceに設定する必要があります。

Serviceへ設定が必要なポート番号の見積方法については，「8.6.4　Serviceの作成」を参照してください。

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

TP1/Client/J，TP1/Server Baseからコンテナ内外のTP1/Server Baseへスケジューラダイレクト機能を使用したRPCができます。システム形態に応じてTP1/Client/J，TP1/Server Baseの定義設定，およびServiceの設定を行ってください。

また，dchostオペランドやdcsvgdefコマンドに指定する通信先のホスト名は，通信先のTP1/Server Baseに指定したipc_response_hostオペランドの値と一致させる必要があります。

(1)　コンテナ内のTP1/Client/Jとコンテナ内のTP1/Server Base間のRPC

図8‒7　コンテナ内のTP1/Client/Jとコンテナ内のTP1/Server Base間のRPC

(a)　TP1/Client/J環境定義の設定【①TP1/Client/J】

TP1/Client/Jインスタンスごとに，次のTP1/Client/J環境定義を設定してください。

表8‒21　TP1/Client/J環境定義の設定

#

オペランド名

設定内容

補足

1

dccltcuprcvport

CUPの電文受信で使用するポート番号

この構成では必ずdccltcuprcvportオペランドを設定してください。

2

dchost=ホスト名:ポート番号

rpcCallメソッドを発行する場合

ホスト名：スケジュールサービス用のServiceが存在するホスト名

ポート番号：③Serviceのspec.ports.targetPortに対応するspec.ports.nodePort

rpcCallToメソッドを発行する場合，このオペランドの設定は不要です。

rpcCallToメソッドを使用する場合は，左記のホスト名を設定したDCRpcBindTblオブジェクトを作成してから，rpcCallToメソッドを発行してください。

また，ホスト名は②TP1/Server Baseのipc_response_hostオペランドの値と一致させてください。

3

dcnotifyreshost

Y

詳細は，マニュアル「OpenTP1 クライアント使用の手引 TP1/Client/J編」を参照してください。

4

dcresponsehost

TP1/Server Baseに通知する，応答電文受信用のホスト名

(b)　システム定義の設定【②TP1/Server Base】

次のシステム定義を設定してください。

表8‒22　システム定義の設定【②TP1/Server Base】

#

定義名

オペランド名

設定内容

補足

1

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

scd_port

スケジュールサービスのポート番号

−

2

システム共通定義

ipc_notify_response_host

Y

詳細は，マニュアル「OpenTP1 システム定義」を参照してください。

3

ipc_response_host

TP1/Client/Jに通知する，②TP1/Server Baseの電文受信用のホスト名

（凡例）

−：該当しません

(c)　図中③Serviceの設定

コンテナ内のTP1/Server BaseへRPCする場合は，Serviceを作成してください。

コンテナ内の②TP1/Server Baseでscd_portオペランドに設定したポート番号と同じポート番号をServiceのspec.ports.targetPortに設定してください。

TP1/Client/Jからスケジューラダイレクト機能を使用する場合は，Serviceのspec.ports.nodePortに対して接続してください。

(d)　図中④Serviceの設定

コンテナ内のTP1/Client/Jからコンテナ内のTP1/Server BaseにRPCする場合は，応答電文を受信するためのServiceを作成してください。

コンテナ内の①TP1/Client/Jで，dccltcuprcvportオペランドに指定したポート番号を，Serviceのspec.ports.targetPortおよびspec.ports.nodePortに設定してください。

(2)　コンテナ内のTP1/Server Base間のRPC

図8‒8　コンテナ内のTP1/Server Base間のRPC

(a)　システム定義の設定【①TP1/Server Base】

次のシステム定義を設定してください。

表8‒23　システム定義の設定【①TP1/Server Base】

#

定義名

オペランド名／コマンド名

設定内容

補足

1

システム共通定義

rpc_port_base

30000以降のポート番号

「8.6.4　Serviceの作成」を参照し，ほかのPodの使用範囲と重複しないポート番号をrpc_port_baseに設定してください。

2

ipc_notify_response_host

Y

詳細は，マニュアル「OpenTP1 システム定義」を参照してください。

3

ipc_response_host

通信先ノードのTP1/Server Baseに通知する，応答電文受信用のホスト名

4

ユーザサービスネットワーク定義

dcsvgdef -hホスト名-p ポート番号

dc_rpc_call関数を発行する場合

ホスト名：スケジュールサービス用のServiceが存在するホスト名

ポート番号：

③Serviceのspec.ports.targetPortに対応するspec.ports.nodePort

dc_rpc_call_to関数を発行する場合，このオペランドの設定は不要です。

dc_rpc_call_to関数を使用する場合は，DCRPC_DIRECT_SCHEDULE関数で左記ホスト名を設定し，DCRPC_BINDING_TBL構造体を作成してからdc_rpc_call_to関数を発行してください。

また，ホスト名は②TP1/Server Baseのipc_response_hostオペランドの値と一致させてください。

(b)　システム定義の設定【②TP1/Server Base】

「表8-22　システム定義の設定【②TP1/Server Base】」に示すオペランドを設定してください。

(c)　図中③Serviceの設定

コンテナ内のTP1/Server BaseへRPCする場合は，Serviceを作成してください。

コンテナ内の②TP1/Server Baseでscd_portオペランドに設定したポート番号と同じポート番号をServiceのspec.ports.targetPortに設定してください。

TP1/Server Baseからスケジューラダイレクト機能を使用する場合は，Serviceのspec.ports.targetPortに対応するspec.ports.nodePortに対して接続してください。

(d)　図中④Serviceの設定

コンテナ内の①TP1/Server Baseでscd_portオペランドに設定したポート番号と同じポート番号をServiceのspec.ports.targetPortに設定してください。

また．コンテナ内のTP1/Server Baseからコンテナ内のTP1/Server BaseにRPCする場合は，応答電文を受信するためのServiceを作成してください。

コンテナ内の①TP1/Server Baseで，応答電文を受信するためのポート番号をServiceのspec.ports.targetPortに設定してください。

応答電文の受信にはエフェメラルポートを使用するため，「8.6.4　Serviceの作成」で求めたエフェメラルポート数分のポートをServiceに設定する必要があります。

Serviceへ設定が必要なポート番号の見積方法については，「8.6.4　Serviceの作成」を参照してください。

(3)　TP1/Server Baseとコンテナ内のTP1/Server Base間のRPC

図8‒9　TP1/Server Baseとコンテナ内のTP1/Server Base間のRPC

(a)　システム定義の設定【①TP1/Server Base】

次のシステム定義を設定してください。

表8‒24　システム定義の設定【①TP1/Server Base】

#

定義名

オペランド名

設定内容

補足

1

システム共通定義

ipc_notify_response_host

Y

詳細は，マニュアル「OpenTP1 システム定義」を参照してください。

2

ipc_response_host

通信先ノードのTP1/Server Baseに通知する，応答電文受信用のServiceが存在するホスト名

3

ユーザサービスネットワーク定義

dcsvgdef -hホスト名-p ポート番号

dc_rpc_call関数を発行する場合

ホスト名：スケジュールサービス用のServiceが存在するホスト名

ポート番号：

③Serviceのspec.ports.targetPortに対応するspec.ports.nodePort

dc_rpc_call_to関数を発行する場合，このオペランドの設定は不要です。

dc_rpc_call_to関数を使用する場合は，DCRPC_DIRECT_SCHEDULE関数で左記ホスト名を設定し，DCRPC_BINDING_TBL構造体を作成してからdc_rpc_call_to関数を発行してください。

また，ホスト名は②TP1/Server Baseのipc_response_hostオペランドの値と一致させてください。

なお，指定するホスト名には①TP1/Server Baseが起動するホストのホスト名を指定しないでください。指定した場合dc_rpc_call関数が失敗します。

(b)　システム定義の設定【②TP1/Server Base】

「表8-22　システム定義の設定【②TP1/Server Base】」に示すオペランドを設定してください。

(c)　図中③Serviceの設定

コンテナ内のTP1/Server BaseへRPCする場合は，Serviceを作成してください。

コンテナ内の②TP1/Server Baseでscd_portオペランドに設定したポート番号と同じポート番号をServiceのspec.ports.targetPortに設定してください。

TP1/Server Baseからスケジューラダイレクト機能を使用する場合は，Serviceのspec.ports.targetPortに対応するspec.ports.nodePortに対して接続してください。

(4)　コンテナ内のTP1/Client/JとTP1/Server Base間のRPC

図8‒10　コンテナ内のTP1/Client/JとTP1/Server Base間のRPC

(a)　TP1/Client/J環境定義の設定【①TP1/Client/J】

次のTP1/Client/J環境定義を設定してください。

表8‒25　TP1/Client/J環境定義の設定

#

オペランド名

設定内容

補足

1

dccltcuprcvport

CUPの電文受信で使用するポート番号

この構成では必ずdccltcuprcvportオペランドを設定してください。

2

dcnotifyreshost

Y

詳細は，マニュアル「OpenTP1 クライアント使用の手引 TP1/Client/J編」を参照してください。

3

dcresponsehost

TP1/Server Baseに通知する，応答電文受信用のServiceが存在するホスト名

(b)　システム定義の設定【②TP1/Server Base】

「表8-22　システム定義の設定【②TP1/Server Base】」に示すオペランドを設定してください。

(c)　Serviceの設定

コンテナ内のTP1/Client/Jからコンテナ外のTP1/Server BaseにRPCする場合は，応答電文を受信するためのServiceを作成してください。

コンテナ内の①TP1/Client/Jで，dccltcuprcvportオペランドに指定したポート番号を，Serviceのspec.ports.targetPortおよびspec.ports.nodePortに設定してください。

(5)　TP1/Client/Jとコンテナ内のTP1/Server Base間のRPC

図8‒11　TP1/Client/JとTP1/Server Base間のRPC

(a)　TP1/Client/J環境定義の設定【TP1/Client/J】

次のTP1/Client/J環境定義を設定してください。

表8‒26　TP1/Client/J環境定義の設定

#

オペランド名

設定内容

補足

1

dchost=ホスト名:ポート番号

rpcCallメソッドを発行する場合

ホスト名：スケジュールサービス用のServiceが存在するホスト名

ポート番号：③Serviceのspec.ports.targetPortに対応するspec.ports.nodePort

rpcCallToメソッドを発行する場合，このオペランドの設定は不要です。

通信先指定RPCを使用する場合は，左記のホスト名を設定したDCRpcBindTblオブジェクトを作成してから，rpcCallToメソッドを発行してください。

また，ホスト名は②TP1/Server Baseのipc_response_hostオペランドの値と一致させてください。

2

dcnotifyreshost

Y

詳細は，マニュアル「OpenTP1 クライアント使用の手引 TP1/Client/J編」を参照してください。

3

dcresponsehost

TP1/Server Baseに通知する，応答電文受信用のServiceが存在するホスト名

(b)　システム定義の設定【②TP1/Server Base】

「表8-22　システム定義の設定【②TP1/Server Base】」に示すオペランドを設定し，スケジュールサービス用のServiceを作成してください。

(c)　図中③Serviceの設定

コンテナ内のTP1/Server BaseへRPCする場合は，Serviceを作成してください。

コンテナ内の②TP1/Server Baseでscd_portオペランドに設定したポート番号と同じポート番号をServiceのspec.ports.targetPortに設定してください。

TP1/Client/Jからスケジューラダイレクト機能を使用する場合は，Serviceのspec.ports.targetPortに対応するspec.ports.nodePortに対して接続してください。

(6)　コンテナ内のTP1/Server BaseとTP1/Server Base間のRPC

図8‒12　コンテナ内のTP1/Server BaseとTP1/Server Base間のRPC

(a)　システム定義の設定【①TP1/Server Base】

次のシステム定義を設定してください。

表8‒27　システム定義の設定【①TP1/Server Base】

#

定義名

オペランド名

設定内容

補足

1

システム共通定義

rpc_port_base

30000以降のポート番号

「8.6.4　Serviceの作成」を参照し，ほかのPodの使用範囲と重複しないポート番号をrpc_port_baseに設定してください。

2

ipc_notify_response_host

Y

詳細は，マニュアル「OpenTP1 システム定義」を参照してください。

3

ipc_response_host

通信先ノードのTP1/Server Baseに通知する，応答電文受信用のServiceが存在するホスト名

(b)　システム定義の設定【②TP1/Server Base】

「表8-22　システム定義の設定【②TP1/Server Base】」に示すオペランドを設定してください。

(c)　図中③Serviceの設定

コンテナ内の①TP1/Server Baseでscd_portオペランドに設定したポート番号と同じポート番号をServiceのspec.ports.targetPortに設定してください。

また，コンテナ内のTP1/Server Baseからコンテナ外のTP1/Server BaseにRPCする場合は，応答電文を受信するためのServiceを作成してください。

コンテナ内の①TP1/Server Baseで，応答電文を受信するためのポート番号をServiceのspec.ports.targetPortに設定してください。

応答電文の受信にはエフェメラルポートを使用するため，「8.6.4　Serviceの作成」で求めたエフェメラルポート数分のポートをServiceに設定する必要があります。

Serviceへ設定が必要なポート番号の見積方法については，「8.6.4　Serviceの作成」を参照してください。

8.6　コンテナ環境独自の設定

OpenTP1の提供機能の中でKubernetes環境固有の設定が必要となる機能について説明します。

8.6.1　OpenTP1の開始と終了

(1)　TP1/Server Base

コンテナ内のTP1/Server Baseは，Podの起動と連動して開始・終了するようにPodを作成してください。

TP1/Server Baseの開始については，コンテナ環境独自の「prcd直接起動方式」を適用します。Podのマニフェストの作成方法，TP1/Server Baseの停止方法，および「prcd直接起動方式」については，取扱説明書を参照してください。

(2)　TP1/Client/J

コンテナ内のTP1/Client/Jは，Podの起動と連動してJavaアプリケーションを開始・終了するようにPodを作成してください。

Podの作成方法については，取扱説明書を参照してください。

サーブレット形態で使用する場合は，アプリケーションサーバの説明書を参照してください。

8.6.2　TP1/Server Baseの再開始

TP1/Server Baseの再開始を行う場合は，KubernetesのnodeSelector機能などを使用し，再開始後も同じノードにPodが起動するように設定してください。Kubernetesのコンテナ内のTP1/Server Baseが使用するOpenTP1ファイルシステムを，Kubernetesの永続ボリューム機能を使用しホストOSと共有することで，OpenTP1の再開始が可能になります。

永続ボリュームの設定については，取扱説明書を参照してください。

8.6.3　TP1/Server Baseのノード追加

Kubernetesのスケール制御を使用したTP1/Server Baseのノード追加はできません。

新たにTP1/Server Baseのノードを追加する場合は，別のPodを作成してください。

ネームサービス機能を使用した場合のノード追加手順の概要を次に示します。

追加するノードの設定方法

TP1/Server Baseのノードを追加する場合，追加するノードでは，既存TP1/Server Baseノードの指定値と一致しないユニークな値を設定する必要があります。

表8‒28　ユニークな値を設定する項目

#

項目

定義オペランド（システム共通定義）

1

OpenTP1識別子

system_id

2

ノード識別子

node_id

3

ネームサービスのポート番号

name_port

上記に従い，新たに作成するPodでOpenTP1システム定義を作成してください。

次に，追加するノードのall_nodeまたはドメイン定義ファイルに，既存のTP1/Server Baseノードのホスト名とポート番号をすべて記載後，必要に応じPod作成前にノード固有の定義を設定してください。

すべての定義設定が完了後，Podを作成します。

既存ノードの設定方法

既存ノードのPodを停止し，all_nodeまたはドメイン定義ファイルに，追加するTP1/Server Baseノードのホスト名とポート番号を設定し，Podを再作成します。

定義の作成はConfigMapでもできます。ConfigMapを使用した定義ファイルの作成方法やPodの作成および停止方法については，取扱説明書を参照してください。

ネームサービス機能を使用するシステムで，ConfigMapを使用してノードを追加する手順を次に示します。

(1)　ネームサービス機能を使用するシステム構成でのノード追加手順

次の構成例を基に，ノードを追加する手順を示します。

(a)　ノード追加前のシステム構成

図8‒13　ノード追加前のOpenTP1システム構成

図8‒14　ノード追加後のOpenTP1システム構成

(b)　ノード追加手順

既存ノードで行う作業

既存ノード（node-A，node-B）のPodを停止する。

システム共通定義のall_nodeオペランドに，追加するTP1/Server Baseのホスト名またはIPアドレス（図node-C）を設定する。

ConfigMap（図①ConfigMap，②ConfigMap）を作成する。

既存ノード（node-A，node-B）のPodを起動する。作成したConfigMapの名称は，起動するPodのspec.volumes.configMap.nameに指定してください。

追加するノードで行う作業

追加するノードのシステム共通定義を作成する。

・ノード識別子，OpenTP1識別子，ネームサービスのポート番号に，既存ノードとは別のOpenTP1システム内でユニークな値を設定する。

・all_nodeオペランドに，既存ノード（node-A，node-B）を設定する。

ConfigMap（図③ConfigMap）を作成する。

ネームサービスのポート番号と同じポート番号をServiceのspec.ports.targetPortに設定し，Service（図④Service）を作成する。

追加するノード（node-C）のPodを起動する。作成したConfigMapの名称は，起動するPodのspec.volumes.configMap.nameに指定してください。

(2)　ネームサービス機能を使用するその他のシステム構成

(a)　all_node_ex定義を使用する場合

all_node_ex定義に宛先ノードを追加する場合は，「8.6.3(1)　ネームサービス機能を使用するシステム構成でのノード追加手順」と同様の方法でホスト名を追加してください。

(b)　ドメイン定義ファイルを使用する場合

ドメイン定義ファイルを使用する場合は，all_nodeのドメイン定義ファイル，およびall_node_exのドメイン定義ファイルに追加を行い，「8.6.3(1)　ネームサービス機能を使用するシステム構成でのノード追加手順」と同様の方法でホスト名を追加してください。

8.6.4　Serviceの作成

コンテナ内のOpenTP1と通信する場合は，Pod間のRPC通信であってもServiceを作成する必要があります。RPC送信元は，Serviceが受付可能なIPアドレス，ポート番号を設定してコネクションを確立します。

ほかのOpenTP1からのコネクション接続を受け付けるポート番号に応じて，Serviceを作成してください。

Serviceの作成方法の詳細は，取扱説明書を参照してください。

(1)　必要なポート数の計算

TP1/Server Baseが使用するポートには，サービス応答で使用するエフェメラルポート（短命ポート）と，スケジューラサービスなどのシステムプロセスが使用するユーザ指定ポートがあります。

サービス応答で使用するエフェメラルポートについては，次に示す計算式で求める必要があります。

(a)　ネームサービスおよびスケジューラダイレクトを使用したRPC

コンテナ内のTP1/Server Baseがサービス応答を受信するためのポート番号には，エフェメラルポートを使用します。

次の計算式で，コンテナ内のTP1/Server Baseに必要なポート数を算出してください。

なお，非応答型のRPCを発行する場合は，エフェメラルポート数の算出とServiceの作成は不要です。

必要なポート数（サービス応答受信用のポート数）
＝（プロセスサービス定義のprc_process_countオペランドに設定した値 ＋ 128）×1.5※

注※

安全係数。1.5〜2.0を推奨します。システムに応じて調整してください。

SUPや，非常駐プロセスなど，サービス応答受信用ポート数は，高負荷などの条件によって必要なポート数が計算式よりも多くなる場合があります。Service作成後，十分なテストを実施してください。

TP1/Server Baseが使用するサービス応答受信用ポート数が，Serviceから公開するポート数を上回った場合，該当するサービス応答でクライアント，サーバ双方にエラーとなることがあります。

(2)　RPCで使用するポートのマッピング

Serviceを作成し，OpenTP1が使用するエフェメラルポートやユーザ指定ポートとServiceから公開するポートをマッピングしてください。

(a)　ネームサービスおよびスケジューラダイレクトを使用したRPC（コンテナ内のTP1/Server BaseからTP1/Server BaseへのRPC）

「8.6.4(1)　必要なポート数の計算」で求めた必要なポート数分のポート名をServiceマニフェストに作成し，Serviceの受信ポート番号とコンテナから公開するTP1/Server Baseのポート番号をマッピングしてください。ポート番号を設定するServiceマニフェストのフィールドについては，「8.5　システム構成と環境設定」中のServiceの説明を参照してください。

システム共通定義にrpc_port_baseオペランドを設定している場合，Serviceの受信ポート番号の設定値は，rpc_port_baseオペランド設定値を基準に，必要な数のポート番号をマッピングしてください。

(b)　スケジューラダイレクトを使用したRPC（コンテナ内のTP1/Server BaseへのRPC）

スケジュールサービス定義のscd_portオペランド，scdmulti定義コマンドの-pオプションに設定したポート数分のServiceを作成してください。

(c)　リモートAPI機能を使用したRPC（コンテナ内のTP1/Server BaseへのRPC）

rapリスナーサービス定義のrap_listen_portオペランドに設定するポート数分のServiceを作成してください。

(d)　TP1/Client/JのRPC応答

コンテナ内のTP1/Client/Jがサービス応答を受信する場合，TP1/Client/J環境定義のdccltcuprcvportオペランドに設定したポート数分のServiceを作成してください。

（例）rpc_port_baseオペランドの設定値が30000，必要なポート数が200個の場合

<service-sample1.yaml>

apiVersion: v1
kind: Service
metadata:
  name: service-sample1
：<略>
 spec:
  ports:
  - name: "tp1-port001"・・ポート名
     protocol: TCP"
     port: 30000
     nodePort: 30000
     targetPort: 30000
  - name: "tp1-port002"・・ポート名
     protocol: TCP"
     port: 30001
     nodePort: 30001
     targetPort: 30001
     ：
   ：<中略>
  - name: "tp1-port099"・・ポート名
     protocol: TCP"
     port: 30098
      nodePort: 30098
     targetPort: 30098
  - name: "tp1-port100"・・ポート名
     protocol: TCP"
     port: 30099
     nodePort: 30099
     targetPort: 30099
  - name: "tp1-port101"・・ポート名
     protocol: TCP"
     port: 30100
     nodePort: 30100
     targetPort: 30100
  - name: "tp1-port102"・・ポート名
     protocol: TCP"
     port: 30101
     nodePort: 30101
     targetPort: 30101
  - name: "tp1-port103"・・ポート名
     protocol: TCP"
     port: 30102
     nodePort: 30102
     targetPort: 30102
     ：
   ：<中略>
  - name: "tp1-port199"・・ポート名
     protocol: TCP"
     port: 30198
     nodePort: 30198
     targetPort: 30198
  - name: "tp1-port200"・・ポート名
     protocol: TCP"
     port: 30199
     nodePort: 30199
     targetPort: 30199

注

spec.ports.nodePort，spec.ports.port：Serviceの受信ポート番号

spec.ports.targetPort：OpenTP1が使用するエフェメラルポートやユーザ指定ポート

注意事項

Kubernetesクラスタ内でTP1/Server Baseが起動するPodを複数起動する場合は，PodごとにServiceの作成が必要になります。Serviceマニフェストに設定するポート番号が，ほかのPodで作成するServiceマニフェストのポート番号と重複する場合は，Serviceの作成に失敗するため，重複しないように調整してください。

（例）dccltcuprcvportオペランドの設定値が30000の場合

<service-sample3.yaml>

apiVersion: v1
kind: Service
metadata:
  name: service-sample3
：<略>
 spec:
  ports:
  - name: "tp1clt-port"・・ポート名
     protocol: TCP"
     port: 30000
     nodePort: 30000
     targetPort: 30000

注

spec.ports.nodePort，spec.ports.port：Serviceの受信ポート番号

spec.ports.targetPort：TP1/Client/J環境定義のdccltcuprcvportオペランドに設定したポート番号

8.7　障害対応

OpenTP1システムプロセスがダウンした場合，OpenTP1が動作していたPodも停止します。その後，KubernetesがPodの停止を検出し，Kubernetesクラスタ内でPodを再起動します。

Pod内で作成・更新されたファイルはPodの停止と共に消失します。そのため，OpenTP1が出力するトラブルシュート情報（トレース，コアファイルなど）は，ホストOS上のディレクトリに格納することを推奨します。ホストOS上で準備するディレクトリについては，取扱説明書を参照してください。

8.8　制限事項

制限事項について説明します。

8.8.1　TP1/Server Baseの制限事項

HAモニタおよびKubernetesの機能を使用した系切り替え構成はサポートしていません。

制限事項については，「表8-11　TP1/Server Baseのサポート機能」および「表8-13　サポートするRPC通信種別（TP1/Server Base-TP1/Server Base）」を参照してください。

8.8.2　TP1/Client/Jの制限事項

(1)　TP1/Client/Jの機能

TP1/Client/Jの機能の制限事項については「表8-12　TP1/Client/Jのサポート機能」および「表8-14　サポートするRPC通信種別（TP1/Client/J-TP1/Server Base）」を参照してください。

(2)　Javaプログラムの種類

Javaアプレットは非対応です。

JavaアプリケーションおよびJavaサーブレットにだけ対応しています。

付録

付録A　TP1/Message Controlで使える通信プロトコル対応製品

OpenTP1で使える通信プロトコルに対応した製品について説明します。これらの製品を使う場合は，TP1/Message ControlとTP1/NET/Libraryが前提となります。

付録A.1　通信プロトコル対応の製品

OpenTP1の通信プロトコル対応の製品は次のとおりです。

(1)　IPネットワーク対応の製品

TP1/NET/TCP/IP

TCP/IPプロトコルで接続されたシステム間で，メッセージの通信をする場合に使う製品です。

コネクション切り替え機能を使うときは，TP1/NET/High Availabilityが前提となります。

TP1/NET/UDP

UDP/IPプロトコルで接続されたシステム間で，メッセージの通信をする場合に使う製品です。

(2)　OSI基本参照モデルのネットワーク対応の製品

TP1/NET/OSI-TP

OSI TPプロトコルに準拠した通信をする場合に使う製品です。

TP1/NET/OSAS-NIF

NIF/OSIプロトコルに準拠した通信をする場合に使う製品です。

TP1/NET/User Agent

OSAS/UAプロトコルに準拠した通信をする場合に使う製品です。

(3)　GUI対応の製品

TP1/NET/XMAP3

XMAP3を使ったメッセージ送受信をする場合に使う製品です。

(4)　SNAネットワーク対応の製品

TP1/NET/SLU - TypeP2

SNAのSLU-TypePプロトコル（二次局）に準拠した通信をする場合に使う製品です。

付録A.2　通信プロトコル対応製品と接続できるシステム

OpenTP1の通信プロトコル対応製品と接続できるシステムの関係を次の表に示します。

表A‒1　OpenTP1の通信プロトコル対応製品の詳細

プロトコル製品

使うプロトコル

主な通信相手プログラム

通信に使う回線

TP1/NET/OSI-TP

OSI TPプロトコル

TP1/NET/OSI-TP

VOS3 XDM/DCCM3（OSAS/TP/DCCM3）

LAN

TP1/NET/OSAS-NIF

NIF/OSIプロトコル

TP1/NET/OSAS-NIF

VOS3 TMS-4V/SP（OSAS/NF/4VSP）

VOS3 XDM/DCCM3（OSAS/UA2/DCCM3）

LAN

TP1/NET/User Agent

OSAS/UAプロトコル

VOS3 TMS-4V/SP（OSAS/UA/4VSP）

VOS3 XDM/DCCM3（OSAS/UA2/DCCM3）

LAN

TP1/NET/TCP/IP

TCP/IPプロトコル

TP1/NET/TCP/IP

TCP/IPプロトコルに対応したプログラム

LAN

TP1/NET/XMAP3

XMAP3

XMAP3

LAN

TP1/NET/SLU - TypeP2

SNAプロトコル（二次局）

SNA（SLU-TypeP）プロトコル（一次局）に対応したプログラム

LAN

TP1/NET/UDP

UDP/IPプロトコル

TP1/NET/UDP

UDP/IPプロトコルに対応したプログラム

LAN

付録B　OpenTP1の関数とコマンドの一覧

OpenTP1で使えるライブラリ関数一覧を，次の表に示します。メッセージキューイング機能（TP1/Message Queue）のライブラリ関数については，マニュアル「TP1/Message Queue 使用の手引」を参照してください。

表B‒1　OpenTP1のライブラリ関数の一覧

機能

ライブラリ関数名

C言語ライブラリ

COBOL-UAP作成用プログラム

リモートプロシジャコール

アプリケーションプログラムの開始

dc_rpc_open

CBLDCRPC('OPEN ')

SPPのサービス開始

dc_rpc_mainloop

CBLDCRSV('MAINLOOP')

遠隔サービスの要求

dc_rpc_call

CBLDCRPC('CALL ')

通信先を指定した遠隔サービスの呼び出し※1

dc_rpc_call_to

−

処理結果の非同期受信

dc_rpc_poll_any_replies

CBLDCRPC('POLLANYR')

エラーが発生した非同期RPC要求の記述子の取得

dc_rpc_get_error_descriptor

CBLDCRPC('GETERDES')

処理結果の受信の拒否

dc_rpc_discard_further_replies

CBLDCRPC('DISCARDF')

非同期応答型RPCの特定応答電文廃棄

dc_rpc_discard_specific_reply

CBLDCRPC('DISCARDS')

サービス関数のリトライ

dc_rpc_service_retry

CBLDCRPC('SVRETRY')

サービス要求のスケジュールプライオリティの設定

dc_rpc_set_service_prio

CBLDCRPC('SETSVPRI')

サービス要求のスケジュールプライオリティの参照

dc_rpc_get_service_prio

CBLDCRPC('GETSVPRI')

サービスの応答待ち時間の参照

dc_rpc_get_watch_time

CBLDCRPC('GETWATCH')

サービスの応答待ち時間の更新

dc_rpc_set_watch_time

CBLDCRPC('SETWATCH')

クライアントUAPのノードアドレスの取得

dc_rpc_get_callers_address

CBLDCRPC('GETCLADR')

ゲートウェイのノードアドレスの取得

dc_rpc_get_gateway_address

CBLDCRPC('GETGWADR')

CUPへの一方通知

dc_rpc_cltsend

CBLDCRPC('CLTSEND ')

アプリケーションプログラムの終了

dc_rpc_close

CBLDCRPC('CLOSE ')

リモートAPI機能

rapリスナーとのコネクション確立

dc_rap_connect

CBLDCRAP('CONNECT ')

CBLDCRAP('CONNECTX')

rapリスナーとのコネクション解放

dc_rap_disconnect

CBLDCRAP('DISCNCT ')

トランザクション制御

トランザクションの開始

dc_trn_begin

CBLDCTRN('BEGIN ')

連鎖モードのコミット

dc_trn_chained_commit

CBLDCTRN('C-COMMIT')

連鎖モードのロールバック

dc_trn_chained_rollback

CBLDCTRN('C-ROLL ')

非連鎖モードのコミット

dc_trn_unchained_commit

CBLDCTRN('U-COMMIT')

非連鎖モードのロールバック

dc_trn_unchained_rollback

CBLDCTRN('U-ROLL ')

現在のトランザクションに関する情報の報告

dc_trn_info

CBLDCTRN('INFO ')

リソースマネジャ接続先選択

dc_trn_rm_select

CBLDCTRN('RMSELECT')

システム運用の管理

運用コマンドの実行

dc_adm_call_command

CBLDCADM('COMMAND ')

ユーザサーバの開始処理完了の報告

dc_adm_complete

CBLDCADM('COMPLETE')

ユーザサーバの状態の報告

dc_adm_status

CBLDCADM('STATUS ')

監査ログの出力

監査ログの出力

dc_log_audit_print

CBLDCADT('PRINT ')

メッセージログの出力

メッセージログの出力

dc_logprint

CBLDCLOG('PRINT ')

ユーザジャーナルの取得

ユーザジャーナルの取得

dc_jnl_ujput

CBLDCJNL('UJPUT ')

ジャーナルデータの編集※2

jnlrput出力ファイルのクローズ

−

CBLDCJUP('CLOSERPT')

jnlrput出力ファイルのオープン

−

CBLDCJUP('OPENRPT ')

jnlrput出力ファイルからジャーナルデータの入力

−

CBLDCJUP('RDGETRPT')

メッセージ送受信

MCF環境のオープン

dc_mcf_open

CBLDCMCF('OPEN ')

MHPのサービス開始

dc_mcf_mainloop

CBLDCMCF('MAINLOOP')

メッセージの受信

dc_mcf_receive

CBLDCMCF('RECEIVE ')

応答メッセージの送信

dc_mcf_reply

CBLDCMCF('REPLY ')

メッセージの送信

dc_mcf_send

CBLDCMCF('SEND ')

メッセージの再送

dc_mcf_resend

CBLDCMCF('RESEND ')

同期型のメッセージ受信

dc_mcf_recvsync

CBLDCMCF('RECVSYNC')

同期型のメッセージ送信

dc_mcf_sendsync

CBLDCMCF('SENDSYNC')

同期型のメッセージ送受信

dc_mcf_sendrecv

CBLDCMCF('SENDRECV')

一時記憶データの受け取り

dc_mcf_tempget

CBLDCMCF('TEMPGET ')

一時記憶データの更新

dc_mcf_tempput

CBLDCMCF('TEMPPUT ')

継続問い合わせ応答の終了

dc_mcf_contend

CBLDCMCF('CONTEND ')

アプリケーションプログラムの起動

dc_mcf_execap

CBLDCMCF('EXECAP ')

アプリケーション情報通知

dc_mcf_ap_info

CBLDCMCF('APINFO ')

UOCへのアプリケーション情報通知

dc_mcf_ap_info_uoc

−

ユーザタイマ監視の設定

dc_mcf_timer_set

CBLDCMCF('TIMERSET')

ユーザタイマ監視の取り消し

dc_mcf_timer_cancel

CBLDCMCF('TIMERCAN')

MHPのコミット

dc_mcf_commit

CBLDCMCF('COMMIT ')

MHPのロールバック

dc_mcf_rollback

CBLDCMCF('ROLLBACK')

MCF環境のクローズ

dc_mcf_close

CBLDCMCF('CLOSE ')

MCF通信サービスの状態取得

dc_mcf_tlscom

CBLDCMCF('TLSCOM ')

コネクションの状態取得

dc_mcf_tlscn

CBLDCMCF('TLSCN ')

コネクションの確立

dc_mcf_tactcn

CBLDCMCF('TACTCN ')

コネクションの解放

dc_mcf_tdctcn

CBLDCMCF('TDCTCN ')

サーバ型コネクションの確立要求の受付状態取得

dc_mcf_tlsln

CBLDCMCF('TLSLN ')

サーバ型コネクションの確立要求の受付開始

dc_mcf_tonln

CBLDCMCF('TONLN ')

サーバ型コネクションの確立要求の受付終了

dc_mcf_tofln

CBLDCMCF('TOFLN ')

アプリケーションに関するタイマ起動要求の削除

dc_mcf_adltap

CBLDCMCF('ADLTAP ')

論理端末の状態取得

dc_mcf_tlsle

CBLDCMCF('TLSLE ')

論理端末の閉塞

dc_mcf_tdctle

CBLDCMCF('TDCTLE ')

論理端末の閉塞解除

dc_mcf_tactle

CBLDCMCF('TACTLE ')

論理端末の出力キュー削除

dc_mcf_tdlqle

CBLDCMCF('TDLQLE ')

DAMファイルサービス

論理ファイルのオープン

dc_dam_open

CBLDCDAM('DCDAMSVC','OPEN')

論理ファイルからブロックの入力

dc_dam_read

CBLDCDAM('DCDAMSVC','READ')

論理ファイルのブロックの更新

dc_dam_rewrite

CBLDCDAM('DCDAMSVC','REWT')

論理ファイルへブロックの出力

dc_dam_write

CBLDCDAM('DCDAMSVC','WRIT')

論理ファイルのクローズ

dc_dam_close

CBLDCDAM('DCDAMSVC','CLOS')

論理ファイルの閉塞

dc_dam_hold

CBLDCDAM('DCDAMSVC','HOLD')

論理ファイルの閉塞の解除

dc_dam_release

CBLDCDAM('DCDAMSVC','RLES')

論理ファイルの状態の参照

dc_dam_status

CBLDCDAM('DCDAMSVC','STAT')

回復対象外DAMファイル使用の開始

dc_dam_start

CBLDCDAM('DCDAMSVC','STRT')

回復対象外DAMファイル使用の終了

dc_dam_end

CBLDCDAM('DCDAMSVC','END ')

物理ファイルの割り当て

dc_dam_create

CBLDCDMB('DCDAMINT','CRAT')

物理ファイルのオープン

dc_dam_iopen

CBLDCDMB('DCDAMINT','OPEN')

物理ファイルからブロックの入力

dc_dam_get

CBLDCDMB('DCDAMINT','GET ')

物理ファイルへブロックの出力

dc_dam_put

CBLDCDMB('DCDAMINT','PUT ')

物理ファイルのブロックの検索

dc_dam_bseek

CBLDCDMB('DCDAMINT','BSEK')

物理ファイルからブロックの直接入力

dc_dam_dget

CBLDCDMB('DCDAMINT','DGET')

物理ファイルへブロックの直接出力

dc_dam_dput

CBLDCDMB('DCDAMINT','DPUT')

物理ファイルのクローズ

dc_dam_iclose

CBLDCDMB('DCDAMINT','CLOS')

TAMファイルサービス

TAMテーブルのオープン※1

dc_tam_open

−

TAMテーブルからレコードの入力

dc_tam_read

CBLDCTAM('FxxR')('FxxU')

TAMテーブルのレコード入力を前提の更新

dc_tam_rewrite

CBLDCTAM('MFY ')('MFYS')('STR ')

TAMテーブルのレコードの更新/追加

dc_tam_write

CBLDCTAM('MFY ')('MFYS')('STR ')

TAMテーブルのレコードの削除

dc_tam_delete

CBLDCTAM('ERS ')('ERSR')

TAMテーブルのレコードの入力取り消し※1

dc_tam_read_cancel

−

TAMテーブルの状態の取得

dc_tam_get_inf

CBLDCTAM('GST ')

TAMテーブルの情報の取得

dc_tam_status

CBLDCTAM('INFO')

TAMテーブルのクローズ※1

dc_tam_close

−

ISTサービス

ISTテーブルのオープン

dc_ist_open

CBLDCIST('DCISTSVC','OPEN')

ISTテーブルからレコードの入力

dc_ist_read

CBLDCIST('DCISTSVC','READ')

ISTテーブルへレコードの出力

dc_ist_write

CBLDCIST('DCISTSVC','WRIT')

ISTテーブルのクローズ

dc_ist_close

CBLDCIST('DCISTSVC','CLOS')

資源の排他制御

資源の排他

dc_lck_get

CBLDCLCK('GET ')

全資源の排他の解除

dc_lck_release_all

CBLDCLCK('RELALL ')

資源名称を指定した排他の解除

dc_lck_release_byname

CBLDCLCK('RELNAME ')

XATMIインタフェース

リクエスト/レスポンス型サービスの呼び出しと応答の受信

tpcall()

TPCALL

リクエスト/レスポンス型サービスの呼び出し

tpacall()

TPACALL

リクエスト/レスポンス型サービスからの非同期応答の受信

tpgetrply()

TPGETRPLY

リクエスト/レスポンス型サービスのキャンセル

tpcancel()

TPCANCEL

会話型サービスとのコネクションの確立

tpconnect()

TPCONNECT

会話型サービスとのコネクションの切断

tpdiscon()

TPDISCON

会話型サービスからのメッセージの受信

tprecv()

TPRECV

会話型サービスへのメッセージの送信

tpsend()

TPSEND

型付きバッファの割り当て

tpalloc()

−※3

型付きバッファの解放

tpfree()

−※3

型付きバッファのサイズの変更

tprealloc()

−※3

型付きバッファの情報の取得

tptypes()

−※3

サービス名の広告

tpadvertise()

TPADVERTISE

サービス名の広告の取り消し

tpunadvertise()

TPUNADVERTISE

サービス関数のテンプレート

tpservice()

TPSVCSTART

サービス関数からのリターン

tpreturn()

TPRETURN

TXインタフェース

トランザクションの開始

tx_begin()

TXBEGIN

トランザクションのコミット

tx_commit()

TXCOMMIT

現在のトランザクションに関する情報の返却

tx_info()

TXINFORM

リソースマネジャ集合のオープン

tx_open()

TXOPEN

トランザクションのロールバック

tx_rollback()

TXROLLBACK

リソースマネジャ集合のクローズ

tx_close()

TXCLOSE

commit_return特性の設定

tx_set_commit_return()

TXSETCOMMITRET

transaction_control特性の設定

tx_set_transaction_control()

TXSETTRANCTL

transaction_timeout特性の設定

tx_set_transaction_timeout()

TXSETTIMEOUT

マルチノード機能※1

OpenTP1ノードのステータス取得の開始

dc_adm_get_nd_status_begin

−

OpenTP1ノードのステータスの取得

dc_adm_get_nd_status_next

−

指定したOpenTP1ノードのステータスの取得

dc_adm_get_nd_status

−

OpenTP1ノードのステータス取得の終了

dc_adm_get_nd_status_done

−

ノード識別子の取得の開始

dc_adm_get_nodeconf_begin

−

ノード識別子の取得

dc_adm_get_nodeconf_next

−

ノード識別子の取得の終了

dc_adm_get_nodeconf_done

−

指定したノード識別子の取得

dc_adm_get_node_id

−

ユーザサーバのステータス取得の開始

dc_adm_get_sv_status_begin

−

ユーザサーバのステータスの取得

dc_adm_get_sv_status_next

−

指定したユーザサーバのステータスの取得

dc_adm_get_sv_status

−

ユーザサーバのステータス取得の終了

dc_adm_get_sv_status_done

−

オンラインテスタの管理

ユーザサーバのテスト状態の報告

dc_uto_test_status

CBLDCUTO('T-STATUS')

性能検証用トレース

ユーザ固有の性能検証用トレースの取得

dc_prf_utrace_put

CBLDCPRF('PRFPUT ')

性能検証用トレース取得通番の通知

dc_prf_get_trace_num

CBLDCPRF('PRFGETN ')

リアルタイム統計情報サービス

任意区間でのリアルタイム統計情報の取得

dc_rts_utrace_put

CBLDCRTS('RTSPUT ')

（凡例）

−：該当しません。

注※1

COBOL-UAP作成用プログラムは使えません。

注※2

ジャーナルデータの編集では，C言語のAPIは使えません。

注※3

XATMIインタフェースでは，該当するCOBOLのAPIはありません。

OpenTP1のコマンド一覧を，次の表に示します。メッセージキューイング機能（TP1/Message Queue）のコマンドについては，マニュアル「TP1/Message Queue 使用の手引」を参照してください。

表B‒2　OpenTP1のコマンド一覧

機能

コマンド名

実行権限

システム管理

OpenTP1のOSへの登録と削除

dcsetup

スーパユーザ

プロセスサービスの再起動および定義の反映

dcreset

OpenTP1管理者

OpenTP1の内部制御用資源の確保と解放

dcmakeup

OpenTP1管理者

OpenTP1の開始

dcstart

OpenTP1管理者

OpenTP1の終了

dcstop

OpenTP1管理者※

システム統計情報の取得開始，終了

dcstats

OpenTP1管理者

マルチノードエリア，サブエリアの開始

dcmstart

OpenTP1管理者

マルチノードエリア，サブエリアの終了

dcmstop

OpenTP1管理者

シナリオテンプレートからのOpenTP1コマンドの実行

dcjcmdex

OpenTP1管理者

システム定義のオペランドの指定

dcjchconf

OpenTP1管理者

ドメイン定義ファイルの更新

dcjnamch

OpenTP1管理者

OpenTP1ノードの状態表示

dcndls

一般ユーザ

共用メモリの状態表示

dcshmls

一般ユーザ

OpenTP1の状態表示

dcstatus

OpenTP1管理者

一時クローズ処理の実行状態の表示

rpcstat

一般ユーザ

OpenTP1の標準出力，標準エラー出力のリダイレクト

prctee

OpenTP1管理者

prcteeプロセスの停止と再開始

prctctrl

スーパユーザ

保守資料の取得

dcrasget

OpenTP1管理者

システム統計情報の標準出力へのリアルタイム編集出力

dcreport

OpenTP1管理者

トラブルシュート情報の削除

dccspool

OpenTP1管理者

システム定義のチェック

dcdefchk

OpenTP1管理者

製品情報の表示

dcpplist

OpenTP1管理者

サーバ管理

サーバの開始

dcsvstart

OpenTP1管理者

サーバの終了

dcsvstop

OpenTP1管理者

サーバの状態表示

prcls

一般ユーザ

ユーザサーバ，およびユーザサーバから起動されるコマンドのサーチパスの表示

prcpathls

一般ユーザ

ユーザサーバ，およびユーザサーバから起動されるコマンドのサーチパスの変更

prcpath

OpenTP1管理者

UAP共用ライブラリのサーチパスの表示

prcdlpathls

一般ユーザ

UAP共用ライブラリのサーチパスの変更

prcdlpath

OpenTP1管理者

OpenTP1のプロセスの強制停止

prckill

OpenTP1管理者

スケジュール管理

スケジュールの状態表示

scdls

一般ユーザ

スケジュールの閉塞

scdhold

OpenTP1管理者

スケジュールの再開始

scdrles

OpenTP1管理者

プロセス数の変更

scdchprc

OpenTP1管理者

プロセスの停止および再起動

scdrsprc

OpenTP1管理者

トランザクション管理

トランザクションの状態表示

trnls

一般ユーザ

トランザクションの強制コミット

trncmt

OpenTP1管理者

トランザクションの強制ロールバック

trnrbk

OpenTP1管理者

トランザクションの強制終了

trnfgt

OpenTP1管理者

トランザクション統計情報の取得開始，終了

trnstics

OpenTP1管理者

未決着トランザクション情報ファイルの削除

trndlinf

OpenTP1管理者

OSI TP通信の未決着トランザクション情報の表示

tptrnls

一般ユーザ

XAリソース管理

XARイベントトレース情報の表示

xarevtr

一般ユーザ

XARファイルの状態表示

xarfills

一般ユーザ

XARトランザクション状態の変更

xarforce

OpenTP1管理者

XAリソースサービスの閉塞

xarhold

OpenTP1管理者

XARファイルの作成

xarinit

OpenTP1管理者

XARトランザクション情報の表示

xarls

一般ユーザ

XAリソースサービスの閉塞解除

xarrles

OpenTP1管理者

XARファイルの削除

xarrm

OpenTP1管理者

排他管理

排他情報の表示

lckls

一般ユーザ

排他制御用テーブルのプール情報の表示

lckpool

一般ユーザ

デッドロック情報ファイルとタイムアウト情報ファイルの削除

lckrminf

OpenTP1管理者

ネーム管理

OpenTP1起動確認，キャッシュ削除

namalivechk

OpenTP1管理者

ドメイン代表スケジュールサービスの登録，削除

namdomainsetup

スーパユーザ

ドメイン構成の変更（システム共通定義使用）

namndchg

OpenTP1管理者

ドメイン構成の変更（ドメイン定義ファイル使用）

namchgfl

OpenTP1管理者

起動通知情報の強制的無効化

namunavl

OpenTP1管理者

OpenTP1のサーバ情報の表示

namsvinf

OpenTP1管理者

RPC抑止リストの操作

namblad

OpenTP1管理者

ノード情報の削除

namndrm

OpenTP1管理者

マネジャノードの変更

nammstr

OpenTP1管理者

ノードリストファイルの作成

namnlcre

OpenTP1管理者

ノードリストファイルの内容表示

namnldsp

一般ユーザ

ノードリストファイルの削除

namnldel

OpenTP1管理者

ノードのオプション情報の変更

namndopt

OpenTP1管理者

メッセージログ管理

メッセージログファイルの内容表示

logcat

一般ユーザ

メッセージログのリアルタイム出力機能の切り替え

logcon

OpenTP1管理者

監査ログ管理

監査ログ機能の環境設定

dcauditsetup

スーパユーザ

OpenTP1ファイル管理

OpenTP1ファイルシステムの初期設定

filmkfs

OpenTP1管理者

OpenTP1ファイルシステムの状態表示

filstatfs

一般ユーザ

OpenTP1ファイルシステムの内容表示

fills

一般ユーザ

OpenTP1ファイルシステムのバックアップ

filbkup

OpenTP1管理者

OpenTP1ファイルシステムのリストア

filrstr

OpenTP1管理者

OpenTP1ファイルグループの変更

filchgrp

OpenTP1管理者

OpenTP1ファイルのアクセス許可モードの変更

filchmod

OpenTP1管理者

OpenTP1ファイル所有者の変更

filchown

OpenTP1管理者

ステータスファイル管理

ステータスファイルの作成，初期設定

stsinit

OpenTP1管理者

ステータスファイルの状態表示

stsls

一般ユーザ

ステータスファイルの内容表示

stsfills

一般ユーザ

ステータスファイルのオープン

stsopen

OpenTP1管理者

ステータスファイルのクローズ

stsclose

OpenTP1管理者

ステータスファイルの削除

stsrm

OpenTP1管理者

ステータスファイルのスワップ

stsswap

OpenTP1管理者

ジャーナル関係のファイル管理

ジャーナル関係のファイルの初期設定

jnlinit

OpenTP1管理者

ジャーナル関係のファイル情報の表示

jnlls

一般ユーザ

再開始中読み込み済ジャーナル関係のファイル情報の表示

jnlrinf

OpenTP1管理者

ジャーナル関係のファイルのオープン

jnlopnfg

OpenTP1管理者

ジャーナル関係のファイルのクローズ

jnlclsfg

OpenTP1管理者

ジャーナル関係の物理ファイルの割り当て

jnladdpf

OpenTP1管理者

ジャーナル関係の物理ファイルの削除

jnldelpf

OpenTP1管理者

ジャーナル関係のファイルのスワップ

jnlswpfg

OpenTP1管理者

ジャーナル関係のファイルの削除

jnlrm

OpenTP1管理者

ジャーナル関係のファイルのステータス変更

jnlchgfg

OpenTP1管理者

ジャーナル関係のファイルのアンロード

jnlunlfg

OpenTP1管理者

自動アンロード機能の制御

jnlatunl

OpenTP1管理者

ジャーナル関係のファイルの回復

jnlmkrf

OpenTP1管理者

ファイル回復用ジャーナルの集積

jnlcolc

OpenTP1管理者

アンロードジャーナルファイルの複写

jnlcopy

OpenTP1管理者

アーカイブ状態の表示

jnlarls

一般ユーザ

アンロードジャーナルファイル，またはグローバルアーカイブアンロードジャーナルファイルの編集出力

jnledit

OpenTP1管理者

アンロードジャーナルファイル，またはグローバルアーカイブアンロードジャーナルファイルのレコード出力

jnlrput

OpenTP1管理者

アンロードジャーナルファイル，およびグローバルアーカイブアンロードジャーナルファイルの時系列ソート，およびマージ

jnlsort

OpenTP1管理者

稼働統計情報の出力

jnlstts

OpenTP1管理者

MCF稼働統計情報の出力

jnlmcst

OpenTP1管理者

リソースグループの接続の強制解除

jnlardis

OpenTP1管理者

DAMファイル管理

物理ファイルの初期設定

damload

OpenTP1管理者

論理ファイルの状態表示

damls

一般ユーザ

論理ファイルの追加

damadd

OpenTP1管理者

論理ファイルの切り離し

damrm

OpenTP1管理者

論理ファイルの論理閉塞

damhold

OpenTP1管理者

論理ファイルの閉塞解除

damrles

OpenTP1管理者

物理ファイルの削除

damdel

OpenTP1管理者

物理ファイルのバックアップ

dambkup

OpenTP1管理者

物理ファイルのリストア

damrstr

OpenTP1管理者

論理ファイルの回復

damfrc

OpenTP1管理者

キャッシュブロック数しきい値の設定

damchdef

OpenTP1管理者

キャッシュブロック数の取得

damchinf

一般ユーザ

TAMファイル管理

TAMファイルの初期作成

tamcre

OpenTP1管理者

TAMテーブルの状態表示

tamls

一般ユーザ

TAMテーブルの追加

tamadd

OpenTP1管理者

TAMテーブルの切り離し

tamrm

OpenTP1管理者

TAMテーブルの論理閉塞

tamhold

OpenTP1管理者

TAMテーブルの閉塞解除

tamrles

OpenTP1管理者

TAMテーブルのロード

tamload

OpenTP1管理者

TAMテーブルのアンロード

tamunload

OpenTP1管理者

TAMファイルの削除

tamdel

OpenTP1管理者

TAMファイルのバックアップ

tambkup

OpenTP1管理者

TAMファイルのリストア

tamrstr

OpenTP1管理者

TAMファイルの回復

tamfrc

OpenTP1管理者

TAM排他資源名称の変換

tamlckls

一般ユーザ

ハッシュ形式のTAMファイルおよびTAMテーブルのシノニム情報の表示

tamhsls

OpenTP1管理者

メッセージキューファイル管理

キューグループの状態表示

quels

一般ユーザ

メッセージキュー用物理ファイルの割り当て

queinit

OpenTP1管理者

メッセージキュー用物理ファイルの削除

querm

OpenTP1管理者

リソースマネジャ管理

リソースマネジャの情報の表示

trnlsrm

一般ユーザ

リソースマネジャの登録

trnlnkrm

OpenTP1管理者

トランザクション制御用オブジェクトファイルの作成

trnmkobj

OpenTP1管理者

トレース管理

UAPトレースの編集出力

uatdump

一般ユーザ

RPCトレースのマージ

rpcmrg

一般ユーザ

RPCトレースの出力

rpcdump

一般ユーザ

共用メモリダンプの出力

usmdump

OpenTP1管理者

リモートAPI管理

リモートAPI機能の実行環境の設定

rapsetup

OpenTP1管理者

リモートAPI機能に使用する定義の自動生成

rapdfgen

OpenTP1管理者

rapリスナーおよびrapサーバの状態表示

rapls

OpenTP1管理者

性能検証用トレース管理

トレース情報ファイルの編集出力

prfed

OpenTP1管理者

トレース情報ファイルの取り出し

prfget

OpenTP1管理者

リアルタイム統計情報サービス管理

RTSログファイルの編集出力

rtsedit

一般ユーザ

リアルタイム統計情報の標準出力への出力

rtsls

一般ユーザ

リアルタイム統計情報サービスの実行環境の設定

rtssetup

OpenTP1管理者

リアルタイム統計情報の設定変更

rtsstats

OpenTP1管理者

OpenTP1解析支援

性能検証用トレース解析

dcalzprf

OpenTP1管理者

コネクション管理

コネクションの状態表示

mcftlscn

一般ユーザ

コネクションの確立

mcftactcn

OpenTP1管理者

コネクションの解放

mcftdctcn

OpenTP1管理者

コネクションの切り替え

mcftchcn

OpenTP1管理者

ネットワークの状態表示

mcftlsln

一般ユーザ

サーバ型コネクションの確立要求の受付開始

mcftonln

OpenTP1管理者

サーバ型コネクションの確立要求の受付終了

mcftofln

OpenTP1管理者

メッセージ多重処理状況の表示

mcftlstrd

OpenTP1管理者

アプリケーション管理

アプリケーションの状態表示

mcfalsap

一般ユーザ

アプリケーションの閉塞

mcfadctap

OpenTP1管理者

アプリケーションの閉塞解除

mcfaactap

OpenTP1管理者

アプリケーション異常終了回数の初期化

mcfaclcap

OpenTP1管理者

アプリケーションに関するタイマ起動要求の表示

mcfalstap

一般ユーザ

アプリケーションに関するタイマ起動要求の削除

mcfadltap

OpenTP1管理者

アプリケーション運用支援

アプリケーションプログラムの起動

mcfuevt

一般ユーザ

論理端末管理

論理端末の状態表示

mcftlsle

一般ユーザ

論理端末の閉塞

mcftdctle

OpenTP1管理者

論理端末の閉塞解除

mcftactle

OpenTP1管理者

論理端末のメッセージキューの先頭スキップ

mcftspqle

OpenTP1管理者

論理端末の出力キュー処理の保留

mcfthldoq

OpenTP1管理者

論理端末の出力キュー処理の保留解除

mcftrlsoq

OpenTP1管理者

論理端末の出力キュー削除

mcftdlqle

OpenTP1管理者

論理端末に関するメッセージジャーナルの取得開始

mcftactmj

OpenTP1管理者

論理端末に関するメッセージジャーナルの取得終了

mcftdctmj

OpenTP1管理者

論理端末に対する継続問い合わせ応答処理の強制終了

mcftendct

OpenTP1管理者

端末代行の開始

mcftstalt

OpenTP1管理者

端末代行の終了

mcftedalt

OpenTP1管理者

アプリケーション起動プロセス用論理端末の未送信メッセージ数の表示

mcfalspsv

一般ユーザ

サービスグループ管理

サービスグループの状態表示

mcftlssg

一般ユーザ

サービスグループの閉塞

mcftdctsg

OpenTP1管理者

サービスグループの閉塞解除

mcftactsg

OpenTP1管理者

サービスグループの入力キュー処理の保留

mcfthldiq

OpenTP1管理者

サービスグループの入力キュー処理の保留解除

mcftrlsiq

OpenTP1管理者

サービスグループの入力キュー削除

mcftdlqsg

OpenTP1管理者

サービス管理

サービスの状態表示

mcftlssv

一般ユーザ

サービスの閉塞

mcftdctsv

OpenTP1管理者

サービスの閉塞解除

mcftactsv

OpenTP1管理者

バッファ管理

バッファグループの使用状況表示

mcftlsbuf

一般ユーザ

マップ管理

マップファイルのパス名変更

dcmapchg

OpenTP1管理者

マップファイルのロード済み資源の表示

dcmapls

OpenTP1管理者

キュー管理

入出力キューの内容複写

mcftdmpqu

一般ユーザ

MCFトレース取得管理

MCFトレースファイルの強制スワップ

mcftswptr

OpenTP1管理者

MCFトレース取得の開始

mcftstrtr

OpenTP1管理者

MCFトレース取得の終了

mcftstptr

OpenTP1管理者

MCF稼働統計情報管理

MCF稼働統計情報の編集

mcfreport

OpenTP1管理者

MCF稼働統計情報の出力

mcfstats

OpenTP1管理者

MCF通信サービス管理

MCF通信サービスの部分停止

mcftstop

OpenTP1管理者

MCF通信サービスの部分開始

mcftstart

OpenTP1管理者

MCF通信サービスの状態参照と開始待ち合わせ

mcftlscom

OpenTP1管理者

ユーザタイマ管理

ユーザタイマ監視の状態表示

mcftlsutm

一般ユーザ

注

プロトコルによって固有のコマンドがあります。プロトコル固有のコマンドについては，マニュアル「OpenTP1 プロトコル」の該当するプロトコル編を参照してください。

注※

dcstopコマンドをUAPから実行する場合は，バックグラウンドで実行してください。

付録C　バージョンアップ時の変更点

各バージョンでの変更点を次に示す分類ごとに示します。

関数，定義およびコマンドの追加と削除

動作の変更

関数，定義およびコマンドのデフォルト値の変更

付録C.1　07-56での変更点

TP1/Server Base 07-56での関数，定義およびコマンドの追加と削除を次の表に示します。

表C‒1　TP1/Server Base 07-56での関数，定義およびコマンドの追加と削除

種類

分類

内容

追加

関数

なし

定義

システム共通定義

ipc_notify_response_hostオペランド

ipc_response_hostオペランド

コマンド

なし

TP1/Server Base 07-56での動作の変更はありません。

TP1/Server Base 07-56でのデフォルト値の変更はありません。

付録C.2　07-53での変更点

TP1/Server Base 07-53での関数，定義およびコマンドの追加と削除を次の表に示します。

表C‒2　TP1/Server Base 07-53での関数，定義およびコマンドの追加と削除

種類

分類

内容

追加

関数

なし

定義

システム共通定義

tp1_monitor_timeオペランド

tp1_monitor_kill_signalオペランド

コマンド

なし

TP1/Server Base 07-53での動作の変更点を次の表に示します。

表C‒3　TP1/Server Base 07-53での動作の変更

分類

内容

定義

トランザクションサービス定義のtrn_extend_functionの指定値に00000002を追加

メッセージ

なし

その他

プロセスサービスを無応答状態から自動で復帰できるよう変更（OpenTP1監視機能）

TP1/Server Base 07-53でのデフォルト値の変更はありません。

付録C.3　07-52での変更点

TP1/Server Base 07-52での関数，定義およびコマンドの追加と削除を次の表に示します。

表C‒4　TP1/Server Base 07-52での関数，定義およびコマンドの追加と削除

種類

分類

内容

追加

関数

なし

定義

システムジャーナルサービス定義

jnl_auto_unload_continueオペランド

システム環境定義

ha_switch_error_retry_countオペランド

ha_switch_error_retry_intervalオペランド

コマンド

dcstatusコマンド

削除

なし

TP1/Server Base 07-52での動作の変更はありません。

TP1/Server Base 07-52でのデフォルト値の変更はありません。

TP1/Message Control 07-52での関数，定義およびコマンドの追加と削除を次の表に示します。

表C‒5　TP1/Message Control 07-52での関数，定義およびコマンドの追加と削除

種類

分類

内容

追加

関数

なし

定義

なし

コマンド

mcfalspsvコマンド

削除

なし

TP1/Message Control 07-52での動作の変更はありません。

TP1/Message Control 07-52でのデフォルト値の変更はありません。

付録C.4　07-51での変更点

TP1/Server Base 07-51での関数，定義およびコマンドの追加と削除を次の表に示します。

表C‒6　TP1/Server Base 07-51での関数，定義およびコマンドの追加と削除

種類

分類

内容

追加

関数

なし

定義

システム共通定義

rpc_close_after_sendオペランド

プロセスサービス定義

prc_hugepage_group_idオペランド

ユーザサービスデフォルト定義

rpc_close_after_sendオペランド

ユーザサービス定義

rpc_close_after_sendオペランド

コマンド

dcshmlsコマンドの-bオプション

scdlsコマンド

-amオプション

-s サーバ名 -mオプション

TP1/Server Base 07-51での動作の変更点を次の表に示します。

表C‒7　TP1/Server Base 07-51での動作の変更

分類

内容

定義

次のオペランドに指定できる値（0〜1945600）を，32ビット版の場合は0〜1945600，64ビット版の場合は0〜67108864に変更

システム環境定義

static_shmpool_size

dynamic_shmpool_size

次のオペランドにLinuxのHugepage機能を指定できるよう変更

システム環境定義

shmpool_attribute

DAMサービス定義

dam_cache_attribute

TAMサービス定義

tam_pool_attri

次のオペランドに65および67を指定できるように変更

システム共通定義

prc_coredump_filter

ユーザサービスデフォルト定義

prc_coredump_filter

ユーザサービス定義

prc_coredump_filter

メッセージ

KFCA00107-Eのerrno値にENOMEMおよびEPERMを追加。

KFCA00880-Iの使用方法のメッセージに次のオプションを追加

-am

-s サーバ名 -m

その他

チェックポイントダンプファイルのサイズの見積もり式

32bitと64bitで見積もり式を変更した。

ステータスファイルのサイズの見積もり式

32bitと64bitでサイズを変更した。

TP1/Server Base 07-51でのデフォルト値の変更はありません。

TP1/Message Control 07-51，TP1/NET/Library 07-51での関数，定義およびコマンドの追加と削除を次の表に示します。

表C‒8　TP1/Message Control 07-51，TP1/NET/Library 07-51での関数，定義およびコマンドの追加と削除

種類

分類

内容

追加

関数

なし

定義

MCFマネジャ定義

mcfmuap定義コマンドの-cオプション

itqretryorderオペランド

コマンド

なし

削除

コマンド

dcmapchgコマンド

--mP

-aP

mcftactcnコマンド

-S

TP1/Message Control 07-51，TP1/NET/Library 07-51での動作の変更点はありません。

TP1/Message Control 07-51，TP1/NET/Library 07-51でのデフォルト値の変更はありません。

付録C.5　07-50での変更点

TP1/Server Base 07-50での関数，定義およびコマンドの追加と削除を次の表に示します。

表C‒9　TP1/Server Base 07-50での関数，定義およびコマンドの追加と削除

種類

分類

内容

追加

定義

システム環境定義

default_value_optionオペランド

チェックポイントダンプサービス定義

cpd_message_id_change_levelオペランド

ジャーナルサービス定義

jnl_message_id_change_levelオペランド

性能検証用トレース定義

prf_buff_sizeオペランド

ユーザサービスデフォルト定義

rpc_rap_inquire_time_checkオペランド

ユーザサービス定義

rpc_rap_inquire_time_checkオペランド

コマンド

filmkfsコマンドの-tオプション

filrstrコマンドの-fオプション

filstatfsコマンドの-Tオプション

TP1/Server Base 07-50での動作の変更点を次の表に示します。

表C‒10　TP1/Server Base 07-50での動作の変更

分類

内容

定義

システム環境定義のserver_countオペランドに指定できる最大値（4096）を，9999に変更

スケジュールサービス定義のscd_server_countオペランドに指定できる最大値（4096）を，8192に変更

メッセージ

KFCA01861-Eの「コマンドで発生したエラー」にVERSIONを追加

KFCA01502-Iの使用方法のメッセージに-fオプションを追加

KFCA01505-Iの使用方法のメッセージに-tオプションを追加

KFCA01551-Iの使用方法のメッセージに-Tオプションを追加

その他

性能検証用トレース情報を格納するバッファサイズを1,024キロバイト（デフォルト値）に変更したことに伴い，静的共用メモリの使用量が928キロバイト増加

TP1/Server Base 07-50でのデフォルト値の変更点を次の表に示します。

表C‒11　TP1/Server Base 07-50でのデフォルト値の変更

分類

内容

定義

システム共通定義のtrn_prf_trace_levelオペランドのデフォルト値を00000001から00000003に変更

システム共通定義のipc_listen_sockbufsetオペランドのデフォルト値をNからYに変更

システム共通定義のfil_prf_trace_delay_timeオペランドのデフォルト値を10から3に変更

ロックサービス定義のlck_deadlock_infoオペランドのデフォルト値をNからYに変更

スケジュールサービス定義のipc_tcpnodelayオペランドのデフォルト値をNからYに変更

ログサービス定義のlog_filesizeオペランドのデフォルト値を1024から10240に変更

性能検証用トレース定義のprf_file_sizeオペランドのデフォルト値を1024から10240に変更

ユーザサービスデフォルト定義のipc_tcpnodelayオペランドのデフォルト値をNからYに変更

その他

性能検証用トレース情報を格納するバッファサイズ（96キロバイト）を1,024キロバイトに変更

TP1/Message Control 07-50，TP1/NET/Library 07-50での関数，定義およびコマンドの追加と削除を次の表に示します。

表C‒12　TP1/Message Control 07-50，TP1/NET/Library 07-50での関数，定義およびコマンドの追加と削除

種類

分類

内容

追加

関数

なし

定義

MCFマネジャ定義

mcfmuap定義コマンドの-cオプション

otqinholdオペランド

errevt_recoveryオペランド

システムサービス共通情報定義

mcf_start_watch_intervalオペランド

コマンド

mcftlscomコマンド

-xオプション

mcfmngrコマンド

-rオプション

mcfcomnコマンド

-rオプション

mcfpsvrコマンド

-rオプション

mcfapliコマンド

-rオプション

mcflinkコマンド

-rオプション

削除

なし

TP1/Message Control 07-50，TP1/NET/Library 07-50での動作の変更点を次の表に示します。

表C‒13　TP1/Message Control 07-50，TP1/NET/Library 07-50での動作の変更

分類

内容

関数

次の関数で，UAPトレースを取得するように変更

dc_mcf_adltap

dc_mcf_tactcn

dc_mcf_tactle

dc_mcf_tdctcn

dc_mcf_tdctle

dc_mcf_tdlqle

dc_mcf_tlscn

dc_mcf_tlscom

dc_mcf_tlsle

dc_mcf_tlsln

dc_mcf_tofln

dc_mcf_tonln

CBLDCMCF('ADLTAP ')

CBLDCMCF('TACTCN ')

CBLDCMCF('TACTLE ')

CBLDCMCF('TDCTCN ')

CBLDCMCF('TDCTLE ')

CBLDCMCF('TDLQLE ')

CBLDCMCF('TLSCN ')

CBLDCMCF('TLSCOM ')

CBLDCMCF('TLSLE ')

CBLDCMCF('TLSLN ')

CBLDCMCF('TOFLN ')

CBLDCMCF('TONLN ')

定義

mcfmsvg定義コマンドの指定数の上限を4096から8192に変更

mcfaalcap定義コマンドの指定数の上限を4096から8192に変更

システムサービス共通情報定義

max_socket_descriptorsオペランドの指定値の上限を2047から3596に変更

max_open_fdsオペランドの指定値の上限を2016から4032に変更

コマンド

次のコマンドで，環境変数DCMCFCMDLOGを設定していなくてもコマンドログを取得するように変更

dcmapchg

mcfstats

mcftactsg

mcftactsv

mcftdctsg

mcftdctsv

mcftdlqsg

mcfthldiq

mcftlscom

mcftrlsiq

mcftstart

mcftstop

その他

エラーイベントの割り当て先がディスクキューの場合，エラーイベントをOpenTP1の再開始時に引き継げるように変更（UAP共通定義（mcfmuap -c）のerrevt_recoveryオペランドで変更前の動作に戻すことができます）

TP1/Message Control 07-50，TP1/NET/Library 07-50でのデフォルト値の変更点を次の表に示します。

表C‒14　TP1/Message Control 07-50，TP1/NET/Library 07-50でのデフォルト値の変更

分類

内容

定義

MCFマネジャ定義

mcfmcomn定義コマンドの-iオプションのデフォルト値（inc）をmsgに変更

mcfmuap定義コマンドの-eオプションのsegsizeオペランドのデフォルト値（512）を32768に変更

mcfmuap定義コマンドの-cオプションのorderオペランドのデフォルト値（function）をcommitに変更

mcfmuap定義コマンドの-cオプションのnoansreplyオペランドのデフォルト値（no）をyesに変更

システムサービス共通情報定義

mcf_prf_trace_levelオペランドのデフォルト値（00000000）を00000001に変更

付録C.6　07-07での変更点

TP1/Server Base 07-07での関数，定義およびコマンドの追加と削除はありません。

TP1/Server Base 07-07での動作の変更点を次の表に示します。

表C‒15　TP1/Server Base 07-07での動作の変更

分類

内容

定義

prcsvpathに指定するパス名の最大文字数（255）を1,023文字に変更

次の実時間監視機能を使用したとき，マイナス誤差による実時間監視満了（指定された時間より早くタイムアウト）が発生しないように変更

ユーザサービス定義

service_expiration_time（サービス関数開始から終了までの実行監視時間）

trn_expiration_time（トランザクションブランチ限界経過時間）

trn_completion_limit_time（トランザクション完了限界時間）

ユーザサービスデフォルト定義

service_expiration_time（サービス関数開始から終了までの実行監視時間）

trn_expiration_time（トランザクションブランチ限界経過時間）

trn_completion_limit_time（トランザクション完了限界時間）

トランザクションサービス定義

trn_expiration_time（トランザクションブランチ限界経過時間）

trn_completion_limit_time（トランザクション完了限界時間）

クライアントサービス定義

trn_expiration_time（トランザクションブランチ限界経過時間）

trn_completion_limit_time（トランザクション完了限界時間）

rapリスナーサービス定義

trn_expiration_time（トランザクションブランチ限界経過時間）

trn_completion_limit_time（トランザクション完了限界時間）

ネットワークコミュニケーション定義

mcfaalcap定義コマンドの-vオプションのntmetim（非トランザクションMHP限界経過時間）

mcfmuap定義コマンドの-uオプションのntmetim（非トランザクションMHP限界経過時間）

ログサービス定義のlog_notify_xxxオペランドをLinux版でも動作するように変更

コマンド

prcpathに指定するパス名の最大文字数（255）を1,023文字に変更

prcpathlsで出力するパス名の最大文字数（255）を1,023文字に変更

dcdefchk -lに次の定義チェックを追加・変更

DCSYSLOGCTYPEにeucが指定されているかどうかのチェックを追加（Linux版だけ）

Linux版のlog_notify_xxxの定義チェックをAIXやHP-UX版と同様のチェックに変更

logconコマンドにコマンドログ取得機能を追加

filmkfsコマンド

-sオプションの指定値の上限を2048から4096に変更

Linux版の-nオプションに指定可能な上限をAIXやHP-UX版と同じ上限（4095）に変更

TP1/Server Base 07-07でのデフォルト値の変更はありません。

付録C.7　07-06での変更点

TP1/Server Base 07-06での関数，定義およびコマンドの追加と削除を次の表に示します。

表C‒16　TP1/Server Base 07-06での関数，定義およびコマンドの追加と削除

種類

分類

内容

追加

関数

なし

定義

システム共通定義

name_service_modeオペランド

name_manager_nodeオペランド

name_remove_down_nodeオペランド

name_node_add_policyオペランド

ネームサービス定義

name_start_watch_timeオペランド

name_start_retry_countオペランド

name_start_retry_intervalオペランド

name_start_errorオペランド

name_sync_ready_timeオペランド

namnlfil定義コマンド

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

scdbufgrp定義コマンドの-e，-s，-pオプション

ユーザサービスデフォルト定義

scd_refresh_processオペランド

scd_process_ctl_optオペランド

scdbufgrp定義コマンドの-s，-pオプション

ユーザサービス定義

scd_refresh_processオペランド

scd_process_ctl_optオペランド

scdbufgrp定義コマンドの-s，-pオプション

コマンド

dcalzprfコマンド

nammstrコマンド

namndoptコマンド

namndrmコマンド

namnlcreコマンド

namnldelコマンド

namnldspコマンド

namsvinfコマンドの-xオプション

削除

定義

MCFアプリケーション定義

mcfaalcap定義コマンドのtypeオペランド

MCFマネジャ定義

mcfmcomn定義コマンドの-r，-cオプション

TP1/Server Base 07-06での動作の変更点を次の表に示します。

表C‒17　TP1/Server Base 07-06での動作の変更

分類

内容

定義

スケジュールサービス定義のscdbufgrp定義コマンドの-nオプションに指定できる最大値（61440）を，31457280に変更

次のオペランドに0を指定できるように変更

システム共通定義

ipc_recvbuf_size

ipc_sendbuf_size

ユーザサービスデフォルト定義

ipc_recvbuf_size

ipc_sendbuf_size

ユーザサービス定義

ipc_recvbuf_size

ipc_sendbuf_size

コマンド

ユーザサーバごとに，共有化したバッファの使用サイズを制限できるようにし，scdlsコマンドの出力形式を変更

メッセージ

なし

その他

性能検証用トレースの情報をCSV形式で出力し，編集できるように変更

メッセージキューサービス定義の定義ファイル数（メッセージキューサーバ数）を0〜1に変更

ネームサービス定義のmax_socket_descriptorsオペランドの算出式を変更

被アーカイブジャーナルノードの不正ジャーナル情報ファイルの最大ファイル数（jnl_dual=N：1,jnl_dual=Y：2）を1に変更

TP1/Server Base 07-06でのデフォルト値の変更はありません。

付録C.8　07-05での変更点

TP1/Server Base 07-05での関数，定義およびコマンドの追加と削除を次の表に示します。

表C‒18　TP1/Server Base 07-05での関数，定義およびコマンドの追加と削除

種類

分類

内容

追加

関数

dc_trn_rm_select

CBLDCTRN('RMSELECT')

定義

システム共通定義

prc_coredump_filterオペランド

rapリスナーサービス定義

scs_prf_trace_level

rap_extend_function

ユーザサービスデフォルト定義

prc_coredump_filterオペランド

rap_extend_functionオペランド

trnrmid定義コマンドの-kオプション

ユーザサービス定義

prc_coredump_filterオペランド

rap_extend_functionオペランド

trnrmid定義コマンドの-kオプション

コマンド

なし

削除

なし

TP1/Message Control 07-05，TP1/NET/Library 07-05での関数，定義およびコマンドの追加と削除を次の表に示します。

表C‒19　TP1/Message Control 07-05，TP1/NET/Library 07-05での関数，定義およびコマンドの追加と削除

種類

分類

内容

追加

関数

COMMIT − MHPのコミット

定義

MCFマネジャ定義

mcfmuap定義コマンドの-cオプション

commitdmlオペランド

noansreplyオペランド

mcfmuap定義コマンドの-rオプション

reschedulecntオペランド

rescheduleintオペランド

reschedulelogオペランド

MCFアプリケーション定義

mcfaalcap定義コマンドの-dオプション

reschedulecntオペランド

rescheduleintオペランド

reschedulelogオペランド

コマンド

mcftlsbufコマンド

-mオプション

-rオプション

mcftlsleコマンド

-mオプション

-rオプション

削除

なし

TP1/Server Base 07-05での動作の変更点はありません。

TP1/Message Control 07-05，TP1/NET/Library 07-05での動作の変更点を次に示します。

表C‒20　TP1/Message Control 07-05，TP1/NET/Library 07-05での動作の変更

分類

内容

定義

なし

コマンド

なし

メッセージ

KFCA10365-I

出力情報に最大未送信メッセージ数の情報を追加

KFCA10366-I

出力情報に最大バッファ使用数の情報を追加

KFCA10505-I，KFCA10509-I

出力情報に-mオプションと-rオプションを追加

TP1/Server Base 07-05でのデフォルト値の変更はありません。

TP1/Message Control 07-05，TP1/NET/Library 07-05でのデフォルト値の変更はありません。

付録C.9　07-04での変更点

TP1/Server Base 07-04での関数，定義およびコマンドの追加と削除を次の表に示します。

表C‒21　TP1/Server Base 07-04での関数，定義およびコマンドの追加と削除

種類

分類

内容

追加

関数

なし

定義

チェックポイントダンプサービス定義

jnl_cdskip_limitオペランド

jnl_cdskip_msgオペランド

プロセスサービス定義

prc_take_over_dlpathオペランド※

コマンド

trncmtコマンド

-qオプション

trnrbkコマンド

-qオプション

trnfgtコマンド

-qオプション

prcdlpathコマンド※

prcdlpathlsコマンド※

削除

なし

注※

ご使用のOSがWindowsの場合はサポートしていません。

TP1/Server Base 07-04での動作の変更点を次の表に示します。

表C‒22　TP1/Server Base 07-04での動作の変更

分類

内容

定義

なし

コマンド

なし

メッセージ

KFCA00974-I，KFCA00976-I，KFCA00977-I

出力情報に-qオプションを追加

TP1/Server Base 07-04でのデフォルト値の変更はありません。

付録C.10　07-03での変更点

TP1/Server Base 07-03での関数，定義およびコマンドの追加と削除を次の表に示します。

表C‒23　TP1/Server Base 07-03での関数，定義およびコマンドの追加と削除

種類

分類

内容

追加

関数

なし

定義

システム共通定義

fil_prf_trace_delay_timeオペランド

fil_prf_trace_optionオペランド

jnl_prf_event_trace_levelオペランド

uap_trace_file_putオペランド

ロックサービス定義

lck_prf_trace_levelオペランド

ネームサービス定義

name_cache_validity_timeオペランド

rapリスナーサービス定義

ipc_sockctl_highwater

ipc_sockctl_watchtime

JNL性能検証用トレース定義

LCK性能検証用トレース定義

リアルタイム取得項目定義

rts_mcf_ap_scd_stayオペランド

rts_mcf_ap_usr_srvcオペランド

rts_mcf_in_msg_scd_waitオペランド

rts_mcf_out_msg_norm_scd_waitオペランド

rts_mcf_out_msg_prio_scd_waitオペランド

rts_mcf_out_msg_resp_scd_waitオペランド

rts_mcf_out_msg_sync_scd_waitオペランド

rts_mcf_que_scd_wait_numオペランド

ユーザサービスデフォルト定義

uap_trace_file_putオペランド

ユーザサービス定義

uap_trace_file_putオペランド

コマンド

filstatfsコマンド

-Sオプション

prctctrlコマンド

prfedコマンド

-vオプション

prfgetコマンド

-fオプションの指定値に_mc，_fl，_jl，_lkを追加

uatdumpコマンド

-fオプション

削除

なし

TP1/Message Control 07-03，TP1/NET/Library 07-04での関数，定義およびコマンドの追加と削除を次の表に示します。

表C‒24　TP1/Message Control 07-03，TP1/NET/Library 07-04での関数，定義およびコマンドの追加と削除

種類

分類

内容

追加

関数

なし

定義

なし

コマンド

mcfalstapコマンド

mcftlsutmコマンド

削除

なし

TP1/Server Base 07-03での動作の変更点を次の表に示します。

表C‒25　TP1/Server Base 07-03での動作の変更

分類

内容

定義

システム共通定義

all_nodeオペランドにサービス情報優先度指定機能を指定できるように変更

name_domain_file_useオペランドで使用有無を決定するドメイン定義ファイルに，優先選択ノードの定義ファイルを追加

性能検証用トレース取得サービスの稼働数，および関連する定義を変更

コマンド

OpenTP1の標準出力，標準エラー出力をリダイレクトするprcteeプロセスを停止・再開始できるよう変更

次のコマンドの出力形式を変更

namsvinf

OpenTP1ファイルシステムのユーザ領域情報として使用中領域と未使用領域（空き領域）の一覧を表示できるよう変更

トレース情報ファイルの編集結果をcsv形式で出力できるように変更

メッセージ

KFCA26954-W，KFCA26956-W，KFCA26965-E，KFCA27790-W

出力情報に，送信元IPアドレスと送信元ポート番号の情報を追加

その他

次に示すイベントトレース情報を取得するように変更

FILイベントトレース

JNL性能検証用トレース

LCK性能検証用トレース

プロセスをアボートしなくてもUAPトレースを取得できるように変更

静的共用メモリの算出式を変更

共用メモリプールのサイズの算出式を変更

監視イベントに次のイベントを追加

OpenTP1サービス開始

OpenTP1サービス停止

UNIXのメッセージ送受信関数で使用する資源の見積もり式で，次の資源の被アーカイブノードの見積もり式を変更

メッセージID

OpenTP1のすべてのメッセージのうちの最大待ち合わせメッセージ数

TP1/Message Control 07-03，TP1/NET/Library 07-04での動作の変更点を次の表に示します。

表C‒26　TP1/Message Control 07-03，TP1/NET/Library 07-04での動作の変更

分類

内容

定義

mcftalcle定義コマンドの-mオプションに0を指定，または指定を省略した場合の解釈値を，無制限から65535に変更

次の定義コマンドで，-jオプションの指定値の上限を131072から4000000に変更

mcfmcomn

mcfmuap

mcftcomn

その他

MCFダンプファイルの出力上限数を99から3に変更

アプリケーションに関するタイマ起動要求の状態を表示できるように変更

ユーザタイマ監視の状態を表示できるように変更

TP1/Server Base 07-03でのデフォルト値の変更点を次の表に示します。

表C‒27　TP1/Server Base 07-03でのデフォルト値の変更

分類

内容

定義

トランザクションサービス定義

thread_stack_sizeオペランドについて，AIX版のuCosminexus TP1/Server Base(64)を使用している場合のデフォルト値を65536に変更

TAMサービス定義

tam_pool_attriオペランドのデフォルト値を次のとおり変更

・HP-UXまたはSolarisの場合：fixed

・AIX，LinuxまたはWindowsの場合：free

TP1/Message Control 07-03，TP1/NET/Library 07-04での関数，定義およびコマンドのデフォルト値の変更はありません。

付録C.11　07-02での変更点

TP1/Server Base 07-02での関数，定義およびコマンドの追加と削除を次の表に示します。

表C‒28　TP1/Server Base 07-02での関数，定義およびコマンドの追加と削除

種別

分類

内容

追加

関数

dc_log_audit_print

CBLDCADT('PRINT')

定義

システム共通定義

nam_prf_trace_levelオペランド

jnl_fileless_optionオペランド

XAリソースサービス定義

xar_prf_trace_levelオペランド

ジャーナルサービス定義

jnl_watch_timeオペランド

システムジャーナルサービス定義

jnl_max_file_dispersionオペランド

jnl_min_file_dispersionオペランド

jnladdpf定義コマンドの-eオプション

ログサービス定義

log_audit_outオペランド

log_audit_pathオペランド

log_audit_sizeオペランド

log_audit_countオペランド

log_audit_messageオペランド

rapリスナーサービス定義

rap_term_disconnect_timeオペランド

rap_stay_watch_timeオペランド

rap_stay_warning_intervalオペランド

log_audit_out_suppressオペランド

log_audit_messageオペランド

watch_timeオペランド

rapクライアントマネジャサービス定義

log_audit_out_suppressオペランド

log_audit_messageオペランド

性能検証用トレース定義

prf_trace_backupオペランド

XAR性能検証用トレース定義

リアルタイム統計情報サービス定義

rts_log_file_backupオペランド

リアルタイム取得項目定義

rts_scd_svc_scd_waitオペランド

rts_scd_svc_using_bufオペランド

rts_scd_parallelオペランド

ユーザサービスデフォルト定義

log_audit_out_suppressオペランド

log_audit_messageオペランド

scdsvcdef定義コマンド

ユーザサービス定義

log_audit_out_suppressオペランド

log_audit_messageオペランド

serviceオペランドの指定値に「UAP共用ライブラリ名」を追加

scdsvcdef定義コマンド

コマンド

dcauditsetupコマンド

dcsetupコマンド

-jオプション

dcstartコマンド

-bオプション

dcstopコマンド

-qオプション

prfgetコマンド

-fオプションの指定値に_nm，_xr，_prを追加

scdlsコマンド

-aeオプション

-eオプション

-tオプション

削除

定義

ユーザサービスデフォルト定義

thdlock_sleep_timeオペランド

ユーザサービス定義

thdlock_sleep_timeオペランド

TP1/Message Control 07-02，TP1/NET/Library 07-03での関数，定義およびコマンドの追加と削除を次の表に示します。

表C‒29　TP1/Message Control 07-02，TP1/NET/Library 07-03での関数，定義およびコマンドの追加と削除

種別

分類

内容

追加

関数

dc_mcf_adltap

dc_mcf_tactcn

dc_mcf_tactle

dc_mcf_tdctcn

dc_mcf_tdctle

dc_mcf_tdlqle

dc_mcf_tlscn

dc_mcf_tlscom

dc_mcf_tlsle

dc_mcf_tlsln

dc_mcf_tofln

dc_mcf_tonln

CBLDCMCF('ADLTAP ')

CBLDCMCF('TACTCN ')

CBLDCMCF('TACTLE ')

CBLDCMCF('TDCTCN ')

CBLDCMCF('TDCTLE ')

CBLDCMCF('TDLQLE ')

CBLDCMCF('TLSCOM ')

CBLDCMCF('TLSCN ')

CBLDCMCF('TLSLE ')

CBLDCMCF('TLSLN ')

CBLDCMCF('TOFLN ')

CBLDCMCF('TONLN ')

定義

MCFマネジャ共通定義

mcfmcomn定義コマンドの-iオプション

コマンド

mcftlssgコマンド

-mオプション

mcftlscomコマンド

-wオプション

-tオプション

削除

なし

TP1/Server Base 07-02での動作の変更点を次の表に示します。

表C‒30　TP1/Server Base 07-02での動作の変更

分類

内容

定義

システム共通定義，およびシステムサービス共通情報定義

thdlock_sleep_timeオペランドの最小値（15）を1に変更

プロセスサービス定義

prc_prf_traceオペランドがY（デフォルト）の場合に取得されるイベントを追加

トランザクションサービス定義

trn_tran_process_countオペランドの指定値の範囲（1〜8192）に，MCFサービスを使用する場合の指定範囲（32ビットの場合 1〜7484，64ビットの場合 1〜6893）を追加

コマンド

dcdefchkコマンド

log_syslog_elistオペランド，およびlog_syslog_elist_rintオペランドの論理チェック（LOG-0011）を変更

DCSYSLOGCTYPEの論理チェック（LOG-0011）を追加

監査ログ関連オペランドの論理チェック（LOG-0013およびLOG-0014）を追加

dcrasgetコマンド

Linuxの場合，-cオプション指定時に取得するファイルの拡張子を.Zから.gzに変更

ジャーナルファイルレスモードで次に示すコマンドを実行したとき，KFCA01141-Eメッセージを出力するように変更

jnlls

jnlunlfg

jnlchgfg

jnlopnfg

jnlclsfg

jnlswpfg

jnlrinf

jnlarls

jnlatunl

jnladdpf

jnldelpf

usmdumpコマンド

Linuxの場合，共用メモリダンプファイルの拡張子を.Zから.gzに変更

その他

damrstrコマンドに指定したバックアップファイルのサイズをチェックして，不正なバックアップファイルを検知した場合は，KFCA02512-Eメッセージを出力するように変更

tamrstrコマンドに指定したリストア元ファイルのサイズをチェックして，不正なリストア元ファイルを検知した場合は，KFCA26209-Eメッセージを出力するように変更

Linux（IPF）の場合，syslogメッセージの出力に失敗した場合にリトライできるように変更

Linuxの場合，共用メモリダンプファイルの拡張子を.Zから.gzに変更

次に示すイベントトレース情報を取得するように変更

XAR性能検証用トレース

NAMイベントトレース

プロセスサービスのイベントトレース

rapクライアントからの要求が，rapサーバ割り当て待ちでrapリスナーサービス定義のrap_stay_warning_intervalオペランドの指定値を超えて滞留した場合に，KFCA27764-Wメッセージを出力するように変更

リアルタイム統計情報サービスの開始時に，RTSログファイルのバックアップファイルを作成するように変更

TP1/Message Control 07-02，TP1/NET/Library 07-03での動作の変更点を次の表に示します。

表C‒31　TP1/Message Control 07-02，TP1/NET/Library 07-03での動作の変更

分類

内容

その他

OpenTP1終了時，一定時間が経過しても入力キューにメッセージが残っている場合，サービスグループごとにKFCA16532-Iメッセージを出力し，残っているメッセージの処理が完了したときにKFCA16533-Iメッセージを出力するように変更

OpenTP1終了時，一定時間が経過しても出力キューにメッセージが残っている場合，論理端末ごとにKFCA16534-Iメッセージを出力し，残っているメッセージの処理が完了したときにKFCA16535-Iメッセージを出力するように変更

OpenTP1終了時，一定時間が経過してもプロトコル制御の終了準備を待ち合わせている場合，MCF通信サービスごとにKFCA16536-Iメッセージを出力し，プロトコル制御の終了準備処理が完了したときにKFCA16537-Iメッセージを出力するように変更

MHPサービス関数動的ローディング機能を使用できるように変更

キューを監視している場合，および相手システムからの応答メッセージ受信を待ち合わせている場合に，監視処理中および処理完了時にログメッセージを出力することで，処理状況を把握できるように変更

次の操作を，ライブラリ関数でできるよう変更

コネクションの状態表示，確立，および解放

サーバ型コネクションの確立要求の状態表示，および受付開始・終了

アプリケーションに関するタイマ起動要求の削除

論理端末の状態表示，閉塞，閉塞解除，および出力キューの削除

MCF通信サービスの状態取得

最大未処理受信メッセージ数を表示できるように変更

TP1/Server Base 07-02でのデフォルト値の変更点を次の表に示します。

表C‒32　TP1/Server Base 07-02でのデフォルト値の変更

分類

内容

定義

システム共通定義

client_uid_checkオペランドのデフォルト値（Y）をAIX，LinuxまたはSolarisの場合はNに変更（HP-UXまたはWindowsの場合はY）

TP1/Message Control 07-02，TP1/NET/Library 07-03での関数，定義およびコマンドのデフォルト値の変更はありません。

付録C.12　07-01での変更点

TP1/Server Base 07-01での関数，定義およびコマンドの追加と削除を次の表に示します。

表C‒33　TP1/Server Base 07-01での関数，定義およびコマンドの追加と削除

種別

分類

内容

追加

関数

なし

定義

ネームサービス定義

name_nodeid_check_messageオペランド

XAリソースサービス定義

xar_msdtc_useオペランド

コマンド

dcpplistコマンド

dcdefchkコマンド

-lオプション

-cオプション

-wオプション

-eオプション

xarinitコマンド

-sオプション

xarlsコマンド

-rオプション

削除

なし

TP1/Message Control 07-01，TP1/NET/Library 07-01での関数，定義およびコマンドの追加と削除を次の表に示します。

表C‒34　TP1/Message Control 07-01，TP1/NET/Library 07-01での関数，定義およびコマンドの追加と削除

種別

分類

内容

追加

関数

なし

定義

ユーザサービス定義

mcf_prf_traceオペランド

MCFマネジャ定義

mcfmsvg定義コマンド

MCFアプリケーション定義

mcfaalcap定義コマンドの-Nオプションのmodelnameオペランド

MCF性能検証用トレース定義

prf_file_sizeオペランド

prf_file_countオペランド

システムサービス情報定義

mcf_prf_traceオペランド

システムサービス共通情報定義

mcf_prf_trace_levelオペランド

DCMCFQUEBAKオペランド

コマンド

mcftlslnコマンド

mcftoflnコマンド

mcftonlnコマンド

削除

なし

TP1/Server Base 07-01での動作の変更点を次の表に示します。

表C‒35　TP1/Server Base 07-01での動作の変更

分類

内容

定義

リアルタイム取得項目定義

rts_jnl_readオペランドで取得する情報（「回数」）を，「回数，最大時間，最小時間，平均時間」に変更

rts_jnl_writeオペランドで取得する情報（「回数」）を，「回数，最大時間，最小時間，平均時間」に変更

コマンド

xarevtrコマンド

.NET Frameworkからの接続に対して「アプリケーションサーバ名称」を表示

「アプリケーションサーバXID情報」の表示（GTRIDの先頭28バイト以内）をGTRIDの先頭64バイト以内に拡大

「アプリケーションサーバXID情報」の表示（BQUALの先頭28バイト以内）をBQUALの先頭64バイト以内に拡大

xarforceコマンド

-tオプションに指定する「OpenTP1トランザクションID」の最大文字数（56文字）を80文字に拡大

-uオプションに指定する「クライアントトランザクションID」の最大文字数（256文字）を280文字に拡大

xarlsコマンド

表示する「OpenTP1トランザクションID」の最大文字数（56文字）を80文字に拡大

表示する「クライアントトランザクションID」の最大文字数（256文字）を280文字に拡大

rtseditコマンド

-mオプションの出力結果にRTSログファイルのバージョン情報を追加

xarfillsコマンド

出力結果に「格納可能RI長」を追加

xarlsコマンド

-cオプションの出力結果に「DID情報」，「ノードID情報」および「MSDTC連携で使用する回復情報」を追加

その他

rapリスナーおよびRTSSPP（リアルタイム統計情報サービスの拡張機能）に対して，次に示すコマンドが有効にならないように変更

scdchprc，scdhold，scdrles，scdrsprc

XAリソースサービスを使用したRPCコールにデータ圧縮機能を追加

TP1/Message Control 07-01，TP1/NET/Library 07-01での動作の変更点を次の表に示します。

表C‒36　TP1/Message Control 07-01，TP1/NET/Library 07-01での動作の変更

分類

内容

その他

次の指定をしたときに，MCF性能検証用トレース情報を取得するように変更

システム共通定義のprf_traceオペランドにYを指定，または指定を省略

システムサービス共通情報定義のmcf_prf_trace_levelオペランドに00000001を指定

MCF通信プロセス識別子を表示できるように変更

サーバ型コネクションの確立要求の受付開始・終了を，手動でできるように変更

TP1/Server Base 07-01，TP1/Message Control 07-01，およびTP1/NET/Library 07-01での関数，定義およびコマンドのデフォルト値の変更はありません。

付録C.13　07-00での変更点

TP1/Server Base 07-00での関数，定義およびコマンドの追加と削除を次の表に示します。

表C‒37　TP1/Server Base 07-00での関数，定義およびコマンドの追加と削除

種別

分類

内容

追加

関数

dc_rts_utrace_put

CBLDCRTS('RTSPUT ')

定義

システム環境定義

user_command_online_tp1mngr_idオペランド※1

システム共通定義

dcstart_wakeup_retry_countオペランド

ipc_listen_sockbufsetオペランド

ユーザサービスデフォルト定義

ipc_listen_sockbufsetオペランド

ユーザサービス定義

ipc_listen_sockbufsetオペランド

ネームサービス定義

name_audit_confオペランドの指定可能値に2を追加

name_audit_watch_timeオペランド

name_rpc_control_listオペランド

トランザクションサービス定義

trn_completion_limit_timeオペランド

trn_rcv_open_close_scopeオペランド

trnstring定義コマンドの-sオプション

rapリスナーサービス定義

rap_message_id_change_levelオペランド

リアルタイム統計情報サービス定義

リアルタイム取得項目定義

コマンド

dcdefchkコマンド

dcsvgdefコマンド

-tオプション

nambladコマンド

ntbtailコマンド※2

rtseditコマンド

rtslsコマンド

rtssetupコマンド

rtsstatsコマンド

tp1consoleコマンド※2

削除

なし

注※1

ご使用のOSがLinuxまたはWindowsの場合はサポートしていません。

注※2

ご使用のOSがWindows 07-00-03以降の場合だけサポートしています。機能の詳細については，マニュアル「OpenTP1 使用の手引 Windows(R)編」を参照してください。

TP1/Message Control 07-00，TP1/NET/Library 07-00での関数，定義およびコマンドの追加と削除を次の表に示します。

表C‒38　TP1/Message Control 07-00，TP1/NET/Library 07-00での関数，定義およびコマンドの追加と削除

種別

分類

内容

追加

関数

なし

定義

MCFマネジャ定義

mcfmuap定義コマンドの-cオプションのorderオペランド

環境変数DCMCFCMDLOG

コマンド

なし

削除

関数

なし

定義

システムサービス構成定義

mrs_confオペランド

MCFマネジャ定義

mcfmcomn定義コマンドの-rオプション

mcfmcomn定義コマンドの-tオプションのdelayedオペランド

mcfmcomn定義コマンドの-cオプション

mcfmrclnt定義コマンド

mcfmrerun定義コマンド

MCFアプリケーション定義

mcfaalcap定義コマンドの-gオプションのtypeオペランド

リモートMCFマネジャ定義

mcfrcomn定義コマンド

mcfrserv定義コマンド

システムサービス情報定義

criticalオペランド

コマンド

なし

TP1/Server Base 07-00での動作の変更点を次の表に示します。

表C‒39　TP1/Server Base 07-00での動作の変更

分類

内容

関数

メッセージログファイルにメッセージログとして出力する文字列の長さの上限値（222バイト）を，Linuxの場合は444バイトに変更した。

-dc_logprint

CBLDCLOG('PRINT ')

定義

システム環境定義

server_countオペランドの最大値（2048）を4096に拡大※1

コマンド

jnlcolcコマンド，jnlcopyコマンド，jnleditコマンド，jnlrputコマンドおよびjnlsortコマンド

指定できるアンロードファイルの数（64個）を256個に拡大

jnleditコマンド

出力結果に「MCFレコード作成日時」および「トランザクションブランチ開始日時」を追加

prcteeコマンド

メッセージの出力先（/tmp）を$DCDIR/spoolに変更※2

エラーメッセージ出力先（/tmp/betran.log）を$DCDIR/spool/.prctee.logに変更※2

xarevtrコマンド

出力結果に，Cosminexus V6.5以降からの接続に対して「アプリケーションサーバ名称」を表示

メッセージ

KFCA00107-E

詳細情報を，モジュール名称からOpenTP1ファイルシステム名に変更

KFCA00854-E

「格納できなかったメッセージサイズ」の情報を追加

その他

指定可能なホスト名長（63文字）を255文字に拡大

JP1/AJS2 - Scenario Operation用サンプルシナリオテンプレートのコマンド優先度（「なし」）を「3」に変更

UNIXドメイン通信ファイルのアクセスモードの設定（755）を777に変更※2

日本語UTF-8メッセージ（LANG ja_JP.UTF-8）に対応※2

注※1

ご使用のOSがLinuxの場合はサポートしていません。

注※2

ご使用のOSがLinuxの場合だけサポートしています。

TP1/Message Control 07-00，TP1/NET/Library 07-00での動作の変更点を次の表に示します。

表C‒40　TP1/Message Control 07-00，TP1/NET/Library 07-00での動作の変更

分類

内容

定義

MCF通信構成定義

mcftenv定義コマンドの-aオプションの構文要素（〈1〜8文字の識別子〉）を〈1〜8文字の英数字〉に変更

コマンド

次に示すコマンドに，コマンドログ取得機能を追加

mcfaactap，mcfaclcap，mcfadctap，mcfadltap，mcfstats，mcftactcn，mcftactle，mcftactmj，mcftactsg，mcftactsv，mcftchcn，mcftdctcn，mcftdctle，mcftdctmj，mcftdctsg，mcftdctsv，mcftdlqle，mcftdlqsg，mcftdmpqu，mcfthldiq，mcfthldoq，mcftrlsiq，mcftrlsoq，mcftspqle，mcftstart，mcftstop，mcfuevt

TP1/Server Base 07-00での関数，定義およびコマンドのデフォルト値の変更はありません。

TP1/Message Control 07-00，TP1/NET/Library 07-00でのデフォルト値の変更点を次の表に示します。

表C‒41　TP1/Message Control 07-00，TP1/NET/Library 07-00でのデフォルト値の変更

分類

内容

定義

MCF通信構成定義

mcfttrc定義コマンドのdiskオペランドのデフォルト値（no）をyesに変更

付録D　リモートプロシジャコールの処理の概要

ここでは，使用する機能や状況別に，リモートプロシジャコールの処理の概要について説明します。ここで説明する処理の概要は，すべてキュー受信型のリモートプロシジャコールについての説明です。

なお，説明中のローカルキャッシュとは，ネームサービスが自OpenTP1で起動しているサーバのサービス情報を管理する領域を指します。また，グローバルキャッシュとは，ネームサービスが他ノードで起動しているサーバのサービス情報を管理する領域を指します。

アプリケーションプログラムの作成方法については，マニュアル「OpenTP1 プログラム作成の手引」，説明中の関数の文法については，マニュアル「OpenTP1 プログラム作成リファレンス C言語編」，またはマニュアル「OpenTP1 プログラム作成リファレンス COBOL言語編」を参照してください。

付録D.1　自ノードへのリモートプロシジャコールの処理の概要

自ノードへのリモートプロシジャコールの処理の概要について，次の図に示します。

図D‒1　自ノードへのリモートプロシジャコールの処理の概要

図で示したTP1-Xの処理の流れについて，次に説明します。番号は，図中の番号と対応しています。

dc_rpc_call関数の引数で指定されたサービスグループ名を検索キーに，該当するサービス情報がローカルキャッシュとグローバルキャッシュに登録されているかを確認します。

該当するサービス情報がローカルキャッシュにだけ登録されていたため，ローカルキャッシュに登録されているサービス情報だけをサービス要求元UAPへ返します。

自ノードで起動しているUAPのサービス情報しか取得できなかったため，TP1-Xは自ノードで起動しているサービス要求先UAP（サーバUAP1）を選択します。

自OpenTP1内のUAPへのサービス要求の場合，スケジュールサービスを経由しないで，サービス要求先UAP（サーバUAP1）のメッセージキューに対して，直接サービス要求を登録します。

サービス要求が登録されたサービス要求先UAP（サーバUAP1）では，メッセージキューからサービス要求を取り出します。

サービス関数を実行します。

サービス関数の実行後，サービス要求を行ったサービス要求元UAPに対して，サービス要求先UAP（サーバUAP1）から，直接応答メッセージを送信します。

付録D.2　他ノードへのリモートプロシジャコールの処理の概要

他ノードへのリモートプロシジャコールの処理の概要について，次の図に示します。

図D‒2　他ノードへのリモートプロシジャコールの処理の概要

図で示した処理の流れについて，次に説明します。番号は，図中の番号と対応しています。なお，1.〜3.および5.〜8.はTP1-Xの処理，4.はTP1-A，TP1-B，TP1-Cの処理，9.〜12.はTP1-Cの処理についての説明です。

dc_rpc_call関数の引数に指定されたサービスグループ名を検索キーに，該当するサービス情報がローカルキャッシュとグローバルキャッシュに登録されているかを確認します。

該当するサービス情報が存在しなければ，ネームサービスにサービス情報の検索要求を送信します。

該当するサービス情報がローカルキャッシュ，グローバルキャッシュに存在しても，次の条件を満たす場合は，グローバルキャッシュに存在するサービス情報をいったん削除したあと，ネームサービスへサービス情報の検索要求を送信します。

該当するサービス情報がグローバルキャッシュに存在し，該当するサービス情報の有効時間※1が経過した場合。

サービス要求先UAPが自ノードで起動したあと，該当するサービスに対して初めて行ったサービス情報の検索要求だった場合。

サービス情報の検索要求を受信したTP1-Xのネームサービスは，システム共通定義のall_nodeオペランドに指定されたノード（TP1-A，TP1-B，TP1-C）に対してサービス情報の検索要求を送信します。

ただし，all_nodeオペランドを指定していない場合は，サービス情報の検索要求は送信しません。また，all_nodeオペランドに指定されたサービス要求先がRPC抑止リスト※2に登録されていた場合，該当するノードに対してサービス情報の検索要求は送信しません。

サービス情報の検索要求を受信したTP1-A，TP1-B，TP1-Cのネームサービスでは，ローカルキャッシュに該当するサービスグループが存在するか検索し，その結果をTP1-Xのネームサービスに送信します。

他ノードに対するサービス要求の応答が返ってきたため，TP1-Xのネームサービスは，受信したサービス情報をグローバルキャッシュに登録します。

TP1-Xのネームサービスは，検索して取得したサービス情報を，サービス要求元UAPに返します。

複数の同一サービスグループ名称のUAPが起動されていた場合は，TP1の内部処理によって，その中から一つのサービス要求先UAP（サーバUAP2）を選択します。この説明では，TP1-Cをあて先に選択すると仮定します。

7.で選択したTP1-Cのスケジュールサービスに対して，サービス実行要求を送信します。

サービス要求を受信したスケジュールサービスでは，該当するサービスグループのサービス要求先UAP（サーバUAP2）のメッセージキューに対し，サービス要求を登録します。

サービス要求が登録されたサービス要求先UAP（サーバUAP2）では，メッセージキューからサービス要求を取り出します。

サービス関数を実行します。

サービス関数の実行後，サービス要求元UAPに対して，サービス要求先UAP（サーバUAP2）から，直接応答メッセージを送信します。

注※1

サービス情報を取得した時間からネームサービス定義のname_cache_validity_timeオペランドで指定した値までの時間を指します。

name_cache_validity_timeオペランドについては，マニュアル「OpenTP1 システム定義」を参照してください。

注※2

未起動ノードの情報を保持しているリストを指します。

他ノードのネームサーバに対する通信に失敗した場合，RPC抑止リストに登録されます。RPC抑止リストにノードが登録されると，該当するノードのサービス情報はグローバルキャッシュからすべて削除されます。ノード監視機能を使用し，停止状態だったノードが稼働状態になったと判断した場合，該当するノードの情報をRPC抑止リストから削除します。

詳細については，「3.2.3(3)　RPC抑止リストに登録されたノードの監視機能」を参照してください。

付録D.3　グローバル検索処理の概要

グローバル検索とは，自OpenTP1がall_nodeオペランドに指定したノードと該当するノードのall_nodeオペランドに指定されたノードまで，サービス検索する検索方法です。グローバル検索機能については，「3.2.2(1)　グローバル検索機能」を参照してください。

ここでは，グローバル検索処理の概要について，次の図に示します。詳細なサービス情報の検索条件については，「付録D.2　他ノードへのリモートプロシジャコールの処理の概要」を参照してください。

図D‒3　グローバル検索処理の概要

図で示した処理の流れについて，次に説明します。番号は，図中の番号と対応しています。なお，1.〜3.および9.〜12.はTP1-Xの処理，4.，5.，7.，8.はTP1-Aの処理，6.はTP1-B，TP1-C，TP1-Dの処理，13.〜16.はTP1-Dの処理についての説明です。

dc_rpc_call関数の引数に指定されたサービスグループ名を検索キーに，該当するサービス情報がローカルキャッシュとグローバルキャッシュに登録されているかを確認します。

該当するサービス情報が存在しなければ，ネームサービスにサービス情報の検索要求を送信します。

TP1-Xは，システム共通定義のall_nodeオペランドに指定されたノード（TP1-A）に対してサービス情報のグローバル検索要求を送信します。

グローバル検索要求を受信したTP1-Aのネームサービスは，ローカルキャッシュとグローバルキャッシュに該当するサービスグループが存在するか検索します。

該当するサービス情報がキャッシュに存在しなければ，TP1-Aはシステム共通定義のall_nodeオペランドに指定されたノード（TP1-B，TP1-C，TP1-D）に対してサービス情報の検索要求を送信します。

サービス情報の検索要求を受信したTP1-B，TP1-C，TP1-Dのネームサービスは，ローカルキャッシュに該当するサービスグループが存在するか検索し，その結果をTP1-Aのネームサービスに送信します。

他ノードに対するサービス要求の応答が返ってきたため，TP1-Aのネームサービスは，受信したサービス情報をグローバルキャッシュに登録します。

TP1-Aのネームサービスは，検索して取得したサービス情報を，サービス要求元ノードであるTP1-Xのネームサービスに送信します。

TP1-Aに対するグローバルサービス検索要求の応答が返ってきたため，TP1-Xのネームサービスは，受信したサービス情報をグローバルキャッシュに登録します。

TP1-Xのネームサービスは，検索して取得したサービス情報を，サービス要求元UAPに返します。

複数の同一サービスグループ名称のUAPが起動されていた場合は，その中から一つのサービス要求先UAP（サーバUAP1）を選択します。この説明では，TP1-Dをあて先に選択すると仮定します。

11.で選択したTP1-Dのスケジュールサービスに対して，サービス実行要求を送信します。

サービス要求を受信したスケジュールサービスでは，該当するサービスグループのサービス要求先UAP（サーバUAP1）のメッセージキューに対し，サービス要求を登録します。

サービス要求が登録されたサービス要求先UAP（サーバUAP1）では，メッセージキューからサービス要求を取り出します。

サービス関数を実行します。

サービス関数の実行後，サービス要求元UAPに対して，サービス要求先UAP（サーバUAP1）から，直接応答メッセージを送信します。

付録D.4　サービス情報の登録・削除処理の概要

ここでは，サービス情報の登録・削除処理の概要について説明します。

サービス情報の登録処理の概要について，次の図に示します。

図D‒4　サービス情報の登録処理の概要

図で示した処理の流れについて，次に説明します。番号は，図中の番号と対応しています。なお，1.〜3.はTP1-Xの処理，4.はTP1-Aの処理についての説明です。

サーバUAP1を起動すると，自OpenTP1（TP1-X）のローカルキャッシュに起動したサーバUAP1のサービス情報を登録します。

TP1-Xのネームサービスに対してサービス情報の登録要求を送信します。

サービス情報の登録要求を受信したネームサービスは，システム共通定義のall_nodeオペランドに指定した，TP1-Aのネームサービスにサービス情報の登録要求を送信します。

サービス情報の登録要求を受信したTP1-Aのネームサービスは，送信元がシステム共通定義のall_nodeオペランドに指定されているか確認します。

送信元がall_nodeオペランドに指定されている場合，サービス情報の登録要求をされたサーバUAP1のサービス情報をグローバルキャッシュに登録します。

送信元をall_nodeオペランドに指定していない場合は，サービス情報は登録しません。

この図では，送信元であるTP1-Xがall_nodeオペランドに指定されているので，サーバUAP1のサービス情報をTP1-Aのグローバルキャッシュに登録しています。

次に，サービス情報の削除処理の概要について，次の図に示します。

図D‒5　サービス情報の削除処理の概要

図で示した処理の流れについて，次に説明します。番号は，図中の番号と対応しています。なお，1.〜3.はTP1-Xの処理，4.はTP1-Aの処理についての説明です。

サーバUAP1を停止すると，自OpenTP1（TP1-X）のローカルキャッシュに登録されている停止したサーバUAP1のサービス情報を削除します。

TP1-Xのネームサービスに対してサービス情報の削除要求を送信します。

サービス情報の削除要求を受信したネームサービスは，システム共通定義のall_nodeオペランドに指定した，TP1-Aのネームサービスにサービス情報の削除要求を送信します。

サービス情報の削除要求を受信したTP1-Aのネームサービスは，送信元がシステム共通定義のall_nodeオペランドに指定されているか確認します。

送信元がall_nodeオペランドに指定されている場合，サービス情報の削除要求をされたサーバUAPのサービス情報をグローバルキャッシュから削除します。

送信元をall_nodeオペランドに指定していない場合は，サービス情報は削除しません。

この図では，送信元であるTP1-Xがall_nodeオペランドに指定されているので，サーバUAP1のサービス情報がTP1-Aのグローバルキャッシュから削除されています。

付録D.5　他ノードへの転送処理の概要

他ノードへの転送処理の概要について，次の図に示します。

図D‒6　他ノードへの転送処理の概要

図で示した処理の流れについて，次に説明します。番号は，図中の番号と対応しています。なお，1.はTP1-Xの処理，2.〜10.はTP1-A，TP1-B，TP1-Cの処理についての説明です。

TP1-Xはネームサービスを検索した結果，TP1-Aノードのスケジュールサービスにサービス要求をします。

TP1-Aのスケジュールサービスがサービス要求しようとした時点で，TP1-Aのサーバが閉塞しているため，キューイングしません。

スケジュールサービスは，ネームサービスに対して転送先を検索します。

サービス要求元のRPC要求がdc_rpc_call_to関数でスケジューラダイレクト機能を使用している場合は，転送しないでサービス要求元にエラーを返します。

TP1-Bのスケジュールサービスに転送します。

サーバの負荷レベルが2で高負荷のためキューイングしません。

スケジュールサービスは，ネームサービスに対して転送先を検索します。

TP1-Cのスケジュールサービスに転送します。

サーバが閉塞中，または高負荷ではないので，サービス要求をメッセージキューに登録します。

サービス関数を実行します。

サービス関数の実行後，サービス要求を行ったサービス要求元UAPに対して，サービス要求先UAP（サーバUAP1）から，直接応答メッセージを送信します。

付録D.6　dcsvgdef定義コマンドを使用したリモートプロシジャコールの処理の概要

ユーザサービスネットワーク定義のdcsvgdef定義コマンドを使用したリモートプロシジャコールの処理の概要について，次の図に示します。

図D‒7　dcsvgdef定義コマンドを使用したリモートプロシジャコールの処理の概要

図で示した処理の流れについて，次に説明します。番号は，図中の番号と対応しています。なお，1.〜2.はTP1-Xの処理，3.〜4.はTP1-B，5.〜7.はTP1-Cの処理についての説明です。

TP1-Xはネームサービスを検索しないで，ユーザサービスネットワーク定義からサービス要求の送信先TP1-Bを求めます。

TP1-Bのスケジュールサービスに送信します。

TP1-Bで起動しているスケジュールサービスがネームサービスを検索し，TP1-BおよびTP1-CにUAPが存在するという結果が通知されます。

ランダムに決めた結果，TP1-Cに転送します。

TP1-Cのスケジュールサービスは，サービス要求をメッセージキューにキューイングします。

サービス関数を実行します。

サービス関数の実行後，サービス要求を行ったサービス要求元UAPに対して，サービス要求先UAP（サーバUAP1）から，直接応答メッセージを送信します。

付録E　用語解説

（英字）

CUP（Client User Program）

OpenTP1クライアント機能（TP1/Client）で使用する，クライアント専用のUAPのことです。エラーログ機能とUAPトレース機能を使用できます。

DAMファイル（Direct Access Method）

OpenTP1専用の直接編成ファイルをDAMファイルといいます。相対ブロック番号をキーとした直接アクセス法で参照，または更新できます。参照だけの場合は順アクセスもできます。

DTPモデル（Distributed Transaction Processing）

オープンシステムの標準化を目的とした団体であるX/Openが規定する，分散処理システムモデルのことです。DTPモデルは，トランザクション処理を管理，実行するトランザクションマネジャ，各種資源を管理するリソースマネジャ（RM），および業務処理をするUAP（AP）から構成されます。

ISTテーブル

ISTサービスで使う，データを格納するテーブルのことです。ISTサービスを使うときには，ISTテーブルの名称を関数に設定してアクセスします。ISTテーブルは各システムのTP1/Shared Table Accessが管理しているので，テーブルの実体がどのノードにあるかをUAPで意識しなくても，ISTテーブルへアクセスできます。

MCFメイン関数

OpenTP1のリソースマネジャであるTP1/Message Controlを使用する場合は，ユーザがメイン関数を作成します。TP1/Message Controlのメイン関数をMCFメイン関数といいます。MCFメイン関数では，main（）とdc_mcf_svstart関数を呼び出します。システムでUOCを使用する場合は，MCFメイン関数にUOCの関数アドレスを設定しておきます。

MCFメイン関数は，通信プロトコル対応向けとアプリケーション起動サービス向けで，別に作成します。

MHP（Message Handling Program）

OpenTP1のUAPのうち，TP1/Message Controlを使用したメッセージ送受信の業務で使用するUAPのことです。MHPは，ほかのシステムから送信されたメッセージを受信するサービス関数と，サービス関数をまとめるメイン関数から構成されます。

MQAキューファイル

メッセージキューイング機能を使った通信をする場合に使う，メッセージキューを格納するファイルのことです。OpenTP1の場合，キューファイルはOpenTP1ファイルシステム上に作成します。

MQAサービス，MQTサービス

メッセージキューイング機能を使った通信をする場合に必要な，OpenTP1のシステムサービスです。MQAサービスとは，メッセージキューやUAPプロセスを管理するシステムサービスです。MQTサービスとは，システム間の通信（TCP/IPプロトコル）とのインタフェースを管理するシステムサービスです。

MQI（Message Queue Interface）

メッセージキューイング機能を使った通信をする場合に，UAPで使う命令文（API）のことです。MQIは，WebSphere MQで標準化しています。

MQシステム

メッセージキューイング機能のキューマネジャがあるシステム（ノード）のことです。

OpenTP1インストールディレクトリ

OpenTP1をインストールするディレクトリのことです。OpenTP1インストールディレクトリのパスは，使用するOSによって異なります。OSごとのOpenTP1インストールディレクトリのパスは次のとおりです。

AIX，HP-UXまたはSolarisの場合：/BeTRAN

Linuxの場合：/opt/OpenTP1

Windowsの場合：C:¥OpenTP1

C:¥は使用している環境によって異なります。

OpenTP1管理者

OpenTP1を管理する，UNIX OSの利用者のことです。OpenTP1管理者をどの利用者名称とするかは，スーパユーザが決めます。OpenTP1管理者は，OpenTP1を使う上で重要な権限を持つユーザです。システムの機密保護上，利用者名称にはパスワードを必ず設定して，限られた人だけがOpenTP1管理者の利用者名称を使えるようにしてください。

OpenTP1ノード

マルチノードエリア，またはマルチノードサブエリアを構成する個々のOpenTP1システムをOpenTP1ノードといいます。それぞれのOpenTP1ノードは，OpenTP1のシステム共通定義で指定したノード識別子で区別されます。系切り替え構成は，一つのOpenTP1ノードと見なします。

OpenTP1ファイルシステム/OpenTP1ファイル

OpenTP1専用のファイルシステムをOpenTP1ファイルシステム，OpenTP1ファイルシステムの個々のファイルをOpenTP1ファイルといいます。OpenTP1ファイルシステムとして使用する領域をキャラクタ型スペシャルファイル上に作成して，OpenTP1のコマンドで初期化します。その後，使用する目的別のコマンドでOpenTP1ファイルを初期化してから使用します。

OpenTP1ホームディレクトリ

OpenTP1で使う各種ファイル，またはディレクトリを格納しているディレクトリのことです。

OpenTP1では，OpenTP1ホームディレクトリをDCDIRという環境変数で管理しています。OpenTP1が組み込んであるマシンでは，任意のディレクトリから環境変数$DCDIRと指定して移動すると，OpenTP1ホームディレクトリに移れます。

OpenTP1の各マニュアルでは，OpenTP1ホームディレクトリを$DCDIR/と表記しています。

OSI TP（Open Systems Interconnection transaction processing）

OSI参照モデルに準拠した，分散トランザクション処理に必要な通信手順を規定したプロトコルのことです。OpenTP1がOSI TPを使う通信には，次に示す2とおりがあります。

クライアント/サーバ形態の通信で通信プロトコルに使う場合

サービス要求と応答で通信する形態です。通信には，XATMIインタフェースのAPIを使います。この形態の通信をする場合には，TP1/Server Baseに加えて，TP1/NET/LibraryとTP1/NET/OSI-TP-Extendedが必要です。

メッセージ送受信形態の通信で通信プロトコルに使う場合

メッセージの送信と受信で通信する形態です。通信には，MCFのAPI（例　dc_mcf_send関数）を使います。この形態の通信をする場合には，TP1/Server Baseに加えて，TP1/Message Control，TP1/NET/Library，およびTP1/NET/OSI-TPが必要です。

RPC（Remote Procedure Call）

→リモートプロシジャコール欄を参照してください。

RPC抑止リスト

OpenTP1システムが，未起動のOpenTP1ノードの情報を保持しているリストのことです。

SPP（Service Providing Program）

OpenTP1のUAPのうち，ファイルへのアクセスなどサーバの役割をするプログラムのことです。SPPは，クライアントUAPから要求されたサービスを実行するサービス関数と，サービス関数をまとめるメイン関数から構成されます。

SUP（Service Using Program）

OpenTP1のUAPのうち，SPPに処理要求をするだけの，クライアント専用のプログラムのことです。ほかのUAPにサービスを提供するための関数は持ちません。

TAMファイル（Table Access Method）

OpenTP1専用の単純構造テーブルを使用してアクセスできるファイルをTAMファイルといいます。単純構造テーブルへは，テーブル名とキー値によってアクセスできます。アクセスすることで，レコードの検索，更新，追加，削除，および検索の取消ができます。さらに，テーブル情報を取得できます。

TCP/IP（Transmission Control Protocol/Internet Protocol）

米国国防総省高等研究計画局（DARPA）のプロジェクトであるARPANETが開発したプロトコルのことです。TCP/IPプロトコルは，主にLANで使われます。OpenTP1がTCP/IPを使う通信には，次に示す2とおりがあります。

クライアント/サーバ形態の通信で通信プロトコルに使う場合

サービス要求と応答で通信する形態です。通信には，OpenTP1独自のRPC（例　dc_rpc_call関数），XATMIインタフェースのAPI，およびTxRPCインタフェースの通信を使います。この形態の通信をする場合には，TP1/Server Baseが必要です。

メッセージ送受信形態の通信で通信プロトコルに使う場合

メッセージの送信と受信で通信する形態です。通信には，MCFのAPI（例　dc_mcf_send関数）を使います。この形態の通信をする場合には，TP1/Server Baseに加えて，TP1/Message Control，TP1/NET/Library，およびTP1/NET/TCP/IPが必要です。

TPモニタ（Transaction Processing）

トランザクション処理の監視，および制御をするソフトウェアのことです。オンラインシステムを構築するための基盤となる機能を提供しています。主な機能として，端末やほかのコンピュータとデータをやり取りするための通信機能，トランザクションを効率的に処理するためのスケジュール機能，トラブルが起こってもデータとトランザクションの消失や不整合を防ぐ回復機能があります。

UAP（User Application Program）

ユーザの業務をプログラムとして作成したものです。アプリケーションプログラムともいいます。

UOC（User Own Coding）

メッセージ送受信のUAPをより多様な業務に対応させるためにユーザがコーディングするプログラムです。起動するアプリケーション名を決定したり，UAPが送信したメッセージを他システムに送信する前に編集できます。

WebSphere MQ

米国IBM社が開発した，メッセージ蓄積型の通信を実現する製品群のことです。OpenTP1では，TP1/Message Queueを使うとメッセージ蓄積型の通信ができるようになります。

（ア行）

アーカイブジャーナルファイル

クラスタ/並列システム形態でOpenTP1を使用する場合に，グローバルアーカイブジャーナル機能で使用する，各OpenTP1ノードから集められたジャーナルを格納するファイルです。

アソシエーション

通信プロトコルにOSI TPを使ったクライアント/サーバ形態の通信をする場合に，システム間で確立する論理的な通信路のことです。このマニュアルでは，通信プロトコルにOSI TPを使ったクライアント/サーバ形態の通信をする場合に限り，論理的な通信路の呼称をアソシエーションと表記します。

アプリケーション

OpenTP1の業務処理の総称です。アプリケーションとして作成するプログラムをアプリケーションプログラム（またはユーザアプリケーションプログラム　UAP）といいます。UAPをOpenTP1に登録して，サーバとして業務を実行するプロセスをユーザサーバといいます。

一方送信メッセージ

TP1/Message Controlを使ったメッセージ送受信の業務で，応答を返さないメッセージを一方送信メッセージといいます。一方送信メッセージには，送信優先度を付けることができます。

エージェントノード

ノード自動追加機能を使用したOpenTP1システムを構築するノードのうち，マネジャノードによって，ノードの停止および開始を監視されるノードのことをいいます。

応答メッセージ

→問い合わせ応答メッセージ欄を参照してください。

（カ行）

稼働統計情報

ユーザサーバ，およびOpenTP1のシステムサービスの稼働情報を稼働統計情報といいます。稼働統計情報を編集して出力することで，OpenTP1の稼働状況を知ることができます。

監査ログ

システム構築者，運用者，および使用者がOpenTP1のプログラムに対して実行した操作，およびその操作に伴うプログラムの動作の履歴が出力されるファイルです。監査ログには「いつ」，「だれが」，「何をしたか」などが記録されます。そのため，システムの使用状況，不正アクセスなどを監査する資料として使用できます。

キューグループID

TP1/Message Controlを使ったメッセージ送受信で使用する，メッセージキューファイルの識別子のことです。OpenTP1のコマンドでキューグループの状態を表示する場合に使用します。

キューマネジャ

メッセージキューイング機能を管理するソフトウェア製品のことです。メッセージキューイング機能を使って通信するシステムには，キューマネジャが必要になります。OpenTP1の場合は，TP1/Message Queueがキューマネジャの役割をします。

クライアント/サーバ

プログラムとプログラムで通信する場合の関係を示す用語です。業務処理を依頼する方をクライアント，要求を受けて業務を実行する方をサーバといいます。クライアント/サーバとは，プログラム間の相対的な関係を示します。

クライアントUAP/サーバUAP

複数のUAPプロセス間でクライアント/サーバ型の通信をするときに，業務処理を依頼するためにサービスを要求するUAPをクライアントUAP，要求を受けて業務を実行するUAPをサーバUAPといいます。クライアントUAPとなるのは，SUP，SPP，およびMHPです。サーバUAPとなるのはSPPです。

クラスタ/並列システム

複数のサーバをLANで接続して，一つのサーバの処理能力ではできないような業務を，サーバ同士で連携して実現するシステム形態のことです。クラスタ/並列システムでOpenTP1を使用する場合は，運用支援のため，TP1/Multiを使用します。

グローバルアーカイブジャーナルサービス

クラスタ/並列システム形態でOpenTP1を使用する場合に，各OpenTP1ノードからジャーナルを集める機能のことです。グローバルアーカイブジャーナルサービスを使用することで，OpenTP1ノードごとにジャーナルをアンロードする手間が省けます。

グローバルキャッシュ

ネームサービスが他ノードで起動しているサーバのサービス情報を管理する領域を示します。

グローバルトランザクション

トランザクション処理を行うUAPプロセスをトランザクションブランチといいます。RPCを使用した場合，複数のUAPプロセスで構成されたトランザクション処理ができます。このように複数のUAPプロセスで構成されたトランザクションブランチの集合をグローバルトランザクションといいます。

トランザクションを開始したトランザクションブランチをルートトランザクションブランチといいます。

コネクション

TP1/Message Controlを使ったメッセージ送受信の業務で，ほかのシステムとOpenTP1システムとの間に確立する論理的な通信路をコネクション（通信プロトコルによってはアソシエーション）といいます。このマニュアルではメッセージ送受信の説明に限り，呼称をコネクションで統一しています。

コミット

トランザクションの同期点を取得できたことをコミットといいます。コミットできた場合，該当するトランザクション処理が有効となります。

（サ行）

サービス

クライアント/サーバシステムでは，クライアントから要求された手続きを総称してサービスといいます。UAPのコーディング時には，C言語の場合は関数として，COBOL言語の場合はサブルーチンとして，サービスを作成します。作成したサービスのことを，C言語の場合はサービス関数，COBOL言語の場合はサービスプログラムといいます。

サービス関数動的ローディング機能

UAP共用ライブラリ化したサービス関数を，動的にローディングする（読み込む）機能です。UAP共用ライブラリ化とは，UAPのソースファイルを翻訳（コンパイル）して作成したUAPオブジェクトファイルを結合（リンケージ）して，共用ライブラリとしてまとめることです。

サービス関数動的ローディング機能を使うと，サービス関数を追加または削除する場合に，スタブの変更，およびUAPの実行形式ファイルの再生成をしなくても，ユーザサービス定義のserviceオペランドの変更だけでサービス関数を追加または削除できます。UAP起動時にサービス関数をローディングするため，UAPの実行形式ファイル作成時には，スタブおよびサービス関数は不要です。

サービスグループ

OpenTP1のサーバUAPは，クライアントからの手続き要求を処理するサービスの集合です。このことから，サーバUAPのことをサービスグループといいます。OpenTP1のリモートプロシジャコールの関数dc_rpc_call（）では，サービスを要求するときにサービスグループ名とサービス名を引数に設定します。

サービス情報優先度指定機能

ネームサービスがサービス要求元のクライアントUAPにサービス情報を返すときに，特定のノードのサービス情報を優先的に返す機能です。サービス情報を優先的に返すノードを，優先選択ノードといいます。

この機能を使用すると，通常は優先選択ノードのサーバUAPを使用し，障害が発生した場合だけ優先選択ノード以外のノードのサーバUAPを使用できるため，サーバUAPを実行系と待機系に分けて扱うことができます。

システムサービス

OpenTP1のUAPをユーザサーバということに対して，OpenTP1の個々の機能を指してシステムサービスといいます。

シナリオ

シナリオテンプレートを業務に関連づけて運用手順として実行できるようにしたものです。JP1/AJS2 - Scenario Operationが，シナリオテンプレートをシナリオとしてJP1/AJSに登録し，JP1/AJSが実行します。

シナリオジョブ

シナリオジョブテンプレートを業務に関連づけて運用手順として実行できるようにしたものです。JP1/AJS2 - Scenario Operationが使用します。シナリオ中に定義されているコマンド，シェルスクリプト，Windows実行ファイルなどを実行させるためのオブジェクトです。

シナリオジョブテンプレート

JP1/AJS2 - Scenario Operationが使用するシナリオテンプレートの部品です。シナリオテンプレート中に定義されているコマンド，シェルスクリプト，Windows実行ファイルなどを定義しています。OpenTP1では，シナリオテンプレートを利用する運用で使用します。

シナリオテンプレート

運用手順を，テンプレート（ひな形）として部品化したものです。JP1/AJS2 - Scenario Operationが使用します。OpenTP1では，シナリオテンプレートを利用する運用で使用します。

シナリオ変数

JP1/AJS2 - Scenario Operationで，運用環境によって変化する情報を，シナリオに応じてあらかじめ設定しておく変数です。OpenTP1のディレクトリ情報などを設定します。

シナリオライブラリ

JP1/AJS2 - Scenario Operationで，シナリオテンプレートを管理するフォルダです。

ジャーナル

システムを回復したり各種の稼働状況を検知したりするために，OpenTP1が取得する履歴情報をジャーナルといいます。OpenTP1では，次に示すジャーナルを取得します。

システムの全面回復，部分回復に使用するジャーナル情報

システムのトレース情報

ユーザが任意に取得するジャーナル情報

出力キュー

TP1/Message Controlを使ったメッセージ送受信の業務で，ほかのシステムへ送信するメッセージの待ち行列を格納するキューを出力キューといいます。

スーパユーザ（superuser）

UNIX OSの最高権限を持つユーザのことです。UNIXファイルシステムのすべてのファイルに対してアクセス権を持ちます。スーパユーザの利用者名称はrootで固定されています。

スケジュール機能

ユーザサーバを負荷の量に応じて起動させたり停止させたりする，OpenTP1の機能です。スケジュールとプロセスを管理することで，負荷を分散したり，使用するプロセス数を抑えたりでき，プロセスが増え過ぎて性能が下がることを避けられます。

スタブ

クライアント/サーバ形態の通信で，サービス要求とサーバUAPのサービスとを結び付けるライブラリの役割をするプログラムをスタブといいます。ユーザが作成したRPCインタフェース定義ファイルから，スタブを生成するコマンドでスタブを作成します。作成したスタブはC言語のプログラムの形式です。このスタブをコンパイルしてUAPの実行形式ファイルにリンケージします。スタブが必要なUAPは，RPCを使用する場合はSPP，XATMIインタフェースの通信を使用する場合はSUPとSPPです。また，MHPにもスタブが必要です。ただし，すべてのサービス関数をUAP共用ライブラリ化してサービス関数動的ローディング機能を使う場合，スタブは不要です。UAP共用ライブラリ化とは，UAPのソースファイルを翻訳（コンパイル）して作成したUAPオブジェクトファイルを結合（リンケージ）して，共用ライブラリとしてまとめることです。

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

ステータスサービス

OpenTP1の機能の一つで，UAPの実行状態などシステム内の各種情報を管理する機能です。

全面回復

OpenTP1に障害が発生した場合に，すべての資源を障害発生前の状態に戻すことを全面回復といいます。

（タ行）

チェックポイントダンプ

OpenTP1に障害が発生した場合に，全面回復に掛かる時間を短縮するために使用するファイルをチェックポイントダンプといいます。ジャーナルの情報を一定間隔で取得して，全面回復時には最新のチェックポイントダンプの情報とそれ以降のジャーナルの情報を参照して回復します。このことで，取得したジャーナルを最初から読み込まなくて済むので，回復時間を短縮できます。

デッドロック

複数のUAPが複数の資源を確保しようとして，互いのUAPが資源を解放するのを待ち続けて処理が止まってしまう状態のことをデッドロックといいます。

問い合わせ応答メッセージ

メッセージ送受信の業務で，メッセージを送信して応答を返す形態で使用するメッセージのことです。

同期点

トランザクション処理の区切りを同期点といいます。トランザクション処理が正常終了したことを示す同期点処理をコミット，トランザクション処理がうまくいかなかったため無効にする同期点処理をロールバックといいます。

ドメイン

ネットワークを論理的に区切った単位のことです。ドメインを管理する場合は，DNSやNISを使います。大規模なネットワークでクライアント/サーバ形態の通信をする場合には，OpenTP1のリモートプロシジャコールにドメイン修飾をして，スケジュールの効率を上げることができます。

トランザクショナルRPC

トランザクションとして実行しているUAPプロセスの処理からRPCを使うと，サービス要求先のUAPプロセスの処理もトランザクションの処理にできます。このようなRPCをトランザクショナルRPCといいます。サービス要求先のプロセスの処理がトランザクションとなるには，サービス要求先のプロセスがトランザクション属性（ユーザサービス定義でatomic_update = Yを指定）であることが前提です。

トランザクション

ファイルからデータを読み出して，変更したデータを書き込む処理（更新処理）では，データの一貫性を保持するため，途中で分けられません。このような処理の単位をトランザクションといいます。トランザクションの処理結果は，有効にするか無効にするかのどちらかに必ず決められます。

トランザクションブランチ

RPCを使用した複数のUAPプロセスにわたる処理をトランザクションとする処理（グローバルトランザクション）を構成するそれぞれのUAPプロセスをトランザクションブランチといいます。トランザクションを開始したトランザクションブランチを，ルートトランザクションブランチといいます。

トランザクションマネジャ（Transaction Manager）

トランザクション処理を管理，および実行する機能のことです。

トリガ

メッセージキューイング機能を使った通信をする場合に，メッセージキューにメッセージが到着したことを自システムのUAPへ知らせる機能のことです。トリガイベントを受信するUAPをトリガモニタアプリケーションといいます。

（ナ行）

入力キュー

メッセージ送受信の業務で，ほかのシステムから受信したメッセージの待ち行列を格納するキューを入力キューといいます。

ノード

ホスト，またはOpenTP1ノードを意味します。

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

同じサービスグループ名のユーザサーバを複数のノードに置いて，そのサービスグループ名でサービスを要求されたときにどちらのノードのユーザサーバでも処理できるようにする負荷分散の形態です。ノードのスケジュール状態に応じて，より効率的に処理できるノードへ負荷を分散できます。

ノードリスト

マネジャノードが管理するノード情報のリストのことです。共用メモリ上で管理します。ノード自動追加機能を使用するすべてのノードで共有し，システム共通定義のall_nodeオペランドに定義していた情報を，管理します。

ノードリストの整合性

マネジャノードは，エージェントノードから定期的にノード情報を取得し，エージェントノードにノードリストを配布します。これによって，ノード自動追加機能を使用するすべてのノードでノード情報を共有できます。このことをノードリストの整合性といいます。

ノードリストファイル

ノード自動追加機能でノードリストの引き継ぎをするときに作成するファイルです。OpenTP1ファイルシステム上に作成し，OpenTP1のオンライン中に，共用メモリ上にあるノードリストの情報を格納します。

ノーマルノード

ノード自動追加機能を使用したOpenTP1システムを構築するノードのうち，次のノードのことをいいます。

バージョン07-05以前のOpenTP1を使用しているノード

ノード自動追加機能を使用していないノード（システム共通定義のname_service_modeオペランドにnormalを指定または省略）

（ハ行）

部分回復

OpenTP1システム全体の回復を全面回復ということに対して，UAPの回復を部分回復といいます。UAPに障害が発生した場合，UAPのトランザクション処理を無効にして，資源を障害発生前の状態に戻します。

プロセス

ユーザサーバ，またはOpenTP1が，OSの作業領域を使用することで生成される作業領域の処理をプロセスといいます。OpenTP1では，ユーザサーバのプロセスが必要以上に増えたり減ったりしないように，使用するプロセスの総数を管理しています。

ホスト

ネットワークにつながれた，OpenTP1が稼働する一つの計算機（マシン）のことです。マルチOpenTP1の場合は，複数のOpenTP1から構成される一つのホストとなります。

（マ行）

マネジャノード

ノード自動追加機能を使用するOpenTP1システムを構築するノードのうち，OpenTP1システムを構成するすべてのノードの情報を管理するノードのことをいいます。OpenTP1システム内で一つだけ必要です。

マルチOpenTP1

一つのホストに複数のOpenTP1がある形態です。それぞれのOpenTP1は個別に運用します。

マルチサーバ

OpenTP1のユーザサーバプロセスを複数起動させて，複数のサービス要求を処理する機能です。マルチサーバによって，UAPの処理効率が上がります。

メッセージキュー（メッセージキューイング機能の用語）

メッセージキューイング機能を使った通信をする場合に使う，メッセージを格納するキューのことです。メッセージキューに登録したメッセージは，キューマネジャが通信相手に送信します。MQAサービス定義，およびMQIの引数の設定で，必要なメッセージを受信した順序に関係なく取り出すこともできます。

メッセージキュー（メッセージ送受信の用語）

メッセージ送受信の業務で，メッセージを格納するファイルをメッセージキューといいます。メッセージキューには，TP1/Message Controlで受信したメッセージを格納する入力キューと，ほかのシステムへ送信するメッセージを格納する出力キューがあります。

メッセージキューイング機能

米国IBM社が開発した，メッセージ蓄積型の通信手順のことです。メッセージキューイング機能を使った通信では，UAPが登録したメッセージをキューマネジャが送受信するため，システム間の通信手順や通信障害時の処理をUAPで意識しなくて済みます。また，UAPは任意のタイミングでメッセージを扱えるので，電子メールのような運用ができます。UAPからキューへアクセスするときには，WebSphere MQ標準のAPI（MQI　Message Queue Interface）を使います。

メッセージ出力通番

メッセージ送受信の業務で，複数のメッセージを送信する場合に，ユーザが送信抜けや二重の送信を認識できるようにするためにOpenTP1が付ける通し番号のことです。

メッセージログ

OpenTP1が出力するシステム管理情報をメッセージログといいます。メッセージログは，操作画面に出力されて，同じ情報が専用のファイルに格納されます。格納したメッセージログを編集出力する場合は，OpenTP1のコマンド（logcatコマンド）を実行します。

OpenTP1のメッセージログを，システム内に専用に作成するアプリケーションプログラムへ通知できます。通知を受信したアプリケーションプログラムは，他社のネットワーク管理システムへOpenTP1の状態を知らせることができます。メッセージログを通知する場合は，OpenTP1のログサービス定義のlog_notify_outオペランドにYを指定しておいてください。

（ヤ行）

ユーザサーバ

OpenTP1のUAP，およびOpenTP1のUAPを実行するプロセスの総称です。UAPの実行形式ファイルが，OpenTP1のサーバの業務をすることからユーザサーバといいます。

ユーザジャーナル（User Journal）

システムジャーナルファイルに取得するユーザ任意の情報をユーザジャーナルといいます。ユーザジャーナルは，UAPの処理から取得できます。

（ラ行）

リアルタイム統計情報

システム全体，サーバおよびサービス単位で，リアルタイムに出力できる統計情報を，リアルタイム統計情報といいます。リアルタイム統計情報を出力することで，OpenTP1システムの稼働状況をリアルタイムに把握でき，システムの運用管理や障害復旧を迅速に行えます。

リアルタイム統計情報サービス

OpenTP1の機能の一つで，OpenTP1システムの稼働状況をリアルタイムに把握するためのリアルタイム統計情報を管理する機能です。

リソースマネジャ（Resource Manager）

分散処理システムでの，資源を管理する機能の総称です。DBMSはリソースマネジャです。

リモートプロシジャコール（Remote Procedure Call）

UAPを実行するプロセス間で通信する機能を，リモートプロシジャコール（RPC）といいます。OpenTP1のUAPは，ほかのシステムのUAPとRPCで通信します。RPCを使用するときは，通信相手がクライアント/サーバシステムのどのノードのUAPかを意識する必要はありません。

ルートトランザクションブランチ

グローバルトランザクションに属するトランザクションブランチのうち，トランザクションを開始したUAPプロセスをルートトランザクションブランチといいます。

ローカルキャッシュ

ネームサービスが自OpenTP1で起動しているサーバのサービス情報を管理する領域を示します。

ロールバック

トランザクション処理を無効にする同期点処理をロールバックといいます。UAPから関数を発行する場合と，OpenTP1からUAPの処理を無効にする場合があります。

論理端末

メッセージ送受信の業務で，ほかのシステムにある通信相手の論理的な名称です。UAPからメッセージ送受信する場合には，論理端末名称を使用します。

論理メッセージ

メッセージ送受信の業務で，システム間でやり取りする業務単位でのメッセージを論理メッセージといいます。論理メッセージは，一つのセグメントから構成される場合と，複数のセグメントから構成される場合があります。

索引

数字

2相コミット[1]、[2]

A

ans型[1]、[2]

C

Client .NET[1]

clt[1]

Connector .NET[1]

cont型[1]、[2]

Cosminexus TP1 Connector[1]

cpd[1]

CUP[1]

D

dam[1]

DAMサービス[1]

DAMファイル[1]

dc_mcf_send関数[1]

DCCM3/Internet[1]

DCCM3/SERVER/TP1[1]

DCDIR[1]

dcmon[1]

DTPモデル[1]、[2]

F

FILイベントトレース[1]

FILイベントトレース情報ファイル[1]

H

HAモニタ[1]

I

ISAM[1]

ISAM/B[1]

ISAMサービス[1]

ISAMファイル[1]

ism[1]

ist[1]

ISTサービス[1]、[2]

ISTサービスの運用例[1]

ISTサービスの構成[1]

ISTテーブル[1]

itv[1]

J

J2EE Connector Architecture[1]

jnl[1]、[2]

JNL性能検証用トレース[1]

JNL性能検証用トレース情報ファイル[1]

JP1[1]

L

lck[1]

LCK性能検証用トレース[1]

LCK性能検証用トレース情報ファイル[1]

log[1]

M

map[1]

MCFアプリケーション定義[1]

MCFイベント[1]

MCFイベントコード[1]

MCFイベント処理用MHP[1]

MCF稼働統計情報[1]

MCF構成変更再開始機能[1]

MCFサービス[1]

MCF性能検証用トレース[1]

MCF通信サービス[1]

MCF通信プロセス[1]、[2]

MCFトレース[1]

MCFマネジャサービス[1]

MHP[1]、[2]

MHPの再スケジュール[1]

mqa[1]

MQAキューファイル[1]

MQAサービス[1]

MQGET[1]

MQI[1]

MQPUT[1]

MSDTC連携機能[1]

N

nam[1]

name_manager_node[1]

name_service_mode[1]

NAMイベントトレース[1]

NAMイベントトレース情報ファイル[1]

noans型[1]、[2]

O

OpenTP1インストールディレクトリ[1]

OpenTP1監視機能[1]

OpenTP1監視サービス[1]

OpenTP1管理者[1]、[2]

OpenTP1クライアント機能（TP1/Client）[1]

OpenTP1識別子[1]

OpenTP1システム[1]

OpenTP1の環境設定手順[1]

OpenTP1の監視[1]

OpenTP1の通信形態[1]

OpenTP1のノード管理[1]

OpenTP1のリモートプロシジャコール通信[1]

OpenTP1ファイル[1]、[2]

OpenTP1ファイルシステム[1]、[2]

OpenTP1ファイルシステムとOSが提供するファイルシステムとの違い[1]

OpenTP1ファイルシステムとOSが提供するファイルシステムの関係[1]

OpenTP1ファイルシステムを作成するファイルの選択方法[1]

OpenTP1ホームディレクトリ[1]

OSI TP[1]

P

prc[1]

Q

que[1]

R

rapクライアント[1]

rapサーバ[1]

rapリスナー[1]

Remote Procedure Call[1]

Resource Manager[1]

RI[1]

rmm[1]

RMが提供するインタフェース[1]

RPC[1]、[2]

RPCトレース[1]

RPC抑止リストに登録されたノードの監視機能[1]

rts[1]

RTSSPP[1]

RTSSUP[1]

S

scd[1]

scd_refresh_process[1]

scdbufgrp[1]

SEWB+[1]

SPP[1]、[2]

sts[1]

SUP[1]、[2]

superuser[1]

T

tam[1]

TAMサービス[1]

TAMテーブル[1]

TAMファイル[1]

TAMファイルサービス[1]

TCP_NODELAY[1]

TCP/IP[1]、[2]

tim[1]

tjl[1]

TP1/Client/J[1]、[2]

TP1/Client/P[1]

TP1/Client/W[1]

TP1/Extension1[1]

TP1/FS/Direct Access[1]

TP1/FS/Table Access[1]

TP1/High Availability[1]

TP1/LiNK[1]

TP1/Message Control[1]

TP1/Message Control/Tester[1]

TP1/Message Control - Extension1[1]

TP1/Message Queue[1]

TP1/Messaging[1]

TP1/Multi[1]

TP1/NET/High Availability[1]

TP1/NET/Library[1]

TP1/NET/OSI-TP-Extended[1]

TP1/NET/XMAP3[1]

TP1/Offline Tester[1]

TP1/Online Tester[1]

TP1/Resource Manager Monitor[1]

TP1/Server Base[1]

TP1/Shared Table Access[1]

TPモニタ[1]

Transaction Manager[1]

trn[1]

TRNイベントトレース[1]

TRNイベントトレース情報ファイル[1]

TxRPCインタフェース[1]、[2]

TXインタフェース[1]

U

UAP[1]

UAP共用ライブラリ[1]

UAPトレース[1]

UAPプロセス[1]

uCosminexus TP1 Connector[1]

UOC[1]

uto[1]

X

XA+インタフェース[1]

XARイベントトレース[1]

XARイベントトレース情報ファイル[1]

XAR性能検証用トレース[1]

XAR性能検証用トレース情報ファイル[1]

xat[1]

XATMIインタフェース[1]、[2]

XATMI通信サービス[1]、[2]

XAインタフェース[1]、[2]、[3]

XAリソースサービス[1]

XDM/DCCM3[1]

XID[1]

XMAP3を使用した通信[1]

あ

アーカイブジャーナルノード[1]

アーカイブジャーナルファイル[1]

アソシエーション[1]

圧縮[1]

アプリケーション[1]

アプリケーション開発支援ツール[1]

アプリケーション起動機能[1]

アプリケーション起動サービス[1]

アプリケーション起動プロセス[1]

アプリケーションプログラム[1]

アプリケーション名[1]

アプリケーション名決定ユーザオウンコーディング[1]

アンロードジャーナルファイル[1]

い

一時クローズ処理[1]

一時クローズ処理の実行状態の確認[1]

一時クローズ処理の実行状態の確認コマンドで取得できる情報[1]

一時クローズ処理要求監視機能[1]

一時クローズ処理要求の監視[1]

インタバルサービス[1]

う

運用[1]

え

エージェントノード[1]、[2]

エラーイベント[1]

お

応答型[1]、[2]

応答メッセージ[1]

か

回復用ジャーナル[1]

型付きバッファ[1]

型付きレコード[1]

環境設定[1]

監査ログによるシステムの監視[1]

監視[1]

き

起動通知機能[1]

キャッシュブロック[1]

キャッシュブロック確保処理[1]

キャッシュレスアクセス[1]

キュー受信型サーバ[1]

キューファイル[1]、[2]、[3]

キューファイル名[1]、[2]

キューマネジャ[1]

共有化したバッファの使用サイズの制限[1]

共用メモリ[1]

く

クライアント/サーバ[1]

クライアント/サーバ形態の通信[1]

クライアントUAP[1]

クライアントUAP/サーバUAP[1]

クライアント拡張サービス[1]

クライアント機能[1]

クライアントサービス[1]、[2]

クラスタ/並列システム[1]

クリーンアップ処理[1]

グローバルアーカイブアンロードジャーナルファイル[1]

グローバルアーカイブジャーナル機能[1]

グローバルアーカイブジャーナルサービス[1]

グローバルキャッシュ[1]

グローバル検索機能[1]

グローバルトランザクション[1]、[2]

け

系切り替え機能[1]

系切り替え後に待機系に実行系の後処理だけを行わせるときの運用[1]

継続問い合わせ応答型[1]、[2]

現用[1]

こ

コネクション[1]、[2]

コミット[1]、[2]

コミット処理[1]

コミュニケーションリソースマネジャ[1]

さ

サーバUAP[1]

サーバリカバリジャーナルファイル[1]

サービス[1]

サービス回復処理[1]

サービスグループ[1]

サービスグループ名[1]、[2]、[3]

サービス情報検索の付加機能[1]

サービス情報優先度指定機能[1]、[2]

サービス情報優先度指定機能を使用する場合の注意事項[1]

サービス提供プログラム[1]

サービス名[1]、[2]、[3]

サービス利用プログラム[1]

再開始[1]

最小分散数[1]、[2]

最大分散数[1]、[2]

索引順編成ファイル[1]

し

システム回復処理[1]

システムサービス[1]、[2]

システムサービス定義[1]

システムジャーナルファイル[1]

システムジャーナルファイルの並列アクセス機能[1]

システム制御情報[1]

システム定義[1]

実行系の後処理だけ行わせるために待機系を起動する場合[1]

シナリオテンプレートを利用したシステムの運用[1]、[2]

ジャーナル維持機能[1]

ジャーナルサービス[1]

集積ジャーナルファイル[1]

縮退運転[1]、[2]

出力キュー[1]

出力キュー（OTQ）[1]

障害対策[1]

常設コネクション[1]、[2]

常駐プロセス[1]

す

スーパユーザ[1]、[2]

スケールアウト[1]

スケールイン[1]

スケジュール機能[1]

スケジュールキュー[1]、[2]

スケジュールサービス[1]

スケジュールバッファグループ名[1]

スタティックコネクションスケジュールモード[1]

スタブ[1]

ステータスサービス[1]、[2]

ステータスファイル[1]

ステータスファイルの片系運転[1]

ステータスファイルの状態[1]

せ

性能検証用トレース[1]

セグメント[1]

そ

送信優先度[1]

た

第1相[1]

第2相[1]

ダイナミックコネクションスケジュールモード[1]

タイプトバッファ[1]

タイプトレコード[1]

タイマサービス[1]

タイムアウト情報[1]

単純型RPC[1]

ち

チェックポイント[1]

チェックポイントダンプ[1]

チェックポイントダンプサービス[1]

チェックポイントダンプ取得契機のスキップ回数の監視[1]

チェックポイントダンプファイル[1]、[2]

着呼[1]

つ

通常ファイル[1]

通信イベント[1]

通信イベント障害時のエラーイベント通知[1]

て

ディスクキュー[1]

ディファード更新[1]

テーブル[1]

テスタサービス[1]

デッドロック[1]、[2]

デッドロック情報[1]

と

問い合わせ応答メッセージ[1]

同期応答型RPC[1]、[2]

同期受信[1]

同期送受信[1]

同期送信[1]

同期点[1]、[2]

同期点ジャーナル[1]

統計用ジャーナル[1]

統合システム運用管理機能[1]

ドメイン代表スケジュールサービス[1]

ドメインネームシステム[1]

トランザクショナルRPC[1]、[2]

トランザクション[1]

トランザクションサービス[1]

トランザクションジャーナルサービス[1]

トランザクション制御[1]

トランザクション属性[1]

トランザクションブランチ[1]、[2]

トランザクションマネジャ[1]、[2]

トランザクションリカバリジャーナルファイル[1]

な

内部通信路[1]

に

入力キュー[1]

入力キュー（ITQ）[1]

ね

ネームサービス[1]、[2]、[3]

ネットワーク障害[1]

の

ノーウェイト型RPC[1]

ノード[1]

ノード監視機能[1]

ノード間通信時の毎回コネクション断機能[1]

ノード間負荷バランス拡張機能[1]

ノード間負荷バランス機能[1]

ノード管理[1]

ノード自動追加機能[1]

ノードリスト[1]、[2]

ノードリストの整合性[1]

ノードリストファイル[1]、[2]

ノーマルノード[1]

ノーリプライ型RPC[1]

は

パーティション[1]

排他制御[1]

排他待ち時間監視[1]

バックアップ[1]

発呼[1]

ハッシュ域[1]

ハッシュ値[1]

ひ

被アーカイブジャーナルノード[1]

非応答型[1]、[2]

非応答型RPC[1]、[2]

引き継ぎファイル[1]

非常駐UAPプロセスのリフレッシュ機能[1]

非常駐プロセス[1]

非同期応答型RPC[1]

ヒューリスティック決定[1]、[2]

ヒューリスティック決定の流れ[1]

ヒューリスティックコミット[1]

ヒューリスティックハザード[1]

ヒューリスティックミックス[1]

ヒューリスティックロールバック[1]

ふ

ファイアウォール[1]

ファイル障害[1]

複数世代保証機能[1]

部分回復[1]

プリペア処理[1]

プロセス[1]、[2]

プロセスサービス[1]

プロセスサービスイベントトレース情報ファイル[1]

プロセスサービスのイベントトレース[1]

ブロック長拡張機能[1]

分散トランザクション[1]、[2]

へ

閉塞[1]

ほ

ポート数の制限方法[1]

保持メッセージ[1]

ホスト[1]

保留[1]

ま

マスタスケジューラデーモン[1]

マッピングサービス[1]

マネジャノード[1]、[2]

マルチOpenTP1[1]

マルチサーバ[1]

マルチサーバ負荷バランス機能[1]

マルチスケジューラデーモン[1]

マルチノードエリア[1]

マルチノード機能[1]

マルチノードサブエリア[1]

マルチホームドホスト[1]

み

未処理受信メッセージ滞留時間[1]

未処理送信メッセージ滞留時間[1]

む

無応答状態[1]

無効[1]

め

メッセージ格納バッファプール[1]

メッセージキュー[1]

メッセージキューイング機能[1]

メッセージキューサービス[1]

メッセージキューファイル[1]

メッセージ出力通番（出力通番）[1]

メッセージ処理プログラム[1]

メッセージ制御機能[1]

メッセージ送受信[1]

メッセージログ[1]、[2]

メモリキュー[1]

ゆ

有効保証世代[1]

ユーザサーバ[1]、[2]

ユーザサーバプロセス[1]

ユーザサービス定義[1]

ユーザサービスネットワーク定義ファイル[1]

ユーザジャーナル[1]

優先選択ノード[1]

よ

予備[1]

り

リアルタイム統計情報[1]

リアルタイム統計情報サービス[1]、[2]、[3]

リストア[1]

リソースマネジャ[1]、[2]、[3]

リソースマネジャモニタサービス[1]

リモートAPI機能[1]、[2]、[3]

リモートプロシジャコール[1]、[2]

リモートプロシジャコールの形態[1]

リラン[1]

る

ルートトランザクションブランチ[1]、[2]

れ

連鎖RPC[1]

ろ

ローカルキャッシュ[1]

ローカルメモリ[1]

ローディング契機[1]

ローリングアップデート[1]

ロールバック[1]、[2]

ロールバック処理[1]

ログサービス[1]

ロックサービス[1]

論理端末[1]

論理端末名称[1]

論理メッセージ[1]