Inbound Thread in Opening Status

Tim,

FCirst I would check the Inbound SMAT in and (hopefully you have this turned on) the SMAT out for the Inbound thread.

I would validate that indeed during the period of time the thread is in an ‘opening’ state you really did receive messages and generated acks. I suspect that is not true.

That does not solve your issue but does indicate the sending system is or is not to be relied upon to report accurately the real message flow or there is someone else responding.

Ask the vendor to provide the acknowledgment messages they received (hopefully you are following the standard with the acknowledgments and are using MSH-3 through MSH-6 properly and are echoing their MSH-10 in the MSA as well as providing your own MSH-10 on the acknowledgment. That may be a clue that you have another thread somewhere listening on the same port.

Look into the process log when this occurs and see if there are any warnings or errors that indicate the remote side shut down.

Tom,

Now I would really doubt they are receiving acknowledgments from anyone.

The remote side shutting down is an indication they are stopping for some reason but not releasing the port (there are a number of reasons that can occur see other forum discussions regarding this).

Is there a firewall in the way?

If no firewall is the sending system windows based (seems like a lot of windows applications do not know how to do TCP/IP properly)?

It would be ideal if you had access to the sending system and they had even half of the troubleshooting facilities Cloverleaf has so you can verify what is happening.

At this point I would definitively say it is unlikely Cloverleaf is the issue.

Is the port number in the ephermal range?

On our AIX Cloverleaf server any port >= 32K (32,768) is in the ephemeral range and should be avoided being used for a cloverleaf interface listener because control of those ports can and do get grabbed away.

a usefull command I’ve used to help with trouble shooting suspect port conflicts is

lsof -i tcp

which will list all the port numbers and the pids using those ports.

With this information I can investigate the pid to see what is consuming that port in the event I have a port conflict this can pin point the culprit.

You might have to set a cloverleaf alert to catch as close as possible to the time when the interface goes to opening becuase if there is a port conflict it sounds like it doesn’t last all that long.

If your port number is below the epermal range then I would expect a port conflict to be more consistant than the random behavior you describe which would be expected for port numbers in the ephermal range.