PQ52656: WEBSPHERE FOR Z/OS DOESN'T USE IXCARM WAITPRED TO SEQUENCE THE STARTING OF WEBSPHERE ADDRESS SPACES | |||||||||||||||||||||||||||
![]() |
|||||||||||||||||||||||||||
APAR status Closed as fixed if next. Error description WebSphere for z/OS doesn't use IXCARM WAITPRED to sequence the starting of WebSphere address spaces. The problem is, when ARM does a restart, he doesn't simply start the daemon who starts the other WebSphere servers, then the application servers. He starts them in any order he wants. The code should be able to handle this, but it is not. The bottom line is, we need to do an ARM register earlier in the bring up life of a control region so if it does come up too early and fails, that ARM can start it again.Local fix Problem summary **************************************************************** * USERS AFFECTED: All users of WebSphere Application Server * * V4.0 for z/OS and OS/390. * **************************************************************** * PROBLEM DESCRIPTION: If the Websphere Application Server * * Daemon and the various Control Regions * * end and are started concurrently by * * ARM, it is possible that the Control * * Regions could start ahead of the Daemon * * and fail with a minor code of C9C21178 * * because the Daemon is required to be * * up for them to start. * **************************************************************** * RECOMMENDATION: * **************************************************************** This problem occurs because ARM does not see the restarted instance of a Control Region until it registers with ARM again. The code which checks for the Daemon's existance is before the registration with ARM, thus a sequencing problem as described above would result in the Control Region failing before it had registered with ARM. Since ARM didn't see the restarted instance, it won't see it fail and therefore won't try again to restart it. The solution to this is to move the ARM registration earlier in the Control Region startup processing.Problem conclusion Temporary fix Comments This APAR is being closed FIN with concurrence from the submitting customer. A solution to this problem will be delivered in a WebSphere Application Server for z/OS and OS/390 release within the next 18 months . A fix for the problem reported by this APAR has been provided in PTF UQ58507 of WebSphere Application Server V4.0.1 for z/OS and OS/390.
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 for z/OS
Operating system(s):
Software version: 400
Software edition:
Reference #: PQ52656
IBM Group: Software Group
Modified date: Jul 24, 2002
(C) Copyright IBM Corporation 2000, 2006. All Rights Reserved.