home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / unix / sysv386 / 14486 < prev    next >
Encoding:
Text File  |  1992-09-14  |  2.1 KB  |  46 lines
  1. Newsgroups: comp.unix.sysv386
  2. Path: sparky!uunet!cs.utexas.edu!wotan.compaq.com!moxie!limbic!gil
  3. From: gil@limbic.ssdl.com (Gil Kloepfer Jr.)
  4. Subject: Re: UUCICO synch/alarm problems
  5. Message-ID: <1992Sep15.021449.29001@limbic.ssdl.com>
  6. Summary: Problems with Xyplex
  7. Organization: Southwest Systems Development Labs, Houston, TX
  8. References: <1992Sep5.001101.860@honte.uleth.ca> <JOCHEN.92Sep8192445@busybit.mrz.sub.org> <BuIsL2.L2I@ucunix.san.uc.edu>
  9. Date: Tue, 15 Sep 1992 02:14:49 GMT
  10. Lines: 34
  11.  
  12. In article <BuIsL2.L2I@ucunix.san.uc.edu> loncars@ucunix.san.uc.edu (Sven Loncaric) writes:
  13. >I have a similar problem. 
  14. [...]
  15. >The problem is the following: The off-campus machine successfully
  16. >connects to the on-campus machine and the data transfer starts but soon
  17. >after that the connection breaks because the on-campus machine does not
  18. >respond any more.
  19. [interesting description of connection through terminal server deleted]
  20.  
  21. This looks like a problem I saw with Xyplex terminal servers.  Nothing
  22. I have ever done has made UUCP work over these beasts, and the
  23. commands you included in your article look like Xyplex server commands
  24. (they emulate DECserver-200-like commands).
  25.  
  26. The only thing I could tell when I tried figuring this out a while ago
  27. was that no matter what you told the server, it would still pad a
  28. carriage-return or line-feed (I don't remember which) with a null
  29. character under certain conditions.  UUCP won't tolerate any kind
  30. of padding of characters, as you probably can guess.
  31.  
  32. The host I was trying to connect to both times I tried this was a
  33. DECstation running ULTRIX, which may also have something to do with the
  34. problem.  The awful thing about it was that I could get the connection
  35. to succeed for a short time, then it would fail miserably.  It would
  36. always fail in the same place on the same file.  Other files would
  37. work fine.  The problem was definitely content-related, and as far as I
  38. can tell (not speed-related).
  39.  
  40. Hope this at least saves you some frustration trying to get this to
  41. work.  Certainly if anyone has gotten this configuration to work, I
  42. would love to hear how.
  43. -- 
  44. ! Gil Kloepfer, Jr.
  45. ! gil@limbic.ssdl.com / ...!ames!limbic!gil
  46.