PK54955: ASRA IN XCLD WHEN CALLED BY PECS TO DELETE MFILE CACHELIST, THE RUNNING TRANSACTION IS PELT

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• You have a program check occur (ABENDS0C4) that shows up as an
  ASRA IN XCLD, OFFSET 00000096.  The contents of GP R8 is
  incorrect, the AR R8 is fine.
  The stack entries of the failing task includes EYU0PECS.
  XLOP -> PELT -> PECS -> XCLD
  PECS has successfully called EYU0XCLD a number times to get rid
  of MPROG and MJRNL cache list pointed to from the EYURPSRD
  control block. The CACHELIST TOKEN (PSRD_EVL_MFILE) for File
  Class Monitoring has been corrupted. This causes a program check
  in EYU0XCLD on a CLC DCLT_CBNAME,CNST_VALD_DCLT, and in this
  case Reg 10 has the incorrect address passed from PECS.
  ADDITIONAL KEYWORDS: RA, R10, XCLD_LIST_ID, PECSXCLD,
  DEL_MFILE_LIST
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All CICSPlex SM V3R2M0 Users                 *
  ****************************************************************
  * PROBLEM DESCRIPTION: While starting up MASes one of your     *
  *                      CMASes receives abend ASRA (S0C4) in    *
  *                      module EYU0XCLD (XCLD - Delete Cache    *
  *                      List), called from module EYU0PECS      *
  *                      (PECS - RTAEVL System Start).  In the   *
  *                      diagnostic data block in the CMAS log   *
  *                      you see that the offset in R10 is not   *
  *                      valid, but the ALET in AR10 appears     *
  *                      to be correct.                          *
  ****************************************************************
  * RECOMMENDATION: After applying the PTF that resolves this    *
  *                 APAR, all CMASes must be recycled to pick    *
  *                 up the new code.  Note that the restarts     *
  *                 do not need to be done at the same time.     *
  ****************************************************************
     When a MAS connects to a plex, EYU0PECS is called to build
  the RTASAM Object Data Descriptor (PSRD).  EYU0CPLM (CPLM -
  Connection Services Return MAS Information) is called to get
  the connection type (LOCAL / REMOTE) for the MAS.  If Communi-
  cations has not added the MAS Directory (MASDIR) element yet,
  CPLM will return STATUS=SCOPE_NOT_FOUND and PECS will roll back
  all changes including the creation of Monitor Resource Class
  cache lists.
     Normally when this occurs, each of the Monitor Resource Class
  cache lists is destroyed and the cache list token in the PSRD is
  cleared, but incorrect XC instructions for the MPROG and MJRNL
  cache list tokens cause the MFILE token to be corrupted.  When
  XCLD is then called to destroy the MFILE cache list, if the
  corrupted offset is within the DMDS data space, XCLD will fail
  with appropriate tracing.  If the corrupted offset is beyond
  the end of the DMDS cache data space, abend ASRA (S0C4) will
  result.
  

Problem conclusion

•    Module EYU0PECS was updated to clear the MPROG and MJRNL
  cache list tokens in the PSRD area correctly.
  

Temporary fix

• FIX AVAILABLE BY PTF ONLY
  

Comments

• While starting up MASes one of your
  CMASes receives abend ASRA (S0C4) in
  module EYU0XCLD (XCLD - Delete Cache
  List), called from module EYU0PECS
  (PECS - RTAEVL System Start).  In the
  diagnostic data block in the CMAS log
  you see that the offset in R10 is not
  valid, but the ALET in AR10 appears
  to be correct.
  
  
     When a MAS connects to a plex, EYU0PECS is called to build
  the RTASAM Object Data Descriptor (PSRD).  EYU0CPLM (CPLM -
  Connection Services Return MAS Information) is called to get
  the connection type (LOCAL / REMOTE) for the MAS.  If Communi-
  cations has not added the MAS Directory (MASDIR) element yet,
  CPLM will return STATUS=SCOPE_NOT_FOUND and PECS will roll back
  all changes including the creation of Monitor Resource Class
  cache lists.
     Normally when this occurs, each of the Monitor Resource Class
  cache lists is destroyed and the cache list token in the PSRD is
  cleared, but incorrect XC instructions for the MPROG and MJRNL
  cache list tokens cause the MFILE token to be corrupted.  When
  XCLD is then called to destroy the MFILE cache list, if the
  corrupted offset is within the DMDS data space, XCLD will fail
  with appropriate tracing.  If the corrupted offset is beyond
  the end of the DMDS cache data space, abend ASRA (S0C4) will
  result.
  
  
     Module EYU0PECS was updated to clear the MPROG and MJRNL
  cache list tokens in the PSRD area correctly.
  

APAR Information

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

  PK55032

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

  UK30910

Modules/Macros

•    EYU0PECS
  

Fix information

• Fixed component name

  CICSTS V3 Z/OS

• Fixed component ID

  5655M1500

Applicable component levels

• R50M PSY UK30910

     UP07/11/07 P F711

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.