IBM Support

PM24292: SEAMLESS NFM MIGRATION FOR SYSPLEXWLB ENABLED CLIENT SYSTEMS

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • DB2DDF DDFL09
    Seamless NFM migration for SysplexWLB enabled client systems.
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All Distributed Data Facility (DDF) users    *
    *                 in a data sharing group environment during   *
    *                 migration processing. Specifically those     *
    *                 with remote applications, running in         *
    *                 Sysplex workload balancing environments,     *
    *                 that connect to the DB2 for z/OS server      *
    *                 data sharing group.                          *
    ****************************************************************
    * PROBLEM DESCRIPTION: During the process of forward/backward  *
    *                      migration of a DB2 for z/OS data        *
    *                      sharing group to/from various modes,    *
    *                      a DB2 server may report mixed levels    *
    *                      of product identification information   *
    *                      and DRDA support from different         *
    *                      members in the same data sharing        *
    *                      group. This behavior of reporting       *
    *                      mixed levels from the same group may    *
    *                      cause remote applications, running in   *
    *                      Sysplex workload balancing              *
    *                      environments, to encounter errors       *
    *                      (such as Error code=-4212 or -4499      *
    *                      from JDBC application environments).    *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    There are several mode transitions during the process
    of migrating a DB2 for z/OS data sharing group to a new
    version. After the transition to New Function Mode (NFM) is
    completed, some members can remain active through the
    migration process while some of the members in the same data
    sharing group can be restarted. Members that remain active
    through the migration process continue to report the same
    (Conversion Mode (CM)) product identification and DRDA level
    information. Other members that are restarted, after the NFM
    migration process is completed, start to report new information
    reflecting the NFM capabilities of the member.
    For example, consider the case of migrating a DB2 for z/OS V8
    data sharing group to DB2 9 for z/OS where there are two
    members in the group, say MemA and MemB. While the DB2 V8 data
    sharing group is first being migrated to DB2 V9, this DB2 group
    is considered to be in DB2 9 for z/OS CM. During the process of
    migrating the group from DB2 V9 CM to DB2 V9 NFM, one of the
    members, say MemA, remains active and lives through the
    migration process to DB2 V9 NFM. MemA continues to report CM
    related information reflecting V9 coexistence environment,
    including product level, and can only negotiate and support
    DRDA functions related to DB2 for z/OS V9 CM. MemB is restarted
    but now reports information reflecting the V9 NFM capabilities
    of the member, including product level, and can now negotiate
    and support DRDA functions available in DB2 V9 NFM. Both
    members are now reporting mixed levels of information to remote
    Sysplex workload balancing client systems.
    The same situation of reporting mixed levels of product
    information and DRDA support also exists in the backward
    migration process. That is, after the DB2 group is migrated to
    NFM, the user can revert the DB2 group back to Enabling New
    Function Mode* (ENFM*) or Conversion Mode* (CM*). After the
    transition back to ENFM* or CM* is completed, some of the
    members can remain active through the backward migration
    process while some of the members in the same data sharing
    group can be restarted. Members that live through the backward
    migration process continue to report product level information
    and support DRDA functions that the members were started with.
    Members that are restarted, after the backward migration is
    completed, report product level and DRDA support reflecting the
    current DB2 level that the members are restarted with.
    For example, consider the case of reverting the same DB2 group
    as above from V9 NFM back to V9 CM*. During the process of
    reverting the group from DB2 V9 NFM to DB2 V9 CM*, one of the
    members, MemA, was started in V9 NFM and lives through the
    backward migration process to DB2 V9 CM*. MemA continues to
    report information reflecting V9 NFM, including product level,
    and can support DRDA functions available in DB2 V9 NFM. MemB is
    restarted but now reports information reflecting DB2 V9 CM*
    capabilities, including product level, and now negotiates and
    supports DRDA functions only available in DB2 V9 CM*. Both
    members are now reporting mixed levels of information to remote
    Sysplex workload  balancing client systems.
    Reporting mixed levels causes problems for remote applications
    in a Sysplex workload balancing environment because consistent
    product level information and consistent support of DRDA
    functions are expected by the remote environment across all
    members in the same data sharing group. When mixed levels are
    encountered, an error is explicitly issued by IBM Data Server
    client Drivers.
    

Problem conclusion

  • DB2 for z/OS server processing has been changed to return
    consistent product level and DRDA functional information across
    all members of the same data sharing group, specifically for
    the benefit of remote application environments that utilize
    Sysplex workload balancing functionality. This occurs
    regardless if the member has been restarted or not during the
    migration process. This change applies to both forward and
    backward migration to ensure that all members in the same
    data sharing group present consistent and predictable behavior.
    -
    To allow for a smooth, seamless, migration of a DB2 for z/OS
    data sharing group, with respect to remote Sysplex workload
    balancing client systems, users are advised to first apply
    this change to all members of their DB2 for z/OS data sharing
    group, specifically as it relates to the target version that
    is being migrated to.
    . Source DB2 for z/OS V8 migration to target V9.
      The V9 target code base for all members should include
      this change.
    . Source DB2 for z/OS V8 or V9 migration to target V10.
      The V10 target code base for all members should include
      this change.
    Also, in order for remote Sysplex workload balancing clients
    to support a seamless migration of DB2 for z/OS to NFM,
    companion IBM Data Server client Driver support is also
    required. The necessary IBM Data Server client Driver
    maintenance is planned to be included in V9.7 FixPak 3A, but
    users should reference Informational APAR II14619 for more
    current information on this maintenance. This informational
    APAR also contains additional information related to DB2 for
    z/OS data sharing group forward/backward migration with respect
    to remote Sysplex workload balancing client systems.
    

Temporary fix

Comments

APAR Information

  • APAR number

    PM24292

  • Reported component name

    DB2 OS/390 & Z/

  • Reported component ID

    5740XYR00

  • Reported release

    910

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2010-10-11

  • Closed date

    2011-02-28

  • Last modified date

    2011-05-02

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

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

    UK65312 UK65313

Modules/Macros

  • DSNDDPSB DSNLCDG2 DSNLCMSL DSNLTACC DSNLTEXC
    DSNLTMIN
    

Fix information

  • Fixed component name

    DB2 OS/390 & Z/

  • Fixed component ID

    5740XYR00

Applicable component levels

  • RA10 PSY UK65312

       UP11/04/05 P F104

  • R910 PSY UK65313

       UP11/04/05 P F104

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.

[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSEPEK","label":"Db2 for z\/OS"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"9.1","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"9.1","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
02 May 2011