OA41951: ABEND0A9 7075 IN ISTORCFB

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• ISTORCFB ABEND0A9 7075 when the same storage is freed twice.
  ISTRPCTC frees it first and then ISTRCCSQ tries to free it
  again causing the abend. VTAM is processing a connection setup
  at the same time the HPR pipe is coming down.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All using HPR/RTP connections.               *
  ****************************************************************
  * PROBLEM DESCRIPTION: ABEND0A9 RC7075 occurs in module        *
  *                      ISTORCFB trying to free a RUPE          *
  *                      (RPN_CSE_PTR storage).                  *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  The problem is summarized as follows:
  
  1) A Connection Setup packet is received from an RTP partner
     to establish a CPSVCMG RTP pipe.
  2) A short time later, VTAM received a
     COB (Client Out-of-Band) segment from the RTP partner
     to request RTP deactivation for this same pipe.
  3) It appears the CPSVCMG pipe has already been established
     on VTAM, and this is a duplicate CS being retransmitted
     from the partner.  This may occur if the active end of
     the RTP pipe does not receive the Connection Identifier
     Exchange segment in a timely fashion.
  4) This scenario exposed a timing window where RTP and RCM
     were running concurrently.  RTP was running with the
     RIV response while RCM was running with the CS which exposed
     a synchronization problem.  In this case, module
     ISTRCCSQ issued a FREERUPE for the RPN_CSE_PTR and module
     ISTORCFB took an ABEND0A9 RC7075, as module ISTRPCTC had
     previously freed it.
  
  Note: After the ABEND0A9 occurred, one of the various
     work queues associated with the RCM PAB became corrupted.
     This occurred because of the mishandling of the RUPE
     storage above which lead to the ABEND0A9.  Because the
     queue was corrupted, any new RTP pipes being created, or
     old RTP pipes shutting down, became hung in various states:
  
     New session hung in PBIPLUBF state (PRTPSTR).  Internally,
     the RPNCB has an RPN_Initial state.  RTP pipes shutting down
     showed an internal state of RPN_PENDING_INACT and RPN_GONE.
  

Problem conclusion

• ISTRPNCB - Defined RPN_RIV_Fmt2_Sent
  
  ISTRPCRC,
  ISTRPCAM - Set RPN_RIV_Fmt2_Sent bit when sending a RIV
             format 2 to RCM
  ISTRCCSP - Modified code to not allocate the CS RUPE for RTP
             if the RPN_RIV_Fmt2_Sent bit is on for
             a connected RTP pipe.
  

Temporary fix

• *********
  * HIPER *
  *********
  

Comments

APAR Information

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

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

  UA68903 UA68904 OA42089

Modules/Macros

• ISTRCCSP ISTRPCAM ISTRPCRC ISTRPNCB
  

Fix information

• Fixed component name

  VTAM V4 MVS/ESA

• Fixed component ID

  569511701

Applicable component levels

• R1C0 PSY UA68903

     UP13/06/10 P F306 Ž

• R1D0 PSY UA68904

     UP13/06/10 P F306 Ž

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.