A fix is available
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 number
PI76833
Reported component name
CICS TS Z/OS V5
Reported component ID
5655Y0400
Reported release
80M
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2017-02-17
Closed date
2017-04-10
Last modified date
2017-05-01
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.
[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSGMGV","label":"CICS Transaction Server"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"5.1","Edition":"","Line of Business":{"code":"LOB35","label":"Mainframe SW"}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"5.1","Edition":"","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
01 May 2017