A fix is available
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
SC18741506 | SC18984105 |
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:
18 February 2011