Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!spool.mu.edu!uunet!zephyr.ens.tek.com!tektronix!percy!m2xenix!quagga!ucthpx!uctcs!ken From: ken@uctcs.uucp (Ken McGregor) Newsgroups: comp.sys.ncr Subject: Re: Finding out if TCP/IP is up Message-ID: <1991May16.120829.13363@ucthpx.uct.ac.za> Date: 16 May 91 12:08:29 GMT Article-I.D.: ucthpx.1991May16.120829.13363 References: <91130.081040TEMNGT23@ysub.ysu.edu> Sender: news@ucthpx.uct.ac.za (UCT News Admin.) Reply-To: ken@staff.UUCP (Ken McGregor) Organization: Dept. of Computer Science, University of Cape Town Lines: 26 In article <91130.081040TEMNGT23@ysub.ysu.edu> TEMNGT23@ysub.ysu.edu (Lou Anschuetz) writes: >I have an NCR Tower 700 with 16MB of memory. All my users come in >through the Ethernet board via a terminal server. It is possible >allocating thousands of 2k streams. I am already set at maximum >for 2k streams, so there is nothing further I can do there. The >problem is that WIN TCP/IP on seeing this error quietly dies. > >What I need, therefore, is a way to determine if TCP/IP is up >from cron. If it is not I can do a win restart (a little >undocumented feature....). Are you sure that this will work. We have a similar problem with WIN-TCP on our Tower 600's. Some resource jams and the system fills up the 2k stream blocks. We are only using terminals on the terminal servers - not pc's. When we restart TCP it restarts fine, but the streams are still full, so it never comes up. What we do to solve the problem is a total reboot. We can identify the problem be running crash with input from a file. This runs strstat. Pipe the output into grep 2048, cut on the free field, then test for 0. If so reboot. We run this via cron every 15 minutes. I wish however that there was a solution available to WIN. Ken MacGregor ken@cs.uct.ac.za Computer Science ken%uctcs%quagga@uunet.uu.net University of Cape Town ...uunet!{m2xenix!quagga,ddsw1!olsa99}!uctcs!ken