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.
IMS TM Users: IMS TM WFI transactions can accept additional
RPCs after receiving TDS-RESET. See TDSTATUS for
details.
