アプリケーション・サーバー設定

サーバーの論理名を指定します。サーバー名は、ノード内で固有でなければなりません。 ただし、クラスター内に複数のノードがある場合、 サーバーとノードのペアが固有であれば、同じサーバー名を異なるサーバーに指定することができます。 このフィールドに表示される値を変更することはできません。

例えば、同じクラスター内で、node1 というノード内の server1 というサーバーと、 node2 というノード内の server1 というサーバーは許可されます。 ただし、同じノード内で 2 つのサーバーに server1 という名前を付けることはできません。この製品は、スクリプトのサーバーを参照するなどの管理アクションで、サーバー名を使用します。

z/OS プラットフォームでは、この名前をロング・ネームと呼ぶ場合があります。

トラブルの回避: グローバル・リソース・シリアライゼーション (GRS) リングを使用して、1 つのシスプレックス環境に 1 つ以上のモノプレックスを接続する場合、 それらのモノプレックスで稼働するすべてのサーバーの セル名は、GRS 環境全体でそれぞれ固有の名前でなければなりません。 この要件は、どのモノプレックスで稼働するサーバーについても、セル名が以下の条件を満たす必要があることを意味します。

• シスプレックス内で実行されているすべてのサーバーのセル名と異なる
• シスプレックスに接続されている別のモノプレックスで実行されているすべてのサーバーのセル名と異なる

重複したセル名を持つサーバーが GRS 環境内に存在する場合、WebSphere Application Server では、シスプレックス・セルとモノプレックス・セルを区別できず、 両方のサーバーを同じセルの部分として扱います。この不正確なセルの関連付けは、通常予測できない処理結果をもたらします。gotcha

サーバーのショート・ネームを指定します。この名前はセル内で固有でなければなりません。このフィールドは、z/OS プラットフォームにのみ表示されます。ショート・ネームは、 デフォルトの z/OS ジョブ名でもあり、Workload Manager (WLM)、自動リスタート・マネージャー、SAF (例えば RACF®)、 および始動済みタスク制御などのオペレーティング・システム固有の機能に対してサーバーを識別します。

このフィールドはオプションであり、z/OS で実行している場合のみ表示されます。 ショート・ネーム・フィールドに 値を指定しない場合、ショート・ネームはデフォルトで BBOSnnn になります。ここで、nnn は 固有のショート・ネームの作成に使用できる、セル内の最初の空き番号です。例えば、デフォルトのショート・ネームが既にセル内の他の 2 つのサーバーに割り当てられている場合に、 このサーバーの作成時にショート・ネームを指定しないと、 ショート・ネーム BBOS003 がこのサーバーに割り当てられます。 アプリケーション・サーバーの作成後、この生成済みショート・ネームは、 ご使用の命名規則に準拠した名前に変更することができます。

サーバントと付属のジョブ名のデフォルト値は、 このショート・ネームに S (サーバントの場合) または A (付属の場合) が付いたものです。 8 文字のサーバー・ショート・ネームを使用する必要がある場合、 サーバントと付属のジョブ名は 9 文字の名前になります。 したがって、新規の 8 文字のサーバー・ショート・ネームを使用するには、 サーバント定義と付属のプロセス定義用に、 開始コマンドの引数を更新する必要があります。 『7 文字のサーバー・ショート・ネームの 8 文字への変換』のトピックに、 この更新を行う方法についての説明があります。

サーバーの汎用ショート・ネームを指定します。 この名前はセル内で固有でなければなりません。 このフィールドはオプションで、z/OS プラットフォームでのみ表示されます。サーバーの汎用ショート・ネームは、 クラスター遷移名 (クラスター化されていないサーバーを作成する場合)、 またはクラスター・ショート・ネーム (クラスター・サーバーを作成する場合) に なります。

汎用ショート・ネーム・フィールドに値を指定しない場合、 汎用ショート・ネームはデフォルトの BBOCnnn に設定されます。 この場合 nnn は、固有の汎用ショート・ネームの作成に使用可能なセル内の最初の空き番号です。例えば、デフォルトの汎用ショート・ネームが既にセル内の他の 3 つのサーバーに割り当てられている場合に、 このサーバーの作成時に汎用ショート・ネームを指定しないと、 汎用ショート・ネーム BBOC004 がこのサーバーに割り当てられます。

このオプションを使用可能にすると、バイトコード検証の使用不可化やジャストインタイム (JIT)・コンパイラーのコンパイル・コストの削減など、一部の JVM 設定を変更するため、アプリケーション・サーバーの起動時間が削減されることがあります。実働サーバーでは、 この設定を使用可能にしないでください。この設定は、バージョン 6.0 以降のセルで稼働しているアプリケーション・サーバー上でのみ使用可能です。

開始値として -Xverify および -Xquickstart JVM プロパティーを使用することを指定します。このオプションを選択する前に、-Xverify および -Xquickstart プロパティーを汎用引数として JVM 構成に追加します。

このオプションを選択した場合は、構成の変更が有効になる前に構成を保存し、サーバーを再始動する必要があります。

このオプションのデフォルト設定は false であり、 サーバーが開発モードでは始動しないことを示しています。 このオプションを true に設定すると、サーバーの起動時間を短縮する設定を使用してサーバーが開発モードで始動するように指定されます。

複数のスレッドでサーバーを始動する場合は、このフィールドを選択します。これにより、 起動時間を短縮できます。

サーバー・コンポーネント、サービス、およびアプリケーションが順次ではなく並列に開始されるように指定します。

このオプションのデフォルト設定は true であり、 サーバーの始動時に、サーバー・コンポーネント、サービス、およびアプリケーションが、マルチスレッドで開始することを示しています。このオプションを false に設定すると、サーバーの始動時に、サーバー・コンポーネント、サービス、およびアプリケーションが、単一スレッドで開始するように指定され、このため、起動時間が長くなる場合があります。

アプリケーションが開始される順序は、 ユーザーがアプリケーションに割り当てるウェイトによって異なります。ウェイトが同じアプリケーションは、同時に開始されます。

アプリケーションのウェイトを設定するには、管理コンソールで「アプリケーション」 > 「アプリケーション・タイプ」 > 「WebSphere エンタープライズ・アプリケーション」 > 「application_name」 > 「始動の動作」とクリックして、「始動の順序」フィールドに適切な値を指定します。アプリケーションが重要であればあるほど、始動順序の値は低くなります。 例えば、最も重要なアプリケーションに始動順序の値 1 を指定し、次に重要なアプリケーションに値 2 を指定します。 また、次の 4 つのアプリケーションすべてを同時に開始させたい場合は、これら 4 つのアプリケーションに始動順序 3 を指定することができます。

このサーバーで実行中のアプリケーションが必要とするときにサーバー・コンポーネントを開始させる場合は、このプロパティーを選択します。

このプロパティーを選択すると、サーバー・コンポーネントは 必要に応じて動的に開始されます。このプロパティーを選択していないと、すべてのサーバー・コンポーネントが サーバー開始プロセス中に開始されます。したがって、このオプションを選択すると、始動プロセス時に開始されるコンポーネントの数が減るため、起動時間を短縮し、サーバーのメモリー占有スペースを削減することができます。

必要に応じたコンポーネントの開始は、サーバーにデプロイされているアプリケーションがすべて同じタイプの場合、最も効果的です。 例えば、このオプションは、すべてのアプリケーションがサーブレット、および JavaServer Pages (JSP) を使用する Web アプリケーションである場合に、より効果的に機能します。 アプリケーションでサーブレット、JSP および Enterprise JavaBeans (EJB) を使用している場合は、 このオプションの効果はほとんどありません。

トラブルの回避: 他の WebSphere 製品との互換性を確保するため、 このオプションはデフォルト設定では選択解除されています。 このオプションを選択する前に、この製品と一緒に実行している他の WebSphere 製品がこの機能をサポートしていることを確認してください。gotcha

アプリケーション・サーバーが 64 ビット・モードで実行するように指定します。これは、デフォルト設定です。 64 ビット・モードで実行すると、追加の仮想ストレージがユーザー・アプリケーションに提供されます。 このフィールドは、z/OS プラットフォームにのみ表示されます。

デフォルトでは、WebSphere カスタマイズ・ツールボックスは、ご使用のアプリケーション・サーバーすべてを 64 ビット・モードで始動するように設定されています。ただし、WebSphere カスタマイズ・ツールボックスの設定を、ご使用のアプリケーション・サーバーすべてを 31 ビット・モードで始動するように変更することができます。特定のアプリケーション・サーバーを 31 ビット・モードで始動するだけの場合は、ご使用のアプリケーション・サーバーのサブセットに対するこの設定を選択解除することもできます。

さまざまなサーバーを実行しているモード間に相互依存関係はありません。 したがって、サーバーのいくつかを 31 ビット・モードで実行し、いくつかを 64 ビット・モードで実行することができます。ただし、最終的にすべてのサーバーを 64 ビット・モードで実行するように変換する必要があります。 それは、31 ビット・モードで稼働するサーバーに対するサポートが推奨されないためです。

サーバーが「制限」モードまたは「許可」モードのどちらで稼働できるかを指定します。

「制限」モードは、マイグレーションに対するアプリケーションの適合性の判別に役立てられる診断モードです。このモードでは、内部アプリケーション・サーバー・クラスがアクセスされるかどうかを判別します。 これらの内部クラスを使用すると、将来のリリースでこれらのアプリケーションが正常に動作しなくなる可能性があります。ただし、「制限」モード は、クラスが変更される可能性がある場合でも、一般的な使用からすべてのクラスを除外することを意図しているものではありません。 変更される可能性があるクラスの中には、アプリケーション・サーバーの正しい動作のために制限されないものもあります。 「制限」モードは、アプリケーションとアプリケーション・サーバー内部クラスを完全に分離することを目的としていません。「制限」モードは、実動ランタイム環境で使用しないでください。結果は、指針としてのみ使用してください。

このプロパティーのデフォルト値は Allow です。

単一のクラス・ローダーですべてのアプリケーションをロードするか、 またはアプリケーションごとに異なるクラス・ローダーを使用するかを選択します。

クラス・ローダーが、クラスをロードする際に、最初に親クラス・ローダーを検索するのか、あるいはアプリケーション・クラス・ローダーを検索するのかを指定します。 Developer Kit クラス・ローダーおよびこの製品のクラス・ローダーの標準は、「親が最初」です。

このフィールドは、「クラス・ローダー・ポリシー」フィールドを S*ingle にした場合にのみ適用されます。

Application first を選択すると、 アプリケーションは、親クラス・ローダーに含まれるクラスをオーバーライドできますが、 オーバーライドされたクラスとオーバーライドされていないクラスを共に使用した場合、 このアクションにより、ClassCastException またはリンケージ・エラーが発生する可能性があります。

ネイティブ・オペレーティング・システム上におけるこのサーバーのプロセス ID。

このプロパティーは読み取り専用です。 この値は、自動的に生成されます。

このサーバーが稼働しているセルの名前。

このプロパティーは読み取り専用です。

このサーバーが稼働しているノードの名前。

このプロパティーは読み取り専用です。

このサーバーの実行時の開始状態。

このプロパティーは読み取り専用です。

「追加プロパティー」の下のこのリンクには、製品のインストールの際の製品情報が表示されます。この情報には、製品名、ID、バージョン、作成日付、および作成レベルが含まれます。