PK92339: NEW PRIVATE_PROTOCOL SUBSYSTEM PARAMETER

Obtain the fix for this APAR.

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

• R810 PSY UK51678

     UP09/11/18 P F911

• R910 PSY UK51679

     UP09/11/18 P F911

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.