VM65916: SIMULATED HIPERSOCKETS LOSS OF INITIATIVE

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• When two hosts are connected by a virtual HiperSockets Guest
  LAN, some applications may notice an unexplained delay in
  response from the second host.  It may take additional network
  activity to "wake up" the destination host.
  
  This was observed with z/OS guests but not with z/Linux or
  VM/TCPIP guests.
  

Local fix

• Apply PTF
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: A z/OS guest using a z/VM HiperSockets       *
  *                 Guest LAN network connectionon could hang    *
  *                 occasionally (or exhibit unexplained delays) *
  *                 responding to individual requests (depending *
  *                 on timing).                                  *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  ****************************************************************
  * RECOMMENDATION: APPLY PTF                                    *
  ****************************************************************
  The z/OS driver uses features of the HiperSockets interface
  that are designed to reduce unnecessary interrupt handling.
  The HiperSockets interface does not reflect an interrupt to the
  guest every time the input buffer is updated.  That is by design
  (to avoid unnecessary interrupt processing for the guest when
  several input buffers are available).  In some circumstances
  (based on timing) this approach to collapse interrupts may
  cause a delay (if there are no additional inbound frames for
  a significant period of time).  It is possible for an inbound
  request to be installed without triggering an interrupt, and
  if no new traffic arrives for this interface the guest is
  unaware of the network data waiting to be processed.  This
  results in a hang if the sender is waiting for a response
  (and there is no new traffic to generate an interrupt).
  

Problem conclusion

• Entry point HCPVAIEV near label EVVIRT is updated to set a
  flag==0 (no transition).  After the EVSETAIF loop, if this is a
  transition from Inactive to Active state, set the flag==1
  (transition).
  Near label EVCHKSUP (where we might suppress a redundant
  interrupt) test the new flag.  If it indicates a transition
  from Inactive to Active, goto EVGTVDEV to reflect the interrupt
  unconditionally.
  

Temporary fix

• FOR RELEASE VM/ESA CP/ESA R540 :
  PREREQ: VM65626
  CO-REQ: NONE
  IF-REQ: NONE
  FOR RELEASE VM/ESA CP/ESA R630 :
  PREREQ: VM65583
  CO-REQ: NONE
  IF-REQ: NONE
  FOR RELEASE VM/ESA CP/ESA R640 :
  PREREQ: NONE
  CO-REQ: NONE
  IF-REQ: NONE
  

Comments

APAR Information

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

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

  UM35089 UM35090 UM35091

Modules/Macros

• HCPVAI
  

Fix information

• Fixed component name

  VM CP

• Fixed component ID

  568411202

Applicable component levels

• R540 PSY UM35089

     UP17/03/22 I 1000

• R630 PSY UM35090

     UP17/03/22 I 1000

• R640 PSY UM35091

     UP17/03/22 P 1901

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.