Action TPS

Characteristics of the Action TPS are:

  • An Action TPS can only have one Tcl proc.
  • When a state is entered, its Action TPS is called with an input message argument. The message is a DATA message, and is automatically saved in the Staging Database.
  • DTCCTX is stored in the input message’s metadata DRIVERCTL:
    keylget args MSGID mh
    set drvctl [msgmetaget $mh DRIVERCTL]
    set dtcctx [keylget drvctl DTCCTX]
  • Use dtcset/dtcget and dtcsetmsg/dtcgetmsg to store and retrieve a value or message to or from the staging databases.
  • Use msgcreate/msgcopy to generate new messages.
  • Append a {DISP …} to the return value dispList for every message, including input and new messages.
  • {DISP …} can be one of:
    • {KILL $mh}: Destroy the message.
    • {OVER $mh}: Put the message into DTC thread’s IB Pre-TPS Queue. The message eventually goes to the xlate thread.
    • {ERROR $mh}: Enter STOP state, rollback and put the original message into the error database.
    • {DTCSEND $mh}: Send the message to the associated thread by ICL.
    • {DTCNEXT {{$mh $code}}}: Return $code. DTC transits to the next state.
  • In dispList, there must be one and only one DTCSEND or DTCNEXT or ERROR, but there can be more than one KILL or OVER.
  • When an asynchronous state is entered, the Action TPS is called with a DATA message. The dispList must include a {DTCSEND $mh}. DTC then sends the message $mh to the associated thread.
  • The associated thread should send back a REPLY message with the same DTCCTX in the DRIVERCTL.
  • When the REPLY message arrives, the Action TPS is called the second time. In it a new DATA message $mh must be created and {DTCNEXT {{$mh $code}} must be included in dispList.