Dynamic pool problems when using TCPIP on VMS 8.2

[Christopher Blackburn]

We are having a problem using the VMS TCPIP
services to send/receive blocks of information via sockets on two networked VMS machines. The operating system on both machines seems to run out of dynamic pool memory. This previously worked without problem on VMS 7.3.

The dynamic pool appears to start with 90M of memory and soon runs out. Terminating all application processes does not return the memory to the pool.

Is there any way of working out which process is using the dynamic pool and for what reason ?

Many thanks in advance - Chris.

[Volker Halle]

Chris,

first make sure you have installed the most recent patch: TCPIP V5.5 ECO 1

You are talking about nonpaged pool, right ?

There are 2 ways to start diagnosing this type of problem (called a 'pool leak'):

- run your application until nonpaged pool has grown significantly. Then stop the app.

$ ANAL/SYS
SDA> SHOW POOL/NONPAGED/SUMMARY

Find out which packets consume most pool. Note the packet type and/or sub-type

Look at the packet headers of those packets:

SDA> SET OUTPUT x.x
SDA> SHOW POOL/NONPAGED/HEAD/TYPE=xxx
SDA> SET OUTPUT TT:

SDA> SPAWN TYPE/TAIL x.x

This will show you the packets of this type allocated from the high end of nonpaged pool, i.e. those packets allocated most recently. You can then also look at individual packets to try to figure out from their contents, where they may belong to.

- turn on pool checking

The easiest way is SYSGEN> SET SYSTEM_CHECK 1 and reboot. Once your application is running and pool has grown, consider to force a crash (press HALT button and >>> CRASH). In the dump, you can look at the pool ring buffer with:

SDA> SHOW POOL/RING and find the caller's PCs.

You can also use the first method shown against the dump, to find out, which code has allocated all those packets, which are depleting your pool.

Assuming that your application itself is not using privileged code and allocating pool, chances are quite high, that you're seeing a bug in TCPIP. Or at least some program bug, which is eating up lots of TCPIP resources. Did you check for the number of BG devices increasing ?

Once you've collected some information from the system or the dump, feel free to attach the info as a .TXT file and we're here to help.

Volker.