z/OS オペレーティング・システムでのスタンドアロン・アプリケーション・サーバーのマイグレーション

スタンドアロン・アプリケーション・サーバー・ノードを WebSphere® Application Server for z/OS® バージョン 9.0 にマイグレーションするためのジョブ制御言語 (JCL) ジョブを生成すると、これらのジョブを実行して実際のマイグレーションを行うことができます。カスタム・マイグレーション・ジョブの生成時には、ジョブの生成に使用された CNTL データ・セットの BBOMBINS メンバーでマイグレーション・ジョブを準備し実行するような、カスタマイズされた指示も作成しています。 スタンドアロン・アプリケーション・サーバーを バージョン 9.0 にマイグレーションするプロセスを実行するために、これらのカスタマイズされた指示に従います。

始める前に

サポートされる構成 サポートされる構成:

この項目では、プロファイル構成マイグレーションについて説明します。アプリケーションを最新バージョンにマイグレーションするには、WebSphere Application Server Migration Toolkit を使用します。詳しくは、WASdev の Migration Toolkit を参照してください。

sptcfg
  • マイグレーション、共存、およびインターオペラビリティーの概要およびマイグレーションに関する考慮事項を参照してください。
  • JCL マイグレーション・ジョブを生成していない場合は、先へ進むことができません。
  • これらの指示で参照する BBOWMG1B、BBOWMG2B、BBOWMG3B、BBOWBPRO、BBOWBPRE、および BBOWBPOS の各ジョブは、WebSphere Administrator ユーザー ID によって実行依頼する必要があります。

    他のすべてのジョブは、ファイル・システムを制御できるユーザー ID によって実行依頼する必要があります。

  • プロファイル・ホーム・ディレクトリーの名前が、単一のアルファベット文字の後にコロンが続くもの (a: など) でないことを確認する必要があります。 マイグレーション・ジョブでは、単一のアルファベット文字の名前が、無限ループを実行する「/」と解釈されます。
  • ヒント: マイグレーション後に構成を以前の状態にリストアできるようにする場合は、WebSphere Application Server バージョン 7.0 以降のスタンドアロン・アプリケーション・サーバーをマイグレーションする前に、backupConfig コマンドまたは設定済みのバックアップ・ユーティリティーを使用して既存の構成をバックアップしてください。 詳しくは、 backupConfig コマンド を参照してください。このバックアップ構成の正確な名前と位置を記録しておく必要があります。

ヘルプについては、マイグレーションのトラブルシューティングを参照してください。

このタスクについて

移行ユーザーの方へ 移行ユーザーの方へ: 以下の製品では、以前は別々のマイグレーション・ツールが必要でしたが、標準マイグレーション・プロシージャーの一部としてマイグレーションされるようになりました。
  • WebSphere Extended Deployment Compute Grid または Feature Pack for Modern Batch
  • WebSphere Virtual Enterprise または Intelligent Management
これらの変更点について詳しくは、マイグレーションの新機能を参照してください。trns

手順

  1. 新規 バージョン 9.0 構成ファイル・システムの作成とマウント。

    マイグレーションを実行するには、 事前に バージョン 9.0 で新規構成用にファイル・システムが存在している必要があります。新規構成ファイル・システムの作成およびマウントは、BBOMBHFS または BBOMBZFS ジョブを実行して行うことができますが、手動でマウントすることもできます。 いずれにしても、ファイル・システムを バージョン 9.0 構成用に作成およびマウントしてから、 先へ進む必要があります。この構成ファイル・システムはマイグレーションのターゲットで、バージョン 7.0 以降 構成ファイル・システムはソースです。

    BBOMBHFS または BBOMBZFS ジョブは、マウント・ポイント・ディレクトリーを作成し、構成のファイル・システムを割り振り、マイグレーション・ジョブの生成時にマウント・ポイントに指定した値でファイル・システムをマウントします。

    構成ファイル・システム・データ・セットの割り振り、作成、およびマウントを、手動もしくは BBOMBHFS または BBOMBZFS ジョブを使用して完了していることを確認してから続行してください。 マウント・ポイントは、WebSphere Admin ID に所有され、 755 以上の許可を持っていなければなりません。 新規構成ファイル・システム構造を BPXPARM に含めて、 次の IPL でマウントされるようにします。

  2. 生成済み JCL プロシージャーをコピーします。

    マイグレーション・ユーティリティー BBOMBCP は、 指定されたプロシージャー・ライブラリーに対してサーバーを開始するのに使用する生成済み JCL プロシージャーをコピーします。 バージョン 9.0 の構成では、バージョン 7.0 以降 の構成で使用したものとは別の JCL プロシージャーを使用する必要があります。このユーティリティーは、 元のバージョン 7.0 以降の構成内の JCL 名を新規 JCL 名で置き換えて、新規 バージョン 9.0 構成を更新します。

    注意: このユーティリティーは、 生成した JCL をプロシージャー・ライブラリーにコピーします。マイグレーション・ジョブの 生成時に バージョン 7.0 以降 構成で使用したのと同じ名前を指定した場合、 このユーティリティーは既存のプロシージャーをオーバーレイします。同じ名前を使用している場合、後でロールバックする必要があるときに、このユーティリティーを実行する前に既存の バージョン 7.0 以降 プロシージャーを必ずバックアップしてください。

    BBOMBCP ジョブをサブミットして、戻りコードの 0 を確認します。

  3. 新規プロシージャー名を指定する場合、コントローラーおよびデーモンの RACF® STARTED プロファイルを更新します。
    コントローラー・リージョンが使用する STARTED プロファイルは、 プロシージャー名および JOBNAME に基づいています。 適切な ID を開始済みタスクに割り当てるために、STARTED プロファイルを適用する必要があります。 例えば、バージョン 7.0 以降のコントローラー JCL プロシージャー名が AZACR であり、バージョン 9.0 に対して AZ6ACR を指定した場合、 次のようにその新規プロシージャー名の STARTED プロファイルを作成する必要があります。
                  new controller      same identity used in
                     JCL name         V7.0 or later configuration
                        |                    |
     RDEFINE STARTED AZ6ACR.* STDATA(USER(AZACRU) GROUP(AZCFG) TRACE(YES))
    注:
    • 異なるユーザー ID を使用して始動しないでください。 ユーザー ID には、他の事項も関連しており、ユーザー ID を変更すると、 それらの事項も変更する必要があります。
    • オリジナル STARTED プロファイルが汎用の場合 (STARTED AZ*.*... など) には、 新規 STARTED プロファイルを作成する必要はありません。
    • サーバント・リージョン STARTED プロファイルは、プロシージャー名ではなく、JOBNAME に基づいています。 このため、サーバントでは、別のプロシージャー名を使用しても問題ありません。
    • デーモンおよびノード・エージェントはコントローラーです。このためこれらのコントローラーに別のプロシージャー名を使用すると、新規 STARTED プロファイルが暗黙指定されます。
  4. BBOWMG1B および BBOWMG2B ジョブをサブミットします。
    注: XA コネクターを使用していない場合、BBOWMG1B および BBOWMG2B ジョブの実行依頼はオプションです。 ただし、トランザクション・ログが確実にクリアされるようにするには、両方のジョブをサブミットする必要があります。

    BBOWMG1B ジョブにより、マイグレーションするアプリケーション・サーバー・ノード上のすべてのサーバーが「ピアの再始動およびリカバリー (PRR)」処理モードで開始できるようになります。 PRR 処理モードは、未解決のトランザクションをすべて解決し、トランザクション・ログをクリアし、サーバーを停止します。 BBOWMG2B ジョブは、PRR モードを使用不可にし、すべてのサーバーを通常の作動状態に戻します。

    以下のステップに従って、XA トランザクション・ログをクリアします。
    1. BBOWMG1B ジョブをサブミットして、戻りコードの 0 を確認します。
    2. アプリケーション・サーバーを再始動し、そのサーバーが PRR 処理を実行して自動的に停止するのを待機します。
    3. BBOWMG2B ジョブをサブミットして、戻りコードの 0 を確認します。
  5. バージョン 7.0 以降のデーモンおよびアプリケーション・サーバーを停止します。

    デーモンは、 同じ LPAR 上で管理するサーバーの最高レベルのバージョンになっている必要があります。サーバーの始動時には、 レベルは バージョン 9.0 になります。

    先に進む前に、バージョン 7.0 以降のアプリケーション・サーバーを停止する必要があります。

  6. ログ・ストリームを削除および再定義します。

    このステップは、 ログ・ストリームを使用するためにバージョン 7.0 以降 サーバーでトランザクション XA パートナー・ログまたは補正ログを以前に構成している場合に限り実行します。

    1. ノードが停止されていることを確認します。
    2. ログ・ストリームを削除および再定義します。

      最初にサーバーでログ・ストリームを使用するように構成している場合、 バージョン 7.0 以降 のカスタマイズ中に作成した BBOLOGSD ジョブおよび BBOLOGSA ジョブを使用することができます。

      以下の例で、これらのジョブの例を示します。
      //RLSP1A  JOB 'xxxx,yyy,?','USERID',MSGCLASS=H,
      //         CLASS=J,MSGLEVEL=(1,1),REGION=4M,NOTIFY=&SYSUID
      //STEP1   EXEC PGM=IXCMIAPU
      //STEPLIB  DD   DSN=SYS1.MIGLIB,DISP=SHR
      //SYSPRINT DD   SYSOUT=*
      //SYSIN    DD   *
      
      DATA TYPE(LOGR) REPORT(YES) /* Default to show output of job */
       DELETE LOGSTREAM NAME(P1ACEL6A.W51ASA2.D)
       DEFINE LOGSTREAM NAME(P1ACEL6A.W51ASA2.D)
              LOWOFFLOAD(20)
              HIGHOFFLOAD(79)
              STG_DUPLEX(YES)
              DUPLEXMODE(UNCOND)
              STG_DATACLAS(OPERLOG)
              STG_SIZE(5000)
              HLQ(Q10RRS)
              LS_SIZE(5000)
              LS_DATACLAS(OPERLOG)
              STRUCTNAME(WAS_LOGRLS)
      /*
  7. 以下のいずれかのアクションを実行します。
    1. BBOWMG3B ジョブをサブミットします。

      BBOWMG3B ジョブは、マイグレーション・ジョブの生成時に入力した情報に基づいて、バージョン 7.0 以降のノードからバージョン 9.0 への物理マイグレーションを実行します。BBOWMG3B ジョブをサブミットし、戻りコードの 0 を受け取ることを確認し、ファイル・システム上のマイグレーションの一時ディレクトリーにあるログ・ファイルを調べてください。マイグレーション一時ディレクトリーは temporary_directory_location/nnnnn であり、 ここで、temporary_directory_location は一時ディレクトリー・ロケーションに指定したディレクトリー (デフォルトは /tmp/migrate)、 nnnnn はマイグレーション・ジョブの生成時にマイグレーション ID 用に 生成した数値です。

    2. 次の 3 つのジョブをサブミットします。
      1. BBOWBPRO ジョブをサブミットします。

        BBOWBPRO は、Websphere Application Server のホームおよびデフォルト・プロファイルを作成します。

      2. BBOWBPRE ジョブをサブミットします。

        BBOWBPRE は、マイグレーション事前アップグレード・プロセスを実行します。

      3. BBOWBPOS ジョブをサブミットします。

        BBOWBPOS は、マイグレーション事後アップグレードおよび完了 (ファイル・アクセス権限の変更) プロセスを実行します。

  8. 新規アプリケーション・サーバー・ノードを始動します。

    バージョン 7.0 以降のアプリケーション・サーバーの開始に使用するものと同じ既存のコマンドを使用しますが、RACF STARTED プロシージャー名は、マイグレーション・ジョブの生成時にコントローラー・プロシージャー名として入力した値に置き換えます。このコマンドにより バージョン 9.0 アプリケーション・サーバーを開始します。サーバーが初期化を終了するまで待機してから、先に進みます。

    次のメッセージがコンソール上および BBOS001 のジョブ・ログ内に表示されます。
    BBOO0019I INITIALIZATION COMPLETE FOR WEBSPHERE FOR z/OS CONTROL PROCESS BBOS001
  9. Compute Grid または Feature Pack for Modern Batch 用に、ジョブ・スケジューラーが正しくマイグレーションされたこと、および、バッチ・アプリケーションをホストしているサーバーにジョブをディスパッチできることを検証します。

    ジョブ・スケジューラーのマイグレーションを検証するには、サーバーの再始動後に、Web ブラウザーを介してジョブ管理コンソールにアクセスします。

    バッチ・アプリケーションをホストしているサーバーが正しく機能していることを検証するには、次のようにします。
    1. マイグレーションされたサーバー上のバッチ・アプリケーションが開始されることを検証します。サーバー・ログで、エラーがないかどうか調べてください。
    2. マイグレーションされたジョブ・スケジューラー・サーバーからジョブをサブミットすることによって、マイグレーションされたサーバーにバッチ・ジョブをディスパッチできることを検証します。ジョブのサブミットは、 ジョブ管理コンソール、WSGrid ユーティリティー、EJB インターフェース、または Web サービス・インターフェースを使用して行うことができます。

次のタスク

バージョン 9.0 へのマイグレーションが正常に終了して、マイグレーション後の構成が正常に稼働することを確認した後、以下の項目を削除します。
  • ソース構成のファイル・システム内にあるすべてのもの
  • ターゲット構成の temporary_directory_location/nnnnn ディレクトリー内にあるすべてのもの。ここで、temporary_directory_location は 一時ディレクトリー・ロケーションに指定したディレクトリー (デフォルトで /tmp/migrate) であり、 nnnnn はマイグレーション・ジョブの作成時にマイグレーション ID 用に生成した 数値です。
  • bbomigrt2.sh ファイル

トピックのタイプを示すアイコン タスク・トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-zos&topic=tmig_z_sas
ファイル名:tmig_z_sas.html