クライアント/サーバ型の通信で，UAPの業務処理を開始するクライアント専用のUAPをサービス利用プログラム（SUP）といいます。クライアント/サーバ型の通信では，すべての業務処理はSUPから開始します。

SUPでは，トランザクションの開始/終了の制御や，サーバUAPへのサービス要求ができます。

SUPは，OpenTP1の開始と同時に開始させることも，オンライン中にOpenTP1のコマンド（dcsvstartコマンド）で，任意の時期に開始させることもできます。このように，SUPは業務に応じた運用ができます。OpenTP1の開始と同時に開始させるかどうかは，ユーザサービス構成定義に指定します。

SUPの終了は，OpenTP1では制御していないので，業務終了後にSUP自身で終了するように作成します。

SUPはクライアント専用のUAPなので，サーバUAPとしてほかのUAPにサービスを提供できません。

クライアント/サーバ型の通信で，ユーザサーバとしてサービスを提供するサーバ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を別々のサービスグループとして開始することも，異なるサービスグループのサービス処理を同じサービス名で開始することもできます。

メッセージ送受信をする場合に使う，メッセージ処理専用の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アプリケーション定義，アプリケーション属性定義で指定します。

オフライン環境でDAMファイルにアクセスするUAPを作成できます。オフラインの業務をするUAPでは，OpenTP1開始前にDAMファイルを初期化する処理をします。

オフラインの業務をするUAPからは，DAMファイルの初期化処理以外のOpenTP1の機能（RPCやメッセージの処理）は使えません。

オフラインの業務をするUAPは，シェルから開始します。オフラインの業務をするUAPの開始，終了はユーザで管理します。