This section discusses how a program can exercise control over the data flow direction:
Figure 12 is a variation on the function provided by the flow shown in "Example 2: Data Flow in Both Directions". When the data flow direction changes, Program A can continue processing instead of waiting for data to arrive on this half-duplex conversation.
The steps shown in Figure 12 are:
| Step | Description |
|---|---|
| (1) through (6) |
The program begins the same as "Example 1: Data Flow in One Direction".
Program A establishes the conversation
and makes the initial transmission of data.
|
| (7) through (10) |
Program A makes use of an advanced-function call,
Prepare_To_Receive, (described in Prepare_To_Receive (CMPTR)), which
sends an indication to Program C
that Program A is ready to receive data.
This call also
flushes the data buffer and places Program A's
end of the conversation
into Receive state.
It does not, as did the Receive call when used
with the initial conversation characteristics in effect, force
Program A to pause and wait for data from Program C to arrive.
Program A continues processing while data is sent to Program C.
|
| (11) through (13) |
Program C, started by System Y's reception of the conversation
startup request and buffered data, makes the
Accept_Conversation and Receive calls.
Program A finishes its processing and issues its own Receive call.
It will now wait until data is received (Step (15)).
|
| (14) through (16) |
The status_received
on the Receive call made by Program C, which is
set to CM_SEND_RECEIVED, tells Program C that the
conversation is in Send state.
Program C can now issue the Send_Data call.
Program A receives the data. Note: There is a way for Program A to check periodically to see if the data has arrived, without waiting. After issuing the Prepare_To_Receive call, Program A can use the Set_Receive_Type call to set the receive_type conversation characteristic equal to CM_RECEIVE_IMMEDIATE. This call changes the nature of all subsequent Receive calls issued by Program A (until a further call to Set_Receive_Type is made). If a Receive is issued with the receive_type set to CM_RECEIVE_IMMEDIATE, the program retains control of processing without waiting. It receives data back if data is present, and a return_code of CM_UNSUCCESSFUL if no data has arrived.
This method of receiving data is not
shown in Figure 12.
For further discussion of this alternate flow, see
Set_Receive_Type (CMSRT) and Receive (CMRCV).
|
Figure 12. The Sending Program Changes the Data Flow Direction
System X System Y
*-------------------------------* *-------------------------------*
| *-------* *--------------* | | *--------------* *-------* |
| |Program| | CPI | *---------------------------* | CPI | |Program| |
| | A | |Communications| | | |Communications| | C | |
| *.------* *-------------.* | | *.-------------* *------.* |
*--.-------------------------.--* *--.-------------------------.--*
. . . .
Initialize_Conversation (sym_dest_name) . .
(1) .*----------------------->. . .
conversation_ID, return_code=CM_OK . .
(2) .<-----------------------*. Logical connection setup, . .
. . if logical connection . .
.Allocate(conversation_ID). not already available . .
(3) .*----------------------->.<------------------------------->. .
. return_code=CM_OK . . .
(4) .<-----------------------*. . .
. . . .
.Send_Data(conversation_ID, data) . .
(5) .*----------------------->. . .
. return_code=CM_OK . . .
(6) .<-----------------------*. permission to send, . .
. . conversation startup request, . .
Prepare_To_Receive(conversation_ID) all buffered data . .
(7) .------------------------>.*------------------------------->. .
. return_code=CM_OK . . .
(8) .<------------------------. . .
. . . .
(9) . (Program A continues . .(Program C is started by .
. to process while . . node services) .
. data is sent to . . .
(10). Program C) . . .
. . . .
. . . Accept_Conversation .
(11). . .<-----------------------*.
. . conversation_ID, return_code=CM_OK
(12). . .*----------------------->.
. . . .
. Receive(conversation_ID). . Receive(conversation_ID).
(13).*----------------------->. .<-----------------------*.
. . . data, .
. . status_received=CM_SEND_RECEIVED
(14). . .*----------------------->.
. . . .
. data, return_code=CM_OK . data Send_Data(conversation_ID, data)
(15).<------------------------.<--------------------------------.<-----------------------*.
. . . return_code=CM_OK .
(16). . .*----------------------->.
. . . .
. (further processing by both programs) .
. . . .
Figure 13 shows how a program on the receiving side of a half-duplex conversation can request a change in the direction of data flow with the Request_To_Send call. (See Request_To_Send (CMRTS) for more information.) In this example, Programs A and C have already established a conversation using the default conversation characteristics.
The steps shown in Figure 13 are:
| Step | Description |
|---|---|
| (1) and (2) | Program A is sending data and Program C is receiving the data. |
| (3) and (4) | Program C issues a Request_To_Send call in order to begin sending data. Program A will be notified of this request on the return value of the next call issued by Program A (Send_Data in this case, Step (6)). |
| (5) and (6) | Program A issues a Send_Data request, and the call returns with control_information_received set equal to CM_REQ_TO_SEND_RECEIVED. |
| (7) and (8) | In reply to the Request_To_Send,
Program A issues a Prepare_To_Receive call,
which allows Program A to continue its own processing
and passes permission to send to Program C.
The call also forces the buffer at System X to be flushed.
It leaves the conversation
in Receive
state for Program A.
Note: Program A does not have to reply to the Request_To_Send call immediately (as it does in this example). See "Example 3: The Sending Program Changes the Data Flow Direction" for other possible responses. Program C continues with normal processing by issuing a Receive call and receives Program A's acceptance of the Request_To_Send on the status_received parameter, which is set to CM_SEND_RECEIVED. The conversation is now in Send state for Program C. |
| (9) and (10) | Program C can now transmit data. Because Program C has only one instance of data to transmit, it first changes the send_type conversation characteristic by issuing Set_Send_Type. Setting send_type to a value of CM_SEND_AND_PREP_TO_RECEIVE means that Program C's end of the conversation will return to Receive state after Program C issues a Send_Data call. It also forces a flushing of the system's data buffer. |
| (11) | Program C issues the Send_Data call and
its end of the conversation
is placed in Receive state.
The data and permission-to-send indication
are transmitted from System Y to System
X.
Program A, meanwhile, has finished its own processing and issued a Receive call (which is perfectly timed, in this diagram). |
| (12) | Program A receives the data requested and, because of the value of the status_received parameter (which is set to CM_SEND_RECEIVED), knows that the conversation has been returned to Send state. |
| (13) and (14) | The original processing flow continues: Program A issues a Send_Data call and Program C issues a Receive call. |
Figure 13. Changing the Data Flow Direction
System X System Y
*-------------------------------* *-------------------------------*
| *-------* *--------------* | | *--------------* *-------* |
| |Program| | CPI | *---------------------------* | CPI | |Program| |
| | A | |Communications| | | |Communications| | C | |
| *.------* *-------------.* | | *.-------------* *------.* |
*--.-------------------------.--* *--.-------------------------.--*
. . . .
. . Programs A and C are in . .
. . conversation . .
. . . .
.Send_Data(conversation_ID, data) data . Receive(conversation_ID).
(1) .*----------------------->.-------------------------------->.<-----------------------*.
. return_code=CM_OK . . data, return_code=CM_OK .
(2) .<-----------------------*. .------------------------>.
. . request for permission . .
. . to send Request_To_Send(conversation_ID)
(3) . .<--------------------------------.<-----------------------*.
. . . return_code=CM_OK .
(4) . . .------------------------>.
. . . .
.Send_Data(conversation_ID, data) data . Receive(conversation_ID).
(5) .*----------------------->.-------------------------------->.<-----------------------*.
. return_code=CM_OK, . . .
control_information_received=CM_REQUEST_TO_SEND_RECEIVED . data, return_code=CM_OK .
(6) .<------------------------. .------------------------>.
. . permission to send, . .
Prepare_To_Receive(conversation_ID) data . Receive(conversation_ID).
(7) .*----------------------->.-------------------------------->.<-----------------------*.
. . .data, return_code=CM_OK, .
. return_code=CM_OK . status_received=CM_SEND_RECEIVED
(8) .<------------------------. .------------------------>.
. (Program A continues . . .
. local processing) . Set_Send_Type(conversation_ID,
. . send_type=CM_SEND_AND_PREP_TO_RECEIVE)
(9) . . .<-----------------------*.
. . . return_code=CM_OK .
(10). . .*----------------------->.
. . permission to send, . .
. Receive(conversation_ID). data Send_Data(conversation_ID, data)
(11).*----------------------->.<--------------------------------.<-----------------------*.
.data, return_code=CM_OK, . . .
. status_received=CM_SEND_RECEIVED . return_code=CM_OK .
(12).<-----------------------*. .------------------------>.
. . . .
.Send_Data(conversation_ID, data) data . Receive(conversation_ID).
(13).*----------------------->.-------------------------------->.<-----------------------*.
. return_code=CM_OK . . data, return_code=CM_OK .
(14).<-----------------------*. .------------------------>.
. . . .
. (further processing by both programs) .
. . . .