${HOME}/trf/cobexeディレクトリには、次のSimple Application CICS実行可能プログラムがあります。
${HOME}/trf/MAP_TCPディレクトリには、次のコンパイル済のSimple Application Data z/OS BMSマップセットがあります。
3.
|
次の行で、キーワードfilename=に続けて、物理マップセット( .mpdefファイル)の物理パスを入力します。
|
注意:
|
mapsets.descファイルはUNIX変数を受け入れないため、このファイルには完全に展開したパスを指定する必要があります。
|
•
|
<KIXDIR>: ~/.profileの ${KIXDIR}変数の値に置換する必要があります。
|
•
|
<HOME>: ~/.profileの ${HOME}変数の値に置換する必要があります。
|
注意:
|
ODCSF0は、物理ファイル名 PJ01AAA.SS.VSAM.CUSTOMERを指す、CICSで以前に定義された論理名を表します。従って、 EXEC CICS文によりCICS Cobolプログラムからこのファイルにアクセスするために認識されている唯一のファイル名でもあります。
|
2.
|
SIMPAPP CICS Runtimeグループ名に属するトランザクションのみが開始されることを、CICS Runtimeに対して示します。
|
Tuxedo
ubbconfigファイルの
*SERVERSセクションの次の例は、
ARTSTRNサーバーの構成を示しています。
ARTSTRNが属するTuxedoグループ名です。
ARTSTRNのTuxedoサーバーの識別子です。
ARTSTRNサーバーが起動されるためには、以前に定義された(かつコメントされていない) Tuxedoサーバー・グループ内の
ubbconfigファイルで定義される必要があります。
この例では、ARTSTRNはTuxedoサーバー・グループGRP02 (
SRVGRP=GRP02)に属しています。
Tuxedo tmadmin psrコマンドを入力して、必要なCICSランタイム・サーバー(
ARTTCPL、
ARTCNXおよび
ARTSTRN)がすべて実行されており、そのメッセージがTuxedoのドキュメントとこのドキュメントに準拠していることを確認します。
Tuxedo tmadmin pscコマンドを入力し、実行されているすべての異なるTuxedoサービスを表示することによって、別のチェックが可能です。
MRMパラメータをTuxedo ubbconfigファイルの*GROUPSおよび*RMSセクションのグループ・エントリに追加します。次の例を参照してください。
SRVGRPによって指定されるグループに関連付けられているトランザクション・マネージャ・サーバー名を示します。
MAXACTIVE=1は、この種類のトランザクション・クラスに属する同時トランザクションが同時実行できないことを示すため、この管理の例外です。
MAXACTIVEが2以上のトランザクション・クラスにリンクされているトランザクションはすべてCICS Runtime Tuxedoサーバー
ARTSTRNによって管理されており、他に何も変更する必要がありません。
MAXACTIVEパラメータが1に設定されているトランザクションでは、
ARTSTR1という名前のCICS Runtime Tuxedoサーバーが、特定の管理を専門に扱います。
注意:
|
CICS Runtimeトランザクション・サーバー(ARTSTRN、ARTSTR1、ARTATRNおよび ARTATR1)はすべて、同じCICS Runtimeトランザクション・グループ・サーバーを共有しており、ubbconfigサーバー・グループ・セクション(*GROUPS)を変更する必要はありません。
|
TRCLASS1が持っている最初のtransclassのmaxactiveパラメータは1であり、このtransclassに属するすべてのトランザクションが
ARTSTR1によって順次管理される必要があることを示します。
最後の2つのtranclasses (TRCLASS2および
TRCLASS10)は、maxactiveパラメータが1より大きく、これらのtranclassesに属するトランザクションが
ARTSTRNサーバーの管理下で同時実行できることを示しているため、実際類似しています。
変更が済むと、transactions.descファイルは次のようになります。
•
|
SA00には変更が行われませんが、これは、このトランザクション・コードにトランザクション・クラスが関連付けられていないことを意味しています。つまり、このトランザクションはMAXACTIVE=1パラメータに関連付けられておらず、順次トランザクションではありません。
|
•
|
SA02と SA03は、MAXACTIVE >= 2と定義されているトランザクション・クラスTRCLASS2とTRCLASS10にそれぞれ関連付けられています。これらのトランザクションが必要でないとわかっている場合、結果は、 SA02と SA03がSA00のようにトランザクション・クラスなしで定義されている場合と正確に同じになります。
|
•
|
順次実行できる SA01は、トランザクション・クラス・フィールドが必須である唯一のものです。それに関連付けられているトランザクション・クラス( TRCLASS1)が、実際にMAXACTIVE=1と定義されていることを確認します。
|
ARTSTRNサーバーと
ARTSTR1サーバーに関しては、ファイルは同じ方法で変更されますが、これらのサーバーの名前に接頭辞を付けるために使用される文字「s」(同期)を、文字「a」(非同期)に置き換える必要があります。
MAXACTIVEパラメータが厳密に1より大きい並列非同期トランザクションを使用するための専用サーバーが
ARTATRNです。
atrn_serverをインストールするには、
ARTSTRNサーバーのインストールについて説明している項を参照してください。
MAXACTIVEパラメータが正確に1に等しい非並列的な非同期トランザクションを使用するための専用サーバーは
ARTATR1です。
ARTSTR1サーバーをインストールするには、
ARTSTR1サーバーの理由とインストールについて説明している項を参照してください。
このサーバーをアクティブ化するには、UBBCONFIGファイルの
*SERVERSセクションで
ARTSRMを構成します。一連の
ARTSRMサーバーが各CICSリージョンの同じグループにある場合のみ、これらを構成できます。次に例を示します。
1.
|
ASYNC_QSPACEという名前のOracle Tuxedo /Qキュー・スペース
|
2.
|
ASYNC_QSPACE内の ASYNC_QUEUEという名前のOracle Tuxedo /Qキュー。
|
•
|
QMCONFIG変数 QMCONFIG - Tuxedo /Qキュー・スペース ASYNC_QSPACEが格納されているディレクトリのフルパスが含まれています。
|
•
|
KIX_QSPACE_IPCKEY変数 - キュー・スペースのIPCキーが含まれています。
|
2.
|
コマンドラインからmkqmconfig.shを実行して、Tuxedo /Q機能を作成します。
|
2.
|
それから、2台のサーバー、TMQUEUEと TMQFORWARDを、ubbconfigファイルの *SERVERSセクションに追加する必要があります。
|
tmadmin psrおよび
pscコマンドを使用して、4台の新しいサーバーと2つの新しいサービスが実行されていることを確認します。
使用される文は、EXEC CICS WRITEQ TS … END-EXEC、
EXEC CICS READQ TS … END-EXEC、
EXEC CICS DELETEQ TS … END-EXECです。
Tuxedo tmadmin psrおよび
pscコマンドを使用して、サーバーが実行され、6つの新しいサービスが公開されていることを確認します。
TSキューは、KIX_TS_DIR UNIX環境変数で定義される専用ディレクトリの順編成ファイルに格納されます。この変数は、
~/.profile UNIXシステム・ファイルで定義され、そこからエクスポートされます。
パラメータがOracle_XA Managerに送信します。
イントラパーティション・キューは、『Oracle Tuxedo Application Runtime for CICSリファレンス・ガイド』に記載されている
tdqintra.descファイルで宣言されています。
現在のリリースではtdqintra.descには文書化のためにのみ含められ、考慮されるのは、/Q構成におけるこれらの値です。
qmadminと
/Q構成の正確で詳細な情報は、Tuxedoドキュメントの
ATMI /Qコンポーネントの使用に関する項を参照してください。
デバイス(KIX_TD_QSPACE_DEVICE)およびQSPACEの作成方法は標準であり、ここでは説明を省略します。
キューを含むqspaceを開くためのqopen QspaceNameコマンドは、任意のキューを作成する前に作成する必要があります。
QspaceNameは、これらのキューのリソース宣言での
QSPACENAMEと一致する必要があります。
qmadminを使用した対話型のキュー作成の例は次のとおりです。
qmadminからの質問は標準のフォントで表示され、ユーザーが入力したエントリは太字で表示されています。
QspaceNameは、これらのキューのリソース宣言での
QSPACENAMEと一致する必要があります。
使用される文は、EXEC CICS WRITEQ TS ... END-EXEC、
EXEC CICS READQ TS ... END-EXEC、
EXEC CICS DELETEQ TS ... END-EXECです。
CICS Runtimeには、このような表すべてを作成できるUNIXスクリプト、crtsptable_{Oracle|UDB}が用意されています。これらの表を作成するには、
MT_DB_LOGIN環境変数を設定し、
crtsptable_{Oracle|UDB}を実行します。
MT_DB_LOGINを設定し、データベース接続情報を入力します。このファイルの例は、次のとおりです。
DBUSER/DBPASSWD@DBSID。Oracleデータベース・ユーザーの例については、
リスト5‑27を参照してください。
2.
|
続いて、Tuxedo UBBCONFIGファイルを変更して、 UBBCONFIG *GROUPSセクションで、 ARTTSQPがOracleへの接続を確立するために使用するサーバー・グループを変更します。
|
3.
|
次に、ARTTSQP CICS Runtime Tuxedoサーバーをアクティブ化します。アクティブ化するには、このサーバーを UBBCONFIG *SERVERSセクションに追加します。例については、 リスト5-28を参照してください。
|
4.
|
最後に、Tuxedo tmadmin psrおよび pscコマンドを使用して、サーバーが実行されていること、および新しいサービスが公開されていることを確認します。例については、 リスト5‑29を参照してください。
|
ARTTSQP_UDBを使用する場合、新規DB2サーバー/表を再バインドするために、次の手順を実行する必要がある場合があります。
1.
|
環境変数MT_DB_LOGINを設定し、データベース接続情報を入力します。
|
Oracle_XA Managerに送信されるパラメータです。
ARTTSQPが属するTuxedoグループ名です。
ARTTSQPのTuxedoサーバーの識別子です。
SYSID(XXXX) : Remote CICS region name
SYNCONRETURN : Used for remote CICS syncpoint or rollback
TRANSID(XXXX) : Remote mirror transaction instead of the CSMI default
Tuxedo tmadmin psrおよび
pscコマンドを使用して、このサーバーが実行されていること、および新しいサービスが公開されていないことを確認します。
EXEC CICS LINK文で呼び出される分散プログラムをアプリケーションが使用できるようにするには、これらのプログラムをCICS Runtimeに対して宣言する必要があります。
•
|
programs.descファイルで、 REMOTESYSTEM (csv形式データセットの7番目のフィールド)をリモートの SYSID名( リスト5‑32のサンプルの KIXD)に設定します。
|
デフォルトはlocal (空のフィールド)で、これはFULL CICS APIを使用できるため、ローカル・プログラムが宣言されることを意味します。
3.
|
Tuxedo tmadmin psrおよび pscコマンドを使用して、DPLプログラムのための新しいサービスが、 ARTDPL: KIXD_RSSAT0001および KIXD_RSSAT0003によって公開および管理されていることを確認します。
|
リストされているサービスのスコープを、ARTDPL (SRVID=500)による管理対象のみに減らすには、Tuxedo
pscコマンドに
-i srvidパラメータを続けて使用し、表示を特定のサーバーIDに制限します。
この領域は、CICS文EXEC CICS ADDRESS CWAが提供するポインタによってアドレッシングされます。アプリケーションにこのCICS文がある場合、CICS Runtime内にこの機能を実装する必要があります。
2.
|
~/.profile UNIXシステム・ファイルを変更して新しいCICS Runtime変数( KIX_CWA_SIZE)をエクスポートし、それを DFHSITの WRKAREAにある値に設定します。この変数が宣言されない場合、デフォルト値は0で、認可される間隔は0 - 32760バイトになります。
|
3.
|
~/.profile UNIXシステム・ファイルを変更して新しいCICS Runtime変数( KIX_CWA_IPCKEY)をエクスポートし、それをCWAとして使用されるクロス・メモリー・セグメントを定義するUNIX IPCキーに指定します。
|
CICS ADDRESS TWAの後では、
TRANSACTION-WORK-AREAという名前のCOBOLグループのアドレスは、CICSによって割り当てられるTWAのアドレスに設定されますが、これは、
TRANSACTION -WORK-AREAがこのメモリー領域をマップおよび調整することを意味します。この共有メモリーの総量は、z/OS
CSD構成ファイルのフィールド
TWasizeで、各トランザクションに対して定義されます。
次の画面には、SA00トランザクション・コードに対して
TWasizeパラメータが122に設定される、z/OS
CEDAシステム・トランザクションの結果が表示されます。
2.
|
CICS ADDRESS TWA文を持つプログラムを使用する各トランザクションに対して、 transactions.descファイルを変更して、その TWasizeをこのcsv形式ファイルの16番目のフィールドで宣言します。
|
DFHMIRSは、インバウンド関数の送信を処理するCICS内の内部ミラー・プログラムです。CICS RTでは、このミラー・プログラムは、TWAが使用される場合に、トランザクション・リソース・ファイル内のリンク・プログラムの実行に使用するトランザクションの下で定義されている必要があります。リストでは、ARTDPLにより、CPMIという名前のトランザクションで、リモートのリンク・プログラムが実行され、そのTWAサイズは100に相当します。
ART CICSトランザクション・トリガー・モニター(ARTCKTI)は、CICS CKTIトランザクションと同じ動作をします。1つまたは複数のWebSphere MQ開始キュー上でリスニングし、トリガー・イベントが発生するとトリガー・メッセージを取得し、トリガー・メッセージをターゲット・トランザクションに転送します。
ARTCKTIは、スタンドアロンのOracle Tuxedoサーバーです。
ARTCKTIサーバーは、次のように動作します。
4.
|
構造MQTMCから MQTMC2にトリガー・メッセージを転送します。
|
MQTMCには多くのフィールドがあるため、構造を
EXEC CICS START呼出しのパラメータとして送信すると、いつでも複雑になりすぎます。
MQTMC2はCKTIで使用され、構造をデータとしてトリガー・モニターの
STARTリクエストに渡します。
CICS CKTIトランザクションは、非同期呼出し(EXEC CICS START)を使用してターゲット・トランザクションを開始するため、
ARTCKTIサーバーも、非同期呼出し(Tuxedo
tpacall)を使用してターゲット・トランザクションを開始します。
注意:
|
デフォルトでは、ARTCKTIはクライアント・モードと特定のWebsphere MQバージョンで構築されます。 ARTCKTIがサーバー・モードでWebsphere MQにアクセスする場合、またはWebsphere MQランタイムのバージョンが、デフォルトの ARTCKTIを構築したときのバージョンより低い場合には、 ARTCKTIサーバーを再構築する必要があります。詳細は、 「ARTCKTIサーバーの再構築」を参照してください。
|
ARTCKTIは、ubbconfigファイル用に次のパラメータを受け入れます。
•
|
-s retry_interval: ARTCKTIがWebSphere MQキュー・マネージャに再接続するか、失敗時にWebSphere MQ開始キューを再オープンする場合の再試行間隔を指定します。
|
前述の例では、INIT1がプロセス
APP1.Pに関連付けられたトリガー・キューとして定義されており、キューに配置された
FIRSTメッセージがトリガーに使用されることを指定しています。それに続くプロセス定義では、
APPLTYPEをUNIXと定義し、ART for CICSトランザクションIDをトリガーするように
APPLICIDとして指定しています。
この定義に基づいて、最初のメッセージがINIT1キューに配置されるとき、
ARTCKTIトリガー・モニターが
ARTATRNサーバーで
START TRANID('SA01')します。アプリケーション・トランザクションが実行されると通常、キューが進み、使用可能なメッセージがすべて処理されます。次に新しいメッセージが
INIT1に配置されると、再びトリガーされます。
TMS_MQMサーバーを構築し、
setenvで設定されている
PATHに含まれるディレクトリに、正しい実行権限で配置します(たとえば、
$TUXDIR/binと
$KIXDIR/bin)。
トランザクション・サーバー(ARTSTR*/ARTATR*/ARTDPL)を構築し、それを
$KIXDIR/binディレクトリ、または
$APPDIRの下のローカル・ディレクトリに正しい実行権限で配置します(ただし、その後
setenvの
$PATH定義に追加します)。
ARTATRNの例を参照してください。
•
|
-rフラグには、リンクするRMを指定します。たとえば、 -r Oracle_XAはOracle DBのRM定義を示し、 -r MQSeries_XA_RMI_COBはCOBOLプログラムのMQ RMを示します。
|
ARTCKTIサーバーをビルドするには、
$KIXDIR/binディレクトリへの書込み権限を持つOracle Tuxedo管理者として、次のコマンドを実行します。
注意:
|
$MQMDIRは、WebSphere MQがインストールされているパスです。
|
WebSphere MQに正しく接続するためのシーケンスは、MQCONN、
MQOPEN、
MQxxx (
GET/PUT)、
MQCLOSEおよび
MQDISCです。メインフレームCICSでは、
MQCONNおよび
MQDISCは多くの場合、リソース管理機能としてCICSによって処理され、アプリケーションは
MQOPEN/MQxxx/MQCLOSEを実行するだけです。
+ MQGMO-FAIL-IF-QUIESCING
MQPUTの場合、
MQMD-FORMATが
MQFMT-STRINGに設定されていれば、ASCIIからEBCDICへの変換は自動的に行われます。例:
SENDERとしてチャネルを定義してローカルのWebSphere MQサーバーを使用する場合、チャネル定義で
CONVERT (YES)を追加すると、プログラムを変更せずにトランスコードを実行できます。
•
|
この機能が有効な場合、ユーザー・アプリケーションで [PA1]/ [PA2]を使用できません。
|
•
|
ARTSRM (同じユーザーが異なるターミナルを介してART for CICSに接続することを防ぎます)。
|
•
|
ARTSTRN (アプリケーション・リスト・トランザクションおよびユーザー・トランザクションを実行します)。
|
CICSランタイム・サーバーARTCSKLは、ART for CICS TCP/IPソケット・リスナーです。クライアント・リクエストを受信すると、作業タスクにリクエストを渡して処理を依頼し、別のクライアント・リクエストを待機します。CICSランタイム・トランザクション・サーバー
ARTATRN/ARTATR1は、ユーザー作成トランザクションを開始および実行します。
•
|
ARTATRN/ARTATR1で実行されるクライアント・アプリケーションおよびユーザー・トランザクションは、C言語でもCOBOL言語でも記述できます。すべてのサポートされるプラットフォーム上でCソケットAPIによって返されるerrnoおよびAIX/Solarisプラットフォーム上でCOBOLソケットAPIによって返されるerrnoは、メインフレームとは異なります。プログラムで errno.hのマクロ定義を使用します。
|
•
|
EXEC CICS STARTを使用した遅延間隔なしでのユーザー・トランザクションの開始のみサポートされます。
|
•
|
ARTCSKLは、サポートされる唯一のソケット・リスナーです。ユーザー作成リスナーはサポートされません。
|
|
|
|
|
|
サーバーはaccept()呼出しを発行し、クライアントからの接続リクエストを受け入れます。呼出しでは socket()の呼出しですでに作成され、 listen()の呼出しによってマークされたソケットを使用します。
|
|
|
bind()の呼出しでは、一意のローカル・ポートを既存のソケットにバインドします。 socket()呼出しの正常完了時、新規ソケット記述子に関連付けられているポートはないことに注意してください。
|
|
|
close()の呼出しでソケットを停止し、そのソケットに割り当てられているすべてのリソースを解放します。ソケットが開いているTCP接続を参照している場合、接続は閉じられます。入力データのキュー登録時にストリーム・ソケットが閉じられている場合、TCP接続は完全に閉じられるのではなく、リセットされます。
|
|
|
connect()の呼出しでは、ローカル・ソケットとリモート・ソケットとの間の接続の確立を試みます。ストリーム・ソケットの場合、呼出しで2つのタスクが実行されます。
|
|
|
fcntl()の呼出しでは、ソケットがブロッキング・モードか非ブロッキング・モードかを制御します。
|
|
|
gethostid()では、ネットワーク・バイト・オーダーで現在のホストの一意の32ビット識別子を取得します。この値は、デフォルトのホームIPアドレスです。
|
|
|
gethostname()では、プログラムが実行されているホスト・プロセッサの名前を返します。
|
|
|
getpeername()では、指定されたソケットに接続されたピアの名前を返します。
|
|
|
getsockname()の呼出しでは、nameパラメータによって示されたsockaddr構造体内のソケットの現在の名前を返します。
|
|
|
getsockopt()では、ソケットに関連付けられているオプションを取得します。
|
|
|
ioctl()の呼出しでは、ソケットの動作特性を制御します。
|
|
|
listen()の呼出しでは、クライアント接続リクエストを受け入れる準備ができていることを示します。
|
|
|
read()の呼出しでは、指定された接続済ソケットでデータを読み取ります。
|
|
|
recv()の呼出しでは、指定されたソケットでデータを受信します。
|
|
|
recvfrom()の呼出しでは、指定されたソケットでデータを受信します。 recvfrom()の呼出しは、接続済か未接続かに関係なく任意のデータグラム・ソケットに適用されます。
|
|
|
select()の呼出しは、複数の処理が発生する可能性のあるプロセスで有用で、プログラムが1つまたは複数の処理の完了を待機できる必要があります。
|
|
|
send()では、接続済のソケットでデータを送信します。
|
|
|
sendto()では、呼出しで指定されたアドレスにデータを送信します。
|
|
|
setsockopt()では、オプションを設定します。
|
|
|
shutdown()の呼出しでは、全二重接続のすべてまたは一部を停止します。
|
|
|
socket()の呼出しでは、通信のエンドポイントを作成し、エンドポイントを表すソケット記述子を返します。
|
|
|
write()では、接続済のソケットでデータを書き込みます。
|
|
|
getclientid()の呼出しでは、TCP/IPアドレス空間に既知の呼出し元アプリケーションの識別子を返します。
|
|
|
initapi()呼出しでは、アプリケーションをTCP/IPインタフェースに接続します。
|
|
|
takesocket()では、別のプログラムからソケットを取得します。
|
注意:
|
takesocket()の呼出しはARTATRN/ARTATR1でのみ使用できます。givesocket()の呼出しはサポートされません。
|
|
|
|
|
|
サーバーはACCEPT呼出しを発行し、クライアントからの接続リクエストを受け入れます。
|
|
|
一般的なサーバー・プログラムでは、SOCKETの呼出しの後に BINDの呼出しが続き、新規ソケットの作成のプロセスが完了します。
|
|
|
CLOSEの呼出しではソケットを停止し、そのソケットに割り当てられているすべてのリソースを解放します。
|
|
|
CONNECTの呼出しは、ローカル・ソケットとリモート・ソケットとの間に接続を確立するためにクライアントによって発行されます。
|
|
|
ソケットのブロッキング・モードは、問い合せることも、FCNTLの呼出しで記述される FNDELAYフラグを使用して非ブロッキングに設定することもできます。
|
|
|
|
|
|
READの呼出しでは、ソケットでデータを読み取ります。
|
|
|
RECVの呼出しでは、 READ同様、記述子 Sのソケットでデータを受信します。
|
|
|
RECVFROMの呼出しでは、記述子 Sのソケットでデータを受信し、バッファに格納します。
|
|
|
|
|
|
SENDの呼出しでは、指定された接続済ソケットでデータを送信します。
|
|
|
SENDTOは、宛先アドレス・パラメータが含まれている点以外 SENDと同様です。
|
|
|
SHUTDOWNの呼出しを使用して、一方向トラフィックを閉じると同時に反対方向のデータ転送を完了します。
|
|
|
SOCKETの呼出しでは、通信のエンドポイントを作成し、エンドポイントを表すソケット記述子を返します。
|
|
|
WRITEの呼出しでは、接続済のソケットでデータを書き込みます。
|
|
|
GETCLIENTIDの呼出しでは、呼出し元プログラムでTCP/IPアドレス空間に既知の呼出し元アプリケーションの識別子を返します。
|
|
|
INITAPIの呼出しでは、アプリケーションをTCP/IPインタフェースに接続します。
|
|
|
TAKESOCKETの呼出しでは、別のプログラムからソケットを取得し、新規ソケットを作成します。
|
注意:
|
GETSOCKOPT、 IOCTL、 SETSOCKOPTおよび GIVESOCKETはサポートされません。
|
図5‑5に、設定に関係するCICS Runtimeコマンドおよびソケット呼出しのシーケンスを示します。CICSランタイム・コマンドの先頭には
EXEC CICSが付いています。この図の他の番号付きアイテムはすべてART for CICS TCP/IP呼出しです。
|
|
|
|
|
CICS TCP/IPの場合、ドメインはTCP/IPインターネット・ドメイン(AF_INET)のみです。タイプは、ストリーム・ソケット( SOCK_STREAM)またはデータグラム・ソケット( SOCK_DGRAM)です。プロトコルは、TCPまたはUDPです。
成功の場合、SOCKETの呼出しはソケット記述子 sを返します。これは常に小桁整数です。取得したソケットはローカルまたは宛先アドレスにまだアタッチされていないことに注意してください。
|
|
|
|
標準モードで実行される場合、これで最初のメッセージがARTCSKLに送信されます。標準モードのリスナーは、クライアントからの最初の伝送内の ARTCSKL入力書式を必要とします。メッセージには、データの最初の4バイトとしてCICSトランザクション・コードが含まれています。バッファ・アドレスおよび送信するデータの長さも指定する必要があります。
|
|
|
|
|
|
|
|
これで、リスナー・プログラムのEXEC CICS STARTコマンドによって渡されるデータを取得します。このデータには、ソケット記述子およびリスナー・クライアントID、オプションでクライアントからの追加データが含まれます。
|
|
TAKESOCKETパラメータで取得するソケット記述子およびリスナーのクライアントIDを指定する必要があります。この情報は、 EXEC CICS RETRIEVEコマンドによって取得されます。
|
|
|
|
|
ARTCSKLはART for CICS TCP/IPソケットのリスナーで、CICS TCP/IPリスナーCSKLと同じ機能を実行できます。クライアント・リクエストを受信すると、作業タスクにリクエストを渡して処理を依頼し、別のクライアント・リクエストを待機します。
ARTCSKLは標準モードまたはエンハンス・モードで実行できます。モードは、ART for CICS TCP/IPソケット・リスナー構成ファイル(
listener.desc)の
FORMATパラメータを介して設定できます。
注意:
|
ARTCSKLは、サポートされる唯一のソケット・リスナーです。ユーザー作成リスナーはサポートされません。
|
ARTCSKLはこのアクティビティの一部をパラレルで実行するよう作成されており、着信接続リクエストを受信するポートを持つリスニング・ソケットがあります。接続リクエストを受信すると、
ARTCSKLはこの接続のエンドポイントを表す新規ソケットを作成し、TCP/IPソケットの
givesocket/takesocket呼出しでアプリケーションに渡します。
標準モードの
ARTCSKLは、クライアントからの最初の伝送内の次の入力書式を必要とします。クライアントはレスポンスを待ってから後続の伝送を送信します。入力は大文字の場合と小文字の場合があります。カンマが必要です。
エンハンス・モードの
ARTCSKLにはこの入力書式は必要ありません。ART for CICSは、TCP/IPソケット・リスナー構成ファイル(
listener.desc)からトランザクション情報を取得します。
ユーザー・トランザクション・プログラムは、EXEC CICS RETRIEVE関数を使用してリスナーによって渡されたデータを取得し、IPv6ソケット・アドレス構造体を格納するために確保した記憶域を拡張します。
EXEC CICS RETRIEVE関数で指定された
LENGTHには、リスナー出力書式を格納するために確保された記憶域の量が反映される必要があります。
LENGTHが送信されたデータの量より小さい場合、
LENGERRフラグが上げられます。
HANDLE条件をコーディングすると、これを含めることができます。
unsigned long give_take_socket; /* Socket being given */
char listen_name[8]; /* Listener name */
char listen_taskid[8]; /* Listener task id */
char client_in_data[35]; /* Client data */
char ote[1]; /* Threadsafe ind. @W1C */
union { /* Clients socket address */
struct sockaddr_in6 sin6;
char reserved2[68]; /* reserved */
unsigned long give_take_socket; /* Socket being given */
char listen_name[8]; /* Listener name */
char listen_taskid[8]; /* Listener task id */
char client_in_data[35]; /* Client-in-data */
char ote[1]; /* Threadsafe ind. @W1C */
char reserved2[68]; /* reserved */
short client_in_data_length; /* Length of data recved */
char client_in_data_2; /* data from Client */
この例では、2つのCICSリージョンが定義されています。SYSIDは、
kixrおよび
kixlとしてそれぞれ指定されています。
kixlでは
GMTRAN=ISSSを指定しており、ユーザーが
DBDCkixLにログインすると、トランザクションが自動的に起動されます。一方、
kixrでは
GMTRANを指定していないため、デフォルトの
CSGMが使用されます。
kixlで指定された
LGNMSGにより、
EXTRACT LOGONMSGで
ISSUE PASSを使用したデータ転送機能が有効になります。
system.descの詳細は、
システム構成ファイルに関する項を参照してください。
GMTRANが定義されている場合(
CSGM、
CESN、
CESFなど、他のシステム・トランザクションではない)、トランザクション/プログラムを
transactions.desc/programs.descで構成し、
ARTSTRN/ARTSTR1でロードする必要があります。
transactions.desc/programs.descの詳細は、
トランザクション構成ファイルに関する項および
プログラム構成ファイルに関する項を参照してください。
•
|
ARTCNXで公開されるDDRを構成する必要があります(例については、次を参照)。
|
ROUTING RANGESで構成される
APPLIDは、大文字で指定する必要があります。
ARTLOGNが正常に起動したかどうかを確認するには、
Tuxedo tmadmin psrおよび
tmadmin pscを使用します。
ARTCNXおよび
TMQUEUEは、各リージョンに含まれています。
図5‑7に示すように、これらのリージョンで発生する対話は、次のとおりです。
•
|
KIXA内のターミナルから CICAへ発行されるAPPCアウトバウンド対話
|
•
|
CICA内のターミナルからKIXBへ発行されるAPPCインバウンド対話
|
system.desc構成ファイルでは、次のCICSリージョンが定義されます。
connection.desc構成ファイルでは、次の接続が定義されます。
•
|
KIXB: KIXBへの接続、プロトコルは APPC
|
•
|
KIXC: KIXCへの接続、プロトコルは LU61
|
•
|
CICA: CICAへの接続、プロトコルは APPC
|
•
|
KIXA: KIXAへの接続、プロトコルは APPC
|
•
|
CICA: CICAへの接続、プロトコルは APPC
|
•
|
KIXA: KIXAへの接続、プロトコルは LU61
|
programs.desc構成ファイルでは、次のプログラムが定義されます。
transactions.desc構成ファイルでは、次のトランザクションが定義されます。
•
|
KVA0: COVSATMC上の APPCクライアント、同期レベル0
|
•
|
KVA2: COVSATMC上の APPCクライアント、同期レベル2
|
UBBCONFIGファイルでは、次のものが構成されます。
•
|
KIXAの ARTSTRNサーバーと、 transactions.descで定義される3つのサービス( KVA0、 KVA2および RV60)
|
•
|
KIXBの ARTCTRNサーバーと、 transactions.descで定義される1つのサービス( KIXB_KVA5)
|
•
|
KIXCの ARTCTRNサーバーと、 transactions.descで定義される1つのサービス( KIXC_RV65)
|
注意:
|
UBBCONFIGでの ARTCTRN構成では、 CONV=Yを指定する必要があります。
|
DMCONFIGファイルでは、次のものが構成されます。
system.desc構成ファイルでCICSリージョンを定義します。
KIXRおよび
KIXXという2つのリージョンを定義する例を、次に示します。
DBDCkixRおよび
DBDCKIXXは、それぞれのアプリケーション定義です。
ISC_ENABLE環境変数を
YESに設定して、同期処理機能を有効にします。
system.desc構成ファイルでCICSリージョンを定義します。
KIXRおよび
KIXXという2つのリージョンを定義する例を、次に示します。
DBDCKIXRおよび
DBDCKIXXは、それぞれのアプリケーション定義です。
この例では、KIXXリージョンからのリクエストは
GRPKIXX内の
ARTSTRNにルーティングされ、他のすべてのリクエストは
GRPKIXR内の
ARTSTRNにルーティングされます。
z/OSで、CICSプログラムはWRITEQ TDコマンドでJCL/KSHジョブを送信し、TDQによってJCL/KSHジョブ文をJES内部リーダーに渡すことができます。ART CICS Runtimeでは、特別なTDQ定義と、TuxJESシステムによって通知される内部サービスを使用して、この機能をサポートします。
•
|
BLOCKFORMAT: TuxJES内部リーダーへのインタフェースとして使用されるエクストラパーティション・キューの非ブロックまたはブロック・レコード書式。
|
z/OSで、CICSプログラムはSPOOLWRITEコマンドでJCL/KSHジョブを送信し、
SPOOLでJCL/KSHジョブ文をJES内部リーダーに渡すことができます。ART for CICSでは、TuxJESシステムによって通知される内部サービスを使用して、この機能をサポートします。
注意:
|
終了フラグをSPOOLファイルに書き込み、JCL/KSHジョブを送信します。そうしないと、 SPOOLに書き込まれたジョブ・ファイルは、 EXEC CICS SPOOLCLOSEが使用されると自動的にJCLジョブ・ファイルとしてTuxJESに送信されます。
|
•
|
artcicsutilはART for CICSサーバー ARTSRMと連携する必要があります。 artcicsutilは、CICSリソース関連の処理を一元化するトリガーです。 ARTSRMはART for CICSでの各CICSリージョンのポータルで、 ARTSRMがすべての処理の実行を担います。
|
//IPCP01 EXEC PGM=IPCPBTCH,PARM='CICS CC ONLY=CICS3'
このJCLでは、IPCPプログラムIPCPBTCHが内部で発行され(
EXEC PGM=IPCPBTCH)、ターゲットCICSリージョンが
CICS3と設定され(
EXEC PARM='CICS CC ONLY=CICS3')、CICSトランザクション
HEL1がターゲットCICSリージョンで開始されます(
INIT KC HEL1)。このケースでは、IPCPサブコマンドを
EXEC PARMとJCL
SYSIN DDの両方で発行できます。
artcicsutil -t IPCPBTCH "CICS CC ONLY=CICS3"
このKSH (artcicsutil -t IPCPBTCH "CICS CC ONLY=CICS3"サブコマンドを参照)では、プログラム
IPCPBTCHが
artcicsutilに翻訳され、
EXEC PARMが位置パラメータとして
artcicsutilに渡され、その他のすべてのサブコマンド(
SYSIN DDに含まれている)がartcicsutilが直接アクセスできるローカル・ファイルとしてART for Batchによって格納されます。
-tオプションを使用してコマンド・セットのタイプが指定され、その値は
IPCPBTCH (IPCPコマンド・セット)に設定されています。
ARTSRMは
artcicsutilユーティリティのプロキシであるため、
UBBCONFIGで構成する必要があります。対応するシステム構成ファイル(
system.desc)も構成する必要があります。詳細は、
「リソース・ファイルの構成」を参照してください。
各ART for CICSリージョンで
ARTSRMを構成する必要があります。
IPCPコマンド・セットのコマンドINIT KCや
ENAB/DISA KC、またはCAFCコマンド・セットの
STRTをJCLファイルで使用する場合、
UBBCONFIGで
ARTATRNを設定する必要があります。ターゲット・トランザクションをトランザクション構成ファイル(
transactions.desc)およびプログラム構成ファイル(
programs.desc)で定義する必要もあります。詳細は、
「リソース・ファイルの構成」を参照してください。
ARTATRNを使用する場合、各ART for CICSリージョンで
ARTATRNを構成する必要があります。
例については、リスト5‑62を参照してください。
artcicsutilが発行するリクエストはすべて、まず
ARTSRMによって受信されるため、
ARTSRMサーバーは必須です。その後
ARTSRMはプロキシとして動作し、ターゲットCICSサーバーにこれらのリクエストの処理を依頼します。JCLで
INIT KCサブコマンドが使用されるため(
リスト5‑60を参照)、
ARTATRNサーバーも指定します。
INIT KCサブコマンドのターゲットCICSトランザクションは、
ARTATRNサーバーにデプロイされたものです。
これは必須です。例については、リスト5‑63を参照してください。CICS Runtimeリージョン
CICS3を構成します。この
CICS3がJCLファイルで指定されるためです(
リスト5‑60の
EXEC PGM=IPCPBTCH,PARM='CICS CC ONLY=CICS3'サブコマンドを参照)。
これらはオプションです。IPCPコマンド・セットのコマンドINIT KCまたはCAFCコマンド・セットの
STRTがJCLファイルで使用される場合は、
ARTATRNが必要です。ターゲット・トランザクションをターゲット構成ファイル(
transactions.desc)およびプログラム構成ファイル(
programs.desc)で定義する必要があります。
エンドツーエンド・モードの場合、DMCONFIGを構成する必要があります。キー・サービス・エントリ
$(APPLID)_CICS_CTRLは、ART for CICSドメイン(
リスト5‑64の太字の
CICS3_CICS_CTRL)全体およびART for Batchドメイン(
リスト5‑65の太字の
CICS3_CICS_CTRL)全体でエクスポート/インポートする必要があります。このサービスは、構成されている各
ARTSRM (
ARTSRMは各ART for CICSリージョンで構成)によって通知されます。接頭辞
CICS3は、ターゲットCICSリージョンの
APPLIDです。
ここで、${APPLID}は大文字である必要があることに注意してください。
CICS3_CICS_CTRL RACCESSPOINT=BATCH1
1.
|
typeterms.descでプリンタ・ターミナル定義を構成します。次に例を示します。
|
3.
|
transactions.descで、プリンタ・プログラム定義をARTSTR1プログラム・グループに構成します。
|
4.
|
programs.descで、プリンタ・プログラムをARTSTR1プログラム・グループに構成します。
|
5.
|
terminals.descでプリンタ・ターミナルを定義して、プリンタ LUNAMEおよび TERMIDを指定します。
|
6.
|
UBBCONFIGで CLOPT -lオプションを使用して、プリンタ・プログラム・グループをARTSTR1プログラム・グループに構成します。
|
図5‑10は、典型的な使用例を示しています。このようなシナリオでの
STARTコマンドによる出力の実装手順は、次のとおりです。
2.
|
以前に指定したLUNAMEを使用して、プリンタ・ターミナルからART TCPへの接続を確立します。
|
4.
|
トランザクションAはSTARTコマンドにより非同期トランザクションBを起動し、 TERMIDを以前に定義した LUNAMEの1つとして指定します。
|
1.
|
tdqintra.descで ATIFACILITYおよび FACILITYIDを次のように構成します。
|
2.
|
terminals.descでPRT2を定義します。
|
ATIトリガー・レベルに達すると、TDI_TRIGGERクライアントが起動され、
-qオプションと
-dオプションがART CICSに通知して、
queue_nameおよび
space_nameに関連するトランザクションがターミナル
PRT2で開始します。
ART CICSでは、INVOKE WEBSERVICEコマンドを使用した、CICSアプリケーションからのWebサービスの呼出しをサポートしています。この機能を実装するには、次の項で説明する構成タスクを実行する必要があります。
cpy2recordツールを使用して、前の手順で生成したCOPYBOOKからRECORD定義を生成し、RECORDの環境変数をエクスポートします。詳細は、
RECORD型バッファの使用に関する項を参照してください。
webservice.desc構成ファイルにサービス・セクションを追加し、
webservice.descで
REQUESTおよび
RESPONSEを指定します。
リスト5‑69に例を示します。
UBBCONFIGファイルで
TMMETADATAおよび
GWWSサーバーを構成します。
リスト5‑70に例を示します。
libkixcallback.soという共有ライブラリを1つのみ作成し、その共有ライブラリで次の2つのコールバック関数を宣言する必要があります。
Linux/Solarisの場合は、$LD_LIBRARY_PATHにカスタマイズ済Cライブラリをインクルードします(AIXの場合は
$LIBPATH)。このライブラリは、実行時に動的にロードされます。
ARTDPLサーバーの起動時に使用される共有メモリーを作成する場合は、
libkixcallback.soという名前で共有ライブラリを作成する必要があります。この共有ライブラリは、2つのコールバック関数をエクスポートし、
$KIXDIR/lib/ディレクトリにある拡張共有ライブラリを置き換えます。詳細は、
「共有ライブラリlibkixcallback.soの作成」を参照してください。
ARTDPLサーバーを起動すると、まず
$KIXDIR/libの下にあるこの拡張共有ライブラリが検索されます。見つからなければ、Linux/Solarisの場合は
$LD_LIBRARY_PATH (AIXの場合は
$LIBPATH)の検索を続行します。この共有ライブラリが見つかると、
ARTDPLサーバーでロードされます。
ARTDPLサーバーの起動時に、Linuxプラットフォームでデータベース表の一部を開きたい場合は、
libkixcallback.soという名前の共有ライブラリを作成します。それによって2つのコールバック関数がエクスポートされ、このC共有ライブラリのパス名が
$LD_LIBRARY_PATH環境変数に含まれていることが確認されます。詳細は、
「共有ライブラリlibkixcallback.soの作成」を参照してください。
ARTDPLサーバーを起動すると、まず
$KIXDIR/libの下にあるこのカスタマイズ済共有ライブラリが検索されます。見つからなければ、
$LD_LIBRARY_PATHの検索を続行します。この共有ライブラリが見つかると、
ARTDPLサーバーでロードされます。
•
|
環境変数KIX_RESSECを Aまたは Yに設定します。
|
•
|
KIX_RESSEC=A: トランザクションでリソースにアクセスする際、リソースベースの認可が実行されます。これはすべてのトランザクションに適用されます。
|
•
|
KIX_RESSEC=Y: トランザクションでリソースにアクセスする際、リソースベースの認可が実行されます。これは、 transactions.descで RESSEC=Yが指定されたトランザクションにのみ適用されます。
|
•
|
KIX_RESSEC=Yを設定する場合、 transactions.descでリソースベースの認可をチェックするトランザクションに対して RESSEC=Yを構成します。
|
ART for CICSには、CheckResourceAuth.gntという名前のデフォルトの認可関数があります(ART for CICSインストール・ディレクトリ)。外部ESMと統合するには、デフォルトの
CheckResourceAuth.gntをカスタマイズした関数に置き換える必要があります。
•
|
UBBCONFIGでTuxedoセキュリティを有効にします。
|
CLOPT="-A -- -n /opt/oracle/CICS_RT/atnldap -z /opt/oracle/CICS_RT/atzldap"
3.
|
ユーザーAおよびBは、animユーティリティを起動したものと同じLinuxアカウントで独自のART for CICSアプリケーション・サーバーを起動するか、ART for CICSサーバーを再起動せずにデバッグ構成リソース・ファイルを動的に変更します。
|
Tuxedo ubbconfigファイルでサービスを宣言する場合、各サーバーでは、CLOPTオプションが次の2つのファイルを含むように定義されています。
たとえば、ARTSTRNサーバーには
stdout_strnという名前の標準出力があります。
たとえば、ARTSTRNサーバーには
stderr_strnという名前のエラー出力があります。
•
|
正常にインストールされ、各.desc構成ファイルの指定に応じて使用可能なリソース(インストールされていても使用できないリソースもあります)。
|
•
|
-lオプションで、1つのグループ(SIMPAPP)が選択されています
|
•
|
/**/を使用して単一行のコメントを表します。 EXEC CICSコマンドの中央にコメントを置かないでください。
|
•
|
EIB宣言は#ifndef行と #endif行で囲まれていますが、すべての変換済ファイルに 含まれるわけではありません。ART CICSは、 EIB内のすべてのフィールド定義を含めるために、ヘッダー・ファイル dfheiblk.hを公開しています。変換された各ファイルはこのヘッダー・ファイルをインクルードすることのみ必要であり、すべての処理はプリプロセッサによって自動的に実行されます。
|
•
|
BMS画面属性定義: CバージョンのDFHBMSCAファイルおよび DFHAIDファイルがCICSによって提供されており、BMSの使用時にはアプリケーション・プログラマによってインクルードされる可能性があります。
|
•
|
ART CICSには、cics.hで宣言される iscics()も用意されていますが、ユーザーは makefileを変更してヘッダー・ファイル・パスをインクルードすることのみ必要です。
|
•
|
C関数のexit()はreturnに変換されます。
|
•
|
C関数のmain()、そのパラメータ・リストおよびカッコは1行で指定します。例:
|
•
|
COMMAREAはポインタである必要があります。ART CICSでは、構造体の指定は、値ではなくポインタのみがサポートされます。
|
COMMAREAのアドレスは、引数としてC main関数に渡されません。ただし、ユーザーは次の2つの方法を使用して、
COMMAREAのアドレスを取得できます。
•
|
COMMAREAを指すグローバル・ポインタ __commptrの使用
|
cobを使用して、Cソース・コードを呼出し可能な共有オブジェクトとしてコンパイルします。動的ライブラリには、Cソース・ファイル名と同じ名前で大文字の名前が必要です。