両方とも db2-cobol プログラムである場合、メイン プログラムから 2 つのサブ プログラムを実行する方法は?
「Mainpgm1」という名前のメイン プログラムは、呼び出されたプログラムである「subpgm1」および「subpgm2」という名前のサブプログラムを呼び出しており、静的呼び出しのみを優先しました。
実際、プランと 1 つのメンバーの代わりに package というステートメントを使用しています。どちらも「db2bind」(バインド プログラム) で、dsn 名を持つ 1 つの dbrmlib と一緒に使用しています。
主な問題は、両方の db2-cobol プログラムをバインドしている間に、'db2bind' でどのような変更が影響を受けるかということです。
同様に、「DB2RUN」(プログラムの実行) でも同様です。
SQL を含む各プログラム (またはサブプログラム) は、前処理して DBRM を作成する必要があります。次に DBRM は、実行時に LOAD モジュールによってアクセスされる PLAN にバインドされ、そこに含まれる SQL ステートメントの正しい DB/2 アクセス パスを取得します。
すべての SQL を 1 つのプログラムに含めることから、複数のサブプログラムに移行しました。基本的なプロセスは変わりません。プログラムを実行するには PLAN が必要です。
DBA は、SQL を含むサブプログラムが複数ある場合、それらのサブプログラム用に PACKAGES を作成し、その PACKAGES を PLAN にバインドするように提案することがよくあります。以前は 1 ステップのプロセスでしたが、現在は 2 ステップです。
PACKAGES の重要な点は何ですか?
SQL を含む 50 のサブプログラムがあるとします。それぞれに対して DBRM を作成し、50 個すべてを 1 つの操作として PLAN にバインドすると、すべてのプログラムのすべての SQL ステートメントを分析してパスにアクセスする必要があるため、PLAN を構築するために多くのリソースが必要になります。彼らのために作成されました。これは、50 のサブプログラムすべてが新規または変更されている場合には、それほど悪くはありません。ただし、比較的安定したシステムを使用していて、1 つのサブプログラムを変更したい場合、50 個の DBRMS すべてを再バインドして PLAN を作成することになります。50 個のうち 49 個は変更されておらず、まったく同じアクセス パスを使用することになります。これはあまり良いアプローチではありません。これは、サブプログラムのいずれかに変更を加えるたびに、50 個のサブプログラムすべてをコンパイルすることに似ています。
ただし、サブプログラムごとに PACKAGE を作成すると、その PACKAGE を構築するのに実際の作業が必要になります。これには、関連する DBRM のすべてのアクセス パスが含まれています。サブプログラムを 1 つだけ変更する場合は、1 つの DBRM を PACKAGE コレクションに再バインドしてから PLAN を再バインドすることにより、その PACKAGE を再構築するだけで済みます。ただし、一連の PACKAGES (コレクション) を PLAN にバインドすると、システム内のすべての DBRM をバインドするよりもリソースの消費が大幅に少なくなります。
プログラムで使用するすべてのアクセス パスを含む PLAN を作成したら、それを使用します。実行中の SQL が subprogram1 からのものか、subprogram2 からのものかは関係ありません。実行中の LOAD に PLAN を関連付けている限り、すべてうまくいくはずです。
すべてのインストールには、パッケージ、コレクション、およびプランを設定するための独自の命名規則と標準があります。さらに先に進む前に、データベース管理者にこれらを確認する必要があります。
DB/2 環境でのプログラムの準備に関する背景情報を次に示し ます。 アプリケーションの開発