How to dynamically monitor UCX quota's.

[Kees van den Bos]

Is there a way to monitor UCX stack parameter usage? Our application has some I/O servers which use the UCX stack to interface with other devices. Now we see regularly a TCP quota has been exceeded but can't determine which one and also want to see the usage of the TCPIP subsystem quota's. Is there any program that can do this, like SHOW_QUOTA.COM which is used on DCL prompt?

System info :
UR21:SMSC> mc ncl sho impl

Node 0
at 2005-02-03-06:02:00.331-03:00I0.145

Characteristics

Implementation =
{
[
Name = OpenVMS Alpha ,
Version = "V7.3-2 "
] ,
[
Name = HP DECnet-Plus for OpenVMS ,
Version = "V7.3-2 25-OCT-2003 02:41:13.63"
]
}

UR21:SMSC> ucx sho ver

HP TCP/IP Services for OpenVMS Alpha Version V5.4 - ECO 2
on a AlphaServer DS15 running OpenVMS V7.3-2

[Kris Clippeleyr]

Hi Kees,

Have you tried the "netstat" command? (various flags give various data).
You can increase the quota for TCP by
$ TCPIP SET [CONFIGURATION] PROTOCOL TCP /QUOTA=(SEND=bytes,RECEIVE=bytes)

Kris (aka Qkcl)

[Kees van den Bos]

The quota what has been tripled from default value since is :

sysconfig -r inet tcp_sendspace=184320

And also put in tcpip$systartup.com

We have noticed this really helped but i just wanted to know if somebody has any knowledge of a script that actively can monitor a process using UCX quota. I have the one that shows the SYSGEN quota usage but it doesn't show any TCPIP INET or SOCKET subsystems in it.

[Kees van den Bos]

And just checked with :
tcpip> show protocol/param

The only quota for TCP protocol to send over is the same as has been tripled with sysconfig before.

[labadie_1]

I would begin by applying the Eco 4 of Tcpip 5.4

[Kees van den Bos]

And installing ECO4 is just a bit problematic since our application for SMS traffic must be fully tested on every OpenVMS version and layered products. But the same is seen on previous TCPIP stack releases also so i don't think ECO4 will solve this. I am sure it is not a UCX related bug but more the other party not responding quickly enough and our application just keeps on sending. We should stop sending in this case ofcourse but the other side should respond timely also so the problem is where is the "breakpoint"....

[labadie_1]

As you problem is serious, you should log a call at HP, preferably with a reproducer, so that you problem is fixed for all Ucx/Tcpip versions.