A typical WebSphere Application Server for z/OS base run-time includes a cell with a location service daemon and one node which, in turn, includes an Application Server with a controller and any number of servants. This article leads you through the background of a base Application Server cell as well as the tasks involved in setting up a WebSphere Application Server for z/OS base Application Server environment.
Before you begin
The installation and customization procedure is the same for a node to be federated into a cell as it is for a stand-alone Application Server.
Note: You can create multiple instances of the base WebSphere Application Server for z/OS function on a single machine using one of two methods:
If applicable, migrate applications, security settings, and the remaining configuration from WebSphere Application Server for z/OS Version 4.0.x and later. You can also choose to coexist with these older WebSphere Application Server for z/OS versions. See Migrating and coexisting for further information.
Why and when to perform this task
This section will reference the following graphic as representation of a typical WebSphere Application Server for z/OS base runtime. In it, the location service daemon is BBODMNB and the Application Server is server1.
The runtime servers use other z/OS functions, such as z/OS UNIX and TCP/IP. Part of installing WebSphere Application Server for z/OS includes configuring these functions for use by the runtime.
J2EE servers contain at least one Web container and one EJB container. The Web container manages Web applications (servlets and JavaServer Pages), while the EJB container manages enterprise beans.
The HTTP internal transport, which is part of the J2EE application server, is a functional component that acts as an HTTP protocol catcher for Web applications. In the graphic, the HTTP internal transport is depicted in server1.
The JMS server, which is also part of the J2EE scalable application server, hosts the JMS function of the WebSphere Application Server for z/OS. In the graphic, the JMS server is depicted in server1.
Follow the steps below to configure your WebSphere Application Server for z/OS base Application Server environment.
Steps for this task
This cell name assignment affects anything that has a cell-qualified name and was formerly used by Application Servers on that base application node, such as:
ex 'WAS500.WAS.SBBOCLIB(BBOWSTRT)'
When using the Customization Dialog, you may find it useful to refer to Simplifying your installation, especially when setting up your first, or practice, run-time.Note: The cell name for a base Application Server node should be considered temporary if the end goal of the configuration is a Network Deployment environment. When the base Application Server node is federated into a deployment manager cell, the base Application Server node's cell name is no longer used. The deployment manager's cell name is what continues to be used.
Load existing application components and modules into your development environment and debug them. See Developing for more information.
See Testing for more information.
Follow normal test procedures as you move the test environment into production. Review the information in the Migrating topic to understand what you must look for. In particular, review the table at the end of the topic that links you to specific recommendations and practices.
You must configure your migrating applications to verify that they migrate in the way that you want. See Migrating and coexisting for more information.
What to do next
Use the Administrative Console (see Using the administrative console for more information) or other administrative tools (see Welcome to System Administration for more information) to validate, observe and control your new environment. The console provides a central location for configuring, monitoring, and controlling your Application Server.