home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / os / os2 / misc / 44147 < prev    next >
Encoding:
Internet Message Format  |  1993-01-27  |  1.9 KB
  1. Path: sparky!dsndata!backbone!crcnis1.unl.edu!price
  2. From: price@helios.unl.edu (Chad  Price)
  3. Newsgroups: comp.os.os2.misc
  4. Subject: Re: TCP/IP Package
  5. Date: 27 Jan 1993 21:16:18 GMT
  6. Organization: University of Nebraska--Lincoln    
  7. Lines: 32
  8. Message-ID: <1k6u32INNds8@crcnis1.unl.edu>
  9. References: <A53880@AC3.maus.de>
  10. NNTP-Posting-Host: helios.unl.edu
  11.  
  12. Marc_Van-Woerkom@ac3.maus.de (Marc Van-Woerkom) writes:
  13.  
  14. >Hello!
  15.  
  16. >We plan to connect a PC to our ethernet, which has several UNIX Workstations
  17. >attached (SGI Iris, probably IBM RS6000 in the near future) to it.
  18.  
  19. >I think OS/2 is the proper operating system, but I need some info about
  20. >the TCP/IP package for OS/2. (X-windows? NFS? 3270 emulation?)
  21.  
  22. I'm using IBM's TCP/IP 1.2.1 for OS/2 to write this response (logged into a
  23. sparc via telnet). FTP is a PM app, and works well; X-win works OK to display
  24. things, tn3270 works very well, NFS works OK, send-mail and nameserver stuff is
  25. somewhat unreliable due, I think, to our particular local Token ring -
  26. eithernet - gateway mix. Our primary nameserver is on an ethernet across a
  27. gateway, and the link across that from the token ring is unreliable. This is a
  28. general problem, not necessarily a TCP/IP problem, as when I am logged into
  29. another machine in Lincoln, NE (I work in Omaha, NE - 50 miles away) and try to
  30. get to machines across that gateway, I often have problems with hung
  31. connections or failures to connect.
  32.  
  33. The only real problem is that after a few hours, all of my connections seem to
  34. get dropped and I have to reboot (to restart all of the TCP/IP stuff). I think
  35. I could just rerun the starttcp.cmd batch file after killing all of the TCP/IP
  36. daemons, but I've never bothered. The time period before dropped connections
  37. was increased by quite a bit with the last CSD, but this seems to be a kludge
  38. until they find out what is really causing the problem. Things get dropped
  39. after 3-4 hours.
  40. --
  41. chad
  42. price@helios.unl.edu
  43. cprice@molecular.unmc.edu
  44.