What would cause a port to freeze up and ignore connection requests?

Greetings, Y'all! We just had an interesting situation, which is not a good thing in this business. All applications that connect through s certain port number (as determined by $INFORMIXSERVER) were hanging. When I connected through a different server alias - which maps to a different port number - all was fine. I even tried that with plain dbaccess. If I specified a database on the server alias for that one port it would hang; but specifying the database @ another alias/port, it connected. And whatever I set INFORMIXSERVER to, the onmode -ky also hung. The only cure was to bounce the engine. In middle of CyberWeek? YIKES!! I had to kill an oninit process to drop the engine. Problem solved for now. But does anyone know of a forensic (or even real-time) method or utility that can tell me what had happened to the port? Overloaded? No error message anywhere, not in the online.log, not in /var/adm/messages. I have the OS (Solaris) and network experts in on this but we are all drawing a blank. IMHO Informix in the victim here, of a network issue. But I have users clamoring for answers so we can either prevent it or catch on quicker when it happens. Thanks much for ideas here. -- JS ------------------------------ +-----------------------------------------------------------+ | I am pleased to report that I had no problems today. | | I had only issues, opportunities, challenges and valuable | | learning experiences. | +------------------------------------------ Jacob S --------+ ------------------------------

Jacob: I would open a support case to see if this is a known issue that has an existing fix. I have vague memory of something like this in some release or two. Art ------------------------------ Art S. Kagel, President and Principal Consultant ASK Database Management Corp. www.askdbmgt.com ------------------------------

dmesg? — Clive Eisen

Typically, this isn't a problem with "the port", but one in the listener thread servicing this port, and maybe even that's just falling victim to a problem elsewhere ... An "onstat -g stk" on that listener thread would provide first and probably best clues, multiple such onstat outputs in a row would help determine if the situation is static (which would explain the perceived hang). We'd go from there determining what other onstats we'd need to see. (-g ath, -g cpu, -g stk all, -g wmx, -g ses 0, -u would be the most important ones) Without this information, even a support case probably had no way of guessing what the problem was. HTH, Andreas ------------------------------ Andreas Legner Informix Dev HCL Software ------------------------------

Yes, check dmesg and /var/adm/messages* Long shot, but there may be something there. ------------------------------ Vladimir Kolobrodov ------------------------------