You must code all parameters described for each function in the order
shown.
The conversation must be in a valid state for the particular
verbname specified. The valid states for each function are
listed in the "Programming Considerations" section for that
function. See TPF ACF/SNA Data Communications
Reference for more information about the finite state machine and valid
states.
You can execute these functions on any I-stream.
The TPF/APPC function generates a crosc_entrc to the TPF/APPC
verb router program, a real-time ECB-controlled program. Additional
E-type programs are activated based on the verbname, the passed
parameters, and the status and conditions that may be present for the
conversation. There must be at least 7 program nesting levels
available.
The TPF/APPC support programs save and restore the contents of EBW016
- EBW103 and the EBX area of the calling ECB.
The TPF/APPC support programs use various data levels of the ECB to
perform their processing. If the data levels used by the support
programs have blocks attached when the TPF/APPC function is executed, the
support programs detach the blocks from the ECB (using DETAC) and attach them
back to the ECB (using ATTAC) before returning control to the calling
program. Data level 15 (DF) is always used. Data levels
12-14 (DC-DE) are used at various times. The application
can reduce the overhead inherent in the DETAC/ATTAC processing by insuring
that these data levels are available when the TPF/APPC function is
executed.
If you code variables that contain enumeration types instead of coding the
enumeration types directly, the expansion of the function creates more
instructions, takes more space, and takes longer to execute.
When a remote LU 6.2 transaction program starts a conversation with
a TPF transaction program, the TPF system receives an ATTACH FMH5
record. See TPF ACF/SNA Data Communications
Reference for a description of the ATTACH interface.
The 2 ACTIVATE functions (tppc_activate_on_confirmation and
tppc_activate_on_receipt) are TPF-only extensions to the LU
6.2 architecture. They allow you to implement a TPF transaction
program with an asynchronous wait mechanism. After issuing either of
the ACTIVATE verbs, the ECB (which represents the transaction program
instance) is expected to call the TPF exit function. When
the wait implied with the synchronous type verb (tppc_receive,
tppc_confirm, tppc_prepare_to_receive,
tppc_deallocate) completes, TPF/APPC support re-creates the TPF
transaction program instance by activating the specified program with a new
ECB.
The TPF/APPC support always returns to the calling transaction program
with a protection key of 1.
See the individual function descriptions for programming considerations
relevant to each supported verb.