Retrieving replies from asynchronous requests

In the asynchronous model, the Client application issues a server request call and then continues immediately with the next statement without waiting for a reply. As soon as the reply is received from the server it is immediately passed to the reply handler of the flow object controlling the interaction; in parallel with whatever else the client happens to be doing.

The example in Figure 1 calls a server program using parameters supplied on the command line. It subclasses the ECI class to handle exceptions and subclasses the flow class to handle the reply from the server.

Here is a simple subclass of the flow class with a reply handler implementation which just prints the reply received:
class MyCclFlow : public CclFlow {
public:
       MyCclFlow( Ccl::Sync sync ) : CclFlow( sync ) {}
  void handleReply( CclBuf* pcomm ){
    cout << "Reply from CICS server: "
               << (char*)pcomm-> dataArea() << endl;
    }
  };

A subclassed ECI object is constructed; then a connection object using the supplied server name, password and user ID. A buffer object is constructed using text from the command line and an asynchronous subclassed flow object.

The link call requests execution of the ECIWTO sample program on the server and passes text to it in the buffer object. Processing then continues with the statement following the link call:
Figure 1. Asynchronous request to call a server program
  …
MyCclECI myeci;
CclConn server1( argv[1],argv[2],argv[3] );
CclBuf  comma1( argv[4] );
MyCclFlow asflow( Ccl::async );
server1.link( asflow,"ECIWTO",&comma1 );
  …
In the example, there is nothing else for the main Client application to do, so to avoid premature termination, it is made to wait for user input:
cout << "Server call in progress. Enter q to quit…" << endl;
char input;
cin >> input;

Meanwhile, when the reply does come back from the server, the reply handler is called and, assuming there are no exceptions, prints the returned communication area. Note that in the asynchronous model, the buffer object to hold the returned communication area is allocated internally within the flow object, and is deleted after the reply handler has run. The buffer object supplied on the original link call is not used for the reply, and can be deleted as soon as the link call returns.

If you call the program in Figure 1 like this:
    ecicpo2 DEVTSERV sysad sysad "Hello World"
the following output is expected on successful completion:
Server call in progress. Enter q to quit…
Reply from CICS server: Hello World
q
If the Client application decides at some point that it really can do no more until a reply is received from the server, it can use the wait method on the appropriate flow object. This effectively makes the interaction synchronous, blocking the client:
asflow.wait();