Data flow

A NetConfig with DTC has these threads:

  • DTC is the main engine that runs the ordered list of steps in the form of a State Machine. This is defined by the user through the DTC IDE GUI.
  • "Inbound" is any thread that sends DATA to a DTC thread. When DATA is received at a DTC thread, a new transaction is created. There can be multiple threads sending DATA to a DTC thread and each instance of DATA creates a new transaction.
  • "Intermediate" are those that receive messages from DTC threads depending on the state transitions. Some states may send a message to their corresponding thread. Some transition to the next state without sending a message. This behavior is programmable through the Action TPS.
  • "Outbound" is the last thread that receives the message. A transaction ends when the outbound thread sends a successful reply message to the DTC thread. The DTC thread then enters a stop state. The outbound thread and successive transition to a stop state is configured through the DTC IDE GUI.

Data flow modes

This table lists the modes of data flow:

Mode Description
Inbound thread→DTC thread

A new Transaction (XID) is created and the Start state is entered with DATA.

Control is passed to Start state’s Action TPS.

This can then return the disposition of DTCNEXT or DTCSEND.

State A→State B

State A’s action returned a disposition of “DCTNEXT {$mh Code}”. The state machine had a rule of “State A + Code→State B.”

State B is entered and control is passed to state B’s Action.

State A→Thread A

State A’s Action returned a disposition of “DTCSEND $mh” and state machine had a rule for “State A + DTCSEND→Thread A.”

A message is sent to Thread A.

State A→Xlate Thread→Thread A

State A’s Action returned a disposition of “DTCXLATE $mh.”

A message is sent to xlate thread which can then translate and route to the appropriate thread.

_{{ {DTCXLATE $mh}_}} sends the message to the DTC translation thread. A data route must be configured between the DTC thread and the destination protocol thread.

Thread A→State A (reply)

Thread A sent a reply message to DTC Thread. State machine had a rule for “State A + DTCSEND→Thread A.”

State A is reverse looked up from this rule and State A is entered and state A’s Action TPS is called.

State A→Stop state and no rule for “Stop State + DTCSEND→Thread X” exists

Stop state’s Action TPS is called. All journal data and user data that are associated with this transaction are deleted and the transaction is deemed to be committed successfully.

State A→Stop state and a rule for “Stop State + DTCSEND→Thread X” exists

Stop state’s Action TPS is called, which returns a disposition of DTCSEND.

A message is sent to Thread X. This is the outbound thread.

The outbound thread sends a reply message to the DTC thread. The thread does a reverse lookup state by the sender thread.

Stop state is entered with REPLY mode and Stop state’s Action TPS is called.

All journal data and user data that are associated with this transaction are deleted and the transaction is deemed to be committed successfully.

Error Anywhere→Stop State

These types of error can occur:

  • Action TPS of any state returns an ERROR disposition.
  • State + Code combination is unknown: There is no rule stating “State A + Code→State B” for Code returned by State A’s Action TPS.
  • Max Steps limit is exceeded.

Stop state is entered with ERROR. The original message at Start state is sent to the Error DB and the Rollback TPS is called for each state visited in reverse order.

All journal data for the transaction is deleted and the transaction is deemed to be rolled back.