WebSphere Application Server for z/OS, Version 6.0.x   
             オペレーティング・システム: z/OS

             目次と検索結果のパーソナライズ化
このトピックは、z/OS オペレーティング・システムにのみ適用されます。

マイグレーション・プロセスに関する FAQ (よくある質問)

この項では、WebSphere Application Server for z/OS のマイグレーション・プロセスに 関する FAQ (よくある質問) にお答えします。

新規バージョン 6.0.x データ・セットをポイントするだけで、サーバーを再始動することができますか?

できません。 WebSphere Application Server for z/OS バージョン 6.0.x では、 バージョン 5.x 構成をバージョン 6.0.x レベルまでマイグレーションする必要があります。

バージョン 6.0.x にマイグレーションする場合は、次の問題に注意してください。
  • WebSphere Application Server 以外のアプリケーションに属するすべての変数はマイグレーションされませんが、そのまま移動されます。したがって、マイグレーションの前に他の製品のアップグレードを調べて、これらのすべての変数がマイグレーション後にまだ正確であることを確認します。
    例えば、WebSphere Application Server バージョン 5.02 では SDK 1.3 を使用するのに対し、WebSphere Application Server バージョン 6.0.x では SDK 1.4 を使用します。また、以下の Java SDK z/OS 環境変数が SDK 1.3 および SDK 1.4 の間で変更されました。
    • IBM_JAVA_ZOS_TDUMP_PATTERNJAVA_DUMP_TDUMP_PATTERN に変更されました
    • IBM_JAVA_ZOS_TDUMP 新バージョンには移植されませんでした
      IBM_JAVA_ZOS_TDUMP=No または JAVA_DUMP_TDUMP=No をコード化して、JVM シグナル・ハンドラーが IEATDUMP を呼び出さないようにし、トランザクション・ダンプを生成することはできません。 これを避けるために、JAVA_DUMP_OPTS 環境変数を使用できます。 以下に例を示します。
      JAVA_DUMP_OPTS="ONDUMP(NONE),ONOUTOFMEMORY(NONE),ONERROR(NONE),ONEXCEPTION(NONE)"
      は、シグナル・ハンドラーにより処理されるすべての状況に対しても、診断アクションを実行することはありません。

      JAVA_DUMP_OPTS 環境変数の使用法について詳しくは、IBM Developer Kit Diagnostics Guide を参照してください。

  • バージョン 5.x から Version 6.0.x へのマイグレーションを実行する前に、地域的な制約 (IEFUSI 制限など) がないかどうかを確認してください。 制限があると予期しない JVM エラーが発生することがあります。

基本的なマイグレーション・プロセスとはどんなものですか?

WebSphere Application Server for z/OS バージョン 6.0.x 用の SMP/E コードをインストールします。カスタマイズ・ダイアログのウォークスルーを使用して、マイグレーションの実行に必要なマイグレーション・ユーティリティーを作成します。 これらのジョブの実行時に、既存のバージョン 5.x 構成とは別に、新規構成が作成されます。これは、バージョン 6.0.x レベルであることを除き、あらゆる点で既存の構成と同一です。

マイグレーションはノードごとのアクティビティーですか?

はい。構成をマイグレーションするプロセスでは、構成内のそれぞれのノードに対して、 提供されているユーティリティーが実行されます。

スタンドアロン・アプリケーション・サーバーでは、ユーザーはノードを 1 つだけ所有します。ただし、そのノードはマイグレーションする必要があります。 これらのステップは、他のノードに対して実行する場合と基本的に同じです。ただし、デプロイメント・マネージャーを稼働状態にする必要はありません。 スタンドアロン・アプリケーション・サーバー・ノードをマイグレーションするためのアクティビティーのチェックリストについては、 スタンドアロン・アプリケーション・サーバー・ノードのマイグレーション・アクティビティーのチェックリスト を参照してください。

マイグレーション・ユーティリティーは何を行うのでしょうか?

マイグレーション・ユーティリティーは、以下の目的で使用します。

ユーティリティー 目的
BBOWMG1B (スタンドアロン・アプリケーション・サーバー・マイグレーション) マイグレーションするノード上のすべてのサーバーが PRR 処理モードで開始できるように構成されます。 このジョブを完了した後、マイグレーションするノード上のすべてのサーバーを開始し、 それらのサーバーが終了するのを待機する必要があります。 PRR 処理モードは、未解決のトランザクションをすべて解決し、 トランザクション・ログをクリアし、サーバーを終了します。 このジョブは、デプロイメント・マネージャーのマイグレーションには不要であり、 XA コネクターを使用しない構成ではオプションになります。

XA アダプターを使用しており XA ログをマイグレーションする必要がある場合にのみ、このジョブは必須になります。 「リソース」>「JDBC プロバイダー」と移動して、DB2、Cloudscape などの XA プロバイダーを選択しているかどうかを調べ、 バージョン 5.x 管理コンソールのリソース・プロバイダーを検査してください。

BBOWMG1F (統合ノード・マイグレーション)
 
 
 
BBOWMG2B (スタンドアロン・アプリケーション・サーバー・マイグレーション) PRR モードを使用不可にしてすべてのサーバーを通常の作動状態に戻します。 このジョブを完了した後、すべてのサーバーを開始する必要はありません。 このジョブは、デプロイメント・マネージャーのマイグレーションには不要であり、 XA コネクターを使用しない構成ではオプションになります。

XA アダプターを使用しており XA ログをマイグレーションする必要がある場合にのみ、このジョブは必須になります。 「リソース」>「JDBC プロバイダー」と移動して、DB2、Cloudscape などの XA プロバイダーを選択しているかどうかを調べ、 バージョン 5.x 管理コンソールのリソース・プロバイダーを検査してください。

BBOWMG2F (統合ノード・マイグレーション)
BBOWMBMT (スタンドアロン・アプリケーション・サーバー・マイグレーション) オプション: バージョン 6.0.x 構成ルート用に HFS およびマウント・ポイントを作成します。 バージョン 6.0.x 構成を組み込むために 既存の HFS を使用する場合は、 このジョブを実行する代わりに、 カスタマイズ・ダイアログで指定したマウント・ポイントを 手動で作成する必要があります。 いずれの場合も、マイグレーションを進める前に、HFS およびマウント・ポイントを作成しておく必要があります。
BBOWMDMT (デプロイメント・マネージャー・マイグレーション)
BBOWMMMT (統合ノード・マイグレーション)
BBOWMG3B (スタンドアロン・アプリケーション・サーバー・マイグレーション) バージョン 5.x からバージョン 6.0.x へ、ノードのマイグレーションを実行します。
BBOWMG3D (デプロイメント・マネージャー・マイグレーション)
BBOWMG3F (統合ノード・マイグレーション)
BBOMBCP (スタンドアロン・アプリケーション・サーバー・マイグレーション) 生成済み JCL プロシージャーをコピーして、 指定されたプロシージャー・ライブラリーに対してサーバーを開始します。 ご使用のバージョン 6.0.x 構成で異なる JCL 開始プロシージャー名を使用することを選択した場合は、 このユーティリティーで元のバージョン 5.x 構成に既存の名前を新規 JCL 名で置き換えて、 新規バージョン 6.0.x 構成を更新します。
BBOMDCP (デプロイメント・マネージャー・マイグレーション)
BBOMMCP (統合ノード・マイグレーション)

マイグレーションはどこで実行するのでしょうか?

マイグレーションするノードが常駐しているシステムと同じシステムでジョブを実行します。

ノードがマイグレーションされるとどうなるのでしょうか?

マイグレーション・ユーティリティーは、現在のバージョン 5.x 構成の内容を新規の別の HFS にコピーします。 このときにバージョン 6.0.x のサポートで必要な変更が行われます。

マイグレーション中に既存構成は失われますか?

マイグレーション中は、元のバージョン 5.x 構成ツリーは影響されません。 何らかの理由で完了前にマイグレーションが失敗した場合は、今までの構成はまだ残ったままです。

自分のノードに複数のアプリケーション・サーバーが存在する場合は、それらすべてをマイグレーションする必要はありますか?

はい。ユーティリティーは、Node Agent を含むすべてのサーバーを検出し、すべてをマイグレーションします。 ノードに対するマイグレーション・ユーティリティーの 1 回の起動で、そのノード内のすべてのサーバーが処理されます。

ノード内のサーバーは、マイグレーションを実行するために停止する必要はありますか?

はい。マルチノード構成では、他のノードを稼働中のままにしておくことが可能です。 ただし、マイグレーションするノードは、そのノードのサーバーを停止しておく必要があります。
注: Network Deployment 構成の一部であるアプリケーション・サーバー・ノードをマイグレーションする場合は、 そのセルのデプロイメント・マネージャーの以前マイグレーションしたバージョン 6.0.x コピーが起動され、稼働している必要があります。 これは、マイグレーションの一部が wsadmin スクリプト機能を使用して、 新規にマイグレーションされたアプリケーション・サーバー・ノードとデプロイメント・マネージャーを同期化するためです。 デプロイメント・マネージャーは、 この同期化を実行するために稼働中になっている必要があります。

1 つのセルで、マイグレーションしたノードの一部だけを作動させ、その他のノードを作動させないことは可能ですか?

はい。可能です。バージョン 5.1 は、同じセル内、および同じ LPAR 上でバージョン 6.0.x と共存できます。ただし、バージョン 5.0.x からマイグレーションする場合、 デプロイメント・マネージャー・ノードおよび他のアプリケーション・サーバー・ノードは、 同じ MVS イメージ上に次々と、すなわち実質的には同時にマイグレーションする必要があります。 バージョン 5.0.x とバージョン 6.0.x のノードは、同一の LPAR 上の同一セル内に存在することはできません。

新規にマイグレーションしたバージョン 6.0.x デプロイメント・マネージャーは、まだバージョン 5.x ノードと通信できますか?

はい。バージョン 6.0.x レベルのコードにマイグレーションされたデプロイメント・マネージャーは、バージョン 5.x ノードを管理できます。管理コンソールによって行われた変更は、そのノードに適用されます。 以下の事柄について、確認してください。
  • デプロイメント・マネージャーがバージョン 6.0.x にマイグレーションされると、「マスター構成」の新規コピーが作成されます。 「マスター構成」の以前のコピー (バージョン 5.x コピー) はまだ残っています。しかしバージョン 6.0.x デプロイメント・マネージャーが構成を変更する場合には、マスター構成の新規バージョン 6.0.x コピーを変更します。バージョン 5.x のコードのコピーが使用可能な場合に、以前のコードが復元されると、バージョン 6.0.x に対して行ったすべての変更は確認できなくなります。
  • バージョン 5.x デプロイメント・マネージャーには、バージョン 6.0.x ノードを管理する機能はありません。

マルチノード・マイグレーションを実行する順序は決まっていますか?

はい。順序は次のとおりです。
  1. 常にデプロイメント・マネージャーを最初にマイグレーションします。
  2. 同一のノード上にデプロイメント・マネージャーとして存在するバージョン 5.0.x アプリケーション・サーバーを、次にマイグレーションする必要があります。 バージョン 5.1 とバージョン 6.0.x のノードは、同一のセル内、および同一の LPAR 上に共存できるため、どのバージョン 5.1 ノードも、即時にマイグレーションする必要はありません。 共存について詳しくは、 共存サポート を参照してください。
  3. デプロイメント・マネージャーと同じシステム上かその他の MVS イメージ上にあるアプリケーション・サーバー・ノードを次にマイグレーションできます。

バージョン 6.0.x のセルと、その他のバージョン 5.x のセルは共存できますか?

はい、共存できます。SYSPLEX または任意の所定の MVS イメージの場合には可能です。 この場合には、以下のようないくつかの制約事項があります。 ほとんどの制約事項は、以前のバージョンにも存在します。
  • 同一のセル・ショート・ネームを持つ 2 つのセルは存在しません。
  • バージョン 5.0.x は、同じセル内、および同じ LPAR 上でバージョン 6.0.x と共存できません。 同一の LPAR 上に複数のバージョン 5.0.x ノードが存在している場合は、すべてのノードを同時にバージョン 6.0.x にマイグレーションする必要があります。
  • 1 つのコードのバージョンのみしか LPA/LNKLST には存在することができません。他のバージョンは STEPLIB に組み込む必要があります。リンク・パック域、リンク・リスト、および STEPLIB を参照してください。
  • 分離セルについては、コードのバージョンが異なっているかどうかとは関係なく、その他の考慮事項があります。 例えば、別の HFS マウント・ポイントおよび別の JCL プロシージャーを持つ必要があります。



関連タスク
Network Deployment 構成のバージョン 6.0.x へのマイグレーションの準備
スタンドアロン・アプリケーション・サーバー・ノードのバージョン 6.0.x へのマイグレーションの準備
スタンドアロン・アプリケーション・サーバー・ノードの マイグレーションに関するカスタマイズ・ダイアログのウォークスルー
デプロイメント・マネージャーに関するカスタマイズ・ダイアログのウォークスルー
スタンドアロン・アプリケーション・サーバー・ノードのマイグレーション
デプロイメント・マネージャー・ノードのマイグレーション
フェデレーテッド・アプリケーション・サーバー・ノードのマイグレーション
他の MVS イメージ上のフェデレーテッド・アプリケーション・サーバー・ノードのマイグレーション
関連資料
Network Deployment 構成用マイグレーション・アクティビティーのチェックリスト
スタンドアロン・アプリケーション・サーバー・ノードのマイグレーション・アクティビティーのチェックリスト
参照トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 10:52:11 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.zseries.doc/info/zseries/ae/rins_51migover.html