XCF tries to provide a response code to indicate what happened to the request. The XCF response code is reported in the target descriptor stored in the answer area for the target (ANSAREA in the IXCRECV macro). If responses are expected (that is, EXPECTREPLY=YES is specified in the originating IXCSEND invocation), the response code is also stored in the corresponding response descriptor.

The IXCYSRVR macro defines the response code provided by XCF. See Processing a request sent by a client.

The response codes might help the sender to determine the recovery action if the target fails to respond. For example, if it can be determined that the target never received the message, it might be appropriate to resend the message. If the message is delivered to the target, the sender might need to determine whether the request was processed or not. Some requests might not be retriable.

However, note that XCF can at best indicate whether the request was presented to the target. XCF can not determine whether the request was processed correctly by the target. Even if XCF reports that the target failed while processing the request, processing of the request might have succeeded. Even if XCF reports that the request was successfully delivered to the target, processing of the request might have failed. In short, only the target can reliably indicate whether the request was successfully processed or not.

The response codes might indicate that the message was never presented to the target ("not sent", "no receiver", "not delivered"), or that the message might or might not have been presented to the target ("in progress"), or that the message was presented but not processed by the target ("refused"), or that the message was presented and possibly processed ("delivered", "failed"), or that the response sent by the target did in fact arrive ("replied"). If the response does arrive, you must check the response to determine whether the request was successful or not.

Several of the response codes have qualifiers that provide additional detail as to the specific circumstances that led to the response code. For example, a message might be "not sent" if the target system does not exist, or if the target system is not running a release of z/OS® that supports the XCF client/server interfaces, or if the sending system had resource constraints. If there is "no receiver", it might mean that no instance of the server exists on the target system, or it might mean that no suitable instance of the server exists (for example, no instance of the server supports the required features).

In order to check the response when the server reply arrives you need to look for information in the response descriptor that is provided by the responding server (usually through return/reason codes, message control data, or message content). It is your responsibility to define and implement an appropriate protocol to handle the situation.