HP-UX SNAplus2 R7 APPC Programmer's Guide

Writing Transaction Programs
Starting TPs
2.9.3 Invoked TPs: User-Started
If an invoked TP is configured to be started by a user, the user can start the invoked TP either before or after the
invoking TP. A TP started in this manner is called a queued, operator-started TP:
• If the user starts the invoking TP first, and does not start the invoked TP before the timeout value for starting
the TP (see Section 2.9.6,
Timeout Values for Invoked TPs) is reached, the incoming Allocate fails.
• If the user starts the invoked TP before the invoking TP issues the [MC_]ALLOCATE verb, the invoked TP
waits until the Attach from the invoking TP arrives, or until the RECEIVE_ALLOCATE timeout value (see
Section 2.9.6, Timeout Values for Invoked TPs) is reached.
2.9.4 Invoked TPs: Automatically Started by the SNAplus2 Attach
Manager
An invoked TP can be configured to start automatically under one of the following conditions:
• The first time an Attach (the SNA message from the remote LU containing the allocation request) is received
by the LU that serves the invoked TP. A TP started in this manner is called a queued, automatically started TP.
If the invoked TP is not running, the first incoming Allocate starts it; a response to the incoming Allocate is
held until the RECEIVE_ALLOCATE verb in the invoked TP is executed (or until a timeout occurs; see Section
2.9.6, Timeout Values for Invoked TPs). At that time, APPC assigns a conversation ID, which is returned to both
TPs as an identifier for the conversation.
If the invoked TP is already running, the Attach is queued until the invoked TP issues another RE-
CEIVE_ALLOCATE verb, or until it finishes running and can be restarted (or until a timeout occurs; see
Section 2.9.6, Timeout Values for Invoked TPs).
• Each time an Attach is received by the LU that serves the invoked TP. A new instance of the program is loaded
and started with each incoming Attach. A TP started in this manner is called a nonqueued, automatically started
TP.
The Attach is queued until the RECEIVE_ALLOCATE verb in the invoked TP is executed (or until a timeout
occurs; see Section 2.9.6, Timeout Values for Invoked TPs). When RECEIVE_ALLOCATE is executed, APPC
assigns a conversation ID, which is returned to both TPs as an identifier for the conversation.
After it has ended a conversation, the invoked TP may terminate, or it may issue another RECEIVE_ALLOCATE.
For frequently-used programs, this provides a way of avoiding the performance overhead of starting a new
instance of the program for each conversation. Each time an Attach is received for a nonqueued, automatically
started TP, SNAplus2 checks whether there is already a RECEIVE_ALLOCATE outstanding from an instance
of this TP. If so, this TP is used for the incoming conversation; otherwise, SNAplus2 starts a new instance of
the program.
2.9.5 Invoked TPs: Automatically Started by a TP Server Application
UNIX
When an Attach arrives at the SNAplus2 node, SNAplus2 distributes Attaches to TP server applications that have
registered to receive the Attaches. The process SNAplus2 uses to route Attaches to an appropriate TP server consists
of the following stages:
1. One or more applications register to receive Attaches for LU and TP names. A TP server application can use
a wildcard to specify the scope of Attaches that the TP server is registered to receive. A TP server application
can use a wildcard for any of the following:
• Local LU alias
• TP name
• Fully qualified partner LU name, which can use a wildcard for any of the following:
71