IBM Support

PM42237: ENABLING FUNCTION RELATED TO PM33761

A fix is available

Subscribe

You can track all active APARs for this component.

APAR status

  • Closed as program error.

Error description

  • Enabling function related to APAR PM33761.
    .
    FIXCAT KEYWORDS:
    DB2MIGV10/K  DB2COEXIST/K
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All Distributed Data Facility (DDF) users    *
    *                 using IBM Data Server Driver for JDBC and    *
    *                 SQLJ Type 4 Connectivity to access a DB2 for *
    *                 z/OS data sharing group.                     *
    ****************************************************************
    * PROBLEM DESCRIPTION: An application using IBM Data Server    *
    *                      Driver for JDBC and SQLJ Type 4         *
    *                      Connectivity calls a stored procedure   *
    *                      with OUT or INOUT parameters on a DB2   *
    *                      for z/OS data sharing group in V9/V10   *
    *                      or V8/V10 coexistence mode and receives *
    *                      incorrect data output results or        *
    *                      encounters various java.lang            *
    *                      exceptions, including:                  *
    *                      - ArrayIndexOutOfBoundsException        *
    *                      - NullPointerException                  *
    *                      - StringIndexOutOfBoundsException       *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    A remote IBM Data Server Driver for JDBC and SQLJ Type 4
    Connectivity environment is configured with both of the
    following properties:
    - enableSysplexWLB
    - useCachedCursor (this is the default setting)
    A remote application in this environment connects to a DB2 for
    z/OS data sharing group and calls a stored procedure multiple
    times using the same statement handle:
    - Because of the enableSysplexWLB property, the first call to
      the stored procedure may be processed by one member of the
      server DB2 for z/OS data sharing group while subsequent calls
      may be processed by other members.
    - Because of the useCachedCursor property, the description of
      the parameters returned for the first stored procedure call
      is cached with the statement object. All subsequent calls
      will use the cached descriptor for processing the stored
      procedure outputs from subsequent calls using the same
      statement handle.
    If one or more of the members processing the stored procedure
    calls is a V10 CM member and one or more of the other members
    are not, then the application may encounter incorrect data
    output results, as well as various java.lang exceptions, when
    calling the stored procedure the second or subsequent time.
    The exceptions occur if a subsequent call to the stored
    procedure returns descriptors for the outputs that are
    different from the cached descriptor, resulting in java driver
    parsing errors. This discrepancy can arise because DB2 10 for
    z/OS utilizes enhanced stored procedure processing for output
    parameters and returns descriptors that may be different from
    those returned in previous versions of DB2. The specific
    erroneous behavior resulting from these parsing errors is
    unpredictable and depends on the data returned.
    

Problem conclusion

  • DB2 has been changed to return the same descriptor for stored
    procedure parameters from every member of the data sharing
    group.
    The changes made by this APAR, PM42237, work in conjunction
    with the changes made by APAR PM40872 and the changes for the
    two APARs should be applied to a DB2 member according to
    recommendations given here.
    PM42237 corrects an incorrect output problem related to stored
    procedures that are invoked in DB2 10 for z/OS data sharing
    coexistence environments. The incorrect output condition only
    occurs relative to remote IBM Data Server Driver for JDBC and
    SQLJ Type 4 Connectivity application environments. To correct
    the incorrect output condition, APAR PM42237 should be applied
    according to the following recommendations depending on the
    various configurations that may apply:
    - Configuration 1:
      If the data sharing group has only V9/V8 NFM members
      (migration source members), then this is not a coexistence
      environment. The incorrect output problem described by this
      APAR will not occur if both APARs, PM40872 *and* PM42237,
      are applied to the V10 library of each V9/V8 NFM member
      before it is migrated to V10 CM.
      Even if one or more DB2 V10 CM members (migration target
      members) of the data sharing group should subsequently
      require fallback to V9/V8, there are no special fallback
      considerations for this configuration relative to APAR
      PM42237.
    - Configuration 2:
      If the data sharing group has both V9/V8 NFM members
      (migration source members) and V10 CM members (migration
      target members), then this configuration is considered to
      be a coexistence environment and may experience the incorrect
      output problem on connections from the IBM Data Server Driver
      to either the V9/V8 and V10 members of the group.
      To correct the incorrect output problem completely, the
      following procedure is recommended:
      . Stop each affected JVM (either stand-alone JVM or
        application server JVM) to prevent further incorrect output
        conditions.
      . Temporarily fallback all DB2 V10 members to DB2 V9/V8,
        leaving only DB2 V9/V8 members in the data sharing group.
      . Start each affected JVM (either stand-alone JVM or
        application server JVM). When each is restarted, it will
        connect to V9/V8 members only and will thus cache V9/V8
        descriptors only.
      . Apply PM40872 *and* PM42237 to the V10 library for each
        member of the data sharing group.
      . Migrate the members that are to be restarted as DB2 V10
        members. When each is restarted, APAR PM42237 will cause
        the DB2 V10 CM member to return V9/V8 descriptors, which
        will be consistent with the descriptors cached by the IBM
        Data Server Driver.
      If the above procedure is followed, then there are no
      additional fallback considerations for this configuration.
    - Configuration 3:
      If the data sharing group has only V10 CM members (migration
      target members), then this is not a coexistence environment.
      All DB2 members return V10 descriptors to the remote clients
      and this configuration will not experience the incorrect
      output problem described by this APAR as long as the IBM
      Data Server Drivers have only cached V10 descriptors.
      If it is known that the IBM Data Server Drivers have cached
      only V10 descriptors (for example, if each connected JVM was
      started after all DB2 members had already migrated to DB2
      V10 CM), then *only* APAR PM40872, *without* PM42237, should
      be applied to at least one DB2 V10 CM member and the
      member(s) should be restarted.
      Subsequently, PM40872 *and* PM42237, along with any other
      DB2 maintenance that has intersections with those APARs, can
      be applied to the members of the group as required without
      affecting the V10 descriptor behavior.
      If there are any concerns or uncertainty that any IBM Data
      Server Drivers may have cached V9/V8 descriptors, or if
      one or more members of the group must fallback to V9/V8 NFM,
      the following procedure is recommended:
      . Ensure that the DB2 Fallback SPE for DB2 V9/V8 is current
        *and* includes PM40872.
      . Stop each affected JVM (either stand-alone JVM or
        application server JVM) to prevent incorrect output
        conditions during and after fallback.
      . Temporarily fallback all DB2 V10 members to DB2 V9/V8,
        leaving only DB2 V9/V8 members in the data sharing group.
      . Start each affected JVM (either stand-alone JVM or
        application server JVM). When each is restarted, it will
        connect to V9/V8 members only and will thus cache V9/V8
        descriptors only.
      . Apply PM40872 *and* PM42237 to the V10 library for each
        member of the data sharing group.
      . Migrate the members that are to be restarted as DB2 V10
        members. When each is restarted, APAR PM42237 will cause
        the DB2 V10 CM member to return V9/V8 descriptors, which
        will be consistent with the descriptors cached by the IBM
        Data Server Driver.
    

Temporary fix

  • *********
    * HIPER *
    *********
    

Comments

APAR Information

  • APAR number

    PM42237

  • Reported component name

    DB2 OS/390 & Z/

  • Reported component ID

    5740XYR00

  • Reported release

    A10

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    YesHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2011-06-22

  • Closed date

    2011-07-20

  • Last modified date

    2011-09-01

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

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

    UK69950

Modules/Macros

  •    DSNLZD00 DSNRRGRI
    

Fix information

  • Fixed component name

    DB2 OS/390 & Z/

  • Fixed component ID

    5740XYR00

Applicable component levels

  • RA10 PSY UK69950

       UP11/08/04 P F108

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.



Document information

More support for: DB2 for z/OS

Software version: A10

Reference #: PM42237

Modified date: 01 September 2011


Translate this page: