State 16

Basically what you need to do is to keep track of the number of retries and move the data message out of the way if it goes past a certain number.

The Proc   validate_reply   does this but requires a different setup on the outbound tab of the thread.  Below is from the Notes in the tclproc on my system:

# Notes:

#               Needs the following procs to run correctly:

#                       save_ob_msg (OB DATA TPS)

#                       kill_ob_save (IB REPLY TPS — AFTER THIS PROC!)

#                       resend_ob_msg (REPLY GEN TPS)

#

#       This proc requires an argument for the following

#

#       {ACKTYPE AA} or {ACKTYPE CA}

#       {MAXRETRIES 1} or whatever you need.

We have used this in the past but changed to cl_check_ack.

Hope this helps out.

Rob

Mike,

It sound like the receiving system is trying to process the message before acknowledging.

In my opinion they should not be doing that. They should just acknowledge receipt of the message. If there are issues with the content of the message then that should appear in an error subsystem (log or whatever) on their system to be worked by them.

Many systems have a configuration option to either acknowledge without processing or process first and frequently the default is process first. Many of the vendor’s field personnel in these cases don’t even know there is such an option or what it means. You may be able to get that changed by just asking.

That would solve your State 16 issue without doing anything (of course the issue about what is wrong with the data still remains).

But if they insist they have to process the message before acknowledging then I think it is eminently reasonable to require them to send an negative acknowledgment when there is an issue (using the appropriate fields in the acknowledgment to let Cloverleaf not only know there was an error but what the error was even if it is something like ‘found an unexplainable error’).

You would then need some code (if you don’t already have some) to handle the acknowledgment and you can take whatever action you want with the held message including some sort of notification to someone who would need to investigate.

So how will you differentiate between a timeout that occurred because the receiving system is hung versus a legitimate timeout because something between Cloverleaf and the receiving system is slow enough to cause the timeout?

If you happen to have a network issue for example, you could throw a lot of errors into the Error DB causing you a lot of work.