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 information
APAR number PQ52656
Reported component name WASKBASE
Reported component ID 5655A9801
Reported release 400
Status CLOSED FIN
PE NoPE
HIPER NoHIPER
Submitted date 2001-09-25
Closed date 2001-09-28
Last modified date 2002-07-24

APAR is sysrouted FROM one or more of the following:

APAR is sysrouted TO one or more of the following:

Modules/Macros

Fix information

Applicable component levels
R400 PSN    UP


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