PK10166: RTA EVENTS REMAIN OUTSTANDING AFTER REGION RECYCLES EYUPM0106E

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• RTA events remain outstanding after a MAS is recycled. The CMAS
  EYULOG contains message:
  .
  EYUPM0106E RTA Specification (specname) unsuccessfully
  released for Context(plexname) Scope(sysname)
  .
  The CMAS auxtrace contains the following exception trace
  entries indicating 2 separate tasks were attempting to discard
  the RTADEF at the same time and both tasks failed to complete
  the discard.
  .
  Trace indicates an XLST task issued exceptions with callback
  of:
  .
  MSTP,MADS,MSBU,MSBX,XLSD,XLSI,MSBB,PEDD,PRTD,PMDD,PMAT,XLST,XLOP
  .
  Method MSTP issued a CAMM for an NNMS MAL which completed
  with response KERNERROR reason MCPL_KERR_EXET due to the
  MAS shutting down. The PMAT MAL is most likely running for
  a PERIODEF which ends at 23:59 and the CMAS log indicates
  the MAS was shutdown at 23:59.
  .
  After APAR PQ57150 , the PMRD_STATUS can have a value of
  PMRD_SUSP if another task is processing the discard request.
  In this instance, the XLST task for the PERIODEF deactivation
  would have set PMRD_SUSP and the PMLT task which had callback
  stkfrm of:
  .
  PMDD,PMTR,PMCE,PMLT,XLOP
  .
  found the PMRD_STATUS set to PMRD_SUSP and issued the
  Dupe_DSC exception pointid 13 .
  .
  The assumption is that the task which set PMRD_SUSP will
  complete successfully.  In this case the XLST failed due
  to the NMMS MAL not being able to complete successfully,
  and the PMLT task for the MAS stop event did not discard
  due to the PMRD_SUSP duplicate flag.
  .
  Additional Symptom(s) Search Keyword(s): resolved unresolved
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All CICSPlex/SM V3R1M0 Users                 *
  ****************************************************************
  * PROBLEM DESCRIPTION:    If an RTADEF which requests analysis *
  *                      of Monitoring data is installed under   *
  *                      the control of a PERIODEF, and if the   *
  *                      target MAS is brought down at the same  *
  *                      time the PERIODEF caused the RTADEF to  *
  *                      be deactivated, then EVENTs may remain  *
  *                      outstanding after the MAS is restarted. *
  ****************************************************************
  * 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.     *
  ****************************************************************
     While an RTADEF is being deactivated or discarded, a flag is
  set in the RTAMRM RTADEF Descriptor to prevent another task from
  simultaneously discarding the same RTADEF.  Module EYU0PMAT
  (PMAT - RTAMRM Asynchronous Install/Discard) was invoked to
  manage the deactivation of the RTADEF under its PERIODEF.  The
  PMRD_SUSP flag was set.  When EYU0PMLT (PMLT - RTAMRM Long
  Running Task) was posted in response to the topology disconnect,
  it was unable to process the discard of the active RTADEF
  because the PMRD_SUSP flag had been set by another task.  It
  abandoned processing of the DISCARD on the assumption that the
  other running task would successfully discard the RTADEF.
     Because Monitor data collection was no longer required, the
  deactivate task invoked module EYU0MSTP (MSTP - Stop Monitor
  Data Collection), which called EYU0CAMM (CAMM - Send MAL to MAS)
  to send a Method Argument List (MAL) for NMMS (EYU0NMMS -
  Start/Stop Monitor Tasks) to stop the Monitor task running in
  the MAS.  The NMMS MAL was returned with Response=KERNERROR,
  Reason=KERR_EXET (Execution Timeout) because the MAS was being
  shut down.  This error was propagated back through the calling
  stack, with the result that one or more outstanding event noti-
  fications were not cancelled.
  

Problem conclusion

•    Because a response of KERNERROR (Kernel Error) signals an
  environmental error which prevented execution of the responding
  method, EYU0MSPT was modified to write a trace documenting the
  failure of the NMMS MAL, but to return to the calling method
  with Response=NORMAL.  This will allow the discard to complete
  normally, cancelling any outstanding event notifications, even
  if the target MAS is no longer active.
  

Temporary fix

• FIX AVAILABLE BY PTF ONLY
  

Comments

•    If an RTADEF which requests analysis of Monitoring data is
  installed under the control of a PERIODEF, and if the target MAS
  is brought down at the same time the PERIODEF caused the RTADEF
  to be deactivated, then EVENTs may remain outstanding after the
  MAS is restarted.
  
     While an RTADEF is being deactivated or discarded, a flag is
  set in the RTAMRM RTADEF Descriptor to prevent another task from
  simultaneously discarding the same RTADEF.  Module EYU0PMAT
  (PMAT - RTAMRM Asynchronous Install/Discard) was invoked to
  manage the deactivation of the RTADEF under its PERIODEF.  The
  PMRD_SUSP flag was set.  When EYU0PMLT (PMLT - RTAMRM Long
  Running Task) was posted in response to the topology disconnect,
  it was unable to process the discard of the active RTADEF
  because the PMRD_SUSP flag had been set by another task.  It
  abandoned processing of the DISCARD on the assumption that the
  other running task would successfully discard the RTADEF.
     Because Monitor data collection was no longer required, the
  deactivate task invoked module EYU0MSTP (MSTP - Stop Monitor
  Data Collection), which called EYU0CAMM (CAMM - Send MAL to MAS)
  to send a Method Argument List (MAL) for NMMS (EYU0NMMS -
  Start/Stop Monitor Tasks) to stop the Monitor task running in
  the MAS.  The NMMS MAL was returned with Response=KERNERROR,
  Reason=KERR_EXET (Execution Timeout) because the MAS was being
  shut down.  This error was propagated back through the calling
  stack, with the result that one or more outstanding event noti-
  fications were not cancelled.
  
     Because a response of KERNERROR (Kernel Error) signals an
  environmental error which prevented execution of the responding
  method, EYU0MSPT was modified to write a trace documenting the
  failure of the NMMS MAL, but to return to the calling method
  with Response=NORMAL.  This will allow the discard to complete
  normally, cancelling any outstanding event notifications, even
  if the target MAS is no longer active.
  

APAR Information

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

  PK06912

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

  UK07593

Modules/Macros

•    EYU0MSTP
  

Fix information

• Fixed component name

  CPSM CICS 3.1

• Fixed component ID

  5655M1501

Applicable component levels

• R100 PSY UK07593

     UP05/09/29 P F509

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.