Using a Sniffer, we've noticed that ADSM sends out packets, typically 598 or 604 bytes in size. When we look at the packet in greater detail, the actual data portion is 536 bytes, with the remainder
Author: Paul Zarnowski <VKM AT CORNELLC.CIT.CORNELL DOT EDU>
Date: Mon, 20 Nov 1995 14:53:53 EST
I don't know about MVS, but on an AIX server you can use the 'no' (network option) command to change the tcpip window sizes, as follows: no -o tcp_sendspace=32768 no -o tcp_recvspace=32768 The defaul
Author: Howard Heitner <CCHH AT MUSICA.MCGILL DOT CA>
Date: Mon, 20 Nov 1995 15:01:41 EST
I mentioned this to one of our network people and he seemed to think that this was the size of an IPX packet. He also said that indeed the packet size is determined by the media (ethernet, etc.). How
Thank you. We do indeed use IPX. I should have also mentioned that our network is token-ring based. So are you telling me that the IPX packet is a fixed size, and the TCP/IP packet is based on this,
Andy Not knowing how your clients and server are connected and addressed, I'd suggest two possibilities. If you've already looked at these issues, please feel free to ignore this information. The fir
The following is from an upcoming netware client PTF. It could be part of your problem: If running TCPIP V2.75 (3.X) or V3.0 (4X), and the ADSM server is located across subnets, you may want to consi
Author: "Strickland, Jay" <jstrickl AT IPCTECH DOT COM>
Date: Mon, 20 Nov 1995 18:27:11 -0500
Andy, On the Netware servers you might want to check the MAXIMUM PHYSICAL = RECEIVE PACKET SIZE. This is could be your bottleneck. Your TCP = packets will have to fit inside of this. The MTU will be
Author: Andy Raibeck[SMTP:raibeck AT CONNIX DOT COM]
Date: Sun, 04 Oct 2015 18:17:49 -0500
Using a Sniffer, we've noticed that ADSM sends out packets, typically = 598 or 604 bytes in size. When we look at the packet in greater detail, the = actual data portion is 536 bytes, with the remain