IBM Support

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

Subscribe

You can track all active APARs for this component.

 

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 number

    PH07835

  • Reported component name

    WEBSPHERE FOR Z

  • Reported component ID

    5655I3500

  • Reported release

    900

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2019-01-28

  • Closed date

    2019-05-31

  • Last modified date

    2019-05-31

  • 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

[{"Business Unit":{"code":"BU053","label":"Cloud \u0026 Data Platform"},"Product":{"code":"SS7K4U","label":"WebSphere Application Server for z\/OS"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"900","Line of Business":{"code":"LOB36","label":"IBM Automation"}}]

Document Information

Modified date:
17 October 2021