onstat -g ntd -- intepretation please!

We have high number of rejections, some say it's because the applications set timeout after a certain period, but I say it's Informix that rejects those connections -- am I wrong? What approach should we take to eliminate this condition? ------------------- Solaris 10 onstat -g ntd IBM Informix Dynamic Server Version 11.50.FC9W1 -- On-Line -- Up 02:41:40 --46239744 Kbytes global network information: #netscb connects read write q-free q-limits q-exceed alloc/max 92/ 92 3 4419 4711 0/ 0 800/ 10 0/ 0 78/ 78 Client Type Calls Accepted Rejected Read Write sqlexec yes 2520 130 4416 4711 srvinfx yes 0 0 0 0 onspace yes 0 0 0 0 onlog yes 0 0 0 0 onparam yes 0 0 0 0 oncheck yes 0 0 0 0 onload yes 0 0 0 0 onunload yes 0 0 0 0 onmonitor yes 0 0 0 0 dr_accept yes 0 0 0 0 cdraccept no 0 0 0 0 ontape yes 0 0 0 0 srvstat yes 0 0 0 0 asfecho yes 0 0 0 0 listener yes 0 0 3 0 crsamexec yes 0 0 0 0 onutil yes 0 0 0 0 drdaexec yes 0 0 0 0 smx yes 0 0 0 0 safe yes 0 0 0 0 Totals 2520 130 4419 4711

Original post: We have high number of rejections, some say it's because the applications set timeout after a certain period, but I say it's Informix that rejects those connections -- am I wrong? What approach should we take to eliminate this condition? ------------------- Solaris 10 onstat -g ntd IBM Informix Dynamic Server Version 11.50.FC9W1 -- On-Line -- Up 02:41:40 --46239744 Kbytes global network information: #netscb connects read write q-free q-limits q-exceed alloc/max 92/ 92 3 4419 4711 0/ 0 800/ 10 0/ 0 78/ 78 Client Type Calls Accepted Rejected Read Write sqlexec yes 2520 130 4416 4711 srvinfx yes 0 0 0 0 onspace yes 0 0 0 0 onlog yes 0 0 0 0 onparam yes 0 0 0 0 oncheck yes 0 0 0 0 onload yes 0 0 0 0 onunload yes 0 0 0 0 onmonitor yes 0 0 0 0 dr_accept yes 0 0 0 0 cdraccept no 0 0 0 0 ontape yes 0 0 0 0 srvstat yes 0 0 0 0 asfecho yes 0 0 0 0 listener yes 0 0 3 0 crsamexec yes 0 0 0 0 onutil yes 0 0 0 0 drdaexec yes 0 0 0 0 smx yes 0 0 0 0 safe yes 0 0 0 0 Totals 2520 130 4419 4711 Response: I took a look in the code where that rejected counter gets bumped and the bulk of the reasons would be as follows: 1) authentication error (bad password etc) 2) network error on the incoming connection 3) wrong mode (like single user/quiescent mode but a non-allowed type tries to connect 4) some problem starting up a new thread That's how I'd break down the kind of things that cause that to get bumped at a high level. So out of those things, some of those are server specific issues, but some could be client issues (for example the network errors could be a client going away before the server gets to the request). However, it does appear that most, if not all, would log something into the MSGPATH file, which you'd need to look at to see if it's really something that needs to be addressed. For example, if all those rejections happen while the server is coming up because the apps try to connect before it's in multi-user mode (so online) that's not really a problem to be concerned with. Jacques Renaut IBM Informix Advanced Support APD Team

Thank you Jacques. I actually had some quick communication with Paul Watson. I believe I was self alarmed too soon. You are right about #3, we bounced the engine w/o having the apps shut down first, therefore, this rejections probably occurs during the time Informix was coming back up. I consider this issue has been cleared. Regards ________________________________ From: JACQUES RENAUT <jrenaut@us.ibm.com> To: ids@iiug.org Sent: Wednesday, December 19, 2012 10:41 AM Subject: Re: onstat -g ntd -- intepretation please! [29119] Original post: We have high number of rejections, some say it's because the applications set timeout after a certain period, but I say it's Informix that rejects those connections -- am I wrong? What approach should we take to eliminate this condition? ------------------- Solaris 10 onstat -g ntd IBM Informix Dynamic Server Version 11.50.FC9W1 -- On-Line -- Up 02:41:40 --46239744 Kbytes global network information: #netscb connects read write q-free q-limits q-exceed alloc/max 92/ 92 3 4419 4711 0/ 0 800/ 10 0/ 0 78/ 78 Client Type Calls Accepted Rejected Read Write sqlexec yes 2520 130 4416 4711 srvinfx yes 0 0 0 0 onspace yes 0 0 0 0 onlog yes 0 0 0 0 onparam yes 0 0 0 0 oncheck yes 0 0 0 0 onload yes 0 0 0 0 onunload yes 0 0 0 0 onmonitor yes 0 0 0 0 dr_accept yes 0 0 0 0 cdraccept no 0 0 0 0 ontape yes 0 0 0 0 srvstat yes 0 0 0 0 asfecho yes 0 0 0 0 listener yes 0 0 3 0 crsamexec yes 0 0 0 0 onutil yes 0 0 0 0 drdaexec yes 0 0 0 0 smx yes 0 0 0 0 safe yes 0 0 0 0 Totals 2520 130 4419 4711 Response: I took a look in the code where that rejected counter gets bumped and the bulk of the reasons would be as follows: 1) authentication error (bad password etc) 2) network error on the incoming connection 3) wrong mode (like single user/quiescent mode but a non-allowed type tries to connect 4) some problem starting up a new thread That's how I'd break down the kind of things that cause that to get bumped at a high level. So out of those things, some of those are server specific issues, but some could be client issues (for example the network errors could be a client going away before the server gets to the request). However, it does appear that most, if not all, would log something into the MSGPATH file, which you'd need to look at to see if it's really something that needs to be addressed. For example, if all those rejections happen while the server is coming up because the apps try to connect before it's in multi-user mode (so online) that's not really a problem to be concerned with. Jacques Renaut IBM Informix Advanced Support APD Team ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.