In the standard (short) transaction model, a mainframe transaction ends as soon as it finishes sending results to a single client request. A long-running transaction does not end the transaction when all results are sent, but remains active, ready to accept additional requests.
Long-running transactions are supported with CICS, MVS,
and with the IMS TM explicit API, but not with the IMS TM implicit
API. To simulate a long-running transaction in the IMS TM implicit
API, you must define the transaction as a WFI (wait-for-input) transaction
in the TRANSACT macro.
Long-running transactions begin like transactions that process single client requests, but, instead of closing the connection after returning results, they switch from SEND to RECEIVE state, ready to accept subsequent requests. Because a transaction can call TDACCEPT only once, it calls TDGETREQ to process subsequent client requests. TDGETREQ also returns the type of request received.
The values assigned to TDSNDDON arguments determine the type of transaction.
For short transactions:
Set STATUS to TDS_DONE_FINAL.
Set CONN_OPTIONS to TDS_ENDRPC. This closes the connection and ends the conversation.
For long-running transactions (when preparing to accept another request).
Set STATUS to TDS_DONE_FINAL.
Set CONN_OPTIONS to TDS_ENDREPLY. This switches the communication state to RECEIVE. The TDS_ENDREPLY option indicates that the host is expecting a subsequent communication from the client.
For IMS TM WFI transactions:
Set STATUS to TDS_DONE_FINAL.
Set CONN_OPTIONS to TDS_ENDRPC. The transaction can call TDGETREQ to accept another client request.
A transaction can determine the communication state by calling TDSTATUS. TDSTATUS returns TDS_SEND or TDS_RECEIVE while the transaction is running and TDS_RESET when a CICS, MVS, or IMS TM explicit transaction ends.
For IMS TM Users, IMS TM WFI transactions can accept
additional RPCs after receiving TDS_RESET.
See TDSTATUS for
details.
