home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!spool.mu.edu!telecom-request
- Date: Sat, 19 Dec 92 00:53:48 CST
- From: Jack.Winslade@ivgate.omahug.org (Jack Winslade)
- Newsgroups: comp.dcom.telecom
- Subject: Re: US Sprint's PC Pursuit
- Reply-To: jack.winslade%drbbs@ivgate.omahug.org
- Message-ID: <telecom12.910.10@eecs.nwu.edu>
- Organization: DRBBS Technical BBS, Omaha
- Sender: Telecom@eecs.nwu.edu
- Approved: Telecom@eecs.nwu.edu
- X-Submissions-To: telecom@eecs.nwu.edu
- X-Administrivia-To: telecom-request@eecs.nwu.edu
- X-Telecom-Digest: Volume 12, Issue 910, Message 10 of 11
- Lines: 26
-
- In a message dated 08-DEC-92, <mlksoft> writes:
-
- > Having used PC Pursuit since 1986, I second PAT's comments.
- > If you understand the limitations of packet networks, it works
- > admirably for applications as diverse as interactive dialup,
- > asynchronous DECnet, and UUCP. At $30 for 30 hours of non-prime
- > time, it is a good deal, especially if your usage isn't exclusively
- > file transfers.
-
- A few years ago, I tried using PCP for UUCP (g) transfers between here
- (Omaha) and the LA area. I NEVER got it to work right, despite
- playing around with the various PCP parameters. Typically it would
- make it through the initial 'chat' phase and the init a/b/c handshake,
- but when the actual session started it would kind of squirt back and
- forth for a while and then error out and abort. Closing the window
- size seemed to increase the time before failure, but not eliminate it.
-
- However, I must admit that it works quite well with Zmodem transfers.
- On very large files it seems to predictably generate one error (buffer
- barf ??) every 200k or so, but this recovers nicely.
-
-
- Good day. JSW
- Ybbat (DRBBS) 8.9 v. 3.14 r.1 DRBBS (1:285/666.0)
-
-