Joint messages

Interesting — I’ve just had this very thing occur but haven’t resolved it yet. If you’re using FTP or disk out and appending to file, it would join all of the messages together. But we’re not appending. And, our individual messages each had an end-of-message segment FTS, but the adjoined messages did not. Could be a problem with the receiver system, but I don’t know at this point. I haven’t seen any others, so I suspect so. Is that the same case with you where there was an isolated incident?

If you know this happens all the time, turn up the engine output on that thread. Then look at the hex dump going out to them.

Make sure the message is formatted data

The last three characters should actually be

The first terminates the last segment.

Next check that you don’t have an extra in the data portion of the message.

That’s a start. We can go further if this checks out ok.

-mh

David,

The answer to your original question is yes, if SMAT says it’s one message then it’s one message.

If a receiver claims that it received two messages in one phrase the only possibilities would be that a translation or TCL procedure did the combining.  But if SMAT says the two messages were descrete then it could only have happened on the receiver end (because it would have received a reply to each descrete message).

In a word – no.  Unless you have modified the recover_33 procs in some way to do that.

I would suggest to you that perhaps the receiving system itself is joining the two messages based on what you see.  It is possible that when two messages come into their buffer close together,  they raed the entire buffer rather the individual messages.  It does happen.  Has happened to all of us at one time or another.

Do you have “Await replies” checked?

This smells like you do not have all the recover33 procs in all the right places. If you do not have await replies checked, you won’t be able to define all the places for the different procs.

This would also explain like Charley said, they are reading the buffer and since you didn’t wait for the reply, you over ran them with data.

-mh

I have a customized version of recovery33 procs.

So mine won’t match yours completely maybe someone

else can verify for you, but it doesn’t look like you are

using pure recovery33 procs either.

Here are some more things to try:

Turn your time out from 10 to 30.

Look at your inbound tab and make sure the outbound only box is checked.

Here’s how our procs are configured:

Send OK Procs: tps_save_ob_msg

Timeout: 30

Reply generation: tps_resend_ob_msg

TPS Inbound reply: tps_checkhl7_ack_argv {VERSION 2.4} {VARIANT idx}

Trxid determination Format: HealthLevelSeven

It looks like we are close with our procs but I question your TPS Inbound reply configuration. Is the proc name really mshkill or msgkill? It doesn’t look like you are validating that ACK/NAK coming back.

-mh

The target system may not be able to respond in 10 seconds so the engine will resend the message again. Therefore if the target system had not read the first message, it could have two messages in it’s buffer and that would be what’s causing this problem. You might even have to change the timeout to something higher than 30.

Could you email me a copy of your recover33 proc file?

I want to read the header of the file where it tells you how

to configure your interface. Also, I’d like to see what these procs are doing.

I believe you need a validation proc for the reply message and

I believe your “TPS Inbound reply” configuration needs tweaking.

You can email to pgmmjh@vmmc.org

Thanks,

-mh