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

Obtain the fix for this APAR.

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 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
  

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.