PK74295: THE XA RECOVERY ALARM IS DELAYED CAUSING THE CONTROL REGION TO DELAY IN INITIALIZATION

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• The XA recovery alarm was not set properly, causing the server
  to delay starting until the next alarm expired successfully.
  

Local fix

• User can issue "F <server>,DIAGDATA=SNOO" on the console
  and any expired XA snoozers are forced to pop, so that the
  snoozer queue can be traced.  This should allow the server to
  complete initialization.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of WebSphere Application Server    *
  *                 V7.0 for z/OS                                *
  *                                                              *
  ****************************************************************
  * PROBLEM DESCRIPTION: Delay in scheduling expired alarms      *
  *                      (SnoozeAlarm services, bbootmsa.cpp)    *
  *                      results in significant server startup   *
  *                      delay.                                  *
  *                                                              *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  The TimerDaemonThread (bbootmot.cpp) schedules expired
  alarms. After processing expired alarms it searches the list of
  registered alarms for the shortest duration alarm in order
  to set a stimer to wake up later to check for expired alarms.
  The method to return the shortest remaining timer is
  getShortestInterval (bbootmq.cpp).  This method will skip
  registered alarms that have already expired and return the
  shortest alarm duration of the set of registered alarms yet
  to expire.
  In the timing window between checking for expired alarms and
  invoking the method getShortestInterval, alarms may expire.
  If a remaining registered alarm has a long duration, the
  TimerDaemonThread will wait for the long duration before
  scheduling the expired alarms.  This resulted in a significant
  delay when starting an application server (close to an hour).
  

Problem conclusion

• Code was modified in the timer method getShortestInterval to
  return an indication that it encountered an expired registered
  alarm while searching for the shortest duration alarm.  This
  indication of an expired alarm will cause the TimerDaemonThread
  to re-examine the set of registered alarms and schedule any
  expired alarms.
  
  APAR PK74295 is currently targeted for inclusion in Service
  Level (Fix Pack) 7.0.0.3 of WebSphere Application Server V7.0
  for z/OS.
  
  Please refer to URL:
  //www.ibm.com/support/docview.wss?rs=404&uid=swg27006970
  for Fix Pack availability.
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

  PK74291

• APAR is sysrouted TO one or more of the following:

Modules/Macros

• BBGUBINF BBOUBINF
  

Fix information

• Fixed component name

  WEBSPHERE FOR Z

• Fixed component ID

  5655I3500

Applicable component levels

• R700 PSY UK45120

     UP09/04/06 P F904

Fix is available

• Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.