|
Problem(Abstract) |
If maintenance applied to IBM® WebSphere® Application
Server Base prior to the node being federated into the Deployment Manager,
is later removed after the node has been federated, the setupCmdLine will
contain incorrect node and cell information. This can prevent application
server startup. |
|
|
|
Cause |
When maintenance is applied to WebSphere Application
Server, the installation process makes a backup undo.jar file. This
undo.jar file takes a snapshot of the system as it is currently
configured. This backup includes a backup of the setupCmdLine.bat/sh as it
exists at the time the maintenance was applied. If this node is later
federated into a Deployment Manager, the backup created at the time the
addnode command is executed will reflect that it is now part of the
network. The WAS_CELL information is updated to reflect this change as
well.
If, after the node has been federated, the previously applied maintenance
is removed without first removing the node from the network by executing
the "removenode" command, the uninstall process will restore the
configuration to the node based on its prefederated environment. The
setupCmdLine.bat/sh will be restored on the application server as it was
prior to federation. The WAS_NODE and WAS_CELL information will be
incorrect and the application server will not start. The application
server is still federated to the deployment manager and this is reflected
in its setupCmdLine.bat/sh. While the application server now thinks it is
stand alone as reflected by its restored setupCmdLine.bat/sh. The node
still exists but the setupCmdLine.bat/sh now reflects the cell name of the
unadded node.
This is not an problem with the service pack or the updateinstaller. The
update installer is working as designed. Uninstallation of service packs
should not and do not remove the node added by the client. |
|
|
Resolving the
problem |
When setting up a Network Deployment environment, the best
practice is to execute addnode while the node is still at the V5.0 or V5.1
level. Then once federated, the additional maintenance can be applied and
if necessary, later removed in reverse order without affecting the
WAS_NODE and WAS_CELL information in the setupCmdLine.bat/sh.
If your environment has been set up and addnode executed after the
maintenance had been applied, the work around would be to verify the
WAS_NODE and WAS_CELL information in the setupCmdLine.bat/sh reflects the
correct values for the added node. This would usually just mean correcting
the WAS_CELL information.
Additional information can be reviewed concerning this issue in technote:
Error
196 - Failed to prepare instance data.... Config.templates
failed. |
|
|
|
|
Cross Reference information |
Segment |
Product |
Component |
Platform |
Version |
Edition |
Application Servers |
Runtimes for Java Technology |
Java SDK |
|
|
|
|
|
|