DTC REPLY failing – what am I doing wrong?

[Jim Kosloskey]

I am experimenting with DTC. I have a configuration where I am orchestrating sending a message to a thread which then replies with the intent Transitions will continue following the reply on to the next step. The transitioned message indeed gets to the intended thread and a reply comes back with what seems to be the proper Trx ID but DTC complains it is an INVALID REPLY.

See the attached for what I think are salient screenshots.

I am open to any and all suggestions.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

Topic

[Jim Kosloskey]

OK so apparently this forum does not like .rtf files. it would be nice if the limitations were provided.

Let me try a PDF format

 

OK that worked.

• This reply was modified 1 year, 9 months ago by Jim Kosloskey.

Attachments:

You must be logged in to view attached files.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Don Martin]

I’m not sure how you copied your message so I can say for sure, but it looks like the DRVCTL metadata didn’t get copied form the original reply message to the new copy of the message, so you’re missing your DTC context.  We use DTC threads a lot, and whenever we copy a message, which is a lot in DTC threads because you need to take replies and change them them to data messages, we do these two additional steps:

set drvctl [msgmetaget $replyMessageHandle DRIVERCTL]

# DTC needs the DRIVERCTL from the copied message
msgmetaset $dataMessageHandleCopy DRIVERCTL $drvctl

The entire snipped to copy a DTC reply and CONTINUE the data message looks like this:

# Reply messages need to be copied to data messages in DTC flow; data message is sent on in the DTC flow.
set mhData [msgcreate -type data [msgget $mh] ]
# DTC needs the DRIVERCTL from the copied message
msgmetaset $mhData DRIVERCTL $drvctl
# set the code for messages with length > 6 to DONE, else QUIT the message
set message [msgget $mhData]
if { [some condition used to determine next state } {
set xCode SOME_STATE
} else {
set xCode DONE

}
lappend dispList “DTCNEXT {{$mhData $xCode}}”
# Kill the reply message prevent leaked memory/handle
lappend dispList “KILL $mh”

[Jim Kosloskey]

Don,

Thanks for the input -very interesting.

But in this case, the message shown is a Reply message not a copy. The thread from which the reply came is a TCP/IP connection to a foreign system that then returns the message you see in the PDF,

The msgcopy you see in 3 of the PDF is done by Cloverleaf as part of the DTC receipt of the Reply message.

So, if the reply is coming from a foreign system, how is the Driver Control from the DTC sent message supposed to transition?

I would think this would be a common scenario:

1. IB Cloverleaf thread –>
2. DTC Thread –>
3. OB Cloverleaf Thread –> Outside system (Driver Control exists in OB Msg)
4. Outside System returns reply –> (Original Driver Control is lost)
5. DTC Thread receives outside system reply requires original Driver Control? How is that possible?

Is that the scenario you are describing? If so, how do you get the Driver Control from the OB message to get into the Reply?

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Author]

Replies