PH27752: CPSM API PROGRAM RECEIVES NODATA ON A RECEIVE WITH DELAY WITHOUT WAITING THE SPECIFIED TIME

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• You have an application program which issues a CPSM API call, a
  GET OBJECT for example, and it specifies the NOWAIT option,
  making this an asynchronous process.
  
  It then issues an EXEC
  CPSM RECEIVE call, with the DELAY option to specify how long it
  wants to wait for the data to come back. The RECEIVE call comes
  back immediately without waiting the time specified by the
  DELAY parm
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All CICSPlex SM users.                       *
  ****************************************************************
  * PROBLEM DESCRIPTION: A EXEC CPSM RECEIVE call with the DELAY *
  *                      option, running in a z/OS batch         *
  *                      (non-CICS) environment,  may            *
  *                      incorrectly receive a NODATA response   *
  *                      without waiting for the specified delay *
  *                      time. This occurs after previously      *
  *                      making a CPSM API call, such as GET     *
  *                      OBJECT, with the NOWAIT option.         *
  ****************************************************************
  During the processing of an API call with NOWAIT option, once
  the the CMAS has completed processing the request, the CMAS
  processing puts the ASYNCREQ response to the output queue, after
  which the ECB for the ASYNCREQ is posted.
  
  However, in specific timing windows, the application performing
  the requests may issue the RECEIVE api call in the window
  between the CMAS completing the request and posting the ECB. In
  this case the RECEIVE processing may remove the ASYNCREQ data
  from the output queue prior to the ECB being posted. The problem
  occurs when an application issues more than one GET with NOWAIT
  and RECEIVE pair. The first RECEIVE may retrieve the ASYNCREQ
  from the output queue, and complete successfully, returning the
  ASYNCREQ. If this is done before the CMAS can post the ECB, and
  EYU0ABAG clears the ECB field, the subsequent RECEIVE call will
  find that the ECB has already been posted, due to it being
  posted later by the CMAS. In this case, as the ECB has been
  posted, but no ASYNCREQ is available on the output queue, the
  subsequent RECEIVE call will not complete successfully,
  returning NODATA.
  
  Additional Keywords: ABTD_ASYNCH_ECB
  

Problem conclusion

• EXEC CPSM RECEIVE api processing has been altered to ensure the
  status of the ASYNCREQ ECB prior to reading the queue. This will
  ensure the ECB has been posted prior to reading the output queue
  to ensure the response data is correctly returned to the caller,
  and the DELAY option is upheld.
  

Temporary fix

Comments

• ×**** PE20/12/16 FIX IN ERROR. SEE APAR PH32746  FOR DESCRIPTION
  

APAR Information

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

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

  UI71962 UI71963

Modules/Macros

• EYU0ABAG EYU0ABM0
  

Fix information

• Fixed component name

  CICS TS Z/OS V5

• Fixed component ID

  5655Y0400

Applicable component levels

• R20M PSY UI71963

     UP20/10/10 P F010

• R30M PSY UI71962

     UP20/10/10 P F010

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.