Cloverleaf 6.1 new Openlink interface shows one pending msg

[Peter Heggie]

The NetMonitor shows the inbound thread with a yellow color, and the status shows one message is pending. Its been that way for over a half hour. When I look in the Recovery DB, there are no messages (and none in the Error DB as well). When I recycle the thread, the Pending count goes to zero but the Msgs In count remains the same and the Last Rd time stays the same.

Is this an Ack problem or a problem with extra or invalid message terminator characters (i.e. the sending application is formatting a little different than expected) or is this a possible problem with CL 6.1?

The sender is Openlink (from Soarian).

This is our very first interface in 6.1, so I will go back and create some simple local-file interfaces to see if I can get ‘normal’ behavior.

Thanks in advance,

Peter

Peter Heggie
PeterHeggie@crouse.org

Topic

[James Cobane]

Typically, a pending message on an inbound thread means that it is trying to write your ACK message out the connection. Is the sending system (OpenLink/Soarian) breaking the connection immediately after it sends (i.e. not waiting for the ACK), therefore causing the ACK to sit pending?  I would turn up EO and see what the logs indicate.

Jim Cobane

Henry Ford Health

[Peter Heggie]

I compared the hl7Raw_ack.tcl and there is no difference. But there is a difference in processing.

The 6.0.2 debug output:

Code:

[0.0.114506737] Writing message to Protocol Driver pdl-tcpip
[0.0.114506737] Write msg to connection
bound message efffa528 to `message0′
  (message length is 81)
PDL changed states: old 0, new 2
Calling Tcl procedure: hci_pd.write
with args: {{message message0}}
Tcl procedure hci_pd.write returns ‘TRANSMIT’
writing out 84 bytes:
0b 4d 53 48  7c 5e 7e 5c  |.MSH|^~|
…..
38 0d 1c 0d               |8…|
write buffer has 84 bytes, currently at +0
wrote 84 bytes out of 84
write buffer has 84 bytes, currently at +84
Calling Tcl procedure: write.done
with args: {{status ok}}
Tcl procedure write.done returns ”
PDL changed states: old 2, new 0
PDL did write msg: code = 0
[0.0.114506737] Writing message succeeded

And the new 6.1 output:

Code:

[0.0.817] Writing message to Protocol Driver pdl-tcpip
[0.0.817] Write msg to connection
bound message effffa28 to `message0′
  (message length is 129)
PDL changed states: old 0, new 2
Calling Tcl procedure: hci_pd.write
with args: {{message message0}}
Tcl procedure hci_pd.write returns ‘TRANSMIT’
writing out 132 bytes:
0b 4d 53 48  7c 5e 7e 5c  |.MSH|^~|
…..
34 0d 1c 0d               |4…|
write buffer has 132 bytes, currently at +0
wrote 132 bytes out of 132
write buffer has 132 bytes, currently at +132
Calling Tcl procedure: write.getResponse
with args: {{status ok}}
Tcl procedure write.getResponse returns ‘RECEIVE’
trying to match phrase: ack-msg

It looks like the code has changed, to use a procedure called write.getResponse instead of write.done ?

Both are inbound threads, both use hl7Raw_ack in the TPS Inbound Data, and both are set to ASCII in the protocol properties encoding.

The 6.1 output goes on with more tries and also says something about a partial message???

Code:

PDL setting timeout in 10.00 seconds
diag ev alloc 0x317e4e38
diag dqe alloc 0x31772f08
tiRegistering TIMER () event 0x317e4e38 for tid 2
evRegistering TIMER () event 0x317e4e38 for tid 2
[0.0.817] Writing message PARTIALLY complete
[0.0.817] Setup callback function for writing partial message
Thread has 0 ready events left.
Thread 2 has been enabled
Thread has 1 ready events.
Processing SOCKET (PDL server) event 0x317730b8
Calling cb 0x300a6b10
Events: E 0, R 8, W 0
PDL clearing timeout
tiUnregistering TIMER () event 0x317e4e38 for tid 2
evUnregister TIMER () event 0x317e4e38 for tid 2
diag dqe free  0x31772f08
diag ev free  0x317e4e38
read 34 bytes
input buffer accepted 34 bytes, now 34
4d 53 48 7c  5e 7e 5c 26  |MSH|^~&|
7c 7c 7c 7c  7c 7c 7c 41  ||||||||A|
43 4b 7c 7c  50 7c 32 2e  |CK||P|2.|
34 0d 4d 53  41 7c 41 52  |4.MSA|AR|
7c 0d                     ||.|
match phrase ack-msg rejected
multi: phrase #0 rejected; trying next
trying to match phrase: nak-msg
match phrase nak-msg rejected
multi: phrase #1 rejected; trying next
no-match: no more phrases to try
Calling Tcl procedure: write.gotNak
with args: {{status error} {type no-match}}
pdiIgnoreInput: chop to 4294967295, bolen 0
pdiIgnoreInput: after clear: 0 + 0
Tcl procedure write.gotNak returns ‘TRANSMIT’

Is this really new code for 6.1 or is this a result of the reception of the ACK by the end end of the connection (OpenLink)?

I will open a ticket.

Peter

Peter Heggie
PeterHeggie@crouse.org

[Jim Kosloskey]

Peter,

Looks like you are creating a diferent length message. Is the acknowledgment really a positive acknowledgment (your display does not show the whole message) or could it be a nak?

132 characters is a litle long for a basic positive acknowldgment

If it is a nak – how does the other side react to a nak?

It almost looks like the other side is not handling the response in a normal fashion.

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Jim Kosloskey]

Peter – are you using mlp or mlp2 pdl?

If using mlp2 pdl that is not likely to work the way you want.

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Peter Heggie]

it is using mlp2 – I will try with mlp.

What is the difference between mlp and mlp2?

I’m trying to get a logon to the sending system so I don’t have to wait 2 hours between attempts.

Peter Heggie
PeterHeggie@crouse.org

[Peter Heggie]

That fixed the problem – thank you.

I found a reference to mlp2:

<a href="https://usspvlclovertch2.infor.com/viewtopic.php?t=4719&highlight=mlp2&#8243; class=”bbcode_url”>https://usspvlclovertch2.infor.com/viewtopic.php?t=4719&highlight=mlp2

Does not quite explain what it was, but I’ll definately try switching those two around if I have similar handshaking problems in the future.

Peter

Peter Heggie
PeterHeggie@crouse.org

[Keith McLeod]

Seems to work fine for 6.1 but gives the following for 5.7 SMATS.

unmatched open brace in list

   while executing

“lindex $rec 0”

   (procedure “selectDate” line 19)

   invoked from within

“selectDate $DTSTART $DTEND $NOTDT”

   (procedure “SMAT::selectMsgs” line 73)

   invoked from within

“SMAT::selectMsgs”

   (procedure “hcismat” line 10)

   invoked from within

“hcismat $argv”

   (file “/hci/cis6.1/integrator/contrib/hcismat” line 1096)

[Author]

Replies