(ZOS) Application server naming conventions

Before we install a new WebSphere Application Server for z/OS environment, it is important to carefully plan your naming convention. Your naming convention should be able to grow with the system when we increase the number of cells, nodes, servers, and clusters. It should also be able to accommodate Sysplex and LPAR names, as well as instances such as test, integration, and production stages in the environment.

Application servers are like IMS™ or CICS regions.

• They contain tailored procedures for the controllers and servants.

• They contain tailored environmental variables for each instance of a server.

• They use WLM Classification of regions, working within the regions, and are defined as application environments.

• They may be self-contained or dependent on other servers.

• They need RACF definitions for Control and Server STC (user IDs, resource profiles), as well as UNIX permissions.

• Their users must be allowed to access the servers and to use various objects within them.

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:

• 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.

The product environment consists of a number of address spaces which require the installation to manage security profiles, workload classification constructs, and so on. To create, manage, and recognize application servers, it may be helpful to create a template for naming the servers and server instances. We can find an example template in the Sample configuration and naming conventions topic.

It is also important to plan the naming conventions for our data sets carefully.

• SMP/E target data sets, depending on your maintenance process (regular data sets and the HFS, including its mount points)
• Customization HFS, including its mount point
• HLQ for our customization data sets (*.CNTL, *.DATA, and *.SAVDCFG)
• Error logstream names
• DB2 collection and package names