マイグレーションに関する考慮事項
WebSphere® Application Server バージョン 9.0 へのマイグレーション・プロセスを開始する前に、注意すべき考慮事項があります。

この項目では、プロファイル構成マイグレーションについて説明します。アプリケーションを最新バージョンにマイグレーションするには、WebSphere Application Server Migration Toolkit を使用します。詳しくは、WASdev の Migration Toolkit を参照してください。
sptcfgz/OS の考慮事項
Application Server for z/OS® をマイグレーションする前に、以下の点について考慮してください。- マイグレーションの進行では、通常、ユーザー定義の変数または Application Server によって定義された変数が繰り越されます。ただし、いくつかの特殊変数については、値が繰り越されません。
これに該当する変数は以下のとおりです。
- WAS_INSTALL_ROOT
- USER_INSTALL_ROOT
- WAS_PRODUCT_ROOT
- WAS_LIBS_DIR
- WAS_PROPS_DIR
- WAS_TEMP_DIR
- APP_INSTALL_ROOT
- DRIVER_PATH
- WAS_INSTALL_LIBRARY
- JAVA_HOME
- DEPLOY_TOOL_ROOT
- CONNECTOR_INSTALL_ROOT
- TRANLOG_ROOT
- MQJMS_LIB_ROOT
- WAS_ETC_DIR
- WEMPS_USER_ROOT
- MQ_INSTALL_ROOT
- WAS_DAEMON_ONLY_ICU_DATA
- WAS_DAEMON_ONLY_CONFIG_ROOT
- WAS_DAEMON_primordial_root
- WAS_DAEMON_daemon_was_env_file
これらの変数の値は、マイグレーションでプロファイルが作成されるときにプロファイル・テンプレートから選択されます。 これらの変数にカスタム値を定義している場合、マイグレーション先の Application Server リリースではそれらの値が維持されません。これらの変数がマイグレーションされないのは、プロファイル属性としての Application Server プロパティーであるためです。 それらの値をデフォルト以外の項目で指定変更する必要がある場合、製品インストール、プロファイル作成、およびマイグレーションのプロセス以外で値を変更する必要があります。トラブルの回避 (Avoid trouble): APP_INSTALL_ROOT 変数については、特に注意する必要があります。 APP_INSTALL_ROOT にカスタム・ロケーションを定義している場合であっても、マイグレーション・プロセスは、デフォルトでアプリケーションを以下のロケーションにインストールします。
gotcha${USER_INSTALL_ROOT}/installedApps
マイグレーション・プロセスで、 アプリケーションのインストール場所としてデフォルトではないロケーションが使用されるようにするには、 次のようにします。- zMMT の「アプリケーション・インストール・ディレクトリー (Application Install Directory)」フィールドでロケーションを指定します。
- インストール・パスを再入力しなくてもそのパスが使用されるように、マイグレーション時に「アプリケーションをマイグレーションし、以前のアプリケーション・インストール・ディレクトリーを使用する」オプションを選択します。 前のリリースのインストール・パスに変数参照が含まれている場合、Application Server は、 マイグレーションされた値でそれらの変数を解決します。
- WebSphere Application Server
バージョン 9.0 を z/OS オペレーティング・システムにインストールした後、既存のセルやノードをマイグレーションする前に、完全な WebSphere Application Server Network Deployment セル構成を作成して、それが正しく機能するかどうかを確認できます。
このプロセスにより、システムは必要なすべての前提条件を備え、製品の新しいレベルをサポートできるようになります。
- マイグレーションを実行する前に、WebSphere Application Server
バージョン 9.0 では推奨されない項目を確認します。
詳しくは、 『非推奨のフィーチャー、安定化されたフィーチャー、置換されたフィーチャー、および除去されたフィーチャー』を参照してください。
- WebSphere Application Server バージョン 7.0 以降からバージョン 9.0 にマイグレーションする前に、アプリケーション・サーバント領域 ID を鍵リングに結合し、その鍵リングに WebSphereCA 証明書が関連付けられていることを確認します。そうでないと、グローバル・セキュリティーがオンになっている場合、セキュリティー・エラーが発生します。
- WebSphere Application Server
バージョン 7.0 以降には HA マネージャーとコア・グループ機能が含まれています。
バージョン 7.0 以降からバージョン 9.0 へのマイグレーションに影響する可能性がある、コア・グループ構成およびトポロジーに関する考慮事項については、『コア・グループのマイグレーションに関する考慮事項』を参照してください。
- バージョン 6.1 より古い Internet Inter-ORB Protocol (IIOP) クライアントを実行して、同じ論理区画 (LPAR) でバージョン 9.0 サーバーと対話させる場合は、バージョン 9.0 デーモンのデーモン・プロシージャー・ライブラリーの STEPLIB に古いリリースの SBBOLD2 と SBBOLPA ライブラリーを含める必要があります。
- マイグレーションをサポートするためには、WebSphere Application Server のソース構成とターゲット構成が LPAR 上に存在する必要があります。
したがって、既存の構成を別の z/OS LPAR にマイグレーションすることはできません。 また、WebSphere Application Server バージョン 9.0 のマイグレーション・ユーティリティーを使用して、z/OS 以外のオペレーティング・システムとの間でマイグレーションを行うこともできません。
- シスプレックス環境やオペレーティング・システムにまたがるセルのマイグレーションでは、
固有のマイグレーション問題が発生しないようにします。
ノード・レベルでマイグレーションを行い、マイグレーションしているノードのプラットフォームに基づいて提供されるツールを使用します。
混合プラットフォーム・セルの設定については、ホワイト・ペーパー「WebSphere for z/OS -- Heterogeneous Cells」を参照してください。
- z/OS オペレーティング・システム上の WebSphere Application Server は、製品の配布版および i5/OS™ 版でサポートされる WASPreUpgrade、WASPostUpgrade、および manageprofiles コマンド行ツールをサポートしません。
z/OS マイグレーション管理ツールまたは zmmt コマンドを使用してマイグレーション・ジョブを生成し、生成された指示に従ってそれらのジョブをサブミットする必要があります。
- バージョン 9.0 へのマイグレーション時にシステムで必要となるストレージの量は、環境によって異なります。
- ファイル・システムのサイズは、マイグレーション定義を生成するときに、z/OS マイグレーション管理ツールまたは zmmt コマンドで指定された、1 次割り振り値 (シリンダー単位) で指定されます。さらに、このファイル・システムは、指定された 2 次割り振りに基づいて、自動的に拡張できます。マイグレーション・ツールによってこの割り振りに指定されたデフォルト値で、通常は構成データには十分です。
- マイグレーション・バックアップ・ディレクトリーには、かなりの量の一時スペースが必要です。正確な必要量はいくつかの要因によって異なりますが、ほとんどの場合、100 シリンダーで十分です (必要な場合は、トレースを含む)。一時ディレクトリーに使用可能なスペースが不明な場合は、z/OS マイグレーション管理ツールまたは zmmt コマンドでオプションを使用して、多くのスペースのあるカスタム・ロケーションに一時ディレクトリーを移動し、そこに独自の一時ファイル・システムをマウントします。適切な一時スペースを確保できないと、マイグレーション・プロセスが途中終了する恐れがあります。
- IBM®
SDK, Java™ Technology Edition バージョン 8 は、WebSphere Application Server
バージョン 9.0 のデフォルト SDK バージョンです。.
トラブルの回避 (Avoid trouble): すべてのノードが バージョン 9.0 にマイグレーションされているのでなければ、SDK Java Technology Edition バージョン 8 を使用可能にしないでください。gotcha
詳しくは、『API および仕様のマイグレーション』を参照してください。
- 複数のノードを持つセルをマイグレーションする場合、すべてのノードがマイグレーションされるまで、アプリケーションは最低の Java SDK レベルに留まる必要があります。
- マイグレーションに関する項目では、WebSphere Application Server
バージョン 9.0 を、以前のバージョンの WebSphere Application Server と共存する必要のある環境にインストールすることを想定しています。共存の使用可能化を計画する際に次の項目について考えてみます。
- 前提条件を WebSphere Application Server
バージョン 9.0 で必要とされるレベルに更新します。
以前のバージョンの WebSphere Application Server は、より高い前提条件レベルで実行されます。
- 定義済みのポートを調べて、WebSphere Application Server
バージョン 9.0 をインストールしても競合が起こらないことを確認します。
特に、WebSphere Application Server バージョン 7.0 以降と共存させてインストールする場合は、デフォルトのデーモン・ポート定義を、両方のバージョンで必ず同じにしてください。
デフォルト・ポート情報については、『デフォルトのポート割り当て』を参照してください。
詳しくは、共存アプリケーション・サーバーの実行を参照してください。
- 前提条件を WebSphere Application Server
バージョン 9.0 で必要とされるレベルに更新します。
- 混合リリース・セルを作成する計画を立てている場合は、以下の情報を検討してください。
- セル内のノードの一部を WebSphere Application Server
バージョン 9.0 にアップグレードして、それ以外は旧リリース・レベルのままにしておくことができます。すなわち、旧リリース・レベルのサーバーと新リリースが稼働するサーバーを、同じセル内で一定期間管理することができます。
この混合リリース環境では、旧リリース・レベルのサーバーでできることに制限があります。 詳しくは、『アプリケーション・サーバーの作成』を参照してください。クラスターとクラスター・メンバーの作成においても制限があります。 詳しくは、『クラスターの作成』を参照してください。
- セル内のノードの一部を WebSphere Application Server
バージョン 9.0 にアップグレードして、それ以外は旧リリース・レベルのままにしておくことができます。すなわち、旧リリース・レベルのサーバーと新リリースが稼働するサーバーを、同じセル内で一定期間管理することができます。
- WebSphere Application Server
バージョン 9.0 のマイグレーションによって、HTTP トランスポートがチャネル・フレームワーク Web コンテナー・トランスポート・チェーンに変換されます。WebSphere Application Server バージョン 9.0 のトランスポート・サポートについて詳しくは、以下の情報を参照してください。
- トランスポート・チェーンの構成
- HTTP トランスポート・チャネルの設定
- トランスポート・チェーン
- 構成ファイル・システム計画を開発する際には、保守に関する考慮事項を組み込んでください。
z/OS マイグレーション管理ツール内の製品ファイル・システム・パスにあるデフォルト値を使用して WebSphere Application Server Network Deployment 環境を構成すると、すべてのノードが、製品ファイル・システムのマウント・ポイントを直接ポイントすることになります。このような構成のため、非破壊的な方法でローリング保守を行うことはほぼ不可能です。 この方法でセルを構成して、製品ファイル・システムにサービスを適用すると、すべてのノードが同時に影響を受けます。 この方法で複数のセルを構成して、製品ファイル・システムにサービスを適用すると、すべてのセルが同時に影響を受けます。
各ノードの構成ファイル・システムと、その製品ファイル・システムの実際のマウント・ポイント間で、 「中間シンボリック・リンク」と呼ぶものを指定できます。 この戦略については、ホワイト・ペーパー「WebSphere Application Server for z/OS V5 - Planning for Test, Production and Maintenance」に説明があります。
この問題と、その保守の適用との関係について詳しくは、 ホワイト・ペーパー「Washington Systems Center Sample WebSphere for z/OS ND Configuration」を参照してください。既存の構成階層ファイル・システム (HFS) を更新して、中間シンボリック・リンクを使用できるようにするユーティリティーの取得および使用について詳しくは、「WebSphere for z/OS: Updating an Existing Configuration HFS to Use Intermediate Symbolic Links」にある指示を参照してください。
- マイグレーション・ツールは、旧バージョンからの構成のバックアップ・コピーが
含まれるマイグレーション・バックアップ・ディレクトリーを作成します。
このディレクトリーのディスク空容量は、少なくとも旧バージョンの構成ディレクトリーとアプリケーションのサイズに、マイグレーションからのバッチ・ジョブ出力のサイズを加えたものである必要があります。
通常、トレースを使用可能にしない限り、マイグレーションからのバッチ・ジョブ出力は非常に小さなものになります。 トレース出力サイズは、トレースを使用可能にしたマイグレーションのパーツによって異なります。 最大のトレース・ プロデューサーは、マイグレーションの WASPostUpgrade フェーズです。 通常、このフェーズにおけるトレース出力は、約 30 MB になります。
- WebSphere Application Server
バージョン 9.0 は、DB2® for zOS ローカル JDBC プロバイダー (RRS) をサポートしません。
マイグレーション対象となるバージョン 7.0 以降の構成で DB2 for zOS ローカル JDBC プロバイダー (RRS) が使用されている場合、バージョン 9.0 にマイグレーションする前、またはマイグレーションした直後に、DB2 Universal JDBC Driver プロバイダーを使用するよう構成を変更する必要があります。バージョン 9.0 のマイグレーション・ツールでは、プロバイダーのマイグレーションは行われません。
マイグレーションするバージョンで DB2 for zOS ローカル JDBC プロバイダー (RRS) を使用する場合、バージョン 9.0 にマイグレーションする前に DB2 Universal JDBC Driver プロバイダーを使用するよう構成を変更しないと、以下のイベントが発生します。- マイグレーション・ツールの実行中に、次のメッセージが表示されます。
MIGR0442W: DB2 for zOS Local JDBC Provider (RRS) jdbc プロバイダーをマイグレーションしていません。 手動で DB2 Universal Driver プロバイダーを作成し、置き換えてください。 詳細については、DB2 の資料を参照してください。
- マイグレーション後に、DB2 アクセスが失敗し、以下のランタイム・メッセージが表示されます。
DSRA8213W: JDBC プロバイダー DB2 for zOS Local JDBC Provider (RRS) は、WebSphere Application Server ではサポートされなくなりました。アプリケーションでは DB2 Universal JDBC Driver Provider Type 2 を使用する必要があります。
DB2 Universal JDBC Driver プロバイダーを使用するように構成を変更する必要があると判断した場合は、次のいずれかのタスクを完了することで、そうすることができます。- バージョン 9.0 にマイグレーションする前に、バージョン 7.0 以降の構成を、DB2 Universal JDBC Driver プロバイダーを使用するように変更します。
この場合、DB2 Universal JDBC Driver プロバイダーに対するマイグレーションを、バージョン 9.0 のマイグレーション・ツールが処理するため、マイグレーション後のアクティビティー ID は必要ありません。
以下のいずれかのアクションを実行します。- DB2 Universal JDBC Driver プロバイダーを使用するように構成を手動で変更します。
- バージョン 7.0 以降からマイグレーションする場合、JDBC Migration Utility for DB2 on z/OS を使用して、DB2 for zOS ローカル JDBC プロバイダー (RRS) から DB2 Universal JDBC Driver プロバイダーにマイグレーションします。
このツールは、DB2 for zOS ローカル JDBC プロバイダー (RRS) から DB2 Universal JDBC Driver プロバイダーへ、ノードを一度に 1 つずつマイグレーションするスクリプトです。 ツールに付属するホワイト・ペーパーに、ツールを実行して構成をマイグレーションする前に、DB2 Universal JDBC Driver をインストールおよび構成する方法に関する説明があります
- バージョン 9.0 にマイグレーションした後で、以下のいずれかのアクションを実行します。
- DB2 Universal JDBC Driver プロバイダーを使用するように構成を手動で変更します。
- JDBC Migration Utility for DB2 on z/OS を使用して、DB2 for zOS ローカル JDBC プロバイダー (RRS) から DB2 Universal JDBC Driver プロバイダーにマイグレーションします。
このツールは、DB2 for zOS ローカル JDBC プロバイダー (RRS) から DB2 Universal JDBC Driver プロバイダーへ、ノードを一度に 1 つずつマイグレーションするスクリプトです。
- マイグレーション・ツールの実行中に、次のメッセージが表示されます。
- 基本アプリケーション・サーバーを、z/OS オペレーティング・システムで稼働している WebSphere Application Server バージョン 9.0 にマイグレーションした後も、管理アプリケーションとユーザー・アプリケーションは、前のリリースの場合と同様に、仮想ホストである default_host において引き続き定義されます。ただし、マイグレーションされたデプロイメント・マネージャーは、 バージョン 6.1 で導入された仮想ホスト admin_host において定義されます。
- 分離されたデータ・リポジトリーを使用し (特に、SIB および Apache Derby データベースのトランザクション・ログなどの非共有データ・リポジトリー)、以前のリリースからマイグレーションする場合は、既存のデータベースおよびトランザクション・ログは保存されます。主幹業務の情報がこのローカル・データ・リポジトリーに保存されている場合は、マイグレーションを行う前に、このリポジトリーと対話操作するすべてのサーバーを正常にシャットダウンする必要があります。このサーバーは、マイグレーションが正常に完了するかロールバックされるまで、オフラインのままにしておきます。
マイグレーションが完了するか前のバージョンにロールバックした後で、この分離されたデータ・リポジトリーと対話操作するサーバーを再始動します。
- Apache Derby データベースをマイグレーションする前に、Apache Derby データベースを使用しているアプリケーションをホスティングするアプリケーション・サーバーが閉じていることを確認します。 閉じていない場合、Apache Derby のマイグレーションは失敗します。
- セキュリティー・ドメインのマイグレーションに関する、次の規則に留意してください。
- セル・レベル有効範囲のセキュリティー・ドメインを持つデプロイメント・マネージャーをマイグレーションする場合、マイグレーション・ツールで以下のアクションが行われます。
- マイグレーションで、新規構成に PassThroughToGlobalSecurity と呼ばれるドメインがまだ存在しない場合は、作成されます。
- マイグレーションで、旧の構成に存在するすべてのクラスターについてのクラスター・マッピングが新規構成に追加されます。
- マイグレーション前にバージョン 9.0 デプロイメント・マネージャー構成にのみ存在したクラスターは、PassThroughToGlobalSecurity に対するそのマッピングは変更されません。
- マイグレーション前に存在したバージョン 9.0 クラスターのマッピングは、マイグレーション後もそのまま存在します。
- マイグレーション前にバージョン 9.0 クラスターのマッピングが存在しない場合、このマッピングはマイグレーション後も存在しません。
- マイグレーション前に、前の構成とバージョン 9.0 構成の両方にクラスターが存在した場合、新規構成内のクラスターは PassThroughToGlobalSecurity ドメインに追加され、前のリリースのクラスターのように動作します。
- マイグレーション前にバージョン 9.0 デプロイメント・マネージャー構成にのみ存在したクラスターは、PassThroughToGlobalSecurity に対するそのマッピングは変更されません。
- マイグレーションにより、マイグレーションされたバージョン 6.1.x 構成に存在したすべてのバスのバス・マッピングが追加されます。
バス・マッピングは、クラスター・マッピングの場合と同じ規則に従って更新されます。
- 管理サーバー (デプロイメント・マネージャー) は、PassThroughToGlobalSecurity ドメインに追加されません。
- セル・レベル有効範囲のセキュリティー・ドメインを持つ統合ノードをマイグレーションする場合、マイグレーション・ツールで以下のアクションが行われます。
- マイグレーションで、新規構成に PassThroughToGlobalSecurity と呼ばれるドメインがまだ存在しない場合は、作成されます。
- マイグレーションにより、旧ノードの構成のすべての非クラスター化サーバーのサーバー・レベル・マッピングが PassThroughToGlobalSecurity ドメインに追加されます。
- クラスターに属している、マイグレーションされるノード上のサーバーは、PassThroughToGlobalSecurity ドメイン内のエントリーを受け取りません。これは、デプロイメント・マネージャーのマイグレーション中に、クラスター・マッピングを使用してアドレス指定されるからです。
このマッピングを除去していた場合、マイグレーションではこの動作を維持します。
- 管理サーバー (ノード・エージェント) は、PassThroughToGlobalSecurity ドメインに追加されません。
- クラスターに属している、マイグレーションされるノード上のサーバーは、PassThroughToGlobalSecurity ドメイン内のエントリーを受け取りません。これは、デプロイメント・マネージャーのマイグレーション中に、クラスター・マッピングを使用してアドレス指定されるからです。
詳しくは、『複数のセキュリティー・ドメイン』の『混合バージョン環境でのセキュリティー・ドメイン』のセクションを参照してください。
- セル・レベル有効範囲のセキュリティー・ドメインを持つデプロイメント・マネージャーをマイグレーションする場合、マイグレーション・ツールで以下のアクションが行われます。
- 前のバージョンの WebSphere Application Server で java.security ファイルを 更新した場合、マイグレーション済み java.security ファイル (V8WAS_HOME/properties/java.security) 内に更新があることを確認してください。
- マイグレーション・ツールを使用して WebSphere Application Server
バージョン 9.0 へのマイグレーションを行った後で、マイグレーション・ツールでは自動的に行われないアクションを実行しなければならない場合があります。
- WebSphere Application Server
バージョン 7.0 以降で使用した可能性のある Lightweight Third Party Authentication (LTPA) セキュリティー設定をすべて検査し、バージョン 9.0 のセキュリティーが適切に設定されていることを確認します。
詳しくは、『Lightweight Third Party Authentication』を参照してください。
- 必要ならば、マイグレーションしたサーバーを WebSphere Application Server
バージョン 9.0 で始動する前に、新しい System Authorization Facility (SAF) プロファイルを作成します。バージョン 6.1 から、 一部のセキュリティー機能は、SAF プロファイルを使用して制御されるようになりました。
- バージョン 7.0 以降、「トラステッド・アプリケーションの使用可能化 (Enabling Trusted Applications)」の設定は、前のリリースで使用されていた内部の WebSphere 変数ではなく、SAF セキュリティー・プロファイルによって制御されます。
「トラステッド・アプリケーションの使用可能化 (Enabling Trusted Applications)」オプションを使用すると、WebSphere Application Server ランタイムは、アプリケーション・コードの代わりに特定の特権命令を実行できるようになります。このオプションは、LocalOS レジストリーまたは SAF 許可を使用するすべてのサーバーに対して必須となります。
- バージョン 7.0 以降では、「許可された OS スレッドとの同期 (Sync to OS Thread Allowed)」フィーチャー (サーバー ID ではなく、オペレーティング・システム ID を使用して、アプリケーションからリソースにアクセスできるフィーチャー) の制御は、SAF セキュリティー・プロファイルと com.ibm.websphere.security.SyncToOSThread 変数によって行われます。
この実装により、管理者とシステム・セキュリティー管理者の両方が、このフィーチャーを使用するかどうかを決定できるようになります。 この実装によって、アプリケーションが どの ID を前提とするかについても制限されます。
WebSphere Application Server の前のバージョンからマイグレーションする場合に、これらのフィーチャーが必要なときは、必須となる SAF プロファイルを作成する必要があります。これらのプロファイルが存在せず、正しくセットアップされていない場合は、LocalOS ユーザー・レジストリーまたは SAF 許可を使用するセルを、バージョン 9.0 で開始しようとしても失敗します。
ご使用のセキュリティー・システムに Resource Access Control Facility (RACF®) を導入する場合は、以下の指示に従ってください。 SAF に準拠した他のセキュリティー・システムを使用する場合は、 セキュリティー・システム・ベンダーに連絡して、 必要な情報を入手してください。- 多重仮想記憶 (MVS™) システム・ログをチェックするか、管理コンソールを使用して、ご使用のサーバーで「トラステッド・アプリケーションの使用可能化 (Enabling Trusted Applications)」が使用可能になっているかどうかを判別します。
開始ログで control_region_security_enable_trusted_applications を探します。 この値が 1 に設定されている場合、「トラステッド・アプリケーションの使用可能化 (Enabling Trusted Applications)」は使用可能です。 このオプションが使用可能になっている場合は、次の SAF プロファイルを作成して、アプリケーション・サーバーの制御領域のユーザー ID に、読み取りアクセス権を与えます。
BBO.TRUSTEDAPPS.cell_shortname.cluster_transition_name
以下の RACF コマンドを使用して、このアクションを完了します。RDEFINE FACILITY BBO.TRUSTEDAPPS.cell_shortname.cluster_transition_name UACC(NONE) PERMIT FACILITY BBO.TRUSTEDAPPS.cell_shortname.cluster_transition_name ID(controller_userid) ACCESS(READ) SETROPTS RACLIST(FACILITY) REFRESH
SAF 機能プロファイルである cluster_name は、 クラスター化されていないサーバーの クラスター遷移名によって置換されます。 セル内のすべてのサーバーで「トラステッド・アプリケーションの使用可能化 (Enabling Trusted Applications)」を使用可能にする場合は、クラスター名をワイルドカード (*) に置き換えます。
詳しくは、『System Authorization Facility のクラスおよびプロファイル』を参照してください。
- 多重仮想記憶 (MVS) システム・ログをチェックするか、管理コンソールを使用して、ご使用のサーバーで「 許可された OS スレッドとの同期 (Sync to OS Thread Allowed)」が使用可能になっているかどうかを判別します。
このオプションが使用可能になっている場合は、次の SAF プロファイルを作成して、アプリケーション・サーバーの制御領域のユーザー ID に、読み取りアクセス権または制御アクセス権を与えます。
次の例には、このアクションを完了するために使用する RACF コマンドが含まれています。BBO.SYNC.cell_shortname.cluster_transition_name
RDEFINE FACILITY BBO.SYNC.cell_shortname.cluster_transition_name UACC(NONE) PERMIT FACILITY BBO.SYNC.cell_shortname.cluster_transition_name ID(controller_userid) ACCESS(CONTROL) SETROPTS RACLIST(FACILITY) REFRESH
クラスター化されていないサーバーのクラスター遷移名によって、 クラスター名が置換されます。 セル内のすべてのサーバーで「許可された OS スレッドとの同期 (Sync to OS Thread Allowed)」を使用可能にする場合は、クラスター名をワイルドカード (*) に置き換えます。
重要:- アプリケーション・サーバー制御領域の
ユーザー ID に制御領域の読み取りアクセス権を与えると、
そのユーザー ID は、SAF SURROGAT プロファイルに基づいて、
スレッド ID を変更できるものに制限されます。
コントローラーのユーザー ID が BBO.SYNC プロファイルへの 読み取りアクセス権を持っていて、com.ibm.websphere.security.SyncToOSThread 変数が true に設定されている場合、 アプリケーションは Sync to OS Thread を要求します。 アプリケーションは、呼び出し元の ID またはロールに関連するユーザー ID のいずれかが、リソースにアクセスするものと想定します。 ただし、サーバントが別のアプリケーション ID で実行するためには、SURROGAT プロファイル BBO.SYNC.application_userid への読み取りアクセスが必要となります。
- アプリケーション・サーバー制御領域のユーザー ID に制御領域の制御アクセス権を与えると、スレッド ID を、OS スレッドとの同期を要求する任意のユーザー ID に切り替えられるようになります。
コントローラーのユーザー ID が BBO.SYNC プロファイルへの 制御アクセス権を持っていて、com.ibm.websphere.security.SyncToOSThread 変数が true に設定されている場合、 アプリケーションは Sync to OS Thread を要求します。 アプリケーションは、呼び出し元の ID または ロールに関連するユーザー ID のいずれかが、 リソースにアクセスするものと想定します。 SURROGAT プロファイルは、チェックされません。
詳しくは、『Application Synch to OS Thread Allowed』を参照してください。
- アプリケーション・サーバー制御領域の
ユーザー ID に制御領域の読み取りアクセス権を与えると、
そのユーザー ID は、SAF SURROGAT プロファイルに基づいて、
スレッド ID を変更できるものに制限されます。
- バージョン 7.0 以降、「トラステッド・アプリケーションの使用可能化 (Enabling Trusted Applications)」の設定は、前のリリースで使用されていた内部の WebSphere 変数ではなく、SAF セキュリティー・プロファイルによって制御されます。
- ロール・ベースの許可に SAF EJBROLE プロファイルを使用する場合は、バージョン 6.1 で導入された 2 つの管理ロール (デプロイヤーロールと管理セキュリティー・マネージャー・ロール) の EJBROLE プロファイルを作成します。
- Java 仮想マシン (JVM) の設定を調べて、始動パフォーマンスを向上させるために少なくとも 50 のヒープ・サイズを使用していることを確認します。
詳しくは、資料の『Java 仮想マシン設定』の項目を参照してください。
使用していたヒープ・サイズがこれより小さい場合は、デフォルトのヒープ・サイズ (50) を使用できます。
- Apache Derby データベースの自動マイグレーションの結果を検証して、ツールによって自動的にマイグレーションされなかった Apache Derby データベースを、すべて手動でマイグレーションします。
詳しくは、『Apache Derby データベースのマイグレーション』をお読みください。
- 同じ論理区画 (LPAR) に複数のノード・エージェントがある場合、マイグレーション・ジョブの実行後に IPC_CONNECTOR_ADDRESS ポートの競合が発生する可能性があります。 競合するポートを再構成してください。
- Transport Layer Security (TLS) を介して Session Initiation Protocol (SIP) Uniform Resource Identifier (URI) への要求の送信を試みるアプリケーションがある場合、WebSphere Application Server のバージョン 6.1 とバージョン 9.0 での動作の相違に注意してください。
SIP アプリケーションがバージョン 6.1 で TLS を介した SIP URI への要求を送信すると、要求 URI のスキームは "sip" から "sips" に変更されます。バージョン 9.0 では、このスキームは変更されずに維持されます。
この違いは、要求 URI に "sip" スキームと "tls" トランスポート・パラメーターが含まれる SIP 要求をアプリケーションが送信しようとしたときに明らかになります。 例えば、バージョン 6.1 のアプリケーションが、
という要求 URI を使用して要求を作成し、それをネットワークに送信すると、SIP コンテナーは、スキームとトランスポート・パラメーターの両方を変更して、sip:alice@atlanta.com;transport=tls
という要求 URI を生成します。バージョン 9.0 では、SIP コンテナーはスキームを変更しません。sips:alice@atlanta.com;transport=tcp
バージョン 6.1 アプリケーション・サーバーをバージョン 9.0 にマイグレーションした後で古い動作が維持されるようにしたい場合は、アプリケーション・コードを変更してください。アプリケーションは、"sips" URI を送信する予定の場合、メッセージの送信を要求する前にこの方法で URI を作成する必要があります。 "sips" URI を使用すると、バージョン 6.1 の動作が維持されます。
- WebSphere Application Server
バージョン 7.0 以降で使用した可能性のある Lightweight Third Party Authentication (LTPA) セキュリティー設定をすべて検査し、バージョン 9.0 のセキュリティーが適切に設定されていることを確認します。


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-zos&topic=cmig_pre
ファイル名:cmig_pre.html