Planning your configuration

Why and when to perform this task

Before installing the product, planning your installation is necessary. Planning your WebSphere Application Server for z/OS product configuration requires you to visualize your end goal. After the end goal is firmly in place, various assumptions and other decisions are factored in.

The following four main objectives are suggested, although not required. Carefully consider these recommendations.

  1. Do not use default configuration values.

    This is to avoid interfering with any other WebSphere Application Server environment that may have made use of default values. It also helps avoid the problem of someone later building a configuration with default values that interfering with WebSphere Application Server for z/OS.

  2. Design a naming convention that is meaningful and flexible.

    The goal to support easy horizontal and vertical scaling is really a statement about the designed naming convention. A poor naming convention might hinder the expansion of the configuration.

  3. Ensure that the configuration design easily supports scaling.

    It is important to consider the "horizontal scaling" of the Application Server cell. Try to avoid, by planning ahead, the necessity to change things like the naming convention just because the cell was expanded.

  4. Ensure that the configuration design easily supports the creation of additional servers on any of the systems.

    Consider this "vertical scaling" of the WebSphere Application Server for z/OS configuration within a given MVS system. Again, the objective is to design the configuration so that adding more servers will not require excessive additional work.

In addition to the basic objectives outlined above, WebSphere Application Server for z/OS Version 5 allows for four other design objectives that are also recommended, but not necessary:

Steps for this task

  1. Minimize the number of JCL start procedures
    One of the features of WebSphere Application Server for z/OS Version 5 is the ability to use a "generic" set of JCL procedures to start multiple servers. The alternative is to use separate JCL procedures for each server.

    Using the same JCL for multiple servers only works if all the servers are under the same HFS mount point. The JCL contains a SET ROOT= line that names the configuration HFS mount point. The value of &ROOT is combined with the passed-in value of &ENV to create the pointer to the was.env file. If two serves are under different HFS mount points, they would then require separate JCL as the SET ROOT= is hard-coded in the JCL.

    The recommended way to address this is to use a mount point that is shared across all MVS images. This is the cleanest and easiest solution.

  2. Minimize the number of RACF userids and groups.

    Any security configurations and/or changes should always be cleared through your security administrator.

    With WebSphere Application Server for z/OS Version 5, you can either minimize the userids/groups or establish separate identities for each server.
  3. Utilize Sysplex Distributor
    For clients outside the cell, it doesn't matter which location service daemon is accessed or which node agent is used. Therefore, you can use the Sysplex Distributor to balance inbound traffic across both location service daemons with the same port values as well as node agents that share ports.
  4. Set up two standalone WebSphere Application Servers on the same MVS image if you do not want to set up a Network Deployment environment.

    If, instead of using a Network Deployment environment, you need to set up two standalone WebSphere Application Servers on the same MVS image, you must set up a separate WAS_HOME directory for each standalone WebSphere Application Server. Use one of the following procedures to set up separate WAS_HOME directories:

    • Create a separate HFS mount points for each standalone WebSphere Application Server. For example, you might create the following HFS mount points if you have two standalone WebSphere Application Servers:
      /WAS510/Cell1/Node1/Appserver
      /WAS510/Cell2/Node1/Appserver
    • Use the same HFS mount point for both application servers, but set up separate WAS_HOME directories off of that HFS mount point. For example, you might set up the following directories off of the HFS mount point /WAS510/Cell/Node/:
      /WAS510/Cell/Node/Appserver1 
      /WAS510/Cell/Node/Appserver2

    Both of these techniques allow the configuration structure for each of the standalone WebSphere Application Servers to be correctly built and maintained.


Related concepts
Warning: no string named [crun_appservname] found.
HFS considerations
Connection optimization
Testing and production phases



Searchable topic ID:   tinsplanconfigz
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_planconfigz.html

Library | Support | Terms of Use | Feedback