OA30924: ABEND0C4 MODULE ISTRCCRA +X'832' FOLLOWED BY ABEND0C4 IN MODULE ISTRCCNV + X'31C' DUE TO ERROR IN HPR PIPE CLEANUP.

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• ABEND0C4 module ISTRCCRA +x'832' followed by ABEND0C4 in
  module ISTRCCNV + x'31C' due to error in HPR pipe cleanup.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All using HPR/RTP connections.               *
  ****************************************************************
  * PROBLEM DESCRIPTION: Storage shortage in UTILPVTS GETBLK     *
  *                      pool leads to various ABENDs and        *
  *                      unpredicatable results.  Reported       *
  *                      errors include:                         *
  *                        ABEND0C4 ISTRCCRA                     *
  *                        ABEND0C4 ISTRCCNV                     *
  *                        ABEND0A9 ISTORCFB                     *
  *                        LOOP - ISTRPCTM processing LIVENESS2  *
  *                               QUEUE (TIMBK chained to itself *
  *                        ABEND0A9 - ISTINCTM                   *
  *                        FFST PROBE ISTTSCZ1                   *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  The problem is summarized as follows:
  1) A storage shortage has depleted the UTILPVTS
     GETBLK pool.  The actual storage shortage is not being
     addressed in this APAR, but the erroneous processing
     that takes place as a result of the storage shortage.
  2) A Connection Setup (CS) arrives to setup a new
     LU-LU RTP pipe.
  3) The RPNCB and associated control blocks used to represent
     an RTP pipe are allocated.
  4) Module ISTRCCSP issues an RTPFIND PASSIVE macro which
     builds and queues an RTP_ALLOCATION_V (RAL) IPS
     signal to RCM.  RAL RUPE contains a pointer to the
     RPNCB to be processed.
  5) Immediately following this flow, module ISTRCCSP
     issues a GETRUPE to allocate a new RUPE.  If successful,
     the input CS would be copied to the new RUPE.  The new
     RUPE would then be queued to the RPNCB (RPN_CSE_PTR).
     Unfortunately, the GETBLK failed as a result of the storage
     failure described in step 1.
  6) This storage failure causes module ISTRCCSP to immediately
     call module ISTRCCDR to free up the RPNCB and associated
     storage.
  7) Module ISTRCCDR issues message IST1488I with a blank
     RTP name since it has not been assigned yet.
  
     IST1488I INACTIVATION OF RTP ........ AS PASSIVE TO xxxx.xxxx
  
  8) Cleanup processing continues which leads to the RPNCB,
     RPN_BaseExt and TIMBKs (RPN_SHORT_REQ_PTR) control blocks
     being freed.  Since the main RPNCB control block was being
     freed, the pointers to the substructures (RPN_BaseExt_PTR,
     RPN_SHORT_REQ_PTR) were not cleared.
  9) At this point, the RCM PAB is dispatched with the RAL RUPE
     which was described in step 4.
  10) Next, RCM processed the RAL signal which
      contained a pointer to the freed RPNCB.  An ABEND could
      result at this point if the RPNCB has been FREEMAINed.
      It had not in our case and processing continued.
  11) An RAL response was built and queued to the ConfigSvcs
      PAB.
  12) This causes processing to dynamically build a RTP PU,
      allocates a network address for the PU, and sets
      the RPRNCBA field to the "freed" RPNCB address.
      A dynamic PU name is assigned as well (i.e. CNRxxxxx).
  13) Module ISTACCAU then builds and sends an RTP_ATTACH_V (RAT)
      RUPE back to RCM.
  14) RCM dispatches and module ISTRCCAT is called to process the
      RAT RUPE.  Module ISTRCCAT detects the RPN_CSE_PTR is zero
      and issues a CPRC with SENSE X'FF200001'.  The pointer is
      zero because of the error described in step 5.
  15) Module ISTRCCAT then calls module ISTRCCDR to cleanup from
      the error.
  16) Module ISTRCCDR issues an HPRCTL delete and module
      ISTRCCRA takes an ABEND0C4 since the RSCV passed as a
      parameter list is contained within one of the previously
      freed structures.  Since an other process could have
      allocated the freed RPNCB control block and related
      stuctures, module ISTRCCDR may be freeing storage that is
      now allocated to a new process.  This can lead to various
      and unpredictable results.
  

Problem conclusion

• ISTRCCSP - Processing has been restructured such that an RAL
             RUPE cannot be forwarded to RCM before the RUPE for
             the CS is allocated.
  ISTTSCDN,
  ISTRCCDR - Various checks have been made to validate that
             structures exist prior to freeing them.  Also, when
             control blocks are freed, their associated pointers
             are now cleared.
  ISTRPCRT - Included for maintenance purposes.
  

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:

  UA51067 UA51068 UA51069

Modules/Macros

• ISTRCCDR ISTRCCSP ISTRPCRT ISTTSCDN
  

Fix information

• Fixed component name

  VTAM V4 MVS/ESA

• Fixed component ID

  569511701

Applicable component levels

• R1A0 PSY UA51067

     UP09/12/04 P F912

• R1B0 PSY UA51068

     UP09/12/04 P F912

• R190 PSY UA51069

     UP09/12/04 P F912

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.