フィックスパック

Rational® Team Concert を使用すれば、 基本アプリケーションに対するフィックスパックまたはパッチを開発できます。

アプリケーションのリリースをデプロイするためのスキームは 2 つあります。 アプリケーションですべてのオブジェクトを置き換えるか、または変更されたオブジェクトのみを置き換えることができます。 IBM® i 上の多くのアプリケーションは、 オブジェクトの基本セットにパッチまたはフィックスが上書きインストールされることでデプロイされます。 この新規オブジェクト・セットを「フィックスパック」と呼びます。 アプリケーションのリリースが進むと、フィックスパック・セットが累積され、時間とともに特定の基本セットに対するいくつかのフィックスパックが作成されます。 逐次適用されなければならないように、または累積されるように、フィックスパックを構成できます。 また、既存のオブジェクトを置き換えるようにフィックスパックを構成したり、 既存のオブジェクトではなくフィックスパック・オブジェクトが解決されるようにライブラリー・リスト検索パスを設定したりすることもできます。

次の例について考えてみてください。 アプリケーションは複数のプログラム、ファイル、およびその他のオブジェクト (小さいライブラリー・セットにすべて登録されているもの) で構成されます。 ユーザーがアプリケーションを実行するときは、これらのライブラリーはすべてライブラリー・リストに入っています。 アプリケーションに対するフィックスパックは、これらのライブラリーに登録されているオブジェクトの一部をより新しいバージョンで置き換えて、 それ以外のオブジェクトはそのまま残します。 ILE におけるサービス・プログラムの実行時バインディング特性により、および OPM におけるプログラム全般の実行時バインディング特性により、 これらのオブジェクトを置き換えることで、アプリケーションの新規バージョンが使用可能になります。

また、ユーザーは、ライブラリー・リストにおいて基本アプリケーションより前にフィックスパックのライブラリーを配置して、 ライブラリー・リストを使用して動的バインディングが行われるようにすることも選択できます。 ライブラリー・リストを使用してすべてのバインディングが行われた場合、 基本ライブラリー内のオブジェクトは置き換えられずに、フィックスパックが効果的に適用されます。

Rational Team Concert を使用すれば、 いずれのフィックスパックも構成できます。

アプリケーションは、複数のプロジェクトに分けることができます。 各プロジェクトのソースは単一 IBM i ライブラリーの ソース・ファイルに保管されます。 このソースから作成されるオブジェクトは、オブジェクト・ライブラリー内に作成されます。 このオブジェクト・ライブラリーは、ソース・ライブラリーと同じ場合があります。 フィックスパックは、このオブジェクト・ライブラリーにある 2 つのオブジェクト・セットで構成されます。
  • ソース (基本ライブラリーのソースから変更されたもの) から作成されたオブジェクト
  • 基本ライブラリー内のソースから作成されたオブジェクト (変更された任意のソース・メンバーに依存する)

この例では、FIX と BASE という 2 つのソース・ライブラリーがあると想定します。 また、話を簡単にするために、アプリケーション・オブジェクトは FIX ライブラリー内に直接作成されるとします。 ソース・ファイル BASE/QRPGLESRC にはメンバー A と B が含まれています。 ソース・ファイル BASE/QRPGLEINC にはメンバー I が含まれています。 I は組み込まれたメンバーであり、A と B の両方によって使用されます。 この例では、インクルード・ソースはすべて QRPGLEINC に入れられ、ソース・タイプ RPGLE が付与されます。 BASE は読み取り専用とします。 すべての変更は FIX で行われます。 また、BASE には、BASE 内のソースから作成されたすべてのオブジェクトが含まれ、FIX には、フィックスパックを構成するオブジェクトが含まれていると想定します。 最初、FIX は空です。

注: RPG コンパイラーには /INCLUDE ディレクティブがあります。 形式は /INCLUDE libraryname/filename,membername です。 ライブラリー名はデフォルトで *LIBL に設定されます。 ファイル名はデフォルトで QRPGLESRC に設定されます。 メンバー名は必須です。 この例では、組み込まれるメンバーは FIX または BASE 内に入る可能性があるため、ライブラリー名は *LIBL であると想定します。

プログラマーは、QRPGLESRC(A) を変更したいと考えています。 プログラマーは、これを行うために、BASE から FIX に QRPGLESRC(A) をコピーする必要があります。 プログラマーは、この作業を行ってメンバーを変更します。 ビルドでは、このソースからモジュール FIX/A が作成されます。

次に、プログラマーは QRPGLEINC(I) を変更したいと考えます。 プログラマーは、QRPGLEINC(I) を BASE から FIX にコピーして変更します。 今度のビルドでは、このソースからモジュール FIX/A が作成されますが、モジュール FIX/B も作成されます。 QRPGLEINC(I) のタイプが RPGLE であっても、QRPGLEINC(I) は組み込まれたメンバーであってコンパイルされないため、QRPGLEINC(I) に関連付けられた モジュールはありません。

プロジェクト編成、ビルド・セットアップ、およびビルド・プロセスには、以下の内容を決定するだけの十分な柔軟性が必要となります。

プロジェクト編成

この例では、Rational Developer for Power Systems Software での i プロジェクト サポートにおける 基本プロジェクト編成は非常に単純です。 QRPGLESRC と QRPGLEINC という 2 つのソース・ファイルが含また単一プロジェクトが存在します。 各ソース・ファイルには上述のメンバーが含まれています。 プロジェクトは 1 つのみであることに注意してください。 リポジトリーはこのプロジェクトのヒストリー全体を追跡するため、その内容は時間とともに変化する可能性があります。 アプリケーションに対する機能拡張またはフィックスを作成するために、別個のプロジェクトを設定する必要はありません。

このプロジェクトを共有してリポジトリー・ストリームに入れることができます。 このストリーム内で、このアプリケーションのベースとなるスナップショットを作成します。 この例では、BASE ライブラリーには既にデータが取り込まれていることを想定します。

アプリケーションを変更し始めると、ストリームに変更内容が保持されます。 ビルド・ワークスペースとそのビルド定義をこのストリームに関連付けます。 ビルド定義には、IBM i 上の FIX ライブラリーが そのロード/オブジェクト・ライブラリーとして登録されます。 このビルド定義にある BASE ライブラリーは唯一の参照ライブラリーとなります。

FIX ライブラリーのロード

ビルドが実行依頼される前に、スナップショット・ロード・プロセスによって FIX ライブラリーとビルド・ワークスペースが同期された状態に保たれます。 ストリームが変更されると、その変更はビルド・ワークスペースに流れ、 そこから IBM i システム上の FIX ライブラリーに流れます。 ただし、基本スナップショットを設定してあるため、基本以外のファイルのみがフィックス・ライブラリーにロードされます。

この例では、プログラマーは QRPGLESRC(A) を変更してから、その変更をストリームに配信します。 このため、変更はビルド・ワークスペースに流れます。 これは基本に対する変更であるため、 メンバーは IBM i システム上の FIX ライブラリーに ロードされます。 同様に、QRPGLEINC(I) が変更されて、FIX ライブラリーに流れます。 現在、FIX ライブラリーには、2 つのソース・メンバーが含まれています。

ビルド中のライブラリー・リスト

ライブラリー・リストは、システム・ライブラリー・リスト、現行ライブラリー、1 つまたは 2 つの製品ライブラリー、 およびユーザー・ライブラリー・リストという 4 つのセクションで構成されます。 さしあたって、ライブラリー・リストのシステム・セクションと製品セクションは無視します。 現行ライブラリーは単一ライブラリーです。 ユーザー・ライブラリー・リストは複数ライブラリーです。 ライブラリーは現行ライブラリーであることも、ユーザー・ライブラリー・リストに表示されることもありますが、 ユーザー・ライブラリー・リスト内で重複することはありません。

前の例を使用して、FIX にコンパイルします。 これは現行ライブラリーにします。 すべての作成コマンドによって、デフォルトでこのライブラリーにオブジェクトが作成されます。 オブジェクトを FIX にコンパイルするため、そのことをビルド定義で指定します。

コンパイラーでメンバーが検出されるように、BASE もライブラリー・リストに入れる必要があります。 これは、ユーザー・ライブラリー・リストで唯一のライブラリーになります。 これは、ビルド定義で参照ライブラリーとして指定します。

ライブラリー・リストでは、BASE の後に他のライブラリーを含めることもできます。 ただし、コンパイル候補を検索する場所を FIX および BASE のみに限定して、その後のライブラリーでは検索を行わないようにします。

ビルド仕様

ビルド仕様にはビルド対象とビルド方法が記述されていて、 それによってビルド・プロセスが指示されます。 この例では、プロジェクトのビルド仕様に 2 つのコマンド・セットがあります。 1 つは ILE RPG 用のコマンド・セットです。 もう 1 つは、モジュールからプログラムを作成するコマンド・セットです。 このビルド仕様には 2 つのビルダーもあります。 1 つは、RPG 用のコンパイル対象について記述するビルダーです。 もう 1 つはプログラムを作成するビルダーです。 通常、複数のビルダー間でコマンド・セットを再利用できますが、今回は単純な例であるため再利用は行いません。

話をまとめると、FIX と BASE の両方にソース・タイプ RPGLE の QRPGLESRC(A) があります。 FIX と BASE にソース・タイプ RPGLE の QRPGLEINC(I) があります。 BASE には QRPGLESRC(B) があります。 A と B の両方に I が組み込まれています。

ビルド・プロセスでは、タイプ RPGLE の QRPGLESRC にあるすべてのコンパイル候補を調べる必要があります。 ライブラリー・リストには FIX と BASE 以外のライブラリーが含まれている可能性があるため、特殊変数 &SP を使用して候補リストを記述します。 この変数にはプロジェクトからのライブラリーが含まれています。 このライブラリーは、コンパイル対象のソースを検索するときに必ず検索場所となるライブラリーです。 今回、&SP は、リスト (FIX BASE) になるようにビルド・エンジンによって設定されます。

今回のビルダー定義では、コンパイル候補の式を次のように定義します。

また、可能性のある依存関係のリストを次のように定義します。

今回の例に最初の式を適用すると、FIX/QRPGLESRC(A) が作成および変更された後で、次のコンパイル候補が示されます。

今回の例に 2 番目の式を適用すると、これらの候補に対する以下の依存関係リストが示されます。

上述のように、QRPGLEINC(I) を変更すると、FIX/QRPGLESRC(A) と BASE/QRPGLESRC(B) がコンパイルされて、 モジュール FIX/A と FIX/B が作成されます。 QRPGLESRC(A) のみを変更すると、FIX/QRPGLESRC(A) のみがコンパイルされて、モジュール FIX/A が作成されます。 そのため、ライブラリー FIX には、フィックスパックに必要なモジュールのみが含まれます。

詳しくは、Jazz™.net を参照してください。


フィードバック