バッファプールとは、Natural プログラムを実行に備えて配置するストレージエリアのことです。 Natural ユーザーからの Natural オブジェクト要求に応じて、プログラムはバッファプールにまたはバッファプールから移動されます。 概念上、プログラムをリエントラントエリアにまたはリエントラントエリアからロードする点で、ロードバッファプールはオペレーティングシステムと類似の機能を提供します。 Natural バッファプールは、サポートされているすべての環境で Natural に必要不可欠です。
以下のトピックについて説明します。
Natural は、リエントラントな Natural オブジェクトコードを生成します。 コンパイルされたプログラムはバッファプールにロードされ、バッファプールから実行されます。 このため、Natural プログラムの 1 つのコピーを複数のユーザーが同時に実行できます。
このセクションでは、以下のトピックについて説明します。
バッファプール内のオブジェクトは、プログラム、サブプログラム、マップ、およびグローバルデータエリアです。 グローバルデータエリアは、コンパイル目的でのみバッファプールに配置されます。 この場合は、同じ名前の 2 つのオブジェクト、つまりグローバルデータエリア自体および対応するシンボルテーブルがバッファプールにロードされます。
Natural オブジェクトがバッファプールにロードされると、ディレクトリエントリと呼ばれるコントロールブロックがこのオブジェクトに割り当てられます。
ディレクトリエントリには、オブジェクトの名前、オブジェクトが属するライブラリ、オブジェクトの取得元のデータベース ID および Natural システムファイル番号などの情報と、いくつかの統計情報（特定の時間にプログラムを同時に実行しているユーザーの数など）が含まれます。
ユーザーがプログラムを実行する場合は、Natural はディレクトリエントリを調べて、プログラムがすでにバッファプールにロードされているかどうかを確認します。 まだロードされていない場合は、プログラムのコピーが適切な Natural システムファイルから取得され、バッファプールにロードされます。
オブジェクトをバッファプールにロードするときに、新しくロードするオブジェクトを収容するために、現在実行中ではない 1 つまたは複数の他の Natural オブジェクトがバッファプールから削除されることがあります。 新しいオブジェクトがロードされると、このオブジェクトを識別するために新しいディレクトリエントリが作成されます。
オブジェクトがシステムファイルから削除されると、そのオブジェクトは使用されなくなるとすぐにバッファプールからも削除されます。 オブジェクトが新しくカタログ化または格納されると、そのオブジェクトの古いバージョンは使用されなくなるとすぐにバッファプールからも削除されます。再度実行を要求された場合は、新しいバージョンがシステムファイルからバッファプールにロードされます。
バッファプールにロードされるプログラムの実際のオブジェクトコードは、テキストプールと呼ばれるエリアに配置され、このテキストプール内の連続したメモリ領域が割り当てられます。 このテキストプールは、いくつかの 4 KB のバッファに分割されます。 このサイズは任意で、Natural 管理者が自由に変更できます。 オブジェクトがロードされると、オブジェクトのオブジェクトコードを保存するために、相互に連続する 1 つ以上のテキストバッファが割り当てられます。
このセクションは、TYPE=NAT のバッファプールにのみ適用されます。
ハッシュテーブルは、バッファプールディレクトリ内のオブジェクトを見つける検索時間を短縮するために使用されます。 ハッシュテーブル内のエントリ数は、ディレクトリエントリ数を 2 倍して次の素数に切り上げた数になります。 これにより、任意の時点でテーブルの半分のみが入力され、競合の確率がほとんどなくなります。 その結果、ハッシュテーブル内の既存のオブジェクトを見つけるための平均テスト回数が理論的に 2 未満になります。
ハッシュの条件は 8 文字長のプログラム名です。 複数のプログラム名がハッシュテーブル内の同じ場所にハッシュされる場合は、オーバーフロー技術によって競合が解決されます。
ハッシュテーブルに必要なストレージは、テキストブロック当たり約 16 バイトです。 このため、テキストプール内の使用可能ストレージが 1.6 ％（1 KB テキストブロック）から 0.1 ％（16 KB テキストブロック）まで削減されます。
グローバルバッファプールの場合は、グローバルバッファプールの起動時に初期化が行われます。
ローカルバッファプールの場合は、初期化のタイミングは環境によって異なります。
バッチモードの場合、TSO、TIAM、および VM/CMS 環境では、Natural セッションを開始したときに初期化が行われます。
TP モニタ環境では、通常、最初のユーザーがこの TP モニタ環境で Natural を起動したときに初期化が行われます。 Com-plete および CICS 環境では、TP モニタの起動時にローカルバッファプールを初期化することも可能です。
前述および後述のとおり、バッファプール内でスペースを割り当てるためのさまざまなメソッドがあります。
検索メソッドを選択するには、以下のパラメータを使用します。
Natural プロファイルパラメータ BPMETH および BPI
または、Natural パラメータモジュール内の NTBPI マクロ
または、グローバルバッファプールの機能パラメータ METHOD
これらのパラメータと NTBPI マクロの詳細については、Natural の『パラメータリファレンス』ドキュメントを参照してください。
以下に、検索メソッドに関する情報を示します。
METHOD=S は、新しいロードの実行に必要なスペースを取得するために、バッファプール内のストレージを割り当てるための検索アルゴリズムとして選択プロセスが使用されることを示します。
使用される選択プロセスは、検索アルゴリズム 1 とアルゴリズム 2 の組み合わせです。
アルゴリズム 1
検索アルゴリズム 1 では、バッファプール内で、フリースペースであるストレージ、または未使用オブジェクト（アクティブであるが使用されていないオブジェクト）によって占有されているスペースであるストレージを見つけようとします。
必要なオブジェクトサイズとまったく同じサイズのフリースペースが見つかった場合は、選択プロセスはすぐに終了します。 それ以外の場合は、検索を続行し、最適なサイズのエントリを見つけるためにバッファプールの先頭から最後まで参照してバッファプール内のエントリを比較します。 また、未使用のオブジェクトの場合は、検索の際に、オブジェクトが最後にアタッチされた時間、つまりオブジェクトがロードまたは検索時に最後に参照された時間も考慮されます。
選択プロセスの終了時には、要求されたサイズ以上のフリースペースまたは未使用オブジェクトのスペースが選択されています。 検索に適用される優先規則では、最初にフリースペースが選択され、次に未使用オブジェクトのスペースが選択されます。 未使用オブジェクトの場合は、最も古いオブジェクトが最初に削除されます。
アルゴリズム 1 の選択プロセスが成功しなかった場合は、アルゴリズム 2 が開始されます。
アルゴリズム 2
選択アルゴリズム 2 は、アルゴリズム 1 が失敗した場合に開始されます。 アルゴリズム 2 では、アルゴリズム 1 から渡されたバッファプール内の位置から検索を開始し、新しいロードに必要なストレージを取得するために、複数のエンティティ（フリーストレージまたは未使用のオブジェクトが占有しているスペース）を組み合わせようとします。
ただし、オブジェクトの古さは考慮されません。
アルゴリズム 2 ではテキストレコードセクションの最後まで処理を続行し、必要に応じて、テキストレコードセクションの先頭までラップアラウンドして先頭から最後までの最終パスを作成します。 それでもスペースが使用できない場合は、アルゴリズム 2 は失敗し、オブジェクトはロードされず、Natural は該当するエラーメッセージを表示します。
METHOD=N は、新しいロードの実行に必要なスペースを取得するために、次に使用可能なフリーまたは未使用スペースが使用されることを示します。 未使用スペースとは、アクティブであるが使用されていないオブジェクトによって占有されているスペースのことです。
次に使用可能なスペースの検索は、ラップアラウンド方式でバッファプールを移動するポインタから開始されます。 次に使用可能な任意のフリーまたは未使用オブジェクトを含むバッファプールエンティティが使用され、場合によっては要求されたストレージ容量を取得するために連結されます。
割り当て要求中にバッファプールの最後に達した場合は、ポインタはバッファプールの先頭にラップアラウンドされ、バッファプールの先頭から最後まで最終検索が 1 回実行されます。 再度バッファプールの最後に達してもオブジェクトをロードできない場合は、ロードは失敗し、Natural は該当するエラーメッセージを表示します。
METHOD=N は、特に、バッファプールの容量が大きい場合はバッファプールキャッシュ機能と組み合わせることを考慮してください。 詳細については、以下の「検索メソッドの選択」も参照してください。
デフォルトでは METHOD=S が使用されます。 このメソッドの長所は、スペースを割り当てる際に入念な検索が行われることです。この検索では、オブジェクトのサイズおよび古さが考慮され、新しいロード用のスペースを確保するために、確実に最も必要のない未使用オブジェクトがバッファプールから削除されます。
METHOD=S の短所は、バッファプールの先頭から最後まで参照する際に、選択プロセスによって大量の CPU 時間が消費される可能性があることです。
METHOD=N の長所は、選択プロセスが短く、通常、参照が少ないのでスペースの割り当てに必要な CPU 時間が短くなることです。 これは、バッファプールの容量が大きい場合に重要です。
METHOD=N の短所は、バッファプールから削除するオブジェクトの選択がそれほど精密に行われないことです。 削除されたオブジェクトの再ロードのために Adabas I/O が増大するのを防ぐために、METHOD=N とバッファプールキャッシュ機能を組み合わせて使用することをお勧めします。
インストールテープで提供された Natural を使用している場合は、ローカルバッファプールを実行しています。 これは、使用中の環境の同じパーティション（またはリージョンかアドレススペース）に割り当てられるバッファプールエリアです。
例えば、バッチモードの場合、TSO または CMS 環境では、各ユーザー用にローカルバッファプールがあります。 Com-plete、CICS、IMS/TMTP などの TP モニタ環境では、TP モニタ当たり 1 つのバッファプールがあり、すべての TP ユーザーはここから実行します。
z/OS 環境では、CSA または ECSA ストレージからグローバルバッファプールが割り当てられます。 このような環境では、すべての TSO ユーザー、バッチユーザー、および TP モニタユーザーは 1 つの共通グローバルエリアから実行できます。
z/VSE 環境では、グローバルバッファプールはシステム GETVIS エリア（上または下）から割り当てられます。 このような環境では、すべてのバッチユーザーおよび TP モニタユーザーは 1 つの共通グローバルエリアから実行できます。
VM/CMS 環境では、グローバルバッファプールを書き込み可能な非連続共有セグメントとしてインストールできます。このセグメントは、Natural/CMS の起動時にユーザーの仮想マシンにダイナミックにアタッチされます。Natural の『インストール』ドキュメントの「VM/CMS 環境での Natural のインストール」および「Natural 用 VM システムの準備」も参照してください。
BS2000/OSD 環境では、グローバルバッファプールは共通メモリプールです。「BS2000/OSD 環境下の Natural グローバルバッファプール」を参照してください。
グローバルバッファプールの詳細については、「Natural グローバルバッファプール」を参照してください。
このセクションは、TYPE=NAT のグローバルバッファプールおよび TYPE=NAT または TYPE=SWAP のローカルバッファプールに適用されます。
バッファプールキャッシュは、グローバルバッファプールおよびローカルバッファプールと組み合わせて使用することができます。 z/VM では使用できません。 バッファプールキャッシュは Natural プログラミングオブジェクト（プログラム、サブプログラム、マップなど）にのみ使用され、Natural for DL/I で生成されたオブジェクトなどには使用されません。
バッファプールが複数ユーザーから要求されたすべてのオブジェクトを収容できるほど大きくない場合は、特別な過負荷対策方法によって、要求されたオブジェクトで既存のオブジェクトを置き換えます。 過負荷状況の発生回数はバッファプールの効率に直接影響します。 望ましくない過負荷を減らしてバッファプールのパフォーマンスを向上させる最適で最も効果的な方法は、単にバッファプールのサイズを増やすことです。
ただし、この方法はほとんどのお客様のサイトで使用できません。プライマリアドレススペース、z/OS (E)CSA、z/VSE システム GETVIS エリア、または BS2000/OSD 共通メモリプールに使用可能なストレージが不足しているからです。
上記の状況を改善するために、バッファプールキャッシュが使用されます。 このメカニズムの主な目的は、"バッファプールストレージ不足" のためにバッファプールから削除されるすべてのオブジェクトが失われないようにすることです。 つまり、オブジェクトの削除は、"バッファプールキャッシュへのスワップアウト" になります。 この機能が意図する利点は、オブジェクトのロードに使用されるデータベースコールが削減され、その結果パフォーマンスが向上することです。
グローバルバッファプールの注意事項：
バッファプールキャッシュエリアは、データスペースに割り当てられます。 バッファプール用にデータスペースが作成されると（z/OS または z/VSE で指定されるプロファイルパラメータ BPCSIZE、または BS2000/OSD で指定される DATA パラメータ）、作成者タスクに所有権が割り当てられます。 このタスクが終了すると、データスペースはシステムによって自動的に削除されます。 この場合は、RESIDENT=Y が設定されているかどうかに関係なく、作成者タスクはまだアクティブです。
ローカルバッファプールの注意事項：（z/OS および z/VSE のみ。Com-plete および IMS/TM は除く）
バッファプールキャッシュは、データスペースまたは "バーの上" のメモリオブジェクトつまり 64 ビットメモリ（z/OS のみ）に割り当てられます。 バッファプール用にデータスペースまたはメモリオブジェクトが作成されると（プロファイルパラメータ
BPCSIZE および BPC64 を参照）、作成者タスクに所有権が割り当てられます。 このタスクが終了すると、データスペースまたはメモリオブジェクトはシステムによって自動的に削除されます。
Natural ユーティリティ SYSBPM（Natural の『ユーティリティ』ドキュメントを参照）は、バッファプールの現在のステータスに関する統計情報を提供します。 SYSBPM を使用すると、バッファプールを必要に応じて調整することもできます。
以下では次のトピックについて説明します。
プリロードリストは、バッファプールにロードされてそのまま常駐するオブジェクトのリストです。 このようなオブジェクトは、ユーザーが実行するために要求したときにはすでにバッファプール内に存在するので、システムファイルからロードする必要がありません。
これにより、パフォーマンスが向上し、バッファプールのフラグメントを防ぎ、システムファイルを含むデータベースがアクティブでない場合でも重要なエラートランザクションを常に使用可能状態にしておくことができます。
Natural は、Natural セッションの開始時にプリロードリストをチェックして、プリロードリスト内のオブジェクトですでにバッファプールに存在するものを確認します。 存在しないオブジェクトは、システムファイルからバッファプールにロードされます。
このチェックとロードは、バッファプールの接続時、再接続時、および初期化時に SYSBPM ユーティリティを使用して実行することもできます。 REFRESH コマンドを使用してグローバルバッファプールを再初期化する場合は、既存の Natural セッションはチェックされません。 つまり、このバッファプールにアクセスする新しい Natural セッションが開始されない限り、プリロードリスト内のオブジェクトはロードされません。
プリロードリストのロードはシリアライズされません。 このため、複数の Natural セッションが同時に開始された場合は、各セッションはプリロードリストに指定されているすべてのオブジェクトをバッファプールにロードしようとします。 これにより、同じ Natural オブジェクトの複数のエントリがバッファプールに複製されることがあります（下記のヒントも参照）。
プリロードリストは名前で識別され、その名前を起動パラメータとして指定（グローバルバッファプールの場合）するか NTBPI マクロで指定（ローカルバッファプールの場合）することにより、特定のバッファプールにアタッチされます。 このため、バッファプールごとに異なるプリロードリストを定義することも、異なるバッファプールに同じプリロードリストを使用することもできます。
指定したプリロードリストが見つからない場合、またはプリロードリストに含まれているオブジェクトをロードできない場合は、セッションの初期化時に該当する警告メッセージが表示されます。 いずれの場合も、後続する各セッションの初期化ごとにプリロードが繰り返されます。
プリロードリスト内のオブジェクトは、最初にロードされるので、バッファプールの先頭に配置されます。ただし、最初のプリロードですべてのオブジェクトをロードできなかった場合を除きます。この場合は、オブジェクトはバッファプール内のいずれかの位置に配置されます。
プリロードリストの管理には、SYSBPM ユーティリティを使用します。Natural の『ユーティリティ』ドキュメントの「SYSBPM - プリロードリストの管理」を参照してください。
ヒント:
ユーザーセッションによるプリロードリスト内のオブジェクトのロードに関連する問題を防ぐには、次の手順に従います。
グローバルバッファプールの場合：
グローバルバッファプールの割り当てまたは更新の直後に、グローバルバッファプールにアクセスして FIN を実行するバッチ Natural セッションを開始します。
CICS および Com-plete 環境下のローカルバッファプールの場合：
TP システムの起動時に、ローカルバッファプールにアクセスする非同期 Natural セッションを開始し、Natural スタックに FIN コマンドを挿入します。 この Natural セッションが NTBPI マクロでプリロードリストの名前を参照していることを確認してください。
Natural オブジェクトが実行されないようにするには、目的のオブジェクトを "ブラックリスト" に配置します。配置したオブジェクトは、バッファプールにロードできなくなり、すでにロードされている場合は実行できなくなります。 このオブジェクトの実行をユーザーが要求すると、該当するエラーメッセージが表示されます。
ブラックリストには、個々のオブジェクトだけでなく、ライブラリ全体を配置することもできます。
例：
|
ブラックリストの管理には、SYSBPM ユーティリティを使用します。 Natural の『ユーティリティ』ドキュメントの「SYSBPM - ブラックリストの管理」を参照してください。
注意:
z/OS 環境では、バッファプールの変更の反映は常に、変更が発生した Natural サブシステム内に限られます（Natural サブシステムの詳細については、「Natural サブシステム」（z/OS）または「Natural サブシステム」（z/VSE）を参照）。 したがって、この場合の "すべてのグローバルバッファプール" は、"同じサブシステム内のすべてのグローバルバッファプール" を意味します。
環境によっては、バッファプールと使用中の Natural アプリケーションの整合性を維持するために、1 つのバッファプール（ローカルまたはグローバル）で発生した変更が他のすべてのグローバルバッファプールにも反映される、つまり、同じ変更が他のグローバルバッファプールでも自動的に行われるということが重要になります。 これは、Sysplex 環境で特に重要です。
例えば、Natural プログラムが 1 つの z/OS イメージで新しくカタログ化された場合、そのプログラムは、反映によって Sysplex 内の他のすべてのグローバルバッファプールから削除され、再実行されると新しいバージョンがシステムファイルからロードされます。
反映される変更は以下のとおりです。
バッファプールからのオブジェクトの削除
バッファプールのブラックリストの変更
バッファプールの再初期化
変更は、現在の z/OS イメージ内または Sysplex 全体の他のすべてのグローバルバッファプール、または Sysplex 内の同じ名前の他のすべてのグローバルバッファプールに反映できます。
反映は、別のグローバルバッファプールのバッファプール内常駐として定義されているオブジェクトには影響しません。
反映は、Natural プロファイルパラメータ BPPROP によってアクティブ化され範囲が制御されます。
注意:
反映は非同期で行われ、オブジェクトは使用されなくなった場合のみバッファプールから削除されるので、オブジェクトの現在のバージョンがすべてのバッファプールで使用可能になるまで多少時間がかかります。
他のローカルバッファプールに反映することはできません。
バッファプールとバッファプールキャッシュのパフォーマンスに関する全般的なヒントについては、Natural の『ユーティリティ』ドキュメントの SYSBPM セクションで「パフォーマンスの考慮事項」を参照してください。
Natural グローバルバッファプールは、オプションの Natural コンポーネントです。
これは、以下のオペレーティングシステムで使用できます。
z/OS（「z/OS 環境下の Natural グローバルバッファプール」を参照）
z/VSE（「z/VSE 環境下の Natural グローバルバッファプール」を参照）
BS2000/OSD（「BS2000/OSD 環境下の Natural グローバルバッファプール」を参照）
以下の Natural プロファイルパラメータを使用して、グローバルバッファプールを設定します。
BPNAME |
グローバルバッファプールの名前を指定します（BPNAME を参照）。 BPNAME=' '（空白）は、ローカルバッファプールへの接続を確立するために使用します。
|
SUBSID |
使用する Natural サブシステムの ID を指定します（プロファイルパラメータ SUBSID を参照。z/OS および z/VSE 環境にのみ適用）。
|
Natural は、起動時にこれらのパラメータを使用してグローバルバッファプールを見つけようとします。
Natural パラメータモジュールの NTBPI マクロまたは対応するプロファイルパラメータ BPI を使用して、複数のバッファプールを定義できます。
セッションの初期化時に、Natural は定義された最初のバッファプールへの接続を確立しようとします。 これに失敗すると、定義された 2 番目のバッファプールへの接続を確立しようとします。 これにも失敗すると、次に定義されているバッファプールへと順に試していきます。バッファプールへの接続の試みが失敗するたびに、該当するメッセージが表示されます。
バッファプールを停止する場合も同じ手順が適用されます。Natural セッションがまだアクティブなときに、現在接続しているバッファプールを閉じると、Natural は定義されている順番に従って別のバッファプールに接続し、セッションを継続しようとします。 このため、Natural 管理者は、アクティブな Natural セッションをすべて終了しなくても、グローバルバッファプールを閉じることができます。
