Here’s Greg Day’s explanation from the archives:
Hi,
> Clovertech’s,
>
> I have had an intermitant problem over the last couple months. I am
> running cloverleaf 3.8.1 on an AIX box (not sure of the model).
> Ocassionally I get an error “[pdl :PDL :ERR /0: tpatcpin] no-match: no
> more phrases to try” on my inbound ADT thread from my HIS. When this
> happens, cloverleaf dosn’t send back an ACK, so my HIS quits transmitting.
> When I bounce the HIS process, it retransmits the last message and
> everything works great.
>
> I have two questions. First, what is the error telling me? I assumed
> it didn’t recognize what came in as a vaid message. I turned up the noise
> by adding “enable pd * * *” to my EO config. This showed me all the
> messages that got to the engine successfully, and what it did with them,
> but it had nothing on the bad message.
>
> My second question is, what would need to be in the EO config to allow
> me to see the message comming into cloverleaf before it rejects it?.
>
> I have a progrm that records all the tcpip packets into and out of my
> cloverleaf box, and from that it looks like the problem occurs when tcpip
> has to have multiple packets resent before trying to reassemble the
> message. I was thinking that it may be a tcpip issue, but my network
> manager, insists it is a problem with cloverleaf, and If I can show him a
> misformed message being passed from tcpip to cloverleaf before cloverleaf
> errors, he will look at it.
>
> Any help or insight you may have would be appreciated.
It’s a little complicated but the essence is that when the engine analyzes
the bytes that show up in the TCP/IP buffer and it can’t match the buffer
contents with any phrase that has been defined in the PDL a no-match error
is produced. So, if you were using the MLP (hl7) PDL and the first byte in
the TCP/IP buffer wasn’t a hex 0b, a no-match error would occur. The engine
would then assume that the bytes are junk and dispose of them.
Sounds like the sending system, in your case, doesn’t time out waiting for a
response so the interface hangs.
The only way to have the engine dump the TCP/IP buffer contents into the log
is to use enable_all as your EO alias.
Greg Day