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.
