Application server settings
Use this page to configure an application server or a cluster member template. An application server is a server that provides services required to run enterprise applications. A cluster member template is the set of application server configuration settings assigned to new members of a cluster.
This topic references one or more of the application server log files. As a recommended alternative, we can configure the server to use the High Performance Extensible Logging (HPEL) log and trace infrastructure instead of using SystemOut.log , SystemErr.log, trace.log, and activity.log files on distributed and IBM i systems. We can also use HPEL in conjunction with the native z/OS logging facilities. If we are using HPEL, we can access all of the log and trace information using the LogViewer command-line tool from the server profile bin directory. See the information about using HPEL to troubleshoot applications for more information on using HPEL. To view this console page, click Servers > Server Types > WebSphere application servers > server_name.
On the Configuration tab, we can change field settings. We can also click Installed applications to view the status of applications that are running on this server. On the Runtime tab, we can view read only information. The Runtime tab is available only when the server is running.
Name
Logical name for the server. Server names must be unique within a node. However, for multiple nodes within a cluster, we might have different servers with the same server name as long as the server and node pair are unique. We cannot change the value that appears in this field.
For example, a server named server1 in a node named node1 in the same cluster with a server named server1 in a node named node2 is allowed. However, we cannot have two servers named server1 in the same node. The product uses the server name for administrative actions, such as referencing the server in scripting.
(zos) On the z/OS platform, this name is sometimes referred to as the long name.
Information Value Default server1 (zos) Avoid trouble: For a global resource serialization (GRS) ring to attach one or more monoplexes to a sysplex environment, the cell name of any servers running in any of the monoplexes must be unique within the entire GRS environment. This requirement means that the cell name of a server running in any of the monoplexes:
- Must be different than the cell name of any servers running in the sysplex
- Must be different than the cell name of any servers running in another monoplex that is attached to the sysplex
If we have servers with duplicate cell names within the GRS environment, WAS cannot differentiate between the sysplex cell and the monoplex cell, and treats both servers as part of the same cell, This inaccurate cell association typically causes unpredictable processing results.gotcha
(zos) Short name
Short name of the server and must be unique within a cell. This field only displays for the z/OS platform. The short name is also the default z/OS job name and identifies the server to the native facilities of the operating system, such as Workload Manager (WLM), Automatic Restart Manager, SAF (for example, RACF ), and started task control.
This field is optional, and only displays if you are running on z/OS. If we do not specify a value for the short name field, the short name defaults to BBOSnnn, where nnn is the first free number in the cell that can be used to create a unique short name. For example, if default short names are already assigned to two other servers in the cell, the short name BBOS003 will be assigned to this server if we do not specify a short name when creating this server. After the application server is created, we can change this generated short name to a name that conforms to the naming conventions.
The default values for the servant and adjunct jobnames are this short name with either an S, for the servant, or an A, for the adjunct, appended. If use an 8-character server short name, the servant and adjunct jobnames become 9-character names. Therefore, you must update the start command arguments for the servant and the adjunct process definitions to use the new 8-character server short name. The topic "Converting a 7-character server short name to 8 characters" describes how to perform this update.
If we specify a short name, the name:
- Must be one to eight characters in length. By default, z/OS assumes you are using a 7-character server short name (JOBNAME). If the naming standards require 8 characters, we can lengthen the 7-character server short name to 8 characters.
- Must contain only uppercase alphanumeric characters
- Cannot start with a number.
- Must be unique in the cell.
(zos) Generic short name
Specifies the generic short name of the server and must be unique within a cell. This field is optional, and only displays for the z/OS platform. The generic short name for the server becomes either the cluster transition name, if you are creating an unclustered server, or the cluster short name, if you are creating a clustered server.
If we do not specify a value for the generic short name field, the generic short name defaults to BBOCnnn, where nnn is the first free number in the cell that can be used to create a unique generic short name. For example, if default generic short names are already assigned to three other servers in the cell, the generic short name BBOC004 is assigned to this server if we do not specify a generic short name when creating this server.
If we specify a generic short name, the name:
- Must be one to eight characters in length.
- Must contain only alpha-numeric or national language characters.
- Cannot start with a number.
- Must be unique in the cell.
(zos)(dist)
Run in development mode
Enable this option might reduce application server start-up time because it changes some of the JVM settings, such as disabling bytecode verification, and reducing just-in-time (JIT) compiler compilation costs. Do not enable this setting on production servers. This setting is only available on an application server running in a Version 6.0 or later cell.
Specifies to use the -Xverify and -Xquickstart JVM properties as startup values. Before selecting this option, add the -Xverify and -Xquickstart properties as generic arguments to the JVM configuration.
If we select this option, then you must save the configuration, and restart the server before this configuration change takes effect.
The default setting for this option is false, which indicates that the server does not start in development mode. Setting this option to true specifies that the server starts in development mode with settings that decrease server start-up time.
Information Value Data type Boolean Default false
Parallel start
Select this field to start the server on multiple threads. This might shorten the startup time.
Specifies we want the server components, services, and applications to start in parallel rather than sequentially.
The default setting for this option is true, which indicates that when the server starts, the server components, services, and applications start on multiple threads. Setting this option to false specifies that when the server starts, the server components, services, and applications start on a single thread, which might lengthen start-up time.
The order in which the applications start depends on the weights that we assign to them. Applications that have the same weight start in parallel.
To set the weight of an application, in the console, click Applications > Application Types > WebSphere enterprise applications > application_name > Startup behavior, and then specify an appropriate value in the Startup order field. The more important an application is, the lower the startup order value should be. For example, you might specify a startup order value of 1 for your most important application, and a value of 2 for the next most important application. We might then specify a startup order of 3 for the next four applications because we want all four of those applications to start in parallel.
Information Value Data type Integer Default 1 Range 0 - 2147483647
Start components as needed
Select this property if we want the server components started as they are needed by an application running on this server.
When this property is selected, server components are dynamically started as they are needed. When this property is not selected, all of the server components are started during the server startup process. Therefore, selecting this option can improve startup time, and reduce the memory footprint of the server, because fewer components are started during the startup process.
Start components as they are needed is most effective if all of the applications, that are deployed on the server, are of the same type. For example, using this option works better if all of the applications are web applications that use servlets, and JSP. This option works less effectively if the applications use servlets, JSPs and EJB.
Avoid trouble: To ensure compatibility with other WebSphere products, the default setting for this option is deselected. Before selecting this option, verify that any other WebSphere products, that you are running in conjunction with this product, support this functionality.gotcha
(zos) Run in 64 bit JVM mode
The application server runs in 64-bit mode, which is the default setting. Running in 64-bit mode provides additional virtual storage for user applications. This field only displays for the z/OS platform.
By default, the WebSphere Customization Toolbox is set up to start all of the application servers in 64-bit mode. However, we can change the settings for the WebSphere Customization Toolbox such that all of the application servers start in 31-bit mode. We can also unselect this setting for a subset of the application servers if you only want specific application servers to start in 31-bit mode.
There is no interdependence between the modes in which we are running different servers. Therefore, we can run some of the servers in 64-bit mode and some of the servers in 31-bit mode. However, you should eventually convert all of the servers to run in 64-bit mode because support for running servers in 31-bit mode is deprecated.
Access to internal server classes
Whether the server can run in Restrict or Allow mode.
The Restrict mode is a diagnostic mode that we can use to help determine the suitability of applications for migration. This mode determines whether internal application server classes are accessed. The use of these internal classes might preclude the successful operation of these applications in future releases. However, the Restrict mode is not intended to exclude all classes from general use even if the classes might change. Some classes that might change are unrestricted in order to enable correct operation of the application server. The Restrict mode is not intended to provide complete isolation between an application and application server internal classes. Do not use the Restrict mode in a production runtime environment; use the results for guidance only.
The default value for this property is Allow.
Class loader policy
Select whether there is a single class loader to load all applications or a different class loader for each application.
Class loading mode
Whether the class loader searches in the parent class loader or in the application class loader first to load a class. The standard for Developer Kit class loaders and the product class loaders is Parent first.
This field only applies if set the Class loader policy field to S*ingle.
If we select Application first, the application can override classes contained in the parent class loader, but this action can potentially result in ClassCastException or linkage errors if we have mixed use of overridden classes and non-overridden classes.
Process ID
The process ID for this server on the native operating system.
This property is read only. The system automatically generates the value.
Cell name
The name of the cell in which this server is running.
This property is read only.
Node name
The name of the node in which this server is running.
This property is read only.
State
The runtime start state for this server.
This property is read only.
Product information
This link under Additional properties, displays the product information for the installation of the product. This information includes the product name, ID, version, build date, and build level.
From the Product Information page, we can click on the following links for additional product information:
- Components, for a list of all of the components that are installed.
- e-Fixes, for a list of all of the service updates that are installed.
- Extensions, for a list of the extensions that are installed.
- History report, for a detailed report of all installation events that have occurred since the product was installed, such as the installation of a specific service level.
- Product report, for a detailed report of the versions of the product that are installed.
- PTFs, for a list of all of PTFs that are installed.
Subtopics
- Java SDK collection
Use this page to specify the default SDK for a node. This page lists the software development kits that are installed on the node. A node can have one default SDK. Servers on the node use the default SDK unless a server overrides the SDK selection and specifies a different SDK.
- Ports collection
Use this page to view and manage communication ports used by runtime components running within a process. Communication ports provide host and port specifications for a server.
- Custom property collection
Use this page to view and manage arbitrary name-value pairs of data, where the name is a property key and the value is a string value that can be used to set internal system configuration properties.
- (zos) Native processes
Use this page to view and modify properties of the JMS Integral Provider native processes.
- Server component collection
Use this page to view information about and manage the types of server components that a specific application server uses during application processing. The list of server components varies according to the type of applications a specific application server processes.
- (iseries)(dist) Thread pool collection
Use this page to view and manage the thread pools that an application server uses. A thread pool enables components of the server to reuse threads, which eliminates the need to create new threads at run time. Creating new threads expends time and resources.
- (zos) Server instance settings
Use this page to view and manage servant instance settings. These settings control the number of servant processes allowed.
Related concepts
(zos) Switching between 64 and 31 bit modes
Class loaders
Related tasks
Administer application servers (zos) Converting a 7-character server short name to 8 characters
Use High Performance Extensible Logging to troubleshoot applications
Object names: What the name string cannot contain Administration service settings Enterprise application collection
Enterprise application settings
Debugging Service details EJB container settings Message listener port collection Performance Monitoring Infrastructure settings Transaction service settings Web container settings Administrative console buttons Startup behavior settings Default Java Persistence API settings