In most cases, the server must provide a work area that XCF can use to store the content of a client request message before the server exit is called to process the request. If XCF does not have such a work area, or if the current work area is not large enough to hold the client message, XCF calls the server exit with a server code indicating that the server needs to provide a work area.

When called to provide a work area, the function specific parameters mapped by ixcysrvr_tGetWorkArea indicate the amount of storage that XCF requires. The server exit routine is expected to obtain the requested storage, update the SXPL_WAD field to indicate the location and size of the storage provided, and return to XCF. If the work area provided by the server is not accessible, XCF stops the server.

Note that on entry to the server exit, the SXPL_WAD field describes the work area that was last given to XCF. If there is an existing work area, the server exit most likely needs to dispose of the storage before updating the SXPL_WAD with information about a new work area.

XCF asks for a work area when it needs space to store the content of a request message. If the server exit does not provide the necessary storage, XCF cannot deliver the request. In such cases, XCF discards the request and sends an acknowledgment to the originator indicating that the request was not delivered because the server failed to provide the necessary work area.

If the server is unable to provide the necessary work area, it can also update the SXPL_RefusalCode with a non-zero value to have XCF send an acknowledgment back to the originator indicating that the server refused the request. In such cases a copy of the SXPL_RefusalCode is provided to the originator. Thus, the server has an opportunity describe the problem or influence how the originator is to proceed.

For example, if the client messages are a known fixed size and the server exit processes each request synchronously, the server exit can provide a work area when called to perform its initialization. This work area can be used again repeatedly for each client request, and the server exit is never called with a "get work area" server code.

Alternatively, a server might have some requests that can be processed synchronously by the server exit routine but might have others that need to be processed asynchronously by some other work unit. If the asynchronous processing needs to access the content of the message, the server exit needs to take care to preserve that content. The server exit might take the work area away from XCF (or provide a different one) and pass the work area along to the asynchronous work unit. Or the server exit might make a separate copy of the message for the asynchronous work unit to use and allow XCF to continue using the current work area. If both the asynchronous work unit and XCF have access to the same work area, there is a danger that XCF might store the content of the next client request in the work area and corrupt the copy of the message to be processed by the other work unit.