PI76833: CPSM API ASYNCREQ_RESPONSE MAY BE INVALID IF ASYNCRONOUS API REQUEST FAILS.

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• ERROR DESCRIPTION:
  When a CPSM API command that is issued with the NOWAIT operand
  fails, the ASYNCREQ_RESPONSE returned to the RECEIVE command for
  the request may indicate OK instead of FAILED.
  
  This API commands affected by this are:
  
  -  EXEC CPSM PERFORM OBJECT
  -  EXEC CPSM PERFORM SET
  -  EXEC CPSM REFRESH
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All CICSPlex SM V5R1M0, V5R2M0 and V5R3M0    *
  *                 Users                                        *
  ****************************************************************
  * PROBLEM DESCRIPTION: When a CPSM API command that is issued  *
  *                      with the NOWAIT operand fails, the      *
  *                      ASYNCREQ_RESPONSE returned to the       *
  *                      RECEIVE command for the request may     *
  *                      indicate OK instead of an error.        *
  *                                                              *
  *                      The API commands affected by this are:  *
  *                                                              *
  *                      -  EXEC CPSM GET                        *
  *                      -  EXEC CPSM PERFORM OBJECT             *
  *                      -  EXEC CPSM PERFORM SET                *
  *                      -  EXEC CPSM REFRESH                    *
  *                      -  EXEC CPSM SET                        *
  ****************************************************************
  * 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.                               *
  ****************************************************************
  All CPSM API commands allow the command to be issued
  synchronously.  That is, the caller does not receive control
  back until the command completes.  In this case, the RESPONSE
  and REASON returned to the caller is the result of the request.
  
  Some CPSM API commands allow NOWAIT to be specified on the
  command, resulting in the command being executed asynchronously.
  That is, the caller receives control back when the command is
  accepted, and receives a RESPONSE of SCHEDULED.  To determine
  the results of the command, the caller must issue a EXEC CPSM
  RECEIVE command to retrieve the ASYNCREQ resource table record
  for the request, which includes the RESPONSE and REASON of the
  results of the request.  The commands that allow asynchronous
  processing are:
  
  -  EXEC CPSM GET
  -  EXEC CPSM PERFORM OBJECT
  -  EXEC CPSM PERFORM SET
  -  EXEC CPSM REFRESH
  -  EXEC CPSM SET
  
  When a CPSM API program issues an EXEC CPSM command, a command
  descriptor (EYUBADCM) is delivered to method EYU0XDNR (XDNR) in
  the CMAS to which the program is connected.  XDNR, which runs
  under transaction XDNR, is the API command router.  It
  determines from the EYUBADCM what command was issued and whether
  NOWAIT was specified.  It builds a parameter list to call the
  controlling method for the command.  If the command specified
  NOWAIT, XDNR returns a RESPONSE of SCHEDULED to the API program
  and adds to the parameter list the address of a FEEDBACK area.
  Then regardless of whether NOWAIT was specified, XDNR calls the
  controlling method and waits for it to complete.
  
  The controlling method calls method EYU0MOMB (MOMB) to build a
  parameter list for the method that will process the command.  It
  then calls method EYU0MOMS (MOMS) to call the CPSM single system
  image (SSI) processing to drive the command processor in the
  appropriate CMASes and/or MASes.  When the SSI returns control
  to MOMS, MOMS calls method EYU0MOFB (MOFB) to update the
  FEEDBACK area with the results of the processing method's
  execution.  MOFB then returns control to MOMS, which returns
  control to the controlling method, which sets the appropriate
  RESPONSE and REASON in the EYUBADCM, and returns to XDNR.
  
  XDNR determines if the command specified NOWAIT:
  
  -  If NOWAIT was not specified, XDNR returns the EYUBADCM
     RESPONSE and REASON to the API program.
  
  -  If NOWAIT was specified, XDNR checks the RESPONSE in the
     FEEDBACK area it passed to the controlling method.  If it is
     null, and it could be if a failure occurs in MOMB when
     building the parameter list for the command processor, then
     XDNR sets both the FEEDBACK RESPONSE and REASON from the
     EYUBADCM, which is properly set if MOMB fails.  It then sets
     the ASYNCREQ RESPONSE and REASON from the FEEDBACK RESPONSE
     and REASON.  The API program retrieves the ASYNCREQ record by
     issuing a RECEIVE command.
  
  Two problems have been identified with NOWAIT processing:
  
  -  When MOFB is called, it presets the FEEDBACK RESPONSE to OK,
     and then interrogates the parameter list for the command
     processor.  In most cases it will then set the RESPONSE and
     REASON properly.  However, if the command processor had a
     severe error, for example if it abended, then MOFB leaves the
     FEEDBACK RESPONSE as OK, and returns a failure to MOMS, which
     propagates the failure to the controlling method, which sets
     the RESPONSE/REASON in the EYUBADCM to FAILED/EXCEPTION.
     Since the FEEDBACK RESPONSE is not null in this situation,
     XDNR will use that RESPONSE of OK instead of the EYUBADCM
     RESPONSE/REASON of FAILED/EXCEPTION when building the
     ASYNCREQ record.
  
  -  When XDNR completes processing for a command, it does not
     terminate.  Instead, it sets a timer for 10 seconds, and goes
     into a wait, either for the timer to expire at which point it
     will terminate, or to posted to process another command.  If
     it is posted to process another command, it does not clear
     the FEEDBACK area from the previous command.  If MOMB fails
     while building the command processor parameter list, then
     XDNR will use the RESPONSE/REASON from the previous command
     that was issued instead of the RESPONSE/REASON in the
     EYUBADCM for the current command.
  

Problem conclusion

• To resolve these problems, the following changes have been made:
  
  -  MOFB has been updated to set the FEEDBACK RESPONSE/REASON to
     FAILED/EXCEPTION if a severe error occurs in the command
     processor.
  
  -  XDNR has been updated to clear the FEEDBACK area prior to
     calling the controlling method.
  

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:

  UI46310 UI46311 UI46315

Modules/Macros

• EYU0MOFB EYU0XDNR
  

Fix information

• Fixed component name

  CICS TS Z/OS V5

• Fixed component ID

  5655Y0400

Applicable component levels

• R00M PSY UI46315

     UP17/04/21 P F704

• R80M PSY UI46310

     UP17/04/21 P F704

• R90M PSY UI46311

     UP17/04/21 P F704

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.