Retrieving replies from synchronous requests

In the synchronous model, the client remains blocked at the server request call until a reply is eventually received from the server.

The example at Figure 1 calls a server program using parameters supplied on the command line. It does no subclassing to handle exceptions or to handle the reply from the server.
Figure 1. Synchronous request to call a server program
  …
CclECI* pECI = CclECI::instance();
CclConn server1( argv[1],argv[2],argv[3] );
CclBuf  comma1( argv[4] );
CclFlow sflow( Ccl::sync );
server1.link( sflow,"ECIWTO",&comma1 );

The Client application gains access to the ECI object and constructs a connection object using the supplied server name, password and user ID. Then a buffer object is constructed using text from the command line and a synchronous flow object is created.

The link call requests execution of the CICS® ECIWTO sample program on the server and passes text to it in the buffer. Processing is then blocked until a reply is received from the server. ECIWTO just writes the communication area to the operator console on the server and returns it, unchanged, to the client.

After the reply is received, the Client application reports the most recent exception code and prints the returned communication area:
cout << "Link returned with \""
           << pECI-> exCodeText() << "\"" << endl;
cout << "Reply from CICS server: "
           << (char*)comma1.dataArea() << endl;
If you call the program in Figure 1 like this:
    ECICPO1 DEVTSERV sysad sysad "Hello World"
the following output is expected on successful completion:
Link returned with "no error"
Reply from CICS server: Hello World

If the flow object controlling the interaction is an instance of a subclass which has implemented a reply handler, this is called and executed before processing continues with the statement following the original server request call. For example, the flow subclass defined in the asynchronous example which follows could have been used.