PM74276: OPTLOCAL CONNECTIONS NOT STAYING LOCAL ON DISTRIBUTOR STACK.

Obtain the fix for this APAR.

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