A fix is available
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
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