PM78817: TCSR FOR DISTRIBUTED DVIPA GOES TO 0 ON MULTIPLE STACKS - FIN REVERSAL OF PK82270

A fix is available

Subscribe

You can track all active APARs for this component.

APAR status

  • Closed as unreproducible.

Error description

  • A sysplex has at least one distributed DVIPA defined with
    multiple backup systems with various priorities, and VIPAROUTE
    statements for the target systems.  Some time after a stack
    takes ownership of a distributed DVIPA, the following message
    is issued on a sysplex distributor stack (possibly for multiple
    target systems):
    
    EZD1182I TARGET SERVER FOR 10.9.8.7 PORT 12345 AT TCPIP ON SYSB
             IS NOT RESPONSIVE - TCSR    0 CER  100 SEF  100
    
    These stacks never recover (no subsequent EZD1183I message),
    unless the DVIPA ownership moves to another system.  While in
    this state, a NETSTAT VDPT report issued on the distributing
    stack will be similar to the following:
    
    EZZ2500I NETSTAT CS V1R9 TCPIP
    DYNAMIC VIPA DESTINATION PORT TABLE:
    DEST IPADDR     DPORT DESTXCF ADDR    RDY TOTALCONN  WLM TSR FLG
    10.9.8.7        12345 10.11.12.2      001 0000000000 04  100 B
    10.9.8.7        12345 10.11.12.3      001 0000000000 05  100 B
    10.9.8.7        12345 10.11.12.4      001 0000004294 04  100 B
    10.9.8.7        12345 10.11.12.5      001 0000007947 07  100 B
    4 OF 4 RECORDS DISPLAYED
    
    
    Additional Symptoms:
    
     - When the distributing stack was taking over the DVIPA, the
       following messages will be generated near simultaneously on
       one of the other stacks (whose TCSR is non-zero):
    
          EZZ8301I VIPA 10.9.8.7 TAKEN OVER FROM TCPIP ON SYSD
          EZZ8303I VIPA 10.9.8.7 GIVEN TO TCPIP ON SYSA
    
             SYSD - The distributing stack before the takeover.
             SYSA - The current distributing stack.
    
     - Packet traces of the distributor's attempt to retry the
       failing target will show the SYN packets looping between the
       distributor and the target.
    
     - Examination of a dump from the failing target system will
       show that the LIF for the DVIPA has the wrong stack's
       DYNAMICXCF address in the liDxcfAddr4 field (+B8).
    

Local fix

  • First verify that the packets sent from the distributing stack
    arrive at the target stack when the configured VIPAROUTE address
    is used (PING or TRACERTE).  If this fails, the routing tables
    being used on the network may need to be corrected.
    
    Do a VARY TCPIP,,SYSPLEX,QUIESCE,xxxx command on the affected
    target system(s), followed by a VARY TCPIP,,SYSPLEX,RESUME,xxxx
    command.  Specify the keyword TARGET to recycle all DVIPAs, or
    PORT=nnnnn (the distributed port number) for an individual
    DVIPA.
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All users of the IBM Communications Server   *
    *                 for z/OS Version 1 Release 11                *
    *                 IP: Distributed DVIPA                        *
    ****************************************************************
    * PROBLEM DESCRIPTION: TCSR drops to zero following            *
    *                      distributed DVIPA movement.             *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    After a distributed DVIPA (with VIPAROUTE configured) moves from
    one stack to another, all the targets have to be properly
    updated to accept the GRE encapsulated packets from the new
    distributor. There is a small timing window where distribution
    information may come in out of order causing the targets to
    have incorrect information about the owner.
    +-------------------------------------------------------------+
    + 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

Temporary fix

Comments

  • TCPIP was modified to correctly update DVIPA distribution
    information at DVIPA targets when a DVIPA moves from one
    stack to another.
    
    This APAR is a logical route of FIN APAR PK82270.
    

APAR Information

  • APAR number

    PM78817

  • Reported component name

    TCP/IP V3 MVS

  • Reported component ID

    5655HAL00

  • Reported release

    1C0

  • Status

    CLOSED UR3

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2012-12-10

  • Closed date

    2013-01-04

  • Last modified date

    2013-02-04

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

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

    UK90743

Modules/Macros

  • EZBXFMS3
    

Fix information

  • Fixed component name

    TCP/IP V3 MVS

  • Fixed component ID

    5655HAL00

Applicable component levels

  • R1B0 PSY UK90743

       UP13/02/01 P F301

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:

1C0

Operating system(s):

z/OS

Reference #:

PM78817

Modified date:

2013-02-04

Translate my page

Machine Translation

Content navigation