PM02263: CPSM API REQUEST HANGS INDEFINITELY IN XDE3XSWX

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• An API task appears to hang indefitely in an XDE3XSWX wait.  Its
  task stkfrm is as follows:
  .
  Task Meth Load-Pt  OPB      OSSB     Stack    Mal      MODB
  6210 XLAP 000B0328 37F385E8 37F38768 37F38790 00000000 39120000
  6210 XDER 39200118 37F385E8 37F38768 37F388D8 37F384B8 39125500
  6210 XDE0 392654A0 37F385E8 37F38768 37F38E08 37F38C90 39125500
  6210 XDE3 39255A00 37F385E8 37F38768 37F39168 37F38FB8 39125500
  6210 XSWX 37AE2050 37F385E8 37F38768 37F39568 37F39538 39123300
  .
  Reviewing the MAL for this task we find the ALET is in CICS
  storage and the CMD Descriptor is for a CONNECT API request.
  The command is failing with a RESPONSE 407 (NOTPERMIT) and
  REASON 541 (USRID).  Further review of the trace shows a MASPOST
  entry that showed XDNP failed.  It appears we were unable to get
  the EBLK address successfully.
  .
  This problem is due to the CONNECT failures that are occurring
  which result in the origin block getting freed prematurely.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All CICSPlex SM V4R1M0 Users                 *
  ****************************************************************
  * PROBLEM DESCRIPTION: If a API program that originates in a   *
  *                      MAS fails to connect, the task under    *
  *                      which the program is running may hang   *
  *                      until it is purged or the MAS is        *
  *                      shutdown.  The hang will be in method   *
  *                      EYU0XSWX (XSWX), as called from method  *
  *                      EYU0XDE3 (XDE3).  The complete call     *
  *                      back method trace will be as follows:   *
  *                                                              *
  *                        XSWX,XDE3,XDE0,XDER,XLAP              *
  *                                                              *
  *                      The failure to connect will be          *
  *                      indicated by message EYUXD0808W in the  *
  *                      EYULOG of the CMAS to which the MAS     *
  *                      connects.  The message will be similar  *
  *                      to the following:                       *
  *                                                              *
  *                        EYUXD0808W  API User(<userid>) has    *
  *                                    failed to signon from     *
  *                                    MASname(<masname>)        *
  *                                    CICSplex(<plexname>).     *
  ****************************************************************
  * 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 an API connect attempt fails, the CONNECT method EYU0XDF1
  (XDF1) calls the DISCONNECT method EYU0XDF2 (XDF2) to ensure
  that cleanup is performed.  As part of normal processing, XDF2
  frees the origin block (EYUBXDOB) for the request if the
  request originated in a MAS.  In this situation, however, XDF1's
  caller, method EYU0XDNR (XDNR), requires access to the EYUBXDOB
  in order to inform the waiting task in the MAS that its connect
  request failed.  Since XDF2 does not clear the EYUBXDOB before
  freeing it, if the storage associated with the freed EYUBXDOB
  has not been reused, then XDNR can use the residual data to
  inform the MAS.  However, if the storage has been reused, for
  example by another connect request EYUBXDOB, then XDNR may
  request notification for an incorrect user.  When this occurs,
  the MAS task will not be informed properly, and will hang until
  it is purged or the MAS is terminated.  Additionally, exception
  traces may be issued in both the CMAS and MAS:
  
  -  in the CMAS, XDNR may issue an exception trace with a debug
     text of "MASPOST" and a trace point ID of 24.
  
  -  in the MAS, method EYU0XDNP (XDNP) may issue an exception
     trace with a debug text of "XDNPEBLK" and a trace point ID of
     6 or 7.  Note that this exception trace will not be sent to
     the CMAS's auxtrace dataset.
  

Problem conclusion

• XDF2 has been updated to not free the EYUBXDOB when called from
  XDF1 to clean up a failed connection attempt.  The block will be
  freed when XDNR has completed using it.
  

Temporary fix

• FIX AVAILABLE BY PTF ONLY
  

Comments

APAR Information

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

  PM02315

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

  UK52433

Modules/Macros

• EYU0XDF2
  

Fix information

• Fixed component name

  CICS TS Z/OS V4

• Fixed component ID

  5655S9700

Applicable component levels

• R60M PSY UK52433

     UP09/12/05 P F912

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.