Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!nike!sri-spam!parcvax!hplabs!tektronix!uw-beaver!ssc-vax!uvicctr!sbanner1
From: sbanner1@uvicctr.UUCP (S. John Banner)
Newsgroups: net.micro
Subject: Re: Telenet PC Pursuit will not upload certain files
Message-ID: <180@uvicctr.UUCP>
Date: Tue, 12-Aug-86 12:44:42 EDT
Article-I.D.: uvicctr.180
Posted: Tue Aug 12 12:44:42 1986
Date-Received: Thu, 14-Aug-86 22:01:34 EDT
References: <2909@brl-smoke.ARPA>
Reply-To: sbanner1@uvicctr.UUCP (S. John Banner)
Organization: University of Victoria, Victoria B.C. Canada
Lines: 48

In article <2909@brl-smoke.ARPA> W8SDZ@SIMTEL20.arpa (Keith Petersen) writes:
>The following is relayed from GEnie's CP/M RoundTable.
>TO:       All PC Pursuit Users
>
>WARNING:  PC Pursuit will not upload certain files!

>Under certain circumstances, files may not be uploaded to a
>remote system with Christensen ("XMODEM") protocol using the PC
>Pursuit service of GTE Telenet.  In particular, the three-byte
>ASCII sequence <CR, '@', CR> (binary <0DH, 40H, 0DH>) is ALWAYS
>interpreted as an escape to Telenet command level.  If this
>sequence occurs in an appropriate place within a file, that file
>cannot be uploaded!  The typical effect with most file transfer
>programs is the occurrence of repeated local timeout errors, and
>an apparent loss of connection when the user returns to terminal
>mode to attempt recovery after the transfer is aborted.
>
>Note that this situation is unlikely to occur within an ASCII
>text file produced on CP/M or MS-DOS systems, since CR is almost
>always followed by LF in such files.  But it is certainly
>possible within a binary (e.g. .COM) file.  (The high bit of each
>byte is insignificant to Telenet, so there are actually eight
>different 3-byte binary sequences which may cause this problem.) 
>Also, there is a small likelihood of this occurring even during a
>text file transfer, due to the binary record count and checksum
>or CRC bytes which are generated by the protocol.  From my own
>experience, the problem seems most likely to occur within
>SQueezed files.
>
>As a possible workaround to this problem, I would suggest trying
>either of the following:
[Work arounds deleted.]

Another possibility (I don't use GTE Telnet, so I can't say it will
work, but I don't see why it shouldn't), is simply to use the Kermit
file transfer protocol.  With the exception of line noise, the given
sequence can never occur because all control characters in the file
being transfered are encoded to printables (CR=="#M" I think), and any
'CR's in required by the protocol itself are immeadiately followed by
H01 (Control A).  That would solve all your problems, so long as the
people on both ends are willing to support Kermit (and Kermit
implimentations are free, so the only cost of suport is getting it
[downloading costs?], disk space, and time to learn Kermit [it is quite
easy to learn]).

                 Hope this helps,

                         S. John Banner.