+

Search Tips   |   Advanced Search

Create application servers

During the installation process, the product creates a default application server, named server1. We use the wsadmin or the administrative console (Create a new application server wizard) to create additional application servers.

We can also create appservers (members) by creating a cluster using the new cluster wizard.

To create a new application server that is not part of a cluster, we can either use the createApplicationServer, createWebServer, or createGenericServer wsadmin command, or we can use the administrative console.


Create a new application server that is not part of a cluster

  1. In the administrative console, click...

      Servers > Server Types > WebSphere application servers > New

    The Create a new application server wizard starts.

  2. Select a node

  3. Enter a name for the appserver.

  4. Click Next.

  5. Select a server template for the new server.

    Use can use the default template or a template optimized for development uses.

  6. Click Next.

    Select Generate unique HTTP Ports.

    Default is enabled. If we select this option, then we might need to update the alias list for the virtual host that we plan to use with this server to contain these new port values. If we deselect this option, then ensure that the default port values do not conflict with other servers on the same physical machine.

  7. ZOS

      Click Next and specify a short name for the server.

      The short name is also used as the JOBNAME for the server. 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 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 we create this server

      (ZOS) Specify a generic short name for the server. The generic short name for the server becomes the cluster transition name. 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 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 we create this server. Set up a RACF SERVER class profile that includes this generic short name.

  8. Click Next. Review the settings for the new server.

  9. To change any of the settings, click Previous until you return to a page where we can change that setting.

  10. Click Finish when we do not want to make any additional changes.

  11. Click Review, select Synchronize changes with nodes> Save to save the changes.

  12. (ZOS) Run the updateZOSStartArgs script to enable an application server to use the z/OS reusable ASID function, if it is not already enabled for the node associated with this application server. This function enables an application server to reuse all ASIDs, including those that are associated with cross-process services.

    Before running this script, verify that we are running on z/OS Version 1.9 or higher, and that the reuse ASID function is enabled during the z/OS startup process. If the function is not enabled on z/OS, running this script has no affect on how ASIDs are handled.

The new application server is in the list of servers on the administrative console Application servers page.


What to do next

This newly created application server is configured with default settings that are not displayed when running the Create New Application Server wizard.

We can:


z/OS

(ZOS) To create a new application server that is not part of a cluster, we can either use the Profile Management tool, the createApplicationServer, createWebServer, or createGenericServer wsadmin command, or we can use the administrative console.

If we are migrating from a previous version of the product, we can upgrade a portion of the nodes in a cell, while leaving others at the previous product level. This means that, for a period of time, we might be managing servers running at two different release levels in the same cell. However, when we create a new server definition, we must use a server configuration template, and that template must be created from a server instance that matches the version of the node for which we are creating the server. There are no restrictions on what we can do with the servers running on the more current release level.

If we are using 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:

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.

If we use additional servers with unique ports, WebSphere Application Server does not automatically configure the virtual host for the server. Specifically, WAS does not automatically add the host alias ports to a virtual host. However, we can use the administrative console to add a new host alias for each of the ports used by the new server. See documentation about configuring virtual hosts.


Subtopics