z/OS MVS Programming: Sysplex Services Guide
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Overview of XCF client/server processing

z/OS MVS Programming: Sysplex Services Guide
SA23-1400-00

Servers and their clients are expected to perform the following actions:
  • Servers must register with XCF and provide an exit routine for XCF to call and process client requests.
  • Clients must initiate requests and gather results.
  • Servers are generally expected to reply to client requests.
A set of XCF macros allows you to perform the following actions:
  • "Instantiate" or start the server to process client requests. To define server properties you use the IXCSRVR macro. You can define one or more servers to receive requests from clients and send responses. See Defining and starting a server.
  • Allow clients to send requests to servers as well as allow servers to send responses to clients. To send a request or response, you use the IXCSEND macro. See Using the IXCSEND macro.
  • Allow programs to obtain the state of messages sent through IXCSEND and also receive responses to requests sent by servers. To obtain message information or responses from a server, you use the IXCRECV macro. See Using the IXCRECV macro.
  • Initiate® server requests to the XCF Server. XCF has its own server, the XCF Server, which processes client requests that are formatted with the IXCREQ macro. See Using the XCF Server and Using the IXCREQ macro.

The IXCYSRVR mapping macro defines mappings and constants to be used when writing client/server applications.

Figure 1 summarizes the processing for a basic client/server communication in the sysplex using the services of XCF.
Figure 1. Overview of client/server processing in the sysplex

The following steps summarize the processing in the figure:

  1. Client issues IXCSEND macro to send request R to server S, providing parameters P. The macro returns a token T that the client later can use to retrieve the results provided by the server. The request R can be at most 100 MB. The target server is identified by its name and the name of the system on which it resides. You can define one or more instances of the same server on each system in the sysplex.
  2. XCF builds control blocks to manage the request and invokes IXCMSGOX to send the request and its parameters to one or more systems on which the server resides.
  3. XCF on the target system intercepts the signal. If the target server does not exist, the message is discarded and acknowledged by XCF with a "no receiver" response". If the server does exist, XCF invokes the message control service (IXCMSGC) to save the message and queues a work item for the server. As needed, a server is selected and resumed.
  4. When the server is resumed, the XCF server exit stub makes suitable preparations for processing the work item, including doing IXCMSGIX to extract the client parameters from the saved message. XCF calls the server exit routine to present the request to the server. The server exit routine inspects R to determine which type of request is to be processed. The server exit can process the request directly or it can arrange for it to be processed asynchronously. It needs to retain the token T that represents the client request for later use when sending the results of the request back to the originating client. Note that the token given to the client and the token given to the server represent the same logical request, but the tokens themselves do not have the same content.
  5. After the server exit or its agent processes the request, the IXCSEND macro is invoked to send the results D back to the originating client. The token T identifies the client request to which the results belong. The results D can be at most 100 MB. XCF decodes the token T to determine where the results are to be sent.
  6. XCF invokes IXCMSGOX to send the results to the originating system. If the message exceeds 60KB, XCF might suspend the responding thread until the IXCMSGOX service finishes sending the message.
  7. XCF on the client system intercepts the server response. XCF locates the control blocks used to manage the original client request. If they are not found, the client request has timed out, and the server response is discarded. Otherwise XCF binds the response message to the client request and holds it until the results are gathered by the client, or the client request times out. If the client is waiting for the results, XCF notifies (that is, resumes) the client.
  8. The client issues an IXCRECV request to gather the results of the request identified by token T (which was returned in step 1 when the request was initiated). The client provides an answer area A to contain metadata that describes the response. The data area D contains the response data sent by the server. In the event that the response has not yet arrived when the client attempts to gather it, the IXCRECV service suspends the client thread until the requested result becomes available. Alternatively, the client can avoid being suspended by using RECEIVE=STATUS to poll for message completion.
  9. To process the IXCRECV request, XCF locates the control blocks being used to manage the request identified by token T. If not found, the request has timed out (or was cancelled) and no results are available. If the request is found, XCF determines whether the response has arrived. If it has not arrived, XCF either suspends the client thread or returns to it with the message status. If suspended, XCF resumes the thread when the results arrive, or when the request times out, or when the request is cancelled, whichever comes first. Assuming the results have arrived, XCF determines whether the answer area and data area provided by the caller are large enough. If not, XCF returns to the client indicating the required size to receive the results. If the output areas are large enough, XCF fills them with the appropriate data, discards the control blocks used to manage the request, and returns to the client.
  10. Client inspects the metadata, the response data, or both, and processes the results of the request. Metadata includes a "response code" to describe the status of the request. For example, the response code might indicate that the request was processed by the server or it might indicate that the server failed. For more details on response code see Response codes and the target receiver.

For reference information about the IXCSRVR, IXCSEND, IXCRECV, and IXCREQ macros, see z/OS MVS Programming: Sysplex Services Reference.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014