A fix is available
APAR status
Closed as new function.
Error description
DB2DDF DDFL09 DB2PRVT New PRIVATE_PROTOCOL subsystem parameter ********************************************************** Additional symptoms and keywords: DSN6FAC PRIVATE_PROTOCOL YES NO Sense 10086021 sense10086021 sns10086021 rc10086021 SQLCODE -512 SQLCODE512 SQL512N SQL0512N SQLCODE -30104 SQLCODE30104 SQL30104N Message DSNT225I MSGDSNT225I DB2MIGV10/K DB2COEXIST/K
Local fix
N/A
Problem summary
**************************************************************** * USERS AFFECTED: All Distributed Data Facility (DDF) users. * * Specifically where the private protocol * * capability is no longer required or * * desired for application remote access. * **************************************************************** * PROBLEM DESCRIPTION: Once all packages and plans have been * * converted from private protocol, * * support is required to prevent any * * future introduction of Private * * Protocol objects or requests into the * * system. * **************************************************************** * RECOMMENDATION: * **************************************************************** Private protocol support will be discontinued in a future version of DB2. Thus, many DB2 users are converting, or have converted, all their applications' plans and/or packages to DRDA protocol. Once the conversion of all packages and plans to DRDA is complete, a DB2 user has no way to prevent the possible accidental reintroduction of private protocol plans or packages into a DB2 catalog. Also, there is currently no method by which one could configure a subsystem to evaluate the effects of private protocol capabilities being no longer available.
Problem conclusion
Temporary fix
Comments
In preparation for a future release of DB2 where private protocol capabilities will no longer be available, a new subsystem parameter, PRIVATE_PROTOCOL, which is a parameter on the DSN6FAC macro, is being provided so that the private protocol capabilities can be enabled or disabled in a subsystem. If one does nothing to an existing subsystem parameters (DSNZPxxx) module after applying the fix to this APAR, private protocol capabilities will still be available. To disable private protocol capabilities in a subsystem, one must first create a new DSNZPxxx module, or modify an existing DSNZPxxx module, where the PRIVATE_PROTOCOL parameter of the DSN6FAC macro is set to NO. 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 re-enable private protocol capabilities on a running subsystem that previously had the capabilities disabled, then one can issue a -SET SYSPARM command, or restart DB2, specifying a DSNZPxxx module which does not have the PRIVATE_PROTOCOL parameter set to NO. Note: If private protocol capabilities are disabled via the -SET SYSPARM command on a running member of a DB2 data sharing group, then it is recommended that DDF be restarted on that member if, prior to the -SET SYSPARM command being issued to disable private protocol, it is determined that private protocol system conversations exist with other DB2 subsystems or groups. The existence of private protocol system conversations with other systems can be determined from the output of the -DISPLAY LOCATION DETAIL command. If any DSNL204I message is issued by the command with either "SYSCON-I" or "SYSCON-O" displayed as part of the message, then private protocol system conversations exist with other DB2 systems and DDF should be restarted on the member having private protocol capabilities being disabled. The restart of DDF will terminate the existing private protocol system conversations with the other systems such that any subsequent attempts by the other systems to initiate private protocol communications of any kind will then be denied by the member which had its private protocol capabilities disabled. If DDF is not restarted, then the existing private protocol system conversations will not be terminated. The other systems will then continue to operate as if this member of the data sharing group has its private protocol capabilities enabled only to have any private protocol data access requests denied by the member which had its private protocol capabilities disabled. These private protocol remote data access denials by the member of the data sharing group which had its private protocol capabilities disabled will be interpreted by the other DB2 requester systems as a temporary loss of the private protocol capabilities of the serving data sharing group not just of the member. For DB2 for z/OS V8, if the DSN6SYSP macro with the DBPROTCL parameter set to PRIVATE is processed before the DSN6FAC macro with the PRIVATE_PROTOCOL parameter set to NO in the assembly of the DSNZPxxx module, the assembly will fail. Also, for DB2 for z/OS V8, if the DSN6FAC macro with the PRIVATE_PROTOCOL parameter set to NO is processed before the DSN6SYSP macro with the DBPROTCL parameter set to PRIVATE in the assembly of the DSNZPxxx module, the assembly will complete with a warning saying that the DBPROTCL parameter is being set to DRDA when the PRIVATE_PROTOCOL parameter of the DSN6FAC macro is NO. When the PRIVATE_PROTOCOL parameter is set to NO, then the subsystem: - will reject any inbound private protocol requests from other systems with the requesting systems receiving a VTAM sense code of '10086021'X (Transaction program not recognized) - will fail any outbound private protocol request with SQLCODE -512 if a plan with member DBRMs or a package is still bound with DBPROTOCOL(PRIVATE) - will fail any BIND or REBIND of a package or plan with message DSNT225I being issued if DBPROTOCOL(PRIVATE) is specified on the command - will fail any remote BIND/REBIND package request with SQLCODE -30104 if DBPROTOCOL(PRIVATE) is explicitly received with the request - will fail the BIND PACKAGE COPY command with message DSNT225I if the source package of the bind was previously bound with DBPROTOCOL(PRIVATE) and OPTIONS(COMPOSITE) is in effect for the command (one would have to specify DBPROTOCOL(DRDA) in addition to the other BIND options to override the source package's DBPROTOCOL bind option) - will prevent the REBIND of a plan or package with message DSNT225I being issued if the plan or package was previously bound with DBPROTOCOL(PRIVATE) - (one would have to specify DBPROTOCOL(DRDA) in addition to other bind options on the REBIND command to override the package or plan's current DBPROTOCOL bind option value) - will fail any remote BIND/REBIND package request with SQLCODE -30104 if DBPROTOCOL(PRIVATE) is implied from the DBPROTOCOL bind option of the source package of BIND PACKAGE COPY or the target package of the REBIND - (DBPROTOCOL(DRDA) would also have to be received with the request to override the implied DBPROTOCOL bind option value) - will leave a package or plan marked as invalid if a request to run the package or plan required an autobind and the package was previously bound with DBPROTOCOL(PRIVATE) The fix to this APAR is not required to be applied to all members of a data sharing group, especially if no further action is taken other than just applying the fix. However, once a DSNZPxxx module is created with the PRIVATE_PROTOCOL parameter set to NO and that module is loaded by one or more members of the data sharing group, then the following events could occur: - on any member where the fix was not applied or the fix was applied but the currently-loaded DSNZPxxx module has the PRIVATE_PROTOCOL parameter set to YES, all private protocol capabilities are available on the member to the extent that new private protocol objects can be created in the group's catalog and applications which are attached or connected to the member can use those objects to perform private protocol remote data access - then on any member where the fix was applied and the currently-loaded DSNZPxxx module has the PRIVATE_PROTOCOL parameter set to NO, any use of private protocol capabilities (as mentioned previously) by applications attached or connected to the member will fail A new DSNT225I message is introduced. Please update the DB2 V8 and V9 Messages manual with the following description: DSNT225I bind-type ERROR FOR object-type object-name, bind-option IS NOT SUPPORTED Explanation: The BIND or REBIND command specified invalid options. - bind-type: BIND, BIND COPY, or REBIND - object-type: PLAN or PACKAGE - object-name: The name of the application plan or package - bind-option: The unsupported bind option One condition under which this message is issued is when DBPROTOCOL(PRIVATE) is specified or implied, and private protocol is not allowed. System Action: The bind process fails. User Response: Correct the bind option, and rerun the BIND or REBIND command. An additional change is required in the DB2 Codes manual for V8 and V9. The Explanation section of SQLCODE -512 will now have an additional condition as follows: - The statement cannot use DB2 private protocol because the PRIVATE_PROTOCOL subsystem parameter is set to NO.
APAR Information
APAR number
PK92339
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
2009-07-26
Closed date
2009-11-03
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:
UK51678 UK51679
Modules/Macros
B390SPA1 B390SPA2
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