PK51284: BAS UPDATES FAIL WHEN CMAS IS RECYCLED. EYUBM0102W BAS HAS REPORTED AN ERROR PROCESSING EVENT (EDEFCHG).

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• You made updates to BAS RASGNDEF and RESDESC while a non-MP
  CMAS was down. When the Non-MP was started, the BAS updates
  for RASGNDEF and RESDESC failed. In this non-MP CMAS you see
  messages:
  EYUBM0102W C05XCMAS BAS has reported an error processing event
  (EDefChg).
  A timing problem exist during CMAS start up where the BAS Long
  running task processes RASGNDEFs before the Topology long
  running task processes the CICS system or CICS Groups that the
  RASGNDEF update references.
  .
  Additonal information and Keyword(s): BMAA_TSCOPE_NOT_FOUND
  CPSM Aux trace shows:
  BMDC BMLT BMLT BAS EXCP.     17 BMDCBMAA CPSM C05XCMAS CMAS
  BMLT XLOP BMLT BAS EXCP.     11 EDefChg  CPSM C05XCMAS CMAS
  

Local fix

• Recycle the non-MP that had the BAS failures. This will rebuild
  the internal BAS MATRIX.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All CICSPlex SM V3R2M0 Users                 *
  ****************************************************************
  * PROBLEM DESCRIPTION: When the maintenance point (MP) CMAS    *
  *                      for a CICSplex connects to a non-MP     *
  *                      CMAS for the same CICSplex, the non-MP  *
  *                      CMAS may receive errors processing BAS  *
  *                      definition updates for the CICSplex,    *
  *                      resulting in message EYUBM0102W being   *
  *                      issued by the non-MP CMAS.              *
  *                                                              *
  *                      The full text of the message is as      *
  *                      follows:                                *
  *                                                              *
  *                       EYUBM0102W BAS has reported an error   *
  *                                  processing event (EDefChg). *
  *                                                              *
  *                      This can result in resources not being  *
  *                      installed properly in MASes connected   *
  *                      to the non-MP CMAS.                     *
  ****************************************************************
  * RECOMMENDATION: After applying the PTF that resolves this    *
  *                 APAR, all CMASes must be restarted.  Note    *
  *                 that the restarts do not need to occur at    *
  *                 the same time.                               *
  ****************************************************************
  When the MP CMAS for a CICSplex connects to a non-MP CMAS for
  the CICSplex, the MP CMAS sends to the non-MP CMAS all
  definition updates for the CICSplex that have been processed by
  the MP CMAS since the two CMASes were last connected.  Method
  EYU0XDRS (XDRS) executes in the non-MP CMAS to process the
  definition updates.  XDRS first acquires the data repository
  (EYUDREP) update lock in EXCLUSIVE mode, and then for each
  definitional update provided, it updates the local EYUDREP and
  then calls method EYU0XDCR (XDCR).  XDCR issues an internal
  EDEFCHG event to notify all CPSM components of the change.
  After XDRS processes the last definitional update, it frees the
  EYUDREP update lock.
  
  Long running tasks (LRTs) for each component listen for the
  EDEFCHG event and process it when it is received.  For example,
  method EYU0TIST (TIST) running under transaction TIST, processes
  the EDEFCHG events for the Topology component, and method
  EYU0BMLT (BMLT) running under transaction BMLT processes the
  EDEFCHG events for the BAS component.  When TIST and BMLT
  receive an EDEFCHG for a definition for their component, they
  will build internal control blocks for that definition.
  
  As part of processing a Topology definition update, method
  EYU0XDGT (XDGT) is called from TIST (or methods it calls) to
  read the definition just written to the EYUDREP.  Before
  performing the EYUDREP read, XDGT will acquire the EYUDREP
  update lock in SHARE mode.  Since XDRS already acquired the lock
  in EXCLUSIVE mode, XDGT will wait until XDRS completes
  processing.
  
  As part of processing a BAS definition update, method BMLT (or
  methods it calls) will need to access Topology control blocks
  for Scopes associated with the BAS definitions.
  
  XDRS acquires the EYUDREP update lock in EXCLUSIVE mode for two
  reasons.  The first is to serialize XDRS processing in the CMAS.
  The second is to ensure that while a single update is made to
  the EYUDREP, no other update or read takes place.  However, the
  way this is currently implemented causes all EYUDREP updates and
  reads to be held up while XDRS is processing all of the updates
  passed to it.  If an update packet sent to the non-MP CMAS
  contains both Topology and BAS definitions, and if the BAS
  definitions contain target and/or related scopes that are being
  defined by the Topology definitions, it is possible that BMLT
  will attempt to process a scope before TIST has been able to
  read the Topology updates and build the control blocks for them.
  When that occurs BMLT will fail with the EYUBM0102W message.
  

Problem conclusion

• To address this problem, XDRS will use two different locks to
  achieve the dual serialization it requires.  A new lock will now
  be used to serialize XDRS processing in a CMAS.  Method EYU0XDIN
  (XDIN) will register this new lock at CMAS initialization.  XDRS
  will acquire this lock in EXCLUSIVE mode upon entry, and free it
  on exit.  This will ensure that multiple instances of XDRS
  running in the CMAS are serialized.  To serialize updates and
  reads to the EYUDREP, the original EYUDREP update lock will
  continue to be used.  However, XDRS will acquire this lock in
  EXCLUSIVE mode just before starting to process a single update,
  and will free it when that update process is complete.  Before
  processing the next request, XDRS will call method EYU0XSSP
  (XSSP) to issue a CICS SUSPEND, to allow other component's LRTs
  to process the request just completed.  This procedure of
  acquiring the EYUDREP update lock, processing the update,
  freeing the lock, and issuing the CICS SUSPEND will continue
  until the entire update packet passed to XDRS is exhausted.
  

Temporary fix

• FIX AVAILABLE BY PTF ONLY
  

Comments

APAR Information

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

  PK31258

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

  UK28387

Modules/Macros

•    EYURXDEQ EYURXDMB EYU0BMTA EYU0XDIN EYU0XDRS
  

Fix information

• Fixed component name

  CICSTS V3 Z/OS

• Fixed component ID

  5655M1500

Applicable component levels

• R50M PSY UK28387

     UP07/08/24 P F708

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.