既存の ICS システムの準備

アップグレードのために ICS システムを準備する際、ICS データベースをマイグレーションする方法として 2 つのオプションがあります。一つは「インプレース・データベース・マイグレーション」で、もう一つは「インプレース・データベース・マイグレーションなし」です。「インプレース・データベース・マイグレーション」は、古いリポジトリーを再利用して、最初に ICS サーバーが始動するときに ICS がリポジトリーをアップグレードするようにする方法です。「インプレース・データベース・マイグレーションなし」は、新しい空のリポジトリー・データベースを使用してアップグレードする方法です。

インプレース・データベース・マイグレーションなしで InterChange Server システムをアップグレードするには、以下の手順が必要です。インプレース・データベース・マイグレーションを使用する場合は、説明中の変更内容が「インプレース・データベース・マイグレーション」として示されます。

  1. ステップ 1 - InterChange Server システムのバックアップ
  2. ステップ 2 - システムを静止状態にする方法
  3. ステップ 3 - InterChange Server とサード・パーティー・ソフトウェアのアンインストール
  4. ステップ 4 - InterChange Server とサード・パーティー・ソフトウェアのインストール
  5. ステップ 5 - オブジェクト・リクエスト・ブローカーのアップグレード
  6. ステップ 6 - InterChange Server のアップグレード
  7. ステップ 7 - InterChange Server とサード・パーティー・ソフトウェアの始動
  8. ステップ 8 - リポジトリーのロード
  9. ステップ 9 - バージョン 4.1.1 からのマイグレーションでの特殊なアップグレード手順
  10. ステップ 10 - アップグレードの検証

ステップ 1 - InterChange Server システムのバックアップ

InterChange Server システムのバックアップを作成すると、新規バージョンのインストール時に不注意でファイルを上書きしても、そのファイルを回復できます。アップグレード手順を実行する前に、静的データと動的データ (アップグレードにかかわらず定期的にバックアップされる変更可能データ) の両方のバックアップを作成します。静的データおよび動的データの例については、表 15 を参照してください。

システムのバックアップを作成するには、以下の手順を行います。

表 15 に、各 ICS コンポーネントのバックアップ方法の概要を示します。

表 15. InterChange Server データのバックアップ方法
データのタイプ バックアップ方法
静的データ

リポジトリー
repos_copy ユーティリティーを使用し、カスタマイズした InterChange Server コンポーネントの一部またはすべてを保管します。 詳細については、「システム管理ガイド」に 記載されている InterChange Server コンポーネントのバックアップ方法を参照してください。

カスタムのコラボレーション Java ファイル (.class)、およびメッセージ・ファイル (.msg ) ProductDir ディレクトリーの collaborations サブディレクトリーをシステム・バックアップに組み込みます。
ProductDir¥collaborations
 

カスタムのマップ Java クラス・ファイル (.class) これらのファイルをシステム・バックアップに組み込むため、システム・バックアップに以下のディレクトリーがあることを確認してください。
ProductDir¥DLMs
 

カスタム・コネクター システム・バックアップにディレクトリー ProductDir¥connectors¥connector_name を含めます。ここで、「connector_name」はカスタム・コネクターの名前です。

カスタマイズされた始動スクリプト 始動スクリプトをカスタマイズしてある場合は、これらがシステム・バックアップに組み込まれていることを確認してください。

ICS 構成ファイル (InterchangeSystem.cfg) ProductDir ディレクトリーにある ICS 構成ファイルをシステム・バックアップに組み込みます。
動的データ

相互参照、失敗したイベント、および関係表 データベースにはデータベース・バックアップ・ユーティリティーを使用します。詳細については、「システム管理ガイド」に 記載されている InterChange Server コンポーネントのバックアップ方法を参照してください。

コネクター・イベント・アーカイブ表 これらの表を含むデータベースには、データベース・バックアップ・ユーティリティーを使用します。

ログ・ファイル 以下のディレクトリーをシステム・バックアップに組み込みます。
ProductDir
 

ステップ 2 - システムを静止状態にする方法

InterChange Server システムをバージョン 4.3 にアップグレードするには、その前にシステムが静止状態であることを確認する必要があります。つまり、環境をバックアップしてアップグレード手順を実行する前に、進行中のイベントをすべて完了し、未確定のトランザクションをすべて解決する必要があります。

以下の手順は、InterChange Server システムを静止状態にする方法について説明します。

  1. 失敗したイベントを再サブミットするか、そのイベントを破棄します (このステップはオプションです)。失敗したイベントを ICS にアップグレードして、システムのアップグレード後にそれを処理するように選択できます。
  2. すべてのアダプターについてイベント表のポーリングを停止するため、PollFrequency プロパティーを No に設定します。
  3. 進行中のイベントを含め、システムですべてのイベントを実行します。必ず未確定トランザクションをすべて解決してください。
  4. コラボレーションを停止します。これによって、アップグレード時に InterChange Server で稼働するイベントはなくなります。
  5. キューから以前のイベントをすべて除去することにより、キューをクリアします。
    注:
    ステップ 5 は、失敗したイベントを処理せずにアプリケーションから再サブミットする場合のみ行ってください。失敗したイベントのアップグレードを選択し、かつ MQ トランスポートを使用している場合は、キューを消去しないでください。キューをバックアップして、アップグレード後にそれらを復元する必要があります。キューのバックアップについては、MQ の文書を参照してください。
  6. InterChange Server とすべての関連コンポーネントをシャットダウンします。
  7. データベースをシャットダウンします。
  8. 4.2.2 より前の ICS バージョンの ORB (Visibroker) をシャットダウンします。
  9. MQSeries をシャットダウンします。

実行中のシステムを正常に停止する方法については、「システム管理ガイド」を参照してください。

ステップ 3 - InterChange Server とサード・パーティー・ソフトウェアのアンインストール

以下のステップは、サード・パーティー・ソフトウェアの正しいアンインストール順序を示します。

  1. ORB (Visibroker) (4.2.2 より前のバージョン用) をアンインストールします。
  2. InterChange Server (ICS) をアンインストールします。
  3. JDK をアンインストールします。
  4. リポジトリー表を除去します。この表は、ICS アップグレードの一部として再ビルドされます。
    注:
    インプレース・データベース・アップグレードの場合は、新規インストールでリポジトリーが再利用されるので、リポジトリー表を除去しないでください。

サービスとして稼働している InterChange Server コンポーネントがある場合は、アップグレードを実行する前に そのサービスをアンインストールしてください。新規リリースは別の場所に置かれるため、既存のサービス定義は誤りになります。アップグレードが完了したら、InterChange Server コンポーネントをサービスとして構成する手順について、"拡張構成オプション"を参照してください。

ステップ 4 - InterChange Server とサード・パーティー・ソフトウェアのインストール

以下のステップは、InterChange Server のコンポーネントの正しいインストール順序を示します。

重要:
サード・パーティー・ソフトウェアをアップグレードする必要がある場合は、システム管理者に依頼して、そのソフトウェアのバックアップを作成してから アップグレードを実行します。
  1. IBM JDK 1.4.2 をインストールします。
  2. DBMS をインストールまたはアップグレードします。ランタイム・データを保持したい場合は、ランタイム表を復元します。

    InterChange Server の前のバージョンからマイグレーションする場合は、データベース・ソフトウェアもアップグレードする必要があるかどうかを確認してください。

    サポートされるデータベース・ソフトウェアのリストについては、ソフトウェア要件のセクション (ソフトウェア要件) を参照してください。既存のデータベース・ソフトウェアのバージョンと、製品の 4.3 バージョンがサポートしているバージョンとを照合してください。

    データベース・ソフトウェアのアップグレードが必要な場合は、データベース管理者 (DBA) が次の手順に従っていることを確認してください。

    データベース・ソフトウェアのバックアップおよびアップグレードを実行する方法の説明については、データベース・サーバーの資料を参照してください。データベースのマイグレーション方法の詳細については、ステップ 8 - リポジトリーのロードに進んでください。

  3. WebSphere MQ 5.3.02 (CSD07) のインストールまたはアップグレードを実行します。
    重要:
    このセクションで説明する手順を実行する必要があるかどうかは、現行の InterChange Server のバージョンによって異なります。
    • InterChange Server の 4.2.0 バージョン、4.2.1 バージョンまたは 4.2.2 バージョンからアップグレードする場合は、WebSphere MQ をアップグレードする必要はありません。
    • InterChange Server の 4.1.1 バージョンからアップグレードする場合は、このセクションで説明する手順を実行して、WebSphere MQ を新規バージョンにマイグレーションしてください。

    WebSphere MQ をアップグレードする場合は、次のいずれかの方法を採用できます。

    WebSphere MQ ソフトウェアをアップグレードした後は、InterChange Server とともに使用するために構成する必要があります。詳細については、WebSphere MQ の構成の説明を参照してください。

  4. 前のバージョンの ICS があるディレクトリーとは別の新規ディレクトリーに InterChange Server をインストールします。

ステップ 5 - オブジェクト・リクエスト・ブローカーのアップグレード

WebSphere InterChange Server システムが VisiBroker オブジェクト・リクエスト・ブローカー (ORB) を使用して ICS とそのクライアント (コネクター、WebSphere Business Integration ツール、SNMP エージェント、アクセス・クライアントなど) との通信を処理することはなくなりました。代わりに、InterChange Server システムは IBM Java ORB を使用するようになりました。ICS インストーラーは、IBM Java ORB を、Java ランタイム環境 (JRE) の一部として自動的にインストールします。

InterChange Server は、VisiBroker Smart Agent の代わりに IBM Transient Naming Server を使用して、そのネーミング・サービスを提供するようになりました。システムをアップグレードして新しいネーミング・サーバーを使用するには、VisiBroker Smart Agent が IBM Transient Naming Server と同じホスト・マシンにインストールされているかどうか、およびこの同じホスト・マシン上にとどまる必要があるかどうかに応じて、次のいずれかを実行します。

注:
IBM Java ORB の概要については、「システム管理ガイド」を参照してください。

プロパティーを使用して IBM Java ORB をセットアップする処理は、のインストール時に提供される始動スクリプトに設定されています。ただし、InterChange Server の 4.3 以前のバージョンで Inprise VisiBroker ソフトウェアを使用し、VisiBroker ORB プロパティーをカスタマイズしていた場合は、新規スクリプトにも同様の変更を行って、4.3 の IBM ORB へのマイグレーションに適応させる必要が生じる可能性があります。IBM ORB プロパティーとその Visibroker 相当品の詳細については、ORB プロパティーのアップグレードを参照してください。

ORB プロパティーのアップグレード

Visibroker ORB には、ORB を調整するために各種の ORB 関連プロパティーが存在していました。カスタマイズされたスクリプトやソフトウェアでこれらのプロパティーを使用していた場合は、これらのプロパティーが IBM Java ORB に対して適切に設定されていることを確認する必要があります。表 16 には、いくつかの VisiBroker ORB プロパティーと、これに相当する IBM Java ORB での名前を示します。

VisiBroker ORB プロパティーを参照するカスタマイズされたスクリプトが、4.3 以前のインストール・システムに存在する場合は、これらのプロパティーを、後出の表 16 に示す IBM ORB の相当プロパティーに置換してください。

注:
表 16 では、いくつかのプロパティー名に改行を挿入して、プロパティー名が表のセルに収まるようにしています。実際のプロパティー名には、スペースや改行は含まれません。

表 16. IBM ORB プロパティーと等価の VisiBroker プロパティー
IBM ORB プロパティー 等価の VisiBroker プロパティー 説明
org.omg.CORBA.ORBInitialHost vbroker.agent.addr IBM Transient Naming Server (tnameserv) が稼働しているマシンの IP アドレスまたはホスト名を指定します。このプロパティーのデフォルト値は localhost です。
org.omg.CORBA.ORBInitialPort vbroker.agent.port IBM Transient Naming Server の listen 先ポートを指定します。
com.ibm.CORBA.ListenerPort vbroker.se.iiop_tp.scm.iiop_tp. listener.port ORB サーバーが着信要求を listen するポート。このプロパティーを指定すると、ORB は ORB.init() の実行時に listen を開始します。デフォルトでは、このポートは動的に割り当てられます。VisiBroker のプロパティー名 OAport が引き続きサポートされます。
com.ibm.CORBA.LocalHost vbroker.se.iiop_tp.host このプロパティーは、ORB が稼働しているマシンのホスト名 (または IP アドレス) を表します。ローカル・ホスト名は、サーバーのホスト名をリモート・オブジェクトの IOR に置くために、サーバー・サイド ORB が使用します。このプロパティーを設定しなかった場合は、InetAddress.getLocalHost(). getHostAddress(); を呼び出すことにより、ローカル・ホストが検索されます。
4.3 では、VisiBroker のプロパティー名 OAipAddr が引き続きサポートされます。
com.ibm.CORBA.ThreadPool. MaximumSize vbroker.se.iiop_tp.scm.iiop_tp. dispatcher.threadMax Server Connection Manager によって作成可能なスレッドの最大数を指定します。デフォルト値 0 は、制限がないことを意味します。4.3 では、VisiBroker のプロパティー名 OAthreadMax が引き続きサポートされます。
com.ibm.CORBA.ThreadPool. InactivityTimeout vbroker.se.iiop_tp.scm.iiop_tp. dispatcher.threadMaxIdle アイドル状態のスレッドが破棄されるまでの時間を (秒単位で) 指定します。VisiBroker のプロパティー名 OAthreadMaxIdle が引き続きサポートされます。
com.ibm.CORBA.BufferSize vbroker.orb.streamChunkSize 最初の試行でソケットから読み取られる (GIOP メッセージとしての) バイト数。バッファー・サイズを増やすと、1 回の試行でメッセージ全体を読み取る確率が高くなり、パフォーマンスの向上につながります。デフォルトは 2048 です。

InterChange Server の 4.3 以前のバージョンでは、InterChange Server によって登録されたすべての ORB オブジェクトを識別するために、VisiBroker ORB に osfind ツールが用意されていました。IBM Java ORB には、このために CosNameServer_Dump と呼ばれるツールが用意されています。このツールは、ProductDir¥bin ディレクトリーにあります。詳しくは、「システム管理ガイド」を参照してください。

ステップ 6 - InterChange Server のアップグレード

アップグレードに関する追加情報は、サーバー・スクリプトのアップグレードおよびコンポーネントのアップグレードの完了を参照してください。

注:

  1. アップグレード時は、新規バージョンを別の 場所にインストールする必要があります。

  2. ICS インスタンスに名前を付けることをインストーラーから要求された場合は、ICS インスタンスのこの名前を 4.3 以前のバージョンと同じ名前にして、失敗したイベントの移植性を確保します。

  3. InterChange Server の元の構成情報を取得するには、インストーラーが「InterChange Server 構成ウィザード」を起動したら、次のいずれか の処置を行います。

ステップ 7 - InterChange Server とサード・パーティー・ソフトウェアの始動

  1. InterChange Server マシンをリブートします。
  2. IBM ORB の Persistent Naming Server を始動するため、ProductDir¥bin ディレクトリーにあるバッチ・ファイル PersistentNameServer.bat を実行します。
  3. IBM MQSeries を始動します。

    キュー・マネージャーと Listener が両方とも稼働中していることを確認します。

  4. データベースをローカルで実行している場合は、データベースを始動します。
  5. 4.1.1 からアップグレードする場合は、前にバックアップした DLM およびコラボレーション用 .class ファイル、.java ファイル、およびメッセージ・ファイルを適切なディレクトリーにコピーします。DLM の場合は、ファイルを ProductDir¥DLMs¥classes および ProductDir¥DLMs¥messages にコピーします。コラボレーションの場合は、ファイルを ProductDir¥collaborations¥classes および ProductDir¥collaborations¥messages にコピーします。
  6. インプレース・データベース・マイグレーションの場合: 元のリポジトリーが存在するデータベースを ICS に指定する必要があります。これを行うには、古い InterchangeSystem.cfg ファイルを再利用するか、ICS 構成ウィザードでデータベース・パラメーターを設定します。
  7. InterChange Server を始動します。

    InterChange Server の始動方法については、"InterChange Server の設定"を参照してください。

    注:
    失敗したイベントの移植性を確保するため、サーバー名は前のバージョンと同じ名前にする必要があります。

    正常に始動したかどうかを確認するには、ProductDir ディレクトリー の InterchangeSystem.log ファイルを検査します。

    注:
    InterChange Server システムのアップグレード後に InterChange Server の始動に失敗した場合は、このアップグレード手順を調べて、すべての指示に従ったかどうかを確認してください。

    それでも失敗の原因が不明であれば、修正しようとしたり、バックアップから復元する前に、IBM テクニカル・サポートにお問い合わせください。

ステップ 8 - リポジトリーのロード

注:
インプレース・データベース・アップグレードを実行する場合、このステップは不要です。

repos_copy コマンドを使用して、前のバージョンからリポジトリー・ファイルをロードします。例えば、ICS 名が WICS で、ユーザー名/パスワードが admin/null、リポジトリー・ファイル名が repos_backup.jar (4.1.1 からのアップグレードの場合は repos_backup.in を使用する) であれば、次のように入力します。

repos_copy -sWICS_NAME -irepos_backup.jar -uadmin - pnull
 

リポジトリーについての詳細は、リポジトリーのアップグレードを参照してください。

ステップ 9 - バージョン 4.1.1 からのマイグレーションでの特殊なアップグレード手順

ICS 4.1.1 からアップグレードする場合は、以下のステップを実行して、ツール用の古い DLM およびコラボレーションをアップグレードします。

  1. 先ほどインストールしたサーバーをリブートします。
  2. System Manager でサーバーに接続します。
  3. 一時 ICL (統合コンポーネント・ライブラリー) を作成して、サーバーからすべてのコンポーネントをインポートします。
  4. すべてのマップおよびコラボレーションのテンプレートをコンパイルします。
  5. プロジェクトを作成し、先ほど作成した ICL 内のすべてのコンポーネントを組み込みます。
  6. サーバー上のリポジトリーを削除します。
  7. プロジェクトをサーバー上に配置します。

ICL についての詳細は、ICL のインポートを参照してください。

これらのステップは、バージョン 4.2.x サーバーの場合は不要です。

ステップ 10 - アップグレードの検証

アップグレードが正常に処理されたかを検証するには、リポジトリー・スキーマが作成され、すべてのオブジェクトが正常にロードされたかどうかを確認します。この検証には以下の手順を実行します。

サーバー・スクリプトのアップグレード

既存の InterChange Server にカスタム・ファイルを作成した場合は、次のファイルを評価して、これらのファイルをアップグレードする必要があるかどうかを判断する必要があります。

サーバー始動スクリプトのアップグレード

VisiBroker ORB から IBM Java ORB への移行に対応し、IBM JRE をサポートするために、すべての始動スクリプトが変更されました。この変更内容は次のとおりです。

4.3 以前の始動スクリプトをカスタマイズした場合は、新規の 4.3 スクリプトにも同様な変更を行う必要があります。これらの始動スクリプトには、次のようなカスタマイズが必要な場合があります。

ツール構成ファイルのアップグレード

ツール構成ファイル cwtools.cfg のタスクの 1 つは、カスタムの .jar ファイルを提供して、これをコンパイル時に組み込むことです。カスタムの .jar ファイルを作成した場合は、classpath 変数の codeGeneration セクションに追加する必要があります。cwtools.cfg ファイルは以下のディレクトリーにあります。

ProductDir/bin
 

環境変数の確認

すべての環境変数が単一の CWSharedEnv ファイルに設定されるようになりました。すべての始動スクリプトでは、その起動プロシージャーの一部としてこのファイルが読み取られます。ICS システム規模のプロパティー (IBM Java ORB のプロパティーなど) が設定されるのは、このファイル内です。アップグレード・プロセスの一環として、次に示すシステム規模のプロパティーが正常に設定されていることを確認してください。

CWSharedEnv ファイルの詳細については、「システム管理ガイド」を参照してください。

カスタム・コンポーネントの評価

リポジトリー表 (スクリプト、データベース表、ストアード・プロシージャーなど) を使用する完全にカスタムのコンポーネントがある場合は、各コンポーネントを評価して、コンポーネントのアップグレードが必要かどうかを判断する必要があります。例えば、新規リリースで変更されたリポジトリー表をストアード・プロシージャーが使用する場合は、このストアード・プロシージャーを変更して、リポジトリー表の新構造と連動する必要があります。

注:
スキーマが変更されていない場合は、イベント表とトリガーのいずれもまったく変更する必要はありません。

リポジトリーのアップグレード

InterChange Server リポジトリーは、InterChange Server コンポーネントについてのメタデータを保持するデータベースです。ICS インストーラーは、ICS リポジトリーの内容を自動的にはアップグレードしません。ただし、前の手順で ICS を始動したときに、ICS は 4.3 以前のリポジトリーにあるスキーマを 4.3 の変更内容によってアップグレードします。アップグレード・プロセスのこの時点で、次のどちらのオブジェクトをリポジトリーにロードするかを決定する必要があります。

System Manager の InterChange Server Component Management 表示を使用して、サーバーにロードされたコンポーネントを表示することができます。

既存のリポジトリー・オブジェクト

InterChange Server の 4.1.1 バージョンからアップグレードしていて、データベース・ソフトウェアをアップグレードする必要があった場合は、DBA が新規データベース・サーバーをインストールし、ICS リポジトリーを含む ICS データベースに必要な変更内容を処理しておく必要があります。ICS インストール・プロセスの一環として、これらの ICS データベースの名前は「InterChange Server 構成ウィザード」で指定済みです。ICS の新規バージョンを始動したときに、サーバーはリポジトリー・データベースのスキーマをアップグレード済みです。この新規リポジトリーを初期化するには、既存のリポジトリー・オブジェクトをロードする必要があります。

リポジトリーのロードを準備するには、次の手順を実行します。

  1. マップとコラボレーションに対応する既存の Java クラス (.class) ファイルを、新規ディレクトリー構造に次のようにコピーします。

    ここで、ProductDir は、新規の 4.3 リリースの製品ディレクトリーです。この手順により、既存のマップおよびコラボレーションの .class ファイルが、新規の 4.3 ディレクトリー構造に確実に置かれるようになります。

  2. ICS システムが関係およびデータベース接続に 使用するデータベースがすべて実行されていることを確認します。ICS が稼働していることも確認します。
  3. 次の手順に従って、既存のリポジトリー・オブジェクトをロードします。
    1. リポジトリー・ファイルを編集して、非互換箇所をいくつか修正します。詳しくは、以下のリポジトリー・ファイルの準備を参照してください。
    2. すべてのリポジトリー・オブジェクトのリポジトリーをクリアします。
    3. 既存のオブジェクトをロードします。

    既存のリポジトリー・オブジェクトを処理するための各ステップについては、以下のセクションを参照してください。

リポジトリー・ファイルの準備

(リポジトリー・ファイルと呼ばれる) 既存の repos_copy バックアップ・ファイルを調べて、すべての値が新規リポジトリーに関連していることを確認します。既存のリポジトリー・ファイルのバックアップ・コピーを作成し、元のリポジトリー・ファイルを編集することにより、次の情報を修正します。

注:
既存のリポジトリー・オブジェクトのファイル内にあるリポジトリー・オブジェクトを、必ずしもすべて ロードしない場合は、4.3 リポジトリーにインポートしたリポジトリー・ファイルから不要なオブジェクトを除去できます。

新規リポジトリーのクリア

既存のリポジトリー・オブジェクトをインポートする前に、4.3 リポジトリーに既に存在している可能性のある重複オブジェクトを削除する必要があります。この手順が必要な理由は、repos_copy ユーティリティーが、以前のフォーマットをリポジトリーにインポートするときに -ar オプションや -arp オプション (重複オブジェクトを処理するオプション) を認識しないからです。ICS は、リポジトリー・ファイル内に重複オブジェクトを検出すると、インポート操作全体をロールバックします。

これらのリポジトリー・オブジェクトを削除するには、repos_copy ユーティリティーの -d オプションを使用します。例えば、次の repos_copy コマンドを実行すると、リポジトリーの内容が削除されます。

repos_copy -sNewICSinstance -uadmin -pnull -d 
 

この repos_copy コマンドの詳細について、以下に説明します。

リポジトリー・ファイルのインポート

リポジトリー・ファイルの内容をリポジトリーにロードするには、repos_copy ユーティリティーを 使用します。ステップ 1 - InterChange Server システムのバックアップで説明したように、repos_copy ユーティリティー の -o オプションを使用して、既存のリポジトリー・オブジェクトをエクスポート し、1 つ以上のリポジトリー・ファイルを作成しておきます。これが終了したら、repos_copy-i オプションを使用して、これらのリポジトリー・オブジェクトを新規のリポジトリーにインポートします。

注:
インポート操作では、リポジトリー・ファイルに定義されたすべてのリポジトリー・オブジェクトがロードされます。ただし、プロジェクト定義はこの対象外 です。プロジェクト定義はリポジトリーに格納されなくなりました。プロジェクト定義は、統合コンポーネント・ライブラリー (ICL) およびユーザー・プロジェクトを介して定義されるようになりました。詳細については、既存のユーザー・プロジェクトのインポートを参照してください。

例えば、Repository411.txt というリポジトリー・ファイルがある場合を考えます。次の repos_copy コマンドを実行すると、このファイル内のすべてのリポジトリー・オブジェクトがロードされます。

 repos_copy -iRepository411.txt -sserverName -uuserName -ppassword -r*
 

この repos_copy コマンドの詳細について、以下に説明します。

既存のリポジトリー・オブジェクトが新規リポジトリーに存在する場合は、引き続き追加のステップを行ってコラボレーション・テンプレートおよびマップのアップグレードを 完了する必要があります。詳しくは、コラボレーション・テンプレートおよびマップのアップグレードの完了を参照してください。

Copyright IBM Corp. 1997, 2004