Setting up a base Application Server cell

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.

Single machine, single node environment

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

  1. If you plan to eventually have a Network Deployment environment, set up an overall naming scheme.
    Plan the scheme with the knowledge that the new cell structure will match that of the deployment manager. The following high level steps apply if your desired result is a deployment manager:
    1. Configure and create a base Application Server node.
    2. Configure and create a deployment manager node.
    3. Federate the base Application Server node into deployment manager cell.
    4. Repeat as needed.
    The steps above in conjunction with the planning knowledge in the bullets below provide adequate information for you to design your naming scheme.
    • Federating a base Application Server node into a deployment manager cell means the base Application Server node will become part of the deployment manager's cell. Consequently, after you federate your base Application Servers into a Network Deployment cell, the cell name associated with the original deployment manager -- not those of any of the original base Application Servers -- will become the new Network Deployment cell name for the newly federated node.

      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:

      • SAF profile names (for example, SERVER, CBIND, or EJBROLE).
      • Any "ENV=" parameter that start z/OS Application Servers (recall that the form is ENV=<cell short name>.<node short name>.<server short name>). If you use z/OS WLM static application environment definitions, you may need to use the WLM administrative application (IWMARIN0) to update the parameter string for the servant process JCL procedure.
      • The RM name used to register the base Application Server with RRS. If you ran transactions on the base Application Server prior to federation, you may find RRS log records left behind that belonged to the base Application Server when it was in its own cell. You may choose to delete these records.

    • The z/OS location service that is part of the deployment manager's cell will become the effective location service for the newly federated node.
  2. Follow the steps in Using the Customization Dialog to configure your base Application Server.
    From there, you will see that a command similar to the following starts the ISPF Customization Dialog:

    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.
    1. Select the option in the Customization Dialog to configure the base Application Server and follow the panels.

    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.

  3. Enable the appropriate level of security after the installation is complete.
    See Securing your environment after installation for more information.
  4. Develop and unit test application components.

    Load existing application components and modules into your development environment and debug them. See Developing for more information.

  5. Assemble code into a main application module or enterprise archive (EAR) file.
    See Assembling or packaging for more information.
  6. Start all servers in the test environment.
    See Starting servers for more information.
  7. Deploy your applications in the test environment.
    See Deploying for more information.
  8. Test all applications thoroughly.

    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.

  9. Prepare and monitor the environment into which you deploy applications.
    See Administering for more information.
  10. Adjust application code, configurations, and system settings to improve performance.
    See Tuning for more information.
  11. Fix any known problems.
    See Troubleshooting or problem determination for more information.
  12. Once you finish running through the Customization Dialog options and have run all the generated jobs, validate the success of your base Application Server configuration by bringing up the Administrative Console.

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.

Related concepts
Simplifying your installation
Related tasks
Planning to install and customize WebSphere Application Server for z/OS
Preparing the base z/OS environment
Setting up a Network Deployment environment
Migrating and coexisting



Searchable topic ID:   tinszosbase
Last updated: Jun 21, 2007 9:56:50 PM CDT    WebSphere Application Server for z/OS, Version 5.0.2
http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp?topic=/com.ibm.websphere.zseries.doc/info/zseries/ae/tins_zosbase.html

Library | Support | Terms of Use | Feedback