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

Obtain the fix for this APAR.

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