PK92339: NEW PRIVATE_PROTOCOL SUBSYSTEM PARAMETER

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

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



Rate this page:

(0 users)Average rating

Document information


More support for:

DB2 for z/OS

Software version:

9.1

Reference #:

PK92339

Modified date:

2011-02-18

Translate my page

Machine Translation

Content navigation