The storage areas passed to the server exit routine are valid for use only when the server exit routine is called by XCF. When the server exit returns to XCF, the client/server application must assume that the storage areas are in flux. When the server exit returns to XCF, the storage containing the SXPL and the work area storage provided by the server are subject to being updated by XCF as part of its preparations for calling the server exit to process another request.

If the server exit processes the request and invokes IXCSEND to send the response before returning to XCF, there are no concerns because the contents of the storage areas remain intact while the server exit is in control. However, if the server exit arranges for the request to be processed asynchronously by a third party, it needs to take care about using the work area that contains the text of the client message.

When the server exit returns to XCF, XCF assumes it can use the work area for the next request to be presented to the server exit. If the server exit wants the third party routine to access the work area storage for the message content, the server exit needs to update the SXPL_WAD to prevent XCF from using the storage to store the content of the message for the next request.

The exit must either obtain a new work area and update SXPL_WAD to point to it, or zero out SXPL_WAD to "take it away" from XCF. (In that case, XCF must call the server exit with a "get work area" request before it can deliver the next request.) Otherwise, there is a possibility that XCF stores a new message in the work area while the third party routine is accessing the storage, which can lead to unexpected results. Depending on the timing and the third party processing, a request might be lost, processed multiple times, or fail because of corrupted message content.

Alternatively, the server exit can copy the text of the client message to some other storage area, in which case it can leave the work area intact for XCF to use for the next request.

In cases where a response is expected, the md_RespToken field contains the response token to use when you invoke IXCSEND to send the response. Because XCF reuses the SXPL storage when it calls the server exit routine to process each request, if the server exit arranges for another work unit to process the request, the md_RespToken (as well as any other data in the SXPL that the third party needs to know) can be updated with new information. Thus, the server exit routine must take care to preserve whatever SXPL content is needed by the third party to process the request. For example, you can copy the relevant data to another storage area.