This article identifies the names you must define during WebSphere® Application
Server for z/OS® configuration
and provides a recommended naming convention.
Each WebSphere Application
Server for z/OS cell,
node, server, and cluster must have both a long name and a short name.
- Long names are the principal names by which cells, nodes, servers and
clusters are known to WebSphere Application Server for z/OS. These are
the names used in scripting and the administrative console. Long names can
be up to 50 characters long and include mixed case alphabetic characters,
numeric characters, and the following special characters: ! ^ ( ) _ - . {
} [ ]
- Short names are specific to the z/OS implementation of WebSphere Application
Server and are the principal names by which cells, nodes, servers and clusters
are known to z/OS.
(Note that z/OS has
an eight-character limit on many operating system interface values.) Short
names must be one to eight characters long, use only uppercase alphabetic,
numeric and national characters, and cannot begin with a numeric character.
While it is possible to assign names to WebSphere Application Server for z/OS objects
on an ad-hoc basis, it is safer and more efficient to assign names in an orderly
fashion.
Note: The WebSphere Application Server for z/OS customization
process provides default values for all these names. We recommend that you
use these default names only when building a "practice" application server
configuration.
The recommended naming convention given here is based
on the one given in the
WebSphere z/OS V6 -- WSC Sample ND Configuration white
paper.
Assumptions
A stand-alone application server is
very simple. It has a basic cell and node structure with a single application
server on a single z/OS system. (Actually, it is possible to add additional
application servers to a stand-alone node, but you cannot manage them from
the administrative console. This makes such a configuration unwieldy.)
A
Network Deployment cell includes a deployment manager (a node of its own),
together with any number of application server nodes. Each application server
node contains a node agent and any number of application servers. The deployment
manager can reside on the same z/OS system as one of the application server
nodes or on a z/OS system
of its own.
- The recommended naming convention assumes that there is only one node
per cell on a given z/OS system. This is not really a functional limitation
because having multiple nodes from the same cell on the same z/OS system does
not provide any better administrative separation, and only provides slightly
more reliability, than having a single node, while incurring additional overhead.
- The recommended naming convention allows you to cluster any application
server. Creation of a cluster begins with either an existing application
server that is then cloned or a newly-defined application server that is then
cloned. The cloning process adds new, identical application servers on other
application server nodes in the cell. To use the recommended naming convention,
follow these steps:
- Select a two-character cell identifier cc for the WebSphere Application
Server for z/OS cell
you plan to create.
- Select a one-character system identifier x for each z/OS system
that will support some part of the cell.
- Select a two-digit server identifer nn for each application
server you create. Use a different value of nn for each
application server in the cell. (This will allow clustering of any application
server later on.) Use "01" for a stand-alone application server.
Cell long name and short name
Each WebSphere Application
Server for z/OS cell,
whether a stand-alone application server or a Network Deployment cell, must
have a long name and a short name. The cell long name is arbitrary, but the
cell short name must be unique in each configuration HFS.
Recommendations:
- Set the cell short name to "ccCELL" in uppercase ("AZCELL"
for example).
- Set the cell long name to be the same as the cell short name but lowercase
("azcell" for example).
- A cell name must be unique whenever the product is running on the same physical machine or cluster of machines, such as a sysplex. Additionally, a cell name must be unique when network connectivity between entities is required either between the cells or from a client that must communicate with each of the cells. Cell names also must be unique if you want to federate their name spaces. Otherwise, you might encounter errors such as a javax.naming.NameNotFoundException exception. In which case, you need to create uniquely named cells.
Node long name and short name
Each WebSphere Application
Server for z/OS node
must have a long name and a short name. A stand-alone application server has
just one node, though it keeps its node name if it is federated into a Network
Deployment cell. A Network Deployment cell has a deployment manager node and
a number of application server nodes.
Note: As noted above, we assume that
a cell has only one application server node on each z/OS system.
The node long
name and short name must be unique within the cell. The node short name of
a stand-alone application server intended for federation into a Network Deployment
cell should also be unique within the Network Deployment cell.
Recommendations:
For
a deployment manager node:
- Set the node short name to "ccDMGR" in uppercase ("AZDMGR"
for example).
- Set the node long name to be the same as the node short name but lowercase
("azdmgr" for example).
For an application server node:
- Set the node short name to "ccNODEx",
where x is the system identifier ("AZNODEA" for example).
- Set the node long name to be the same as the node short name but lowercase
("aznodea" for example).
Server long name and short name
Each WebSphere Application
Server for z/OS server
must have a long name and a short name.
The server long name and short
name must each be unique within the node and should not exist in any other
node to which you might clone this server to form a cluster. In the Customization
Dialog, server short names are limited to seven characters.
Recommendations:
For
a deployment manager server:
- Set the server short name to "ccDMGR" in uppercase
("AZDMGR" for example).
- The server long name is "dmgr" (unchangeable).
For a node agent:
- Set the server short name to "ccAGNTx"
("AZAGNTA" for example).
- The server long name is "nodeagent" (unchangeable).
For an application server node:
- Set the server short name to "ccSRnnx",
where nn is the server identifier and x is
the system identifier ("AZSR01A" for example).
- Set the node long name to be the same as the node short name but lowercase
("azsr01a" for example).
Jobnames
Each server controller, servant and control
region adjunct (CRA) has an MVS jobname, set by the Customization Dialog:
- The controller jobname is the same as the server short name ("AZSR01A"
for example).
- The servant jobname is the server short name with an "S" appended ("AZSR01AS"
for example).
- The control region adjunct jobname is the server short name with an "A"
appended ("AZSR01AA" for example).
These values cannot be changed in the Customization Dialog. This is also
why the dialog limits server short names to seven characters--to allow room
for the final character that differentiates a servant or CRA from the controller.
It
is possible to change any server jobname using the administrative console.
Because of this, for example, it is possible to change server short names
to be eight characters long. However, this would require you to make corresponding
changes to RACF® profiles
and so on.
The location service daemon
The location service
daemon is a special server with no servant or CRA. Each cell must have one
location service daemon running on each z/OS system on which the cell is configured.
If a server is started and finds that its location service daemon is not
running, it starts the location service daemon before continuing its processing.
A
location service daemon has a jobname, which is also used as its server short
name.
Note: A location service daemon has no server long name.
All location
service daemons in a cell use the same jobname.
A stand-alone application
server, like any cell, has a location service daemon of its own. However,
when the stand-alone application server is federated into a Network Deployment
cell, the newly-created application server node in the Network Deployment
cell uses its own location service daemon--one with the same jobname and TCP/IP
ports as the deployment manager's location service daemon--and the location
service daemon originally used by the stand-alone application server is abandoned.
Recommendations:
- For a Network Deployment cell, set the location service daemon jobname
to "ccDEMN" ("AZDEMN" for example).
- For a stand-alone application server, set the location service daemon
jobname to "ccDEMNmm", where mm is
chosen to make the location service daemon jobname unique on the z/OS system.
Cluster transition name
Each controller that has
servants uses Workload Management (WLM) to start the servants. To do this,
it needs a WLM application environment name.
- For an unclustered application server (or deployment manager), the cluster
transition name is used as the WLM application environment name.
- When a cluster is created, it is assigned a cluster short name. If the
cluster is based on an existing initial server, then the cluster short name
is set to the server's cluster transition name. If the cluster is based on
a new initial server, then the cluster short name is set to BBOC00n,
where n is a number incremented as needed to maintain uniqueness
in the cell. The cluster short name is used as the WLM application environment
name for all servers in the cluster.
Therefore, the cluster transition name is used as the WLM application
environment name for a stand-alone application server, for the same server
after it is federated (or created from scratch, unclustered) in a Network
Deployment cell, or for an entire server cluster based on the original server.
When
you assign a cluster transition name to a server, it must be unique in the
cell.
Recommendations:
- For a deployment manager, set the cluster transition name to "ccDMGR".
This is the same as the server short name.
- For an application server, set the cluster transition name to "ccSRnn"
("AZSR01" for example). This is the same as the server short name without
the system identifier.
Note: This also illustrates why a different two-digit
server identifier is used for each server. Suppose you had two servers AZSR01A
and AZSR01B. If you create a cluster based on AZSR01A and want to extend it
to the B system, the obvious server name choice is AZSR01B - which is already
taken. But if the servers are named AZSR01A and AZSR02B, then you can cluster
either and extend the cluster to the other system without conflict. The respective
cluster short names would be AZSR01 and AZSR02.