End of segment characters changed from x0d to x0a

[David Dillard]

HI,

The end of segment character for the outbound message on ONE of my theads suddenly changed from the x0d to x0a.

I was away on vacation for a few weeks and when I got back my workmates informed me that the thread was ‘stuck’ and not getting an ack back from the destination.

When I enable the EO config I can clearly see that each segment ends in x0a — instead of x0d.  The Saved message files also show the x0a for this thread only.

I thought it might be something with the protocoll but the thread uses the mlp_tcp_pdl which is used by many different threads in multiple sites.

I checked another thread which uses the same mlp_tcp_pdl and the messages for that thread are correct.

Everyone tells me that they made no changes but something is different.  When I checked the site files, the dates for the xlates, tcl code and HL7 formats files are all before it stopped working — so It does not look like that was changed.

Is there some setting in the engine where you can tell it to use the x0a instead of the x0d for the end-of-segment character?

Any clues to where I can look to fix this problem would be appreciated.

Thanks in advance

Topic

[Ryan Spires]

David,

Several things to look for… Is the x0a actually at the end of every segment?  And this has changed recently?  

The typical HL7 message outbound should look something like

MSH|….x0d

PID|…x0d

OBX|…xodx0a

If you have x0a where you should have x0d, then you may have a proc that had previously split the segments on x0d and joined them with a x0a

Also, are you saving your inbound date, does it have the x0a.

Another thing to consider is if a file had been “resent” through the outbound thread that is formatted with x0a instead of x0d.

Just some suggestions to look for.

Thanks,

Ryan

[David Dillard]

Ryan,

Thanks for the ideas.   Something must have become ‘hosed’ in the thread’s pending messages, but when you mentioned “resent” messages it gave the idea to save off any messages in the recovery database and then clean them out to start fresh.

It did the trick and now things are working fine.

Thanks for all your help

<>

---

Just for future reference (my own mostly) , I did do some additional troubleshooting

The outbound save message really had x0a after each segment.

Code:

000838f0 7c525553 5045440a 4f42587c 347c5458 |RUSPED.OBX|4|TX
00083900 7c363832 3134345e 4e2e474f 4e4f5252 |682144^N.GONORR
00083910 484f4541 45204259 20544d41 7c317c4e HOEAE BY TMA|1|N
00083920 45474154 4956457c 7c4e6567 61746976 EGATIVE||Negativ
00083930 657c7c7c 7c467c7c 7c323030 35313032 e||||F|||2005102
00083940 35303834 337c4f4d 4c5e5e5e 30353130 50843|OML^^^0510
00083950 32343036 3334367c 52555350 45440a4e 2406346|RUSPED.N
00083960 54457c31 7c7c4e65 69737365 72696120 TE|1||Neisseria
00083970 676f6e6f 7272686f 65616520 62792054 gonorrhoeae by T
00083980 4d412069 73204644 41206170 70726f76 MA is FDA approv
00083990 6564206f 6e6c7920 666f7220 656e646f ed only for endo
000839a0 63657276 6963616c 0a4e5445 7c327c7c cervical.NTE|2||

At one point I thought it might be the the delivery protocol so I made a copy of the thread and routes, keeping everything except setting the copy to deliver the message to a file

The message in the copy was correct, so I could eliminate the xlate, tcl procs and other settings in for the route and thread.

I knew the protocol was working for other threads without a problem so that led me to look a the actual data.

The data format was ok for the thread copy – so that (along with Ryan’s suggestion about resent messages) let me to consider something in the pending message was causing the trouble.

[Author]

Replies