My first thought was "Go to the TCP/IP messages manual"... But the two messages
weren't in there. (IBM? You listening?)
So... Search for "Small data buffers" in the Planning and Customization manual, and
you'll find topic 4.52, which tells how to change the number of buffers initially
allocated. The default is zero. If you set this to 60, you shouldn't see the messages.
However, since TCPIP will automatically allocate an additional 10% whenever the pool
drops below 5% available, this may or may not be why your TCP/IP locked up.
Under normal operation, use the "NETSTAT POOLSIZE" to monitor the buffers being used
in the various pools. It will tell you the number of each type of buffer allocated,
the current number used, the "lo-water" mark; the smallest number available, and the
number of available buffers below which you'll see a warning. The "NETSTAT RESETPOOL"
will clear the lo-water information so that you can get a more current feel for what's
going on. Initially, lo-water is the lowest number of buffers since TCP/IP started.
Not sure you really saw a "crash"; it may have just been really, really slow, since it
was messing with buffers. You might look into what was going on at that time that
would have put a load on TCPIP... File transfer, lots of users, ... something
triggered the incident. But when your users can't get to the system, it's hard to say
"Let's see if this clears up in a bit..." Restarting TCPIP did no more harm than the
condition which caused you to try it.
----
Robert P. Nix internet: [EMAIL PROTECTED]
Mayo Clinic phone: 507-284-0844
RO-CE-8-857 page: 507-270-1182
200 First St. SW
Rochester, MN 55905
---- "Codito, Ergo Sum"
"The three chief virtues of a programmer: Laziness, Impatience and Hubris."
-- Larry Wall, author of Perl
> -----Original Message-----
> From: Ramon Gutierrez Camus [SMTP:[EMAIL PROTECTED]
> Sent: Wednesday, October 01, 2003 11:56 AM
> To: [EMAIL PROTECTED]
> Subject: "TCP/IP is low on Small data buffers" message DTCMON402W (and TCPIP
> z/VM user "crash")
>
> Hi All,
>
> Our TCPIP z/VM "user" was up and running from Jul 2003... until now...
>
> This morning the TCPIP user crashed (or something like a crash): Not ICMP, not
> tn3270, nothing... The only way to administer our Linux guests (and the z/VM
> environment) was "go stairs down", and do a logon at the hardware console.
>
> I don't know anything about z/VM. (Sorry... I'm a poor Linux sysadmin ;)...
> and I take the "easy" mswindows way:
>
> 1) From MAINT user I could see the TCPIP user running and DSC --disconnected--
> (Q NAMES)
>
> 2) I did logon / logoff TCPIP user.
> (#CP LOGOFF)
>
> 3) I did a LOGON TCPIP again, and a "#CP DISC".
>
> ... and everything go up...
>
> Now, we needed to know what happened, and how we can solve this problem for
> the future.
>
> We can see this messages in a TCPMAINT log:
>
> 10:23:03 DTCMON402W TCP/IP was very low on Small data buffers. Of 23 blocks,
> 11 are free after 11 more were allocated.
> 10:23:45 DTCMON402W TCP/IP was very low on Small data buffers. Of 34 blocks,
> 12 are free after 11 more were allocated.
> 10:24:34 DTCMON401I TCP/IP is low on Small data buffers. Of 34 blocks, 2 are
> free. You should monitor this.
> 10:24:37 DTCMON402W TCP/IP was very low on Small data buffers. Of 45 blocks,
> 12 are free after 11 more were allocated.
> 10:25:20 DTCMON402W TCP/IP was very low on Small data buffers. Of 56 blocks,
> 13 are free after 11 more were allocated.
>
> z/VM Version 4 Release 3.0, Service Level 0201
> built on IBM Virtualization Technology
> There is no logmsg data
> FILES: 0001 RDR, 0007 PRT, NO PUN
> RECONNECTED AT 10:36:52 UTC WEDNESDAY 10/01/03
>
> B
> CP LOGOFF
> CONNECT= 99:59:59 VIRTCPU= 003:55.69 TOTCPU= 004:55.23
>
> ^^^^^_________ This is my LOGON / LOGOFF secuence before the restart.
>
> Do you know where can I get more information about those "DTCMON401I" and
> "DTCMON402W" messages?
>
> Some TCPIP parameter or OSA/QDIO configuration file that we must review?
>
> Regards,
> --Ramon
>
>
> --
