PM74276: OPTLOCAL CONNECTIONS NOT STAYING LOCAL ON DISTRIBUTOR STACK.

A fix is available

Subscribe

You can track all active APARs for this component.

APAR status

  • Closed as program error.

Error description

  • Sysplex Distributor is configured with OptLocal.  The TCPIP
    stack acting as a distributor is also a target stack.
    Connections originating on the distributing stack are not using
    the OptLocal setting.  The connections will be distributed based
    on the DistMethod configured.  However, connections originating
    on the other stacks will use the OptLocal value configured.
    This can cause the distribution of connections to favor the
    other stacks.  In the case where there are only 2 target stacks
    active and the servers are equally weighted via WLM, the
    connection balance will be 3 to 1 instead of the 1 to 1 balance
    the WLM weights would use.
    .
    The problem occurs when a VARY
    TCPIP,tcpip,SYSPLEX,QUIESCE,TARGET then a VARY
    TCPIP,tcpip,SYSPLEX,DEACTIVATE,DVIPA=xx.xx.xx.xx
    is done, moving the DVIPA to a backup system.  Then, a
    VARY TCPIP,tcpip,SYSPLEX,RESUME,TARGET and a
    VARY TCPIP,tcpip,REACTIVATE,DVIPA=xx.xx.xx.xx is done. A timing
    window exists where a OPTLOCAL table will be accepted from the
    old distributor after the REACTIVATE has completed.  This table
    will be found when processing connection requests, causing the
    request to be sent to the distributor.
    

Local fix

  • Wait two minutes between the
    VARY TCPIP,TCPCS,SYSPLEX,RESUME,TARGET
    and the
    VARY TCPIP,TCPCS,SYSPLEX,REACTIVATE,DVIPA=xx.xx.xx.xx command.
    .
    If the problem has already occured, issue
    VARY TCPIP,TCPCS,SYSPLEX,DEACTIVATE,DVIPA=xx.xx.xx.xx
     wait two minutes, then issue
    VARY TCPIP,TCPCS,SYSPLEX,REACTIVATE,DVIPA=xx.xx.xx.xx
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All users of the IBM Communications Server   *
    *                 for z/OS Version 1 Release(s) 13 IP: DVIPA   *
    ****************************************************************
    * PROBLEM DESCRIPTION: TCP connections are not staying local   *
    *                      even though an Optlocal was coded       *
    *                      for the DVIPA.                          *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    User has two systems in a sysplex, system1 and system2.
    System1 is a distributor and a target. System2 is a backup and
    a target.
    An OPTLOCAL 5 is coded on the vipadistribute statement.
    
    Then user issued the following commands via automation from
    System1.
    
    1- Quiesce target on distributor stack
     VARY TCPIP,TCPCS,SYSPLEX,QUIESCE,TARGET
    2- Deactivate the DVIPA
     VARY TCPIP,TCPCS,SYSPLEX,DEACTIVATE,DVIPA=xxx.yyy.zzz.ww
    3- Resume target on distributor
     VARY TCPIP,TCPCS,SYSPLEX,RESUME,TARGET
    4- Reactivate DVIPA to force takeback
     VARY TCPIP,TCPCS,SYSPLEX,REACTIVATE,DVIPA=xxx.yyy.zzz.ww
    
    After that, connections originating on system1 were not
    staying local, but were being sent to the distributor.
    The connections originating on system1 were not staying local
    because the OPTLOCAL flags were incorrectly turned off.
    
    Since the above commands were issued via an automation, an
    Optlocal message was received on system1 after the DVIPA
    was re-activated and the optlocal control blocks were reset.
    The optlocal message from system2 had the keep connections local
    flag turned off since the target on system1 was in quiesce.
    +-------------------------------------------------------------+
    + Please check our Communications Server for OS/390 homepages +
    + for common networking tips and fixes.  The URL for these    +
    + homepages can be found in Informational APAR II11334.       +
    +-------------------------------------------------------------+
    

Problem conclusion

  • EZBXFMS3 has been changed to remove Optlocal data when an
    empty DPT message is received from a stack that relinquished
    ownership of a DVIPA.
    
    * Cross Reference between External and Internal Names
    

Temporary fix

Comments

APAR Information

  • APAR number

    PM74276

  • Reported component name

    TCP/IP V3 MVS

  • Reported component ID

    5655HAL00

  • Reported release

    1D0

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2012-10-03

  • Closed date

    2012-11-02

  • Last modified date

    2013-03-04

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

    UK83275

Modules/Macros

  • EZBXFMS3
    

Fix information

  • Fixed component name

    TCP/IP V3 MVS

  • Fixed component ID

    5655HAL00

Applicable component levels

  • R1D0 PSY UK83275

       UP13/02/20 P F302

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

Add comments

Document information


More support for:

z/OS family

Software version:

1D0

Operating system(s):

z/OS

Reference #:

PM74276

Modified date:

2013-03-04

Translate my page

Machine Translation

Content navigation