PH07835: MIGRATING A CELL USING THE CLONE OPTION DOESN'T CREATE A DIFFERENT COREGROUPUID

9.0.5.0: WebSphere Application Server traditional Version 9.0.5 Refresh Pack
9.0.5.1: WebSphere Application Server traditional Version 9.0.5 Fix Pack 1
9.0.5.2: WebSphere Application Server traditional Version 9.0.5 Fix Pack 2
9.0.5.3: WebSphere Application Server traditional Version 9.0.5 Fix Pack 3

APAR status

• Closed as program error.

Error description

• After a cell is migrated using the clone option, it has the
  same coreGroupUID in the DefaultCoreGroup coregroup.xml as the
  original cell.
  
  If the two cells are running on the same LPAR at the same time
  with the same coreGroupUID for the DefaultCoreGroup, this can
  cause discovery and server monitoring issues.
  

Local fix

• Do not run both the original and migrated cell at the same time
  on the same LPAR.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED:  All users of IBM WebSphere Application      *
  *                  Server V9.0 Configuration Migration         *
  ****************************************************************
  * PROBLEM DESCRIPTION: After a clone migration, both old and   *
  *                      new servers belong to the same          *
  *                      coregroup.                              *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  This problem occurs because migration does not have logic to
  handle coregroups in a clone migration. In a standard
  migration, because of the potential of a mixed-cell
  environment, migration brings forward all the old coregroup
  configuration including names and coreGroupUIDs. For clone,
  the intent is to generate a new coreGroupUID for the coregroup
  so both cells can be up and running at the same time without
  interfering with each other.
  Additionally, on z/OS, XCF uses the coregroup name as an XCF
  name if it is 8 characters long or shorter, so on this
  platform only, coregroups with short enough names must be
  renamed so that the servers do not join the same XCF grouping.
  

Problem conclusion

• Migration was adjusted to generate new coreGroupUIDs and
  separate the coregroups in the new environment from the old
  environment.
  
  The fix for this APAR is currently targeted for inclusion in
  fix pack 9.0.5.0.  Please refer to the Recommended Updates
  page for delivery information:
  http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980
  

Temporary fix

Comments

APAR Information

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

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

Fix information

• Fixed component name

  WEBSPHERE FOR Z

• Fixed component ID

  5655I3500

Applicable component levels

• R900 PSY

     UP