PK64045: PREPARATION FOR ELIMINATION OF PRIVATE PROTOCOL IN DB2 10 FOR Z/OS

A fix is available

Subscribe

You can track all active APARs for this component.

APAR status

  • Closed as new function.

Error description

  • DB2DDF DDFL09 DB2PRVT
    Preparation for elimination of DDF Private Protocol in a future
    release.
    
    DB2MIGV10/K  DB2COEXIST/K
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All Distributed Data Facility (DDF) users.   *
    *                 Specifically those with plans or packages    *
    *                 bound with DBPROTOCOL(PRIVATE).              *
    ****************************************************************
    * PROBLEM DESCRIPTION: Private protocol capability will not    *
    *                      be available in DB2 10 for z/OS.        *
    *                      Thus, many customers are trying         *
    *                      to migrate their application plans      *
    *                      and packages to use DRDA protocol and   *
    *                      need assistance in knowing the steps    *
    *                      to convert to DRDA protocol.  Also,     *
    *                      certain application processing which    *
    *                      uses private protocol may not convert   *
    *                      correctly to DRDA protocol.             *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    DB2 10 for z/OS will no longer support private protocol
    distributed processing.  Many customers have application plans
    and packages which currently used private protocol and they
    need assistance in determining the actions that are needed to
    convert those plans and packages to DRDA protocol.  Also,
    since private protocol substitutes the object name defined by
    a three part name alias at the requester into any SQL statement
    sent to the remote location, some application access might not
    convert successfully to DRDA because DRDA protocol does not
    currently support such a substitution.
    

Problem conclusion

Temporary fix

Comments

  • In preparation for DB2 10 for z/OS where private protocol
    capabilities will no longer be available, and so that any use
    of private protocol processing can be converted to DRDA
    protocol, a new capability, DRDA alias resolution processing,
    is being provided.
    Alias resolution processing is the substitution of object names
    into an SQL statement at a DB2 requester before the SQL is sent
    to a remote server. This always occurs for private protocol
    connections but this same substitution behavior is required to
    aid in the conversion to DRDA protocol. A new subsystem
    parameter, DRDA_RESOLVE_ALIAS, via the DSN6SPRM macro, offers
    the ability to enable or disable this substitution behavior for
    DRDA connections.
    When DRDA alias resolution processing is enabled at a DB2 for
    z/OS DRDA requester, any DRDA server (accessed by the
    requester) will not require a two-part name alias to aid in
    resolving the object names in the SQL statement (at the
    server).
    If DRDA alias resolution processing is disabled at a DB2 z/OS
    DRDA requester, then the SQL statements sent to a DRDA server
    will contain references to the requester's alias name, which
    may require a two-part name alias (at the server) to aid in
    object name resolution at the DRDA server.
    If one does nothing to an existing subsystem parameters
    (DSNZPxxx) module after applying the fix to this APAR, DRDA
    alias resolution processing is disabled.  To enable DRDA
    alias resolution processing in a subsystem, one must first
    create a new DSNZPxxx module, or modify an existing DSNZPxxx
    module, where the DRDA_RESOLVE_ALIAS parameter of the DSN6SPRM
    macro is set to YES.  Once the DSNZPxxx module is created, the
    DB2 subsystem must be started with the created/modified
    DSNZPxxx module, or:
    - a -SET SYSPARM command must be issued with the LOAD keyword
      specifying the created/modified DSNZPxxx module, or
    - a -SET SYSPARM command must be issued with the RELOAD keyword
      if the updated module has the same name as the currently
      loaded module.
    If one wants to subsequently disable DRDA alias resolution
    processing on a running subsystem that previously had the
    capability enabled, then one can issue a -SET SYSPARM command,
    or restart DB2, specifying a DSNZPxxx module which does not
    have the DRDA_RESOLVE_ALIAS parameter set to YES.
    DRDA alias resolution processing occurs when any of the
    following conditions is processed at a DB2 for z/OS subsystem:
    - a dynamic SQL statement is received from an application,
      local to the subsystem, and the statement refers to one or
      more aliases which define three-part name objects which must
      all refer to the same remote location.
    - a dynamic SQL statement is received from a client connected
      to the subsystem and the statement refers to one or more
      aliases which define three-part name objects which must all
      refer to the same remote location.
    - any statement within a package that is being bound against
      a remote location.
    Thus, DRDA alias resolution processing only affects the
    contents of SQL statements which are sent from the DB2 for
    z/OS requester to a DRDA server.  If the server is also a
    DB2 for z/OS subsystem, and the modified statement received
    at the DB2 for z/OS DRDA server refers to a three-part name
    at the DB2 for z/OS server subsystem, then the package created
    at the DB2 for z/OS DRDA server, to support the DRDA protocol
    requests from the DB2 for z/OS DRDA requester, must now be
    bound copied from the DB2 for z/OS DRDA server to a further
    downstream DRDA server.  The following depicts this
    relationship:
    - An alias, ALIAS1, is defined at a DB2 subsystem, LOC1, to
      refer to an object named LOC2.AUTHID1.MYTABLE1.
    - An application is built which creates a package named
      COLLID1.PKG1, which contains a statement which refers to
      ALIAS1.
    - For DRDA protocol to succeed, the package, COLLID1.PKG1,
      must then be BIND PACKAGE COPY'd to LOC2.
    - During the remote package bind of the package against LOC2,
      the statement in the package, which references ALIAS1, is
      sent to LOC2 as a reference to "AUTHID1"."MYTABLE1".
    - At LOC2, in binding the statement which refers to
      "AUTHID1"."MYTABLE1", the subsystem determines that
      "AUTHID1"."MYTABLE1" actually is a three-part name alias
      defined to refer to an object named, LOC3.AUTHIDX.TABLEY.
    - The remote package bind against LOC2 will succeed, but in
      order for the eventual execution of the statement (now
      contained in the package LOC2.COLLID1.PKG1) to succeed,
      a BIND PACKAGE COPY at LOC2 of package LOC2.COLLID1.PKG1
      must be performed against LOC3.
    It should be noted that DRDA alias resolution processing will
    always be performed by DRDA protocol without the option of
    disabling it in DB2 10 for z/OS where private protocol is no
    longer supported.
    
    DB2 is also being changed to provide tools to aid in the
    conversion of packages and plans which utilize private
    protocol to now use DRDA protocol.
    For DB2 for z/OS V8, the following is being provided:
    - A private protocol to DRDA protocol catalog analysis REXX
      tool, DSNTP2DP, and an installation job, DSNTIJPD, which
      can be tailored for one's installation to run DSNTP2DP.
    - A private protocol trace analysis program, DSN1PPTP, and
      installation job, DSNTIJPT, which can be tailored for
      one's installation to run DSN1PPTP.
    - A private protocol statement checker REXX tool, DSNTPPCK,
      and an installation job, DSNTIJPK, which can be tailored
      for one's installation to run DSNTPPCK.
    For DB2 9 for z/OS, the following is being provided:
    - A replacement to the private protocol to DRDA protocol
      catalog analysis REXX tool, DSNTP2DP, and its corresponding
      installation job, DSNTIJPD.
    - A private protocol trace analysis program, DSN1PPTP, and its
      corresponding installation job, DSNTIJPT.
    - A private protocol statement checked REXX tool, DSNTPPCK,
      and its corresponding installation job, DSNTIJPK.
    The new or replaced DSNTP2DP REXX tool is built based on the
    assumption that DRDA resolution processing will be enabled in
    the subsystem. This allows successful processing of the
    generated commands which convert the packages and/or plans to
    DRDA protocol.
    
    The new DSN1PPTP program will analyze the private protocol
    performance trace, IFCID157, records so that a private protocol
    information table can be created.  This table gives the
    DSNTP2DP program additional information about the remote
    locations accessed by plans and/or packages which cannot be
    determined by querying the catalog. The DSNTIJPT job contains
    the steps which can be executed to:
    - Analyze the IFCID157 trace records to produce DB2 LOAD
      utility input data.
    - Create a private protocol information table.
    - Populate the private protocol information table.
    The program only supports processing a copy of the SMF
    type-102 records which contain IFCID157 trace data.
    
    The new DSNTPPCK program will analyze the embedded SQL
    statements, in packages and/or plans, for private protocol
    SQL which will become invalid in DB2 10 for z/OS which no
    longer supports private protocol.  The program will produce
    a report stating which packages, and/or member DBRMs of
    plans, contain the invalid syntax.  The program will scan
    either the SYSIBM.SYSSTMT catalog table, the SYSIBM.SYSPACKSTMT
    catalog table, or both.
    
    Documentation changes are required to describe the functional
    characteristic of the tools.
    Please refer to the additional documentation provided with
    the PTF associated with this APAR.
    ž**** PE10/05/21 PTF IN ERROR. SEE APAR PM14816  FOR DESCRIPTION
    

APAR Information

  • APAR number

    PK64045

  • Reported component name

    DB2 OS/390 & Z/

  • Reported component ID

    5740XYR00

  • Reported release

    910

  • Status

    CLOSED UR1

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    YesSpecatt / New Function

  • Submitted date

    2008-04-07

  • Closed date

    2010-02-19

  • Last modified date

    2011-02-18

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

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

    UK54507 UK54508

Modules/Macros

  •    DSNDHOPP DSNDQWPZ DSNDRDSI DSNDSPRM DSNDXFC
    DSNDZPHI DSNLXCQH DSNLXHIM DSNLXHNO DSNLXHOC DSNLXHOP DSNLXHPR
    DSNLXHSE DSNLXHSP DSNLXPRS DSNLXRCM DSNLXRSS DSNLZHC0 DSNLZHC1
    DSNLZHC2 DSNLZHOP DSNLZHP0 DSNLZHP1 DSNLZHP2 DSNLZHP3 DSNLZHR0
    DSNLZHR1 DSNLZR02 DSNTIDXA DSNTIJPD DSNTIJPK DSNTIJPT DSNTIJUZ
    DSNTINST DSNTINS1 DSNTPPCK DSNTP2DP DSNWZIF8 DSNWZIF9 DSNXEALS
    DSNXEDP  DSNXEDS1 DSNXEPM  DSNXIEPL DSNXOALS DSNXOCF  DSNXOCNR
    DSNXOFCR DSNXOFD  DSNXOIWS DSNXOMRG DSNXONDA DSNXOOP  DSNXOPL
    DSNXOPT  DSNXOP0  DSNXOP1  DSNXORFN DSNXORFR DSNXORSO DSNXOTDA
    DSNXOTL  DSNXOVD  DSNXOVM  DSNXRDA  DSN1PPTP DSN6SPRM HDB8810J
    HDB9910J
    

Publications Referenced
SC18741506 SC18984105      

Fix information

  • Fixed component name

    DB2 OS/390 & Z/

  • Fixed component ID

    5740XYR00

Applicable component levels

  • R810 PSY UK54507

       UP10/03/11 P F003

  • R910 PSY UK54508

       UP10/03/10 P F003

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.



Rate this page:

(0 users)Average rating

Add comments

Document information


More support for:

DB2 for z/OS

Software version:

9.1

Reference #:

PK64045

Modified date:

2011-02-18

Translate my page

Machine Translation

Content navigation