PH37812: CICSPLEX SM SERVICEABILITY LOCKING DIAGNOSTICS

APAR status

• Closed as program error.

Error description

• When CPSM method XLNE calls method XQAQ, but the queue lock
  is not available, the XQAQ operation will fail, and the
  documentation captured is often insufficient to determine
  why the lock was not available.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All CICSPlex SM users.                       *
  ****************************************************************
  * PROBLEM DESCRIPTION: When CPSM method XLNE calls method      *
  *                      XQAQ, but the queue lock is not         *
  *                      available, the XQAQ operation will      *
  *                      fail, and the documentation captured    *
  *                      is often insufficient to determine      *
  *                      why the lock was not available.         *
  ****************************************************************
  * RECOMMENDATION: After applying the PTF which resolves        *
  *                 PH37812, all CMASs should be restarted       *
  *                 to activate the fix. These restarts can      *
  *                 be performed independently of one another.   *
  ****************************************************************
  CICSPlex SM uses a notification system for internal events.
  Events are appended to a queue by method XLNE (EYU0XLNE),
  and the queue is monitored by the XLNX task executing in a CMAS.
  Events can be broadcast from one CMAS to another through CMAS
  to CMAS communications. When this happens, XLNE will typically
  run under the CMAS to CMAS receive link task (TRANID LNMI, for
  MRO connections, or LNCI, for LU6.2 connections).
  In cases where the queue lock on the XLNX queue is not
  available, this can cause the LNMI/LNCI task to wait. This
  means that the CMAS will be unable to receive any further
  messages over that receive task until the wait has terminated.
  Usually the queue lock becomes available very quickly and the
  CMAS to CMAS communications link returns to normal operations,
  but in cases where the queue lock remains unavailable, the
  CMAS to CMAS communications tasks for that link will
  eventually be purged to allow a new link to be established.
  When this occurs, there is typically insufficient information
  available to determine why the queue lock was not available.
  
  The purge of the receive task will be reported through the
  CMAS log as follows:
  +EYUXL0033I cmas Attempting to PURGE TRANID(LNMI),
              TASKID(ttttt), METHOD(XSWX), CALLER(XSRA)
  +EYUXL0905E cmas AEXY IN XSWX, OFFSET ????????
              PSW=00000000 00000000 LEVEL=JCInnnM PFX=EYU
  +EYUXL0905E INTC=0000 ILC=0 TXCP=00000000 SCODE=S????
              TRAN=LNMI TASK=ttttttt
  +EYUXL0905E Methods=XSWX,XSRA,XQAQ,XLNE,CTEX,CTSK,CTRD,CLMU,
  +EYUXL0905E Methods=CLMT,XLOP
  

Problem conclusion

• Method XLNE (EYU0XLNE) has been updated so that the existing
  exception trace entry, emitted when method XLNE is purged
  after having been unable to obtain the queue lock, will also
  cause a system dump to be captured.
  This is achieved through the ESDUMP mechanism, so the number
  of such dumps captured is subject to the ESDUMP and ESDUMPLIMIT
  parameters specified through the CMAS EYUPARM data set.
  

Temporary fix

Comments

APAR Information

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

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

  UI80548 UI80549 UI80550

Modules/Macros

• EYU0XLNE
  

Fix information

• Fixed component name

  CICS TS Z/OS V5

• Fixed component ID

  5655Y0400

Applicable component levels