PQ60828: INCONSISTENCY WITH WLMBOOTSRVRS_TABLE CAUSING ADMIN SERVER NOT TO START PROPERLY. | |||||||||||||||||||||||||||||||||||||
![]() |
|||||||||||||||||||||||||||||||||||||
APAR status Closed as program error. Error description involving the WSBootSrvrs table of the repository: 1. This table contains nodes that are not part of and at no time were thought to be part of the domain in question. (phantom nodes) 2. This table shows inconsistency with both the actual state of specific nodes (running or stopped) and with the entries in the liveobject table.Local fix Thru support customer's have been able to correct the state of the table and have the adminservers startup properly. This correction included SQL command alterations of the table which is unacceptable as a way of recovery.Problem summary **************************************************************** * USERS AFFECTED: WebSphere Application Server users of * * Workload Management * **************************************************************** * PROBLEM DESCRIPTION: WLM code appears to hang while updating * * all running admin servers with new * * server group information. * **************************************************************** * RECOMMENDATION: * **************************************************************** WLM code appears to hang while updating all running admin servers with new server group information. One of the symptoms is that the Admin server is taking unusually long time to come up. Another symptom is one of the following event or warning messages may be observed in Admin console or Admin trace file: WWLM0014: Could not update Administrative Server information WLMBootstrapI E Comm failure pushing to admin server If security is enabled, there will also be a symptom of an initialization problem during Admin server startup time. If security is enabled, the security e-fix PQ61779 will also need to be applied. Both this e-fix and the security e-fix are being built in the next available PTF. Currently, PTF 3 is the current PTF.Problem conclusion The internal WLM code wasn't always in sync with the SM code as far as the state of the environment in regards to clones. What WLM did to fix this problem is the WLM code now gets clone information from SM verses an internal WLM table in the admin database. The internal WLM table is still there because WLM felt that as little code should be changed to fix the problem to reduce the risk of introducing an additional problem. Plus, having the table there is not going to do any harm to the overall system.Temporary fix Comments
APAR is sysrouted FROM one or more of the following: APAR is sysrouted TO one or more of the following: Modules/Macros
|
Document Information |
Product categories: Software > Application Servers >
Distributed Application & Web Servers > WebSphere Application
Server > General
Operating system(s):
Software version: 400
Software edition:
Reference #: PQ60828
IBM Group: Software Group
Modified date: May 31, 2002
(C) Copyright IBM Corporation 2000, 2006. All Rights Reserved.