|
Problem(Abstract) |
Service level coexistence for nodes within cell for
V5.0.x |
|
|
|
Cause |
n/a |
|
|
Resolving the
problem |
"Daemon Coexistence Support Statement"
This statement is intended to address running nodes within a cell at
different service levels.
Software coexistence strategy is split into two categories:
Maintenance andVersion. The first two
numbers of the release denote the version of WebSphere® Application Server
for instance software levels starting with 5.0 are at a different version
of WebSphere Application Server than software levels starting with 5.1.
The third and subsequent numbers of the release denote the maintenance
level within the version, for instance software levels starting with 5.0.1
and 5.0.2 are software at different maintenance levels within the same
version of WebSphere Application Server.
Note: Please refer to the following techdoc for suggestions for setting up
your configuration to plan for rolling out maintenance (service levels):
http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP100396
Maintenance Coexistence
A multi-node configuration of differing maintenance levels within the same
version deployed on the same LPAR in the same cell is formally
supported by WebSphere Application Server for z/OS® v5.0 and higher. The
following must be true:
- The Daemon configured for the cell is at a maintenance
level that is the highest or equal to the highest maintenance in the cell
for that LPAR. This means that the Daemon and the common routines that it
directly loads are compatible with other WebSphere Application Server
processes (DM, Node Agents, JMSServers and Application Servers) when those
servers are within the same version.
- Each node configured in the LPAR is within the scope of
the minimum to maximum supported maintenance levels for the Daemon. If not
documented, within the latest PTF applied to the Daemon, then the
assumption is that all levels of the release are supported. <At the
time of this writing, the V5.0 Daemon is compatible with any other
maintenance level of WebSphere Application Server V5.0.>
- Each node configured in the LPAR has its own WebSphere
Application Server runtime HFS. This is achieved by specifying unique
'WebSphere SMP/E home directory' during the Base Application Server Node
customization process. The node's runtime HFS must not be shared with any
other node in the Sysplex if runtime upgrades to this node are to be fully
indepedent of any other node.
- Native library isolation is achieved by exploiting STEPLIB
in node-level PROCs. A recommended approach is to have one level of
maintenance loaded in LPA, and STEPLIB those processes that are configured
that are to run at levels different that of the LPA libraries. An example
is that the highest level maintenance be loaded into LPA, and down-level
nodes use STEPLIBs to achieve isolation.
Version Coexistence
A multi-node configuration of differing versions of WebSphere Application
Server deployed on the same LPAR in the same cell is
not formally supported by WebSphere Application Server for
z/OS. The strategy for version coexistence within the same cell is
supported, but requires nodes to be configured on multiple LPARs. Version
coexistence can be achieved on the same LPAR, but requires nodes to be
configured in differing cells, allowing the different version levels to be
serviced by Daemons at the appropriate and compatible level of software.
<We recommend that if a customer would like WebSphere Application
Server to support version coexistence across nodes in the same cell on the
same LPAR, that a formal requirement be submitted as this represents a
departure from our current coexistence strategy and design.> |
|
|
|
|
|
|