This has been handled by creating an additional thread that actually does the odbc connection and updating, and then ACKS back to the sending thread. It looks like this:
myinbound —> myoutbound ……… odbcthread
uses this thread has 2 inbound tps procs
recovery33 1) Performs the odbc functions
procs 2) Performs the ACK’ing (back to “myoutbound”)
The myoutbound thread is a standard TCP/IP localhost “client” connection, which connects to the odbcthread (which is a standard TCP/IP
“server” connection). The odbcthread has two inbound tps procs:
1) the first proc is the one that performs the odbc stuff
2) the second proc simply creates an “ACK” back to the sending thread.
That way the “myoutbound” thread only sends a subsequent message when it receives an ACK from the odbcthread. If the odbc proc is unable to perform it’s duties, the ACK proc won’t run, thus not sending an acknowledgement back to “myoutbound”; so the messages queue on “myoutbound” until it can get an ack back from “odbcthread”.
Hope this helps.
Jim Cobane
Henry Ford Health
