Service level coexistence for nodes within cell for V5.0.x
 Technote (troubleshooting)
 
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.>
 
 
 


Document Information


Current web document: swg21169122.html
Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server for z/OS > Migration
Operating system(s): z/OS
Software version: 5.0
Software edition:
Reference #: 1169122
IBM Group: Software Group
Modified date: May 15, 2004