PK45718: EYURCSTB CONTROL BLOCKS BEING ORPHANED WHILE SHORT-ON-STORAGE (S OS)

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• When experiencing a short-on-storage condition, you may receive
  message:
      EYUCT0105E Transport Services control block shortage
      has occurred.
   (Note that the EYUCT0105E message can occur at other times,
   including valid usage.)
  .
  CTMB failed with an exception setting trace pointID 4
  CMPI_SCPT_NOTSPBLK in the ACQUIRE_TSPBLK routine.  PointID 4 is
  is set if the TRNSPT_FTSPP queue is zeros.  In the COM's MOEB at
  x'458' TRNSPT_FTSPP is 00000000 FF86897D which says we are out
  of Transport blocks.
  .
  During this time the MAS is SOS so there are several CTRC trace
  entries with a tpid of 17 indicating an error getting storage.
  When this occurs, we exit without freeing the CTSB back to the
  free pool.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All CICSPlex SM V3R2M0 Users                 *
  ****************************************************************
  * PROBLEM DESCRIPTION: Various communications errors may occur *
  *                      due to an orphaning of Transport        *
  *                      services control blocks (EYURCTSB),     *
  *                      when a CMAS or MAS experiences a short- *
  *                      on-storage (SOS) condition in EDSA.     *
  *                                                              *
  *                      When this occurs, the CMAS or MAS will  *
  *                      issue message EYUCT0105E.  Examination  *
  *                      of the region's auxtrace dataset will   *
  *                      show exception trace records issued by  *
  *                      method EYU0CTRC (CTRC) that have a      *
  *                      trace point ID of 17 and a debug text   *
  *                      of "EXCEPT".                            *
  *                                                              *
  *                      Please note that a CMAS or MAS may      *
  *                      experience temporary shortages of       *
  *                      EYURCTSB control blocks based upon      *
  *                      activity within the region.  When this  *
  *                      occurs, message EYUCT0105E will be      *
  *                      issued, but the CMAS or MAS will not    *
  *                      experience an SOS condition in EDSA,    *
  *                      and CTRC will not issue the exception   *
  *                      trace records noted above.  When this   *
  *                      occurs, please refer to the             *
  *                      documentation for message EYUCT0105E    *
  *                      regarding tuning suggestions.           *
  ****************************************************************
  * RECOMMENDATION: After applying the PTF that resolves this    *
  *                 APAR, all CMASes and MASes must be           *
  *                 restarted.  Note that the restarts do not    *
  *                 need to occur at the same time.              *
  ****************************************************************
  When method EYU0CTRC (CTRC) is called to perform cleanup of a
  completed communication request, it calls method EYU0XLML (XLML)
  to retrieve METAMFLD records associated with the request's
  parameter list (method argument list - MAL).  Since CTRC does
  not know how many METAMFLD records are associated with the MAL,
  it passes a buffer to XLML that would allow it to return 100
  records on a single call.  Since this area is too large to be
  part of the normal working (STAK) storage for CTRC, a CICS
  GETMAIN is issued for the storage area.  If the GETMAIN request
  fails because the CMAS or MAS is SOS, CTRC fails the cleanup
  request, and does not free up the EYURCTSB associated with the
  communication request.  Depending upon how long the SOS
  condition exists, this could result in all EYURCTSB control
  blocks being orphaned.  When this occurs, the CMAS or MAS can
  neither issue nor receive communications requests with other
  CMASes and MASes.
  
  In addition to orphaning EYURCTSB blocks when an SOS condition
  occurs in EDSA, the practice of issuing a GETMAIN request
  whenever cleanup is performed for a completed communications
  request results in unnecessary overhead.  Methods EYU0CTST
  (CTST) and EYU0CTRP (CTRP) perform similar GETMAIN requests when
  communications requests between CMASes are sent (CTST) or
  received (CTRP), adding to this overhead.
  

Problem conclusion

• To reduce the overhead and remove the EDSA SOS orphaning risk,
  the following changes have been made:
  
  -  XLML and its MAL (EYUZXLML) have been updated to allow its
     caller to request a specific number of METAMFLD elements,
     specifying a starting ID of the first METAMFLD to be
     returned.
  
  -  Callers of XLML for METAMFLDs have been updated to request at
     most 10 elements on a call to XLML.  The storage for these
     elements is now reserved in the caller's STAK, removing the
     requirement for the CICS GETMAIN.  Since limiting the caller
     to receiving 10 METAMFLD elements at a time could result in a
     caller requiring multiple calls to XLML for a single request,
     other operands have been specified in the calls to XLML to
     limit the type of METAMFLD records being returned to match
     exactly what the caller requires.  As a result, most requests
     are satisfied with a single call to XLML.
  
     CTRC and CTRP have been updated to use this new method to
     call XLML.  CTST, which did not use the METAMFLD records
     itself, but instead passed them to method EYU0CTSD (CTSD),
     has been updated to remove its call to XLML.  This has now
     been moved to CTSD.  Finally methods EYU0CTED (CTED) and
     EYU0CTER (CTER), which handle sends (CTED) and receives
     (CTER) between a CAMS and MAS, have been updated also.
  

Temporary fix

• FIX AVAILABLE BY PTF ONLY
  

Comments

APAR Information

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

  PK43973

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

  UK27396

Modules/Macros

•    DYU0XLML EYUQXLML EYURCOEB EYURCTSR EYURXLML
  EYUTRKNL EYUYXLML EYUZXLML EYU0CTED EYU0CTER EYU0CTRC EYU0CTRP
  EYU0CTSD EYU0CTST EYU0XLML EYU9XLPU EYU9XLP3 EYU9XLP4
  

Fix information

• Fixed component name

  CICSTS 3.X Z/OS

• Fixed component ID

  5655M1500

Applicable component levels

• R50M PSY UK27396

     UP07/07/26 P F707

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.