When you say ‘stuck in pending’, do you mean that the are queued on the Outbound thread (which is connected)? If your thread is ‘Awaiting Replies’ and you aren’t getting ACKs back from the external system, that could be the cause.
You may have await replies set but are you getting ACK’s back. On that outbound thread, check the “Last Rd” time to see if it closely matches the time of the “Last Wt”. If there is a significant time gap, the destination may not be returning ACK’s.
Status : up Started: Fri Dec 20 13:32:32 EST 2019
Msgs in : 0 Last Rd: Never
Bytes in : 0
Msgs out : 2 Last Wt: Fri Dec 20 13:32:43 EST 2019
Bytes out : 1892
Proto Info: N/A
Proto Err : Fri Dec 20 13:35:36 EST 2019
Error Msg :
Xlated: 0 Pending: 1 Forwarded: 0 Failed: 0
IB Lat: 0.000 OB Lat : 853.576 Total Lat: 8.319
Looks like it is as Tom indicated – no acknowledgments being received (note Msgs IN is zero). With a wait forever timeout (-1) messages will stay pending until the receiving system sends and acknowledgment.
There may be additional issues at play but for right now it appears you are not getting acknowledgments from the receiving system.
email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.
First, you should not set await replies to forever (-1) because of the gridlock issue you have. If it is taking a long time for vendor to respond set it some high value like 300. Most interfaces are set to 30 or 60.
Some vendors implement TCP/IP without regard to the spec. So if they shut down and do not send a FIN message there is no way for Cloverleaf to know.
If you set the timeout to a reasonable value at least you will know you are resending so the interface is down. Then you need to have a discussion with the vendor.
I would suggest a network sniffer on the port so you can see what is really on the wire. Without it you always will get fingers pointing in both directions.
SMAT the inbound data (on your outbound thread) to see what ACK the downstream system is sending, if any at all. This will give you some confidence either way to definitively point the downstream system toward.
On your Outbound tab of the thread, are you using any proc to handle the TPS Inbound Reply? The “cl_check_ack” will validate the ACK message while the “hcitpsmsgkill” will accept any type of reply from the receiving system.
When things go awry, ALWAYS check the error database. It never fails when “everything is built correctly” but it still isn’t working right.
The issue was due to a timeout setting for the ack on the receiving system. I wasn’t receiving the ack and once they modified this setting items went through.
.
.