This section discusses how to pass data between the front-end and back-end transactions. The first subsection explains how to send data, the second describes how to switch from sending to receiving data, and the third explains how to receive data.
The SEND command is used to send data to the connected partner. This command is valid in allocated state (state 1) or send state (state 2). Because a successful simple SEND completes in send state (state 2), it is possible to issue a number of successive sends.
The column for send state (state 2) in the state table shows that there is more than one way of switching from send state (state 2) to receive state (state 5).
One possibility is to use a SEND INVITE command. The state table shows that after SEND INVITE the conversation switches to pendreceive state (state 3). As the column for state 3 shows, a WAIT TERMINAL command switches the conversation to receive state (state 5).
Another possibility is to specify INVITE and WAIT on the SEND command. As the state table shows, SEND INVITE WAIT switches the conversation to receive state (state 5).
The RECEIVE command is used to receive data from the connected partner. The rows in the state tables for the RECEIVE command show the EIB fields that should be tested after issuing a RECEIVE command. As well as showing which field should be tested, the state tables also shows the order in which the tests should be made. Note that you should always test for RESP values.
The transaction whose side of the conversation is in receive state cannot change to send state, but can request a change of direction by using the ISSUE SIGNAL command. This causes the SIGNAL condition to be raised in the partner transaction the next time it issues a SEND, RECEIVE, or CONVERSE command. The application is responsible for determining the purpose of the SIGNAL condition and responding appropriately.
A transaction can wait for its partner to send a signal. This is done by issuing the WAIT SIGNAL command and testing for the SIGNAL condition. The WAIT SIGNAL command suspends the transaction until its partner responds with an ISSUE SIGNAL command. This response activates the suspended transaction and raises the SIGNAL condition.
The CONVERSE command combines the functions SEND INVITE and RECEIVE. This command is useful when one transaction needs a response from the partner transaction to continue processing.
If a transaction is receiving data on a conversation and needs to notify its partner of an error, it can use the ISSUE SIGNAL command to request that the partner does a SEND INVITE. When the ISSUE SIGNAL request is received, EIBSIG is set to X'FF' and the SIGNAL condition is raised. Note that when a signal is received, the transaction is not obliged to issue SEND INVITE.
If it is important to safeguard data integrity across connected transactions, then the following synchronization commands are available:
The use of these commands in DTP is described in Syncpointing a distributed process.
[[ Contents Previous Page | Next Page Index ]]