LU 6.2 API Application Programmer's Reference Guide (30294-90008)

27
2 Conversations
An LU 6.2 application is called a transaction program (TP).
Transaction programs are written in pairs to communicate with each
other across a network. Every TP on the HP 3000 will have at least one
partner TP on a remote system that is designed to communicate with it.
The communication between two TPs is called a conversation.
Conversations take place across sessions. An APPC session is
analogous to the telephone connection that must be established before
two people can conduct a conversation across the telephone network.
Once a transaction program is running, it can allocate multiple
conversations with TPs on remote systems. Each conversation requires
one session.
On MPE XL, the APPC subsystem can support a maximum of 256
sessions at the same time. On MPE V, the maximum number of sessions
is 8. These sessions must be shared by all the TPs running on the APPC
subsystem. Therefore, on MPE XL, one TP can carry on 256
simultaneous conversations, but only if it is the only TP running.
Likewise, 256 TPs can be running simultaneously (on MPE XL), but
none of them may carry on more than one conversation. The available
sessions can be activated, deactivated, and reapportioned among the
active TPs as needed. For more information on session limits and
session management, see the APPC Subsystem on MPE XL Node
Manager’s Guide, or the APPC Subsystem on MPE V Node Manager’s
Guide.
Two types of conversations can be conducted between TPs: one-way
conversations and two-way conversations. In a one-way conversation,
data travels in only one direction, and in a two-way conversation, both
sides send and receive data.
Whether a conversation is one-way or two-way, the two sides must
remain synchronized for communication to take place. The LU 6.2
architecture allows a TP to ask its partner whether the conversation is
synchronized and whether everything is going smoothly on the remote
side. One TP sends a confirmation request, and the other TP must
respond with a confirmation response.
How confirmation is used in a conversation is up to the TP
programmers. It can be used, for example, to verify that a conversation
has been allocated properly and that the remote TP is ready to receive
data. It can also be used after data is sent, to verify that the remote TP
received everything the local TP sent. If a conversation uses
confirmation requests and responses, it is called a conversation with
confirm.
This chapter uses a phone conversation as an analogy to illustrate
one-way and two-way conversations with and without confirm.