Joint messages

[David Teh]

Hi folks,

On QDX 3.8.1P.

I am following up a case where the receiving system is saying they got messages joined together.

If I am checking the messages in SMAT, and they appear as individual messages, would that be sufficient to conclude that they were indeed sent to the receiving system as individual messages?

Anyone have encountered similar situations?

TIA!

Topic

[Ryan Boone]

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?

[David Teh]

Hi all,

Additional infor.

Connection to the receiving system is via PDL-TCPIP. Recovery33 is implemented.

TIA!

[Michael Hertel]

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

[Anonymous]

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).

[David Teh]

Hi Greg and all,

Thanks for the replies.

Is it possible for some problems in Recovery 33 (in the procs themselves or when receiving system should ack too slowly) to cause such a problem? In this case, the message(s) would be sent from memory and not captured in the outbound logs?

Thanks!

[Charlie Bursell]

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.

[David Teh]

Hi folks,

Some more findings.

1. ‘x0d’ is indeed missing from the joint messages, although according to SMAT, they were sent as individual messages. However, I did spot a few messages without the ‘end ‘x0d’ but the receiving system has confirmed they were received as individual messages.

2. In the process logs, I found traces of the ‘problem’ messages indicating they were sent out successfully. But a little after , error messages pertaining to the same message would appear as follow:

~~~~~~~PASTE PARTIAL PROCESS LOG~~~~~~~~~~~

[pd  :pdtd:ERR /0:   threadname] Tcl error:

msgId = message0

proc = ‘tpsSaveObMsg’

args = ”

result = ‘(SAVE_OB_MSG/threadname) FATAL ERROR! Attempt to save over message ‘message2’ with message ‘message0”

errorInfo: ‘

(SAVE_OB_MSG/threadname) FATAL ERROR! Attempt to save over message ‘message2’ with message ‘message0’

   while executing

“error $errmsg”

   (“run” arm line 27)

   invoked from within

“switch -exact — $mode {

       start {

           # Initialize the ob_save global if needed

           if {[lsearch [info globals] ob_save] == -1}…”

   (procedure “tpsSaveObMsg” line 11)

   invoked from within

“tpsSaveObMsg {MSGID message0} {CONTEXT send_data_ok} {ARGS {}} {MODE run} {VERSION 3.0}”‘

~~~~~~~END PASTE PARTIAL PROCESS LOG~~~~~~

Thanks folks.

[Michael Hertel]

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

[David Teh]

>This smells like you do not have all the recover33 procs in all the

> right places.

Let’s run through the config:

INBOUND REPLIES:

– ‘Await Replies’ selected, with Timeout: 10

– Reply generation with tpsResendObMsg

– TPS Inbound reply: – tpsKillObSave  – hcitpsmshkill {DISP KILLREPLY}

OUTBOUND DATA:

Send OK procs: tpsSaveObMsg

All procs are as supplied from Quovadx. Anything missing?

>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.

Is that a ‘misconfiguration’ on the receiving system?

I am still having problems trying to visualise the chronological events.

Anything else to check?

Thanks!

[Michael Hertel]

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

[David Teh]

Hi Michael,

>Turn your time out from 10 to 30.

How would this affect the issue?

>Is the proc name really mshkill or msgkill?

Sorry, typo. It’s msgkill.

Thanks!

[Michael Hertel]

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

[Author]

Replies