Rev 2 mlp_tcp.pdl

[Ian Morris]

Hello,

I (think) I have a problem related to the mlp_tcp.pdl ever since I installed the Rev2 patch.  My messages are going into a state 101 and won’t leave my outbound thread.  

The outbound thread goes to another site on the same server.  

Any thoughts?

Code:

[pdl :open:INFO/0:summit2_adt_send:12/22/2008 14:52:55] Loading PDL driver ‘mlp_tcp.pdl’
[pdl :PDL :DBUG/0:summit2_adt_send:12/22/2008 14:52:55] PDL does not exist in site, and master site is not set; search in root.
[pdl :PDL :DBUG/0:summit2_adt_send:12/22/2008 14:52:55] PDL found in root.
[pdl :PDL :DBUG/0:summit2_adt_send:12/22/2008 14:52:55] Loading driver: /opt/quovadx/qdx5.6/integrator/pdls/mlp_tcp.pdo
[dbi :elog:DBUG/3:summit2_adt_send:12/22/2008 14:52:55] [0.0.121994] Looking for mid in error db
[dbi :dbi :DBUG/1:summit2_adt_send:12/22/2008 14:52:55] (0) ‘cl_keyfindlock: About to do d_keylock’
[dbi :dbi :DBUG/1:summit2_adt_send:12/22/2008 14:52:55] (0) ‘cl_keyfindlock: About to do d_keyfind, keyval:’
[dbi :rlog:DBUG/3:summit2_adt_send:12/22/2008 14:52:55] [0.0.121994] Looking for mid in recovery db
[dbi :dbi :DBUG/1:summit2_adt_send:12/22/2008 14:52:55] (0) ‘cl_keyfindlock: About to do d_keylock’
[dbi :dbi :DBUG/1:summit2_adt_send:12/22/2008 14:52:55] (1000) ‘cl_keyfindlock: About to do d_keyfind, keyval:’
[msg :Mid :DBUG/3:summit2_adt_send:12/22/2008 14:52:55] Assigned mid [0.0.121994] to msg 0xb76f7028
[msg :Msg :DBUG/0:summit2_adt_send:12/22/2008 14:52:55] [0.0.121994] MSG alloc 0x0xb76f7028
[pdl :PDL :DBUG/0:summit2_adt_send:12/22/2008 14:52:55] Loaded: tcpip-mlp (version 2.0)
[pdl :PDL :DBUG/0:summit2_adt_send:12/22/2008 14:52:55] Evaling:
       proc hci_pd.write { info } {
   global MsgId
   
   keylget info message MsgId
           keylset continuations ok     write.done
           keylset continuations error write.error
   keylset continuations timeout [list 15000 write.timeout]
   hci_pd_send basic-msg [list [list data [list message $MsgId]]] $continuations
       }

       proc write.done {info} {}
       
       proc write.error {info} {
           hci_pd_report_exception 1 “write failure”
   hci_pd_set_result_code 1
       }
       
proc write.timeout {info} {
   global MsgId
           msgmetaset $MsgId FLAGS {{proto_timeout 1}}
           hci_pd_set_result_code 1
}

proc hci_pd.read {info} {

   keylset continuations basic-msg read.done
   keylset continuations error read.error
   keylset continuations timeout [list 15000 read.timeout]
   hci_pd_receive $continuations
}

proc read.done {info} {
   keylset accept text [list [keylget info data]]
   keylset accept end [keylget info end]
   hci_pd_accept $accept
}

proc read.error {info} {
   
   keylget info type type
   switch -exact — $type {
input-error {
   hci_pd_report_exception 1 “device error (remote side probably shut down)”
   hci_pd_ignore_input -all
}
no-match {
   hci_pd_ignore_input 1
   hci_pd_ignore_input -until xb
}
default {
   hci_pd_report_exception 2 “unknown fail: $type”
   hci_pd_ignore_input -all
}
   }
}

proc read.timeout {info} {
   hci_pd_ignore_input 1
   hci_pd_ignore_input -until xb
}

[pdl :PDL :DBUG/2:summit2_adt_send:12/22/2008 14:52:55] PDL changed states: old 7, new 4
[pdl :PDL :DBUG/0:summit2_adt_send:12/22/2008 14:52:55] Calling Tcl procedure: hci_pd.initialize
[pdl :PDL :DBUG/0:summit2_adt_send:12/22/2008 14:52:55] with args: {}
[pdl :PDL :DBUG/0:summit2_adt_send:12/22/2008 14:52:55] Tcl procedure hci_pd.initialize returns ”
[pdl :PDL :INFO/0:summit2_adt_send:12/22/2008 14:52:55] connected to 172.17.40.78 on port 8001
[pdl :PDL :DBUG/0:summit2_adt_send:12/22/2008 14:52:55] tcp-client: attempting connect to: 172.17.40.78:8001
[pdl :PDL :INFO/0:summit2_adt_send:12/22/2008 14:52:55] tcp-client: connect error (Operation now in progress)
[pdl :PDL :DBUG/1:summit2_adt_send:12/22/2008 14:52:55] PDL setting timeout in 0.10 seconds
[diag:leak:DBUG/0:summit2_adt_send:12/22/2008 14:52:55] diag ev alloc 0x0xa4909b0
[diag:leak:DBUG/0:summit2_adt_send:12/22/2008 14:52:55] diag dqe alloc 0x0xa499058
[pti :even:DBUG/0:summit2_adt_send:12/22/2008 14:52:55] Registering TIMER () event 0x0xa4909b0 for tid 4

Topic

[Jim Kosloskey]

Ian,

I doubt the pdl (especially mlp_pdl) is causing you to have a trxid issue.

Is the message erroring out your inound message or is it a reply from the receiving system?

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

[Ian Morris]

I’m not sure….

It’s a sending thread that goes to another site.  I can tell you that when this thread first receives the message it is a valid message.  I was thinking it might be problem related to this:  

Quote:

If you use check_ack (known as validate_reply in some recover_33 packages), then make sure the logic in the proc is based on check_ack from recover_56.tcl. This updated procedure uses the OBMSGID argument in place of the ob_save global variable.

                                                                                 4.      Look for a line in your check_ack that looks like the following:

set my_mh $ob_save

Replace it with the following:

keylget args OBMSGID my_mh

I’m thinking it’s related because we use the recovery33 proc in our environment.

I don’t think the recovery 33 is a problem though because we are not making use of check_ack in this situation.

[Jim Kosloskey]

Ian,

Check the Error DB and see what message is in there.

Is it your outbound message or a reply?

Trxid errors are generated when there is an inbound messge (or reply) for which there is no valid routing and the message has reached the route function (in other words not disposed of after receipt).

Now it is true you need to validate your acknowledgment handling carefully with 5.6 Rev2 and you should have acknowledgment handling even in a site-to-site connection.

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

[Ian Morris]

Jim,

I would say it’s an outbound message.  Here’s what the error db looks like…

Code:

-bash-3.1$ hcidbdump -e -m 0.0.122405
                       C
                       l T
                       a y F
                       s p w
Created  Message Id     s e d Prio State Length Source          Dest
——– ————– – – – —- —– —— ————— —————
16:16:24   [0.0.122405] E D N 5120   101     74 summit2_adt_sen

Code:

-bash-3.1$ hcidbdump -e -L -m 0.0.122405
msg: 0x0xb7da903c
   msgType           : DATA
   msgClass          : ENGINE
   msgState          : Unsupported Trxid (101)
   msgPriority       : 5120
   msgRecoveryDbState: 3
   msgFlags          : 0x8002
   msgMid            : [0.0.122405]
   msgSrcMid         : midNULL
   msgSrcMidGroup    : midNULL
   msgOrigSrcThread  : summit2_adt_send
   msgOrigDestThread :
   msgSrcThread      : summit2_adt_send
   msgDestThread     :
   msgXlateThread    :
   msgSkipXlate      : 0
   msgSepChars       :
   msgNumRetries     : 0
   msgGroupId        : 0
   msgDriverControl  :
   msgRecordFormat   :
   msgRoutes         :
   msgUserData       :
   msgStaticIsDirty  : 0
   msgVariableIsDirty: 0
   msgTimeStartIb    : 1229980584.247
   msgTimeStartOb    : 1229980119.690
   msgTimeCurQueStart: 0.000
   msgTimeTotalQue   : 0.229
   msgTimeRecovery   : 1229980584.539
   msgEoConfig       : 0x(nil)
   msgData (BO)      : 0x0xb7da9120
   message           : ‘MSH|^~&|ADM||||200812220707||ADT^A03|136552|D|2.2|||AL|NEx0dMSA|AA|136552|x0d’

Here’s the original message…

Code:

MSH|^~&|ADM||||200812220707||ADT^A03|136552|D|2.2|||AL|NE
EVN|A03|200812220706
PID|1|HSMTVD0002184|H001418|H1296|GRINCH^MR.^^^^||19701201|M|^^^^^|CA|10 WHOVILLE AVENUE^^CHAMBERSBURG^PA^17201||(171)267-3000|(717)267-3000||M|UN|H00000023325|000-00-0000||
NK1|1|GRINCH^LOU^WHO^^^|WI^01 WIFE|10 WHOVILLE AVENUE^^CHAMBERSBURG^PA^17201|(171)267-3000||NOK
NK1|2|GRINCH^LOU^WHO^^^|WI^01 WIFE|10 WHOVILLE AVENUE^^CHAMBERSBURG^PA^17201|(171)267-3000||NOT
NK1|3|CHBGHOSP||112 N SEVENTH ST^^CHAMBERSBURG^PA^17201||(717)267-3000|EMP||||||CHAMBERSBURG HOSP|||||||||||||||||||||FT
PV1|1|I|CPCUS^0224^2|EL|||SHELLY^Shelly D.O.^R^Lucas^^^|||PCU||||PHY|||SHELLY^Shelly D.O.^R^Lucas^^^|IN||SP||||||||||||||||SNF|||CHBG||DIS|||200811190849|200812220703|||||||MARTZL^Martzluf^Douglas^R^^^M.D.|
PV2||PCU^PROGRESSIVE CARE UNIT|FEELING GREEN (?FOOD POISONING)
OBX|1|CE|ZADCOUNTY2^Enter county of patient:^ADM||FRANKLIN^Franklin County||||||F
OBX|2|CE|ZADDSPRO23^Discharged To Skilled Nur Home:^ADM||395012^Menno Haven||||||F
OBX|3|TX|ZADDSPRON^Needed To Go With Nurse:^ADM||N||||||F
OBX|4|TX|ZADDSPROTX^Was Transfer Summary Printed (DC to Rehab)?^ADM||Y||||||F
OBX|5|TX|ZADECF^Is Patient a transfer from an Extended Care Facility?^ADM||N||||||F
OBX|6|TX|ZADESBL^Have you ever had ESBL?^ADM||N||||||F
OBX|7|TX|ZADHIPAA1^1. Do you want your information in our Facility Directory?^ADM||N||||||F
OBX|8|TX|ZADHIPAA2^3. Do you want your Religious Affiliation shared?^ADM||N||||||F
OBX|9|TX|ZADHIPAA3^4. Do you want us to notify your church of your admission?^ADM||N||||||F
OBX|10|TX|ZADHIPAA6^**Was this info verified by Hipaa Questionnaire?^ADM||Y||||||F
OBX|11|TX|ZADHISPAN2^Is Patient of Hispanic or Latino Origin?^ADM||N||||||F
OBX|12|TX|ZADHOSPITA^Is this a Hospitalist Patient?^ADM||N||||||F
OBX|13|TX|ZADINTRP^Interpreter Needed?^ADM||N||||||F
OBX|14|TX|ZADMCRNOT5^Date^ADM||||||||F
OBX|15|TX|ZADMCRNOT7^Y/N^ADM||||||||F
OBX|16|TX|ZADMCRNOT8^Date^ADM||||||||F
OBX|17|TX|ZADMCRNOT9^Comment^ADM||||||||F
OBX|18|TX|ZADMRSA^Have you ever had the infectious bacteria MRSA?^ADM||N||||||F
OBX|19|TX|ZADPRIV1^Date Privacy Notice Was Given:^ADM||20081119||||||F
OBX|20|TX|ZADPRIV2^Was Privacy Acknowledgement Form Refused?^ADM||N||||||F
OBX|21|TX|ZADPRIV3^Reason Patient or Representative Refused to Sign:^ADM||||||||F
OBX|22|TX|ZADVRE^Have you ever had the infectious bacteria, VRE?^ADM||N||||||F
OBX|23|TX|ZADVRSA^Have you ever had the infectious disease, VRSA?^ADM||N||||||F
OBX|24|CE|ZCODE^*Code Status:^ADM||I^I:FULL CODE||||||F
OBX|25|TX|ZADMAELIG2^Verified eligibility on EVS (Y/N):^INS^^^SP||Y||||||F
OBX|26|TX|ZADMAELIG3^Date Verified:^INS^^^SP||20081119||||||F
GT1|1||GRINCH^MR.||10 WHOVILLE AVENUE^^CHAMBERSBURG^PA^17201|(171)267-3000|||||SP|000-00-0000||||CHBGHOSP|112 N SEVENTH ST^^CHAMBERSBURG^PA^17201|(717)267-3000||FT|
IN1|1|SP||SELF PAY INSURANCE|||||||CHBGHOSP|||||GRINCH^MR.^^^^|SP||||||||||||20081119|PCHILCOTE||||||||||||FT^1 FULL-TIME EMPLOYED|||QUEUED
UB2|||||||

[Jim Kosloskey]

ian,

Nope – that is an acknowledgment.

Check to make sure you are killing the reply in your acknowledgment handling on the outbound thread.

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

[Ian Morris]

I talked to David from tech support and he had the same suggestion you did.  He also suggested checking the Outbound only option.  Here’s what my thread looks like now…

Thank you for your help!

[Jim Kosloskey]

Ian,

Did that take care of your issue?

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

[Ian Morris]

Yes it did.  Thank you!

[Author]

Replies