VM66886: ISFC MESSAGE LOSS MAY CAUSE LINK/LOGOFF HANG IN SSI

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• Some CP commands within an SSI cluster involve resources
  available to other members, so high-priority messages must be
  exchanged with all other members when (for example) a LINK is
  established to a minidisk on a real storage device that is
  available to other SSI members.
  
  The evidence indicates that the storage management subsystem
  requested authorization to access such a minidisk, but one of
  the members had failed to receive a numbered segment of
  information from this member, so the high-priority queue on that
  ISLINK was blocked. Subsequent high-priority messages could not
  be processed (blocking newer attempts by some users to LINK,
  LOGOFF, or LOGON).
  

Local fix

• Reset the ISFC linkage in the SSI cluster with DEACT/ACT ISLINK
  commands.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of ISFC in SSI environments.       *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  ****************************************************************
  * RECOMMENDATION: APPLY PTF                                    *
  ****************************************************************
  When members within an SSI are using ISFC links, there is a
  possibility of losing a 'packet' of information during
  transmission that cannot be recovered. As the ISFC link has no
  method to identify and replicate a lost packet like this,
  the link must be brought down and re-established in order to
  continue transmission on the link. While the receiver is
  waiting for that lost packet, it will not process new packets
  that arrive. This will eventually cause hanging or
  unavailability of resources for users of associated SSI
  systems using this link to provide said resources.
  

Problem conclusion

• To address the unresolved hanging of the ISFC links caused by
  this problem, the ISFC code in HCPKCW was altered in order to
  detect a missing packet. The code was enhanced to be able to
  discard unneeded duplicates in the packet queue. Then tag each
  packet with a time such that packets can be tracked, and link
  can be reset if an amount of time has passed since a certain
  packet arrived on the queue. In this way, the link will not
  be reset preemptively and an appropriate amount of time is
  given for a duplicate packet to be sent from the other end of
  the link. However, once it is noticed that an inappropriate
  amount of time has passed since a packet with the correct
  sequence number has been processed, the ISFC link will be
  reset. Without resetting, the link would never receive a
  retransmission of a packet with the correct sequence number,
  and resetting allows the link to re-sync. Through this fix,
  users of the SSI might experience a brief period of
  unresponsiveness while the ISFC link detects and addresses the
  issue through resetting.
  

Temporary fix

• FOR RELEASE VM/ESA CP/ESA R730 :
  PREREQ: VM66823
  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:

  UM90576

Modules/Macros

• HCPKCW   HCPMES   HCPMESB  HCPMXRBK HCP2718E
  

Fix information

• Fixed component name

  VM CP CP

• Fixed component ID

  568411202

Applicable component levels

• R730 PSY UM90576

     UP25/12/18 I 1000

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.