In the synchronous model, the client remains blocked at the server request call until a reply is eventually received from the server.
…
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.
cout << "Link returned with \""
<< pECI-> exCodeText() << "\"" << endl;
cout << "Reply from CICS server: "
<< (char*)comma1.dataArea() << endl;
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.