In WebSphere® Application Server for z/OS®, cells and nodes are created using customization jobs that are built using the Profile Management Tool or the zpmt command. When you use the Profile Management Tool to create these customization jobs, most fields are preset to default values. Defaults are used that follow the standard naming convention if one- and two-character cell, cluster, and system identifier values are specified during customization.
The standard naming convention is suitable for both initial and production use, and it allows you to create groups of cells and servers with each group sharing a common set of user IDs and group names. A group of cells and servers is distinguished by sharing the same cell identifier.
This administrative group is not actually a part of the WebSphere Application Server architecture; it simply represents the fact that on z/OS, a group of cells can use a common set of SAF groups and user IDs, which in turn simplifies the setup of connections between these cells. On the other hand, using different SAF groups and user IDs for separate cells provides for administrative and runtime separation so that the cells using different SAF identities can interact only in ways that you specify or not at all.
To simplify interaction between two cells, create them using the same cell identifier. To minimize or prevent interaction between two cells, create them using different cell identifiers.
For a Network Deployment cell with one node per z/OS system, assign a single alphanumeric character to each z/OS system and use that value when configuring the federated or managed application server nodes on that system. For other types of cells, you can assign any desired convention for the system identifier as long as no two servers of the same type share both a cell identifier and a system identifier.
One Network Deployment cell and up to 36 of each of the other cell types can be configured with the standard naming convention under a single cell identifier by assigning a unique system identifier to each of the other cell types. In other words, two standalone application servers or two job managers that share a common cell identifier must have separate system identifiers.
Name | ND Cell Deployment Manager | ND Cell Managed Node | Standalone Application Server | Administrative Agent | Job Manager | Secure Proxy Server | Secure Proxy Administrative Agent |
---|---|---|---|---|---|---|---|
Cell name | aaCELL | aaCELL | aaBASEs | aaADMAs | aaJMGRs | aaPROXs | aaPRXAs |
Node name | aaDMNODE | aaNODEs | aaNODEs | aaADMAs | aaJMGRs | aaPROXs | aaPRXAs |
Note that the Network Deployment cell has one deployment manager node and can have one application server node (managed or federated) for each system identifier. The node name for a standalone application server uses the same convention as the Network Deployment cell, allowing for easy federation. The other server types use the same value as the cell name and node name because none of them require multiple nodes or an elaborate naming convention.
All of the names used so far are uppercase because they are z/OS short names, such as the cell short name and node short name, which must be uppercase. Each of these values also has a mixed-case long name, which is the internal WebSphere Application Server version of the name. For convenience, the standard naming convention uses the same value for the long name as for the short name but changes it to lowercase.
Server names are constructed from the cell identifier, system identifier, and (in the case of application servers) the cluster identifier. A Network Deployment cell can have only one deployment manager, and each of the other non-application server types has only a single server. Each server is also assigned a generic short name that is used to identify the server to Workload Management and is also used as the initial cluster name for application servers being clustered.
Name | ND Cell Deployment Manager | Application Server in an ND Cell or Standalone | Administrative Agent | Job Manager | Secure Proxy Server | Secure Proxy Administrative Agent |
---|---|---|---|---|---|---|
Server name | aaDMGR | aaSRnns | aaADMAs | aaJMGRs | aaPROXs | aaPRXAs |
Generic name | aaDMGR | aaSRnn | aaADMAs | aaJMGRs | aaPROXs | aaPRXAs |
This application server naming convention allows additional servers to be created in an application server node following the same naming convention, and it also makes clustering easier.
ccCFG | Configuration group Provides administration and server privileges |
ccSRVG | Servant group Provides privileges needed by servant regions |
ccGUESTG | Unauthenticated, local user, or guest group Provides basic privileges to access the cell but nothing more |
ccACRU | Controller user ID Controller, control region adjunct, and daemon started tasks |
ccASRU | Servant user ID Servant started tasks |
ccADMIN | Administrator user ID Used for cell configuration and, in certain circumstances, as a WAS administrator |
ccGUEST | Unauthenticated-user user ID (z/OS-managed security
only) Represents an unknown user for security purposes |
OMVS.MNT.cell_short_name/node_short_name.HFS
(for an HFS dataset)
OMVS.MNT.cell_short_name/node_short_name.ZFS
(for a zFS dataset)
You can modify these names to fit
local conventions, but make it clear which cell and node are associated
with each dataset. The default mount points for these configuration
file systems use the cell and node long names (simply lowercase versions
of the long names by default) for readability: /wasv8config/cell_long_name/node_long_name
The datasets can be renamed, but the mount points should not be changed after initial customization because they are referred to throughout the configuration files. One result of this is that when a standalone application server is federated into a Network Deployment cell, it retains its original configuration mount point even if that mount point contains the old (standalone) cell name. Users who know that a standalone application server is to be federated into a particular Network Deployment cell might want to manually update the configuration file system dataset name and mount point during creation of the standalone application server to reflect the node's eventual cell name.
Most application servers consist of a controller (control region) and one or more servants (servant regions). An application server also has a messaging region called a control region adjunct. The job name for the control region is the same as the server short name. The initial job name for the servant consists of the server short name followed by an S, while the initial job name for the control region adjunct consists of the server short name followed by an A. (This is why server short names are customarily limited to a length of seven characters.)
Each control region, servant region, and control region adjunct requires a cataloged procedure that points to the server's configuration file system. In practice, this means that each node has its own controller, servant, and (in some cases) control region adjunct cataloged procedures; but the different servers in an application server node do not need their own cataloged procedures because they share a configuration file system.
Name | ND Cell Deployment Manager | Application Server Node (Node Agent in ND Cell) | Application Nerver Node (Application Server) | Administrative Agent | Job Manager | Secure Proxy Server | Secure Proxy Administrative Agent |
---|---|---|---|---|---|---|---|
Controller job name | ccDMGR | ccAGNTs | ccSRnns | ccADMAs | ccJMGRs | ccPROXs | ccPRXAs |
Servant job name | ccDMGRs | ccAGNTsS | ccSRnnsS | ccADMAsS | ccJMGRsS | ccPRXAsS | |
Adjunct job name | ccSRnnsA | ||||||
Controller procedure | ccDCR | ccACRs | ccACRs | ccGCRs | ccJCRs | ccXCRs | ccYCRs |
Servant procedure | ccDSR | ccASRs | ccASRs | ccGSRs | ccJSRs | ccYSRs | |
Adjunct procedure | ccAARs |
Name | ND Cell (All Nodes) | Standalone Application Server | Administrative Agent | Job Manager | Secure Proxy Server | Secure Proxy Administrative Agent |
---|---|---|---|---|---|---|
Daemon job name | ccDEMN | ccDEMNs | ccDMNGs | ccDMNJs | ccDMNXs | ccDMNYs |
Daemon procedure | ccDEMN | ccDEMNs | ccDMNGs | ccDMNJs | ccDMNXs | ccDMNYs |