このドキュメントでは、CICS 環境の Natural を設定するためのガイドラインを説明します。
内容は以下のとおりです。
環境固有の考慮事項は以下のとおりです。
CICSplex 環境（z/OS のみ）で Natural を実行する場合は、Natural ロールサーバーを使用する必要があります。
しかし、単一の CICS リージョンで Natural をローカルに実行する場合は、複数の選択肢があります。
選択肢の 1 つは（z/OS のみ）、Natural ロールサーバーを使用することです。 CICS ロール機能およびスワッププールを使用することに対するロールサーバーの利点は、Natural ロールサーバーは、CICS リージョンに非同期に実行されるため、スワッププールよりデータスペースにおいて多くのロールバッファを提供できることです。
このセクションでは、次のセクションについて説明します。
両方のロール機能（VSAM および補助の一時ストレージ）をコントロールインターバルの最大サイズである 32 KB に定義することを強くお勧めします。 これにより、ロールを実行するのに必要な I/O の数および CPU オーバーヘッドを最小限にすることができます。
コントロールインターバルのサイズを 32 KB 未満にする理由には、ディスクトラックを有効利用できる、または VSAM バッファ用仮想ストレージを使用するということもあります。
CISIZE／レコードサイズが同じ場合は、一時ストレージは VSAM ロールファイルより CPU オーバーヘッドが少なくなります。
一時ストレージに n 個のレコードを書き込むには、n+1 個の CICS 要求を発行する必要があります（DELETQ に 1 個、PUTQ に n 個）。これに対して VSAM ロールファイルには、VSAM トランザクションロジック n 倍（UPDATE の READ に加えて REWRITE）のために 2 n 個の要求を発行する必要があります。
VSAM 更新要求に対しては物理的な I/O が常に実行されます。これに対して、一時ストレージ（AUX）レコードに対してはバッファが実行されるため、多くの場合、読み込まれるレコードはバッファに残っています。
しかし CICS 一時ストレージは、他のアプリケーションにも使用されている場合にはボトルネックになる場合があります。
特に I/O の競合を回避できる場合は、Natural で VSAM ロールファイルを使用する方がこの状況を克服できます（ただし追加の VSAM バッファスペースが必要です）。 他の要件のために CICS 一時ストレージファイルにこのレコードサイズを指定できない場合は、最適／最大の CISIZE／レコードサイズを持つ VSAM ロールファイルは特に効果的です。
CICS 一時ストレージを Natural 専用にできる場合は、常に CICS 一時ストレージを使用してください。 CICS 一時ストレージが他のアプリケーションにも使用される場合は、VSAM ロールファイルを使用するときの方が Natural のパフォーマンスが優れているかどうかを評価する必要があります。
CICS 一時ストレージを使用しても Natural のパフォーマンスが低下しない場合は、CICS 一時ストレージをロール機能に選択し、"節約できた" VSAM ロールファイルのバッファスペースは、TS バッファやスレッドの追加に使用してください。
主なロール機能は VSAM RRDS です。一時ストレージのデフォルトタイプは AUXILIARY です。
VSAM ロールファイルを使用している場合は、CICS セッション中にすべてのロールファイルがいっぱいになるか使用不可能になったときに、Natural CICS インターフェイスは一時ストレージ（AUX）を使用します。
ただし、ロールファイルを使用したくない場合、またはロールファイルが正しくインストールされていない場合、CICS 環境の Natural はすべてのロールに対して一時ストレージ（AUX）を使用します。 一時ストレージ（AUX）をロールファイルとして使用する場合、このファイルのコントロールインターバルのサイズは最低でも 4 KB 必要です。 補助の一時ストレージを利用できない場合は、代わりにメインの一時ストレージが使用されます。
CICS SIT パラメータ TS によって定義された VSAM バッファの数は、物理 I/O の数を減らすために適切な値に増やす必要があります。 CICS 統計で、このエリアのボトルネックをチェックしてください。
CICS のメインの一時ストレージをロール機能として使用すると、ロールにおいて I/O は実行されませんが、使用されるメインストレージが大きくページングが増加するため、調整を検討する必要がある場合があります。
FCT の BUFNO および STRNO パラメータなど、通常の CICS VSAM ファイルの調整については、VSAM ロールファイルを検討する必要があります。 CICS シャットダウン統計で、このエリアのボトルネックをチェックしてください。
ロールファイルは Natural に対して一種のページデータセットとして機能するため、ジャーナリングとロギングが発生します。このため、Natural のロール処理の速度を低下させるものはすべて回避する必要があります。ロールファイルに対するダイナミックトランザクションバックアウト（DTB）およびフォワードリカバリは機能せず、オーバーヘッドの原因となるだけです。
パフォーマンスの理由から、VSAM ロールファイルは Natural アプリケーションが実行されているのと同じ CICS システムで定義する必要があります。MRO 機能シップは起動しないでください。 利用できるバッファが十分にある場合は、CICS のローカル共有リソース（LSR）を使用することができます。
スレッド数より大きな文字列数（STRNO）で、Natural ロールファイルに対して個別の LSR プールを定義することをお勧めします。 バッファ数もスレッド数より大きい必要があります。 バッファ数が大きいほど索引のヒット率が上昇します。
大量の VSAM 一時ストレージ（AUX）バッファまたは一時ストレージ（MAIN）よりも、スワッププールを使用することを強くお勧めします。
Natural スワップマネージャは、圧縮されたセッションストレージを非常に効率的に処理し、CPU および I/O のオーバーヘッドを削減します。 スワッププールのサイズは、できるだけ大きくしてください。 例えば、50 KB スロットに適合する 50 のセッションを保持するには、2.5 MB のスワッププールが必要です。
パフォーマンスの観点からは、スワッププールのバックアップ機能としてメインの一時ストレージを使用することは意味がありません。これらの機能はいずれも CICS メインストレージを使用するためです。 しかし一般的には、CICS のサービスオーバーヘッドがなくなるため、スワッププールを使用する方が効率的です。 メインの一時ストレージにオーバーフローするよりも、スワッププールを拡大してディスクストレージ（つまり VSAM ロールファイルまたは補助ストレージ）をバックアップ機能として使用する方が有利です。
仮想ストレージがボトルネックになる場合は、ロール機能バッファの数およびスレッド数などを、スワッププールのために最小限にする必要があります。
Natural スワッププールキャッシュを使用する場合は、Natural の最大スレッドサイズのロールバッファが、スワッププールとその（データスペース）キャッシュ間での Natural セッションデータの転送に必要です。 このロールバッファはスワッププールの
GETMAIN から得られます。つまり、スワッププールに実際に利用できるストレージのサイズは、指定されたサイズから Natural の最大スレッドサイズを引いたものです。
したがって、スワッププールのサイズおよびそのキャッシュのサイズの両方が、Natural の最大スレッドサイズの少なくとも 2 倍である場合にのみ、Natural スワッププールキャッシュが割り当てられます。
このセクションでは、次のセクションについて説明します。
共有ストレージのスレッドは、Natural CICS システムの初期化時にあらかじめ割り当てられます。つまり、アクティブなセッションがあるかどうかに関係なく、これらのスレッドの対象となるストレージは Natural CICS システム専用に使用されます。
これに対して、GETMAIN を実行したスレッドは、CICS タスクがアクティブな間のみ存在します。
共有ストレージのスレッド（TYPE=SHR）については、CICS 環境の Natural は、Natural の初期化時にあらかじめ割り当てられたストレージを常に使用します。このため、Natural スレッドによって使用されるストレージのサイズは容易に予測することができます。 しかし、GETMAIN を実行したスレッド（TYPE=GETM）については、実際に使用されるストレージは、現在アクティブな Natural セッションの数によって異なります。
Natural 自体には GETMAIN を実行したスレッドの最大数を設定するメカニズムはありませんが、Natural トランザクションコードを TRANCLASS（CICS バージョン 4.1 より前の TCLASS）にグループ化することによって制御することができます。 トランザクションコードがこのようなクラスに属する場合は、並行タスクの最大数は、TRANCLASS 定義の MAXACTIVE パラメータによって（または CICS バージョン 4.1 より前の CICS システム初期化テーブル（SIT）の CMXT パラメータを使用して）調整することができます。
Natural セッションが共有ストレージのスレッドを解放するとき、別のセッションが特にそのスレッドを使用する必要がなければ、セッションデータは非圧縮形式でスレッドに保存されます。 この場合、新しいセッションが古いセッションのデータを保存する役割を果たします。
このようなアクティビティを "据え置きロール" と呼びます。 これにより、利用できるスレッドの数が、同時にアクティブな Natural セッションの数以上であれば、ローリングまたはスワッピングを完全になくすことができます。
これに対して GETMAIN を実行したスレッドを使用するセッションは、常に CICS タスクの終了時に FREEMAIN 操作に先立ってデータを保存します。このため、同時にアクティブな Natural セッションの数に関係なくローリング／スワッピングによるオーバーヘッドが発生します。
Natural トランザクションが大量に発生する環境においては、"即時" ロールによる方法でも" 据え置き "ロールによる方法でも、セッションデータの保存に実質的な違いはありません。
処理量が多く、プログラムストレージスレッドに対する Natural セッションの比率が高い Natural 環境においては、これらのスレッドは複数の Natural セッションによって共有されるため、ロールイン／ロールアウトのオーバーヘッドがさらに高くなります。 この状況で発生する可能性がある問題として、長期間にわたる Adabas 要求、つまり多くの Adabas 呼び出しを含む Natural タスクによって引き起こされるスレッドの競合があります。
このようなタスクによってスレッドが長期間 "ロック" されるのを防ぐために、Natural プロファイルパラメータ DBROLL を適切に使用することによって、これらのタスクのスレッドを強制的に解放することができます。
しかし、GETMAIN を実行したスレッドの場合は、複数の Natural セッション間の競合は発生しません。これは、TYPE=GETM スレッドは以前割り当てられていた Natural セッションにのみ属するためです。
このように、TYPE=GETM スレッドは共有されることのない "使い捨ての" リソースと考えることができます。これに対して、TYPE=SHR スレッドは共有できる "複数回使用可能な" リソースと考えることができます。
z/OS における CICS/TS の最も重要な機能は、トランザクションアイソレーションです。つまり、タスクのストレージを他のタスクから保護する機能です。
Natural でこの機能を利用するには、TYPE=GETM スレッドを使用する必要があります。これらのスレッドはトランザクションアイソレーションの対象となりますが、"共有される" TYPE=SHR スレッドは対象外になるためです。 また、CICS/TS では TYPE=SHR スレッドに対する CICS のオーバーヘッドが増加します。
TYPE=GETM スレッドのスレッド選択アルゴリズムは単純ですが（Natural タスクが開始されると、スレッドは CICS GETMAIN を介して割り当てられる）、TYPE=SHR スレッドではもっと複雑になります。この場合は、Natural スレッド環境は NCISTART（キューイングおよびバランス）によって管理されますが、CICS は Natural スレッドに関して何も認識しません。 CICS が遅くともタスクの終了時にスレッドを解放する TYPE=GETM スレッドとは違い、TYPE=SHR スレッドの場合、Natural セッションに対するスレッドの割り当て／解放を Natural で行う必要があります。 このために、Natural はスレッドコントロールブロック（TCB）のリストを保持しています。
Natural は、タスクの異常終了時に CICS が認識していないセッションリソース（例えば TYPE=SHR スレッド）を解放できるように出口を常にアクティブにしていますが、Natural タスクが、関連する TCB においてスレッドが解放済みとしてマークされることなく終了する状況が発生する場合があります（EXEC CICS ABEND CANCEL 要求が Natural によって呼び出された Natural 以外のプログラムで発行された場合、または Natural セッションがパフォーマンスモニタの KILL トランザクションによってフラッシュされた場合など）。
意図せずにスレッドが使用中のままになっている問題を防ぐために、CICS 環境の Natural では、常にスレッド選択アルゴリズムで、使用中のスレッドに関連する CICS タスクが存在するかどうかをチェックして、存在しない場合はそのスレッドを解放します。
CICS/TS より前の CICS バージョンでは、アクティブな CICS タスクに対するこのチェックは、コントロールブロックのジャンプによって実行されました。つまり、Natural は、タスクの EISTG、TCA、および TQE コントロールブロックの一貫性をテストすることによって、アクティブなタスクをチェックしていました。 CICS/TS では、トランザクションアイソレーションのために、別のタスクのストレージにアクセスすることはできません。
CICS/TS でこの機能を実現するために、NCISTART は、スレッド選択ルーチンにおいて使用中と認識されたスレッドに対して EXEC CICS INQUIRE STORAGE TASK() 要求を発行します。 つまり、スレッドリソースに対してタスクが最後に ENQueue される前に、CICS 要求があった可能性があります。 同じ CICS コマンドが、Natural セッションのシリアライゼーションにも使用されます（TYPE=SHR スレッドの据え置きロールなど）。
TYPE=SHR スレッドと TYPE=GETM スレッドのどちらも、長所と短所があります。 しかし CICS/TS では、次の理由から TYPE=GETM スレッドが有利です。
トランザクションアイソレーションのサポート（z/OS のみ）
より CICS に近い調整の可能性
TYPE=SHR スレッドのパフォーマンスの低さ
CICS SIT パラメータ AMXT および CMXT は、同時に実行する Natural タスクの数を制御するために使用します。
指定する数は、スレッド数より大きい必要があります。 また、非同期 Natural タスクおよび Natural Advanced Facilities スプールタスクに対して、適切な CMXT パラメータで個別のトランザクションクラスを指定することも検討する必要があります。これは、スレッドを占有するこのような "バックグラウンド" タスクが多すぎるために、"通常の" Natural 端末のタスクがログアウトするのを防ぐためです。 このようなトランザクションに特別なスレッドグループを定義することもできます。
Software AG の担当者からデバッグ目的のために依頼されない限り、Natural トランザクションに対する CICS ダンプは実施しないでください。 Natural は、プログラムチェック以外の異常終了に対して、および Natural
セッションパラメータ DU が ON に設定されている場合のプログラムチェックに対して、（EXEC CICS DUMP を介して）ダンプを生成します。 Natural ダンプが生成されない場合は、CICS ダンプは冗長でオーバーヘッドを発生させるだけです（特にシステム／リージョンのダンプを作成する場合。これは、スナップダンプが完成するまで CICS システム全体が停止されるためです）。
問題を分析するときに CICS のトレースは不可欠ですが、システムにオーバーヘッドが発生します。 また、CICS パフォーマンスモニタリングツールおよびアカウンティングパッケージは、30 パーセント以上のシステムオーバーヘッドを発生させます。 一部のパッケージでは、内部的に CICS トレースを有効にしてからインターセプトします。 この潜在的なシステムオーバーヘッドに注意してください。 Natural CICS インターフェイスは、CICS コマンドレベルのアプリケーションプログラミングインターフェイスを使用することも注意する必要があります。CICS コマンドレベルの要求は、CICS マクロレベル要求よりかなり多くのトレースエントリを（他のオーバーヘッドとは別に）生成します。
Natural は、RA（アドレス反復）および画面イメージなどその他の技術によってデータストリームを最適化します。他の行圧縮システムがインストールされた場合は、Natural トランザクションは、これらのシステムによって処理されないようにする必要があります。この理由は、オーバーヘッドが発生するだけで何の利点もないからです。
セッションを再開する場合、会話型の Natural タスクは最初のスレッドにロックされます。つまり、そのとき最初のスレッドを利用できない場合は、会話型のタスクはこのスレッドが空くのを待つ必要があります。 しかし、擬似会話型 Natural タスクは柔軟性があるため、空いている任意のスレッドを利用することができます。
言いかえれば、会話型のタスクに見られる "古典的な" 利点（画面 I/O 操作によるデータの保存／リストアにおいて I/O が少ない）は、Natural で使用されるスレッド技術のために Natural では活用されません。
CICS の Natural タスクは Adabas 呼び出しが完了するのを待つため、サービスを提供する Adabas リージョン／パーティションは、待ち時間を最小限にするために CICS リージョン／パーティションより常に優先度が高くなる必要があります。
CICS モニタリング製品は、CICS タスクを除去する機能を備えているため、アプリケーションによって設定された異常終了出口をバイパスできます。
 |
注意: このような機能を Natural タスクをキャンセルするのに使用しないでください。Natural はリソースをクリーンアップできない場合があります。さらに悪い場合、タスクの処理内容によっては Natural CICS システムが一貫性のない状態になる可能性があります。 |
Natural セッションをキャンセルするには、Natural SYSTP ユーティリティのセッションのキャンセル／フラッシュ機能を代わりに使用してください。詳細については、Natural の『ユーティリティ』ドキュメントで関連するセクションを参照してください。
