Reply To: Perl over SMAT – The search begins

Jim;

They are TCP/IP connections and we are using system level acks.

I can find the inbound message in the SMAT file (associated to the receiving thread), but NOT in the outbound SMAT file.  That is the strange thing.

Even stranger is when I run the route test, all is good, it shows that the message will be delivered as it should be.

At this point I have 6 messages out of over 15 thousand a day that went MIA at the end of December.  We have not had any other reports of missing data.  I am more and more inclined to say that there was a change in the engine code, but yet I can’t find a change and why did only some of the messages go MIA?  Very strange indeed.

Thus the need to externally audit what I get and what I send.

I am currently working on building a TCL proc that will produce a file with key information if one of the suspect messages is received on the inbound thread.  Then on the outbound thread I will again examine the message for the suspect message type and if found, write to another file (MRN,ACCT,DOS).  Run a diff at the end and the day and if NOT good, I can at least find them before my users do and be able to diagnosis real time instead of a month later.

The perl over SMAT is so I can look at the files produced by the engine and not effect the processing within the engine. (reading every message twice)  Only problem there is that I can write TCL way faster then I can perl.

Jim Kosloskey wrote:

Tony,

I would be intersted to find out if these are TCP/IP connections AND if you are using application level acknowledgment.

If you are not using any acknowledgment protocol, then I find no surprise you might be missing messages. A resend could very well work.

If you are using an acknowledgment protocol, then check the SAMT for the acknowledgments and the foreign system to insure acks were properly processed.

Like Jim Cobane said if they are not in the inbound SMAT, then Cloverleaf did not get them.

Jim Kosloskey