PK53012: CMAS TO CMAS CONNECTION LOST (CMTCMLNK STATUS PENDING)

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• In a PLEX there are two lpars currently running with two CMASes.
  Then two new lpars were added to the PLEX with 2 new CMASES.
  All four CMASes came up successfully and were able to connect.
  Then one CMAS seemed to become dormant and the other 3
  eventually  time out.  The CMAS to CMAS connection with the
  dormant CMAS was lost.  The CMTCMLNK view shows that the status
  for this connection is PENDing and you are unable to issue any
  CPSM commands.  There was an orphaned lock that was held up due
  to a timing issue.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All CICSPlex/SM V3R1M0 Users                 *
  ****************************************************************
  * PROBLEM DESCRIPTION: A CMAS may hold the CPSM communications *
  *                      network lock in EXCLUSIVE mode until it *
  *                      is terminated if an error occurs while  *
  *                      the CMAS is attempting to remove a link *
  *                      to another CMAS.                        *
  *                                                              *
  *                      Examination of the CMAS's joblog will   *
  *                      show an abend occurring in method       *
  *                      EYU0CPRL (CPRL).  Examination of the    *
  *                      CMAS's auxtrace dataset will show an    *
  *                      exception trace issued by CPRL, with a  *
  *                      trace point ID of "2" and a debug text  *
  *                      of "CPRLXCP".                           *
  *                                                              *
  *                      Various external symptoms may be        *
  *                      observed:                               *
  *                                                              *
  *                      -  Communications between the CMAS and  *
  *                         other CMASes will terminate          *
  *                         abnormally.  Automatic attempts to   *
  *                         re-establish connections will also   *
  *                         fail.                                *
  *                                                              *
  *                      -  MASes may not connect and join into  *
  *                         the network.                         *
  *                                                              *
  *                      -  EUI/API/WUI requests may hang.       *
  *                                                              *
  *                      -  Auxiliary storage shortages may      *
  *                         occur on the LPAR where the CMAS is  *
  *                         executing.                           *
  *                                                              *
  *                      -  Various dataspace storage shortage   *
  *                         related messages may be issued by    *
  *                         any CMAS or MAS running on the LPAR  *
  *                         where the CMAS is executing.         *
  *                         Possible messages are:               *
  *                                                              *
  *                           EYUXC0016S                         *
  *                           EYUXC0021S                         *
  *                           EYUXC0022S                         *
  *                           EYUXC0023S                         *
  *                           EYUXC0024S (CMAS only)             *
  ****************************************************************
  * 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 CPRL is called in a CMAS to remove a link to another CMAS,
  it must acquire the network lock.  To do this, it requests that
  method EYU0CPLK (CPLK) be started under another task to hold the
  lock.  Upon returning from this request, CPRL sets flags that
  will require it to issue a free lock request upon termination if
  an error occurs.
  
  If an abend occurs in CPRL as it returns from the CPLK request,
  it is possible that CPLK will run and acquire the lock, but the
  abend recovery routine that gets control in CPRL does not check
  for this.  Thus CPLK will not issue a free lock request upon
  termination, and the lock will be held until CMAS termination.
  

Problem conclusion

• CPRL has been updated such that in its abend recovery routine it
  checks to see if it was abended while making its CPLK request.
  If so, it will check to see if the lock has been acquired, and
  if it has, will issue a free lock request on termination.
  

Temporary fix

• FIX AVAILABLE BY PTF ONLY
  

Comments

• A CMAS may hold the CPSM communications
  network lock in EXCLUSIVE mode until it
  is terminated if an error occurs while
  the CMAS is attempting to remove a link
  to another CMAS.
  
  Examination of the CMAS's joblog will
  show an abend occurring in method
  EYU0CPRL (CPRL).  Examination of the
  CMAS's auxtrace dataset will show an
  exception trace issued by CPRL, with a
  trace point ID of "2" and a debug text
  of "CPRLXCP".
  
  Various external symptoms may be
  observed:
  
  -  Communications between the CMAS and
     other CMASes will terminate
     abnormally.  Automatic attempts to
     re-establish connections will also
     fail.
  
  -  MASes may not connect and join into
     the network.
  
  -  EUI/API/WUI requests may hang.
  
  -  Auxiliary storage shortages may
     occur on the LPAR where the CMAS is
     executing.
  
  -  Various dataspace storage shortage
     related messages may be issued by
     any CMAS or MAS running on the LPAR
     where the CMAS is executing.
     Possible messages are:
  
       EYUXC0016S
       EYUXC0021S
       EYUXC0022S
       EYUXC0023S
       EYUXC0024S (CMAS only)
  
  
  When CPRL is called in a CMAS to remove a link to another CMAS,
  it must acquire the network lock.  To do this, it requests that
  method EYU0CPLK (CPLK) be started under another task to hold the
  lock.  Upon returning from this request, CPRL sets flags that
  will require it to issue a free lock request upon termination if
  an error occurs.
  
  If an abend occurs in CPRL as it returns from the CPLK request,
  it is possible that CPLK will run and acquire the lock, but the
  abend recovery routine that gets control in CPRL does not check
  for this.  Thus CPLK will not issue a free lock request upon
  termination, and the lock will be held until CMAS termination.
  
  
  CPRL has been updated such that in its abend recovery routine it
  checks to see if it was abended while making its CPLK request.
  If so, it will check to see if the lock has been acquired, and
  if it has, will issue a free lock request on termination.
  

APAR Information

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

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

  PK53053 UK29616

Modules/Macros

•    EYU0CPRL
  

Fix information

• Fixed component name

  CPSM CICS 3.1

• Fixed component ID

  5655M1501

Applicable component levels

• R100 PSY UK29616

     UP07/09/27 P F709

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.