CICS® Transaction Server for z/OS® プログラムは、入力として COMMAREA データ構造またはチャネル・データ構造のいずれかを使用してリンクが可能です。どちらの構造の場合も、出力として同じデータ構造を返します。 CICSRequest ノードは、COMMAREA またはチャネルのデータ構造による CICS との対話をサポートしています。
CICS と通信するための入力データ構造として COMMAREA を使用する場合、CICSRequest ノードは、CICSRequest ノードの「要求」プロパティーで定義されているように Input Body の一部を取得し、それを CICS に COMMAREA として送信します。
その後、戻される COMMAREA は Output ツリーに入れられて、CICSRequest ノードの「結果」プロパティーで定義された場所で既存の Body を置き換えます。 その後、COMMAREA は CICSRequest ノードの「応答メッセージの構文解析」プロパティーを使用して、構文解析のために構成されます。
入力として COMMAREA データ構造を定義する場合、CICSRequest ノードの「通信域の長さ」プロパティー値は、入力要求データまたは出力応答データが収まる十分な長さにしなければなりませんが、最大値の 32767 バイトは超えないようにしてください。 「通信域の長さ」値の長さが応答データまたは要求データで 使用するために十分でない場合は、CICS でメモリー・リークが 生じます。 COMMAREA のサイズを CICS プログラムで変更することはできません。 直列化された要求データが通信域の長さよりも大きい場合、データは通信域の長さとなるように切り捨てられます。 通信域の長さの値は、CICS 管理者または開発者から入手できます。
CICSRequest ノードの「データ構造」基本プロパティーのデフォルト値は、「通信域」です。
入力としての COMMAREA データ構造の使用法について詳しくは、CICS Transaction Server for z/OS データ構造の定義、CICSRequest ノードでのメッセージ・フローの開発、および CICSRequest ノードのためのメッセージの作成を参照してください。
CICS チャネルは、コンテナーと呼ばれる複数の構造を保持します。 コンテナーは、ターゲットの CICS プログラムがアクセスするビジネス情報を保持します。 各コンテナーは最大で 2 GB のデータを保持でき、チャネルには必要に応じていくつでもコンテナーを含めることができます。これにより、データのサイズとレイアウトの点で柔軟性が得られます。 それぞれのコンテナーには最大で 16 文字の英数字からなるコンテナー名があります。これはチャネル内で固有な名前で、チャネルからコンテナーのコンテンツを取り出すための手段として使用されます。
COMMAREA 構造とは異なり、応答チャネルのサイズは要求に対応している必要はありません。一方、COMMAREA の場合は要求に応答のサイズを見込んでおく必要があります。
CICS におけるチャネルおよびコンテナー
以下の図の例の場合、CICS チャネルには、CustomerName と Order という 2 つのコンテナーがあります。
01 ORDER_STRUCTURE.
03 QTY COMP-1.
03 ITEM PIC X(10).
03 PRICE PIC S9(9).
ターゲットの CICS プログラムは、GET CONTAINER API の使用時にコンテナー名を指定することにより、チャネルからどちらのコンテナーも取り出すことができます。 CICS プログラムにデータが提供されると、プログラムは自分が選んだ方法でデータを処理します。 例えば、プログラムは、PUT CONTAINER API を使用して、他のコンテナーをチャネルに入れて、呼び出されたコンテナーに対する応答を提供できます。WebSphere Message Broker におけるチャネルおよびコンテナー
WebSphere Message Broker では、CICS チャネルはメッセージ・コレクション構造として表されます。 メッセージ・コレクションは子メッセージを持つことができ、CICSRequest ノードによってそれぞれがコンテナーとして扱われます。 メッセージ・コレクション構造は、チャネル・データ構造の使用時には CICSRequest ノードの入力と出力の両方として使用されます。 メッセージ・コレクションについて詳しくはメッセージ・コレクションを、メッセージ・コレクションの作成方法については ESQL によるメッセージ・コレクションの作成をそれぞれ参照してください。
メッセージ・コレクション名を使用して、チャネルに名前が付けられます。 メッセージ・コレクション内の子メッセージの名前は、チャネル内のコンテナーの名前として使用され、固有でなければなりません。 メッセージ・コレクション内の子メッセージ名が固有でない場合には、CICS で要求が拒否されます。
CICS | WebSphere Message Broker |
---|---|
チャネル名 | メッセージ・コレクション名 |
コンテナー名 (親チャネルに対して固有でなければならない) | 子メッセージ名 (メッセージ・コレクションに対して固有でなければならない) |
名前値属性
WebSphere Message Broker では、コンテナーを作成するためにメッセージ・コレクションに名前値属性を追加することをサポートしています。 メッセージ・コレクションには 0 個以上の属性を指定できます。 属性名は、メッセージ・コレクションで固有でなければなりません。 メッセージ・コレクションの標準属性は、CollectionName と呼ばれる属性です。
名前値属性をメッセージ・コレクションに追加して、CICS コンテナーを作成できます。 メッセージ・コレクションで単純データに対して、CollectionName とは別の名前値属性を完全なメッセージ・フォルダーの代わりに使用できます。 例えば、メッセージ・コレクションで名前値ストリング属性を設定すると、そのエレメントのメッセージ・セットを作成しないでも、CICSRequest ノードがこの属性を直接使用することができます。
名前値属性は出力のコンテナーから生成できますし、入力としても受け入れられます。 コンテナーからメッセージ・フォルダーではなく属性を作成する方法については、CICSRequest ノードを参照してください。
以下の図の例の場合、CICS チャネルは Collection という名前のメッセージ・コレクションによって表されています。 Collection には、CustomerName および Order という名前の子メッセージによって表される 2 つのコンテナーがあります。 CollectionName と CustomerName はどちらも名前値属性ですが、CollectionName 属性は CICSRequest ノードによってコンテナーとして扱われないので、CICS には送信されません。
CustomerName 属性が CICSRequest ノードによって文字コンテナーとして扱われる場合、LocalEnvironment でこれを反映する必要があります。
LocalEnvironment
SET OutputLocalEnvironment.Destination.CICS.RequestChannel.Containers.<myContainerName> = CHARACTER;
要求に続いて、メッセージ・コレクションが CICSRequest ノードから発信されると、返されたコンテナーのタイプ情報が LocalEnvironment に入ります。 例えば、応答チャネルが CICS から戻ると、LocalEnvironment の以下の場所に、戻ってきたコンテナーのタイプが示されます。LocalEnvironment.CICS.ResponseChannel.Containers.<myContainerName> = CHARACTER
SET OutputLocalEnvironment.Destination.CICS.RequestChannel.ChannelName = <myNewChannelName>;
SET OutputLocalEnvironment.Destination.CICS.RequestChannel.SingleMessageContainerName = <mySingleMessageContainerName>;
メッセージ・コレクションを使用するとチャネル内の各コンテナーを別個のメッセージとしてモデル化できるので、それぞれのメッセージには独自の構造と構文解析のオプションを指定できます。 例えば、あるコンテナーを XML にして、別のコンテナーをコピーブックに基づいて作成できます。それぞれは、メッセージ・コレクション内で XMLNSC メッセージと MRM メッセージを使用して表せます。
メッセージ・コレクション内の子メッセージにはそれぞれ、その子メッセージに関連する Properties フォルダーに入っている、メッセージ・ドメイン、セット、タイプ、形式、CCSID、およびエンコードに関する各情報が含まれています。子メッセージはバイト・ストリームに直列化されて、CICS に送信されます。 CICS に送信される、メッセージ・コレクション内にある各子メッセージ・フォルダーは、メッセージ・プロパティー・ドメインの最後の子のレベルで直列化されます。 すべての CICS コンテナーを表すためにメッセージ・セットが必要とされるわけではありません。
前述の例の場合、Order コンテナーは MRM として表すことができ、それを表すためにコピーブック ORDER_STRUCTURE からメッセージ・セットを作成することができます。 戻されるチャネルはメッセージ・コレクションに変換され、メッセージ・コレクション内のすべての子メッセージは、チャネルのコンテナーを表します。 メッセージ・コレクション内の子メッセージは、子メッセージ名を使用して、メッセージ・ドメイン、セット、タイプ、形式、CCSID およびエンコードの情報のリストにマップされますが、文字メッセージの場合、CCSID とエンコードの情報は無視されます。 メッセージ内でマッピングが見つからない場合、デフォルトのマッピングを使用できます。
応答に含まれるコンテナー数を把握することはできないので、出力としては常にメッセージ・コレクションが生成されます。
CICSRequest ノードの「応答メッセージの構文解析」プロパティーを使用して、戻されるコンテナーを、メッセージ・ドメイン、セット、タイプ、形式、CCSID、およびエンコードの情報にマップできます。 特に、「結果データのロケーション」プロパティーを使用すると、結果ツリーを 1 つのメッセージ・フォルダーや、1 つの出力のフィールドまたはサブツリーまで減らすことができます。 「結果データのロケーション」プロパティーについては、CICSRequest ノードを参照してください。
チャネルは WebSphere Message Broker ではメッセージ・コレクションで表されるので、メッセージ・コレクション名を設定することにより、チャネル名を作成できます。 メッセージ・コレクション名は CollectionName 属性を使用して設定します。 メッセージ・コレクションの作成とメッセージ・コレクション名の設定について詳しくは、ESQL によるメッセージ・コレクションの作成を参照してください。
コンテナーは WebSphere Message Broker では子メッセージによって表されるので、子メッセージ名を設定することにより、コンテナー名を作成できます。 メッセージ・コレクションの作成および子メッセージ名の設定について詳しくは、ESQL によるメッセージ・コレクションの作成を参照してください。
CICSRequest ノードのメッセージ・コレクションを作成してデータを取り込むことによりチャネル・ベースの CICS プログラムを呼び出す方法、および呼び出し後にコレクションを処理する方法を示す例が提供されています。 詳しくは、CICS Transaction Server for z/OS Channel Connectivityを参照してください。