[Carole Arthurs]

Our Radiology dept in their testing, put TEST**** in their transcription.  Our vendor had some old legacy code in their listener for x12 messages.  In x12, ST* denotes the END of a message (news to me).

Thanks to all for your help and suggestions, I am much wiser now and it helped considerably in proving to vendor that the issue was on their end.  

TGIF!

[Carole Arthurs]

I have re-sent my result (one order result) several times to my receiving system.  When I cycle the message processor on that system and resend my results, it consistently ‘pops out’  of the message at OBX 33.  When I have not cycled the processor, the results seem less consistent, it sends an ack mid-message and then tries to process the remainder of the msg as a new msg.

Although I can see from my process log that the message is going to the receiving system as a complete message – I am wondering if THAT system is exiting the message due to some kind of control character.

Question:  How/where exactly would I be able to see ‘control’ character in my  OBX?  The line in question has no text.

THX

[Carole Arthurs]

HL/7 messages

Answer:  Yes

Does your Receiving System send an HL/7 Acknowledgment for each message?

A:  Yes

Do you have Clovereaf(R) configured to Await Replies for the Receiving System thread?

A:  Yes

Do you have acknowledgment handling implemented (Recover33 procs)?

A: I am unfamiliar with the Recover33 procs, the thread is set up to await replies.

Have you turned up the Engine ‘Noise’ level (EO Config) so that you can see in the log what Cloverleaf(R) is sending (and maybe what is coming back)?

A:  (which is a question) Is this something other than viewing the output from the thread?

Addl Question:  If my xlate is calcing the number of OBX segments, could I possible have a variable that is not getting reinitialized, could this confuse Cloverleaf as to where msg begins and ends?

[Carole Arthurs]

Yes and yes.  I have it as .GIF , also tried .BMP

[Author]

Replies