The pattern of calls in a long-running transaction is as follows:
A long-running transaction processes the first client request the same way any transaction processes a client request.
For the first client request, a long-running transaction:
Calls TDACCEPT to accept the request.
Uses TDINFPGM to determine the type of request received. This will be an RPC or a language, cursor, or dynamic request.
Processes the request and returns results.
Calls TDSNDDON with CONN_OPTIONS set to TDS_ENDREPLY, which puts the mainframe in RECEIVE state, ready to receive another request.
For subsequent client requests, a long-running transaction:
Calls TDGETREQ to accept each subsequent request and determine whether it is an RPC or a language, cursor, or dynamic request.
Processes the request and returns results.
Calls TDSNDDON with CONN_OPTIONS set to TDS_ENDREPLY, which puts the mainframe in RECEIVE state, ready to receive another request.
A long-running transaction must free up all resources after it accepts and processes the last client request. It treats the new request as any other subsequent client request, then calls TDTERM to end the transaction.
For the final client request, a long-running transaction:
Calls TDGETREQ, with WAIT_OPTION set to TDS_FALSE, to:
Accept the final request, if one is present, or
End the transaction, if no request is pending.
Processes the request and returns results.
Calls TDSNDDON with CONN_OPTIONS set to TDS_ENDRPC, which ends the transaction.
Calls TDFREE.
Calls TDTERM to free up all resources.
TDTERM is required for IMS TM and
MVS. It is optional but recommended for CICS.
Refer to “Processing a long-running transaction” to see the skeleton of a basic long-running transaction.
