Date   : Sat, 09 Aug 1986 21:58:00 MDT
From   : Keith Petersen <W8SDZ@SIMTEL20.ARPA>
Subject: Telenet PC Pursuit will not upload certain files

The following is relayed from GEnie's CP/M RoundTable.

--Keith Petersen
Arpa: W8SDZ@SIMTEL20.ARPA
uucp: {ihnp4,allegra,cmcl2,dual,decvax,mcnc,mcvax,vax135}!seismo!w8sdz
GEnie Mail: W8SDZ
RCP/M Royal Oak: 313-759-6569

---forwarded message---
TO:       All PC Pursuit Users

WARNING:  PC Pursuit will not upload certain files!

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

As if the busy signals and disconnects were not enough (sigh),
listen to this...

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.

I have verified the above with Telenet customer service and
engineering representatives.  Their response was that this is an
unfortunate result of the established Telenet command structure,
and it is not likely that any attempt will be made to provide a
solution to this problem for PC Pursuit customers!  (Considering
the difficulty of making network connections at almost any hour
of the night, I'm sure there must be A LOT of us PC Pursuers out
there...  At $25 per month each, I had hoped we deserved a better
response than that.)

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:

1.  Change the file compression.  I.e., (un)SQueeze or (un)CRUNCH
    the file, as appropriate to its original form.  Then leave a
    message to the remote system's SysOp requesting that the file
    be restored after it is received.

2.  If you are using XMODEM-CRC mode, try Checksum mode (or vice-
    versa).  If you are using 1K-byte (YMODEM) transfers, try
    using the slower 128-byte transfers instead.  Either of these
    changes may allow recovery from a small class of situations
    which could cause the problem.

The following facts should also be noted:

1.  This problem occurs only with uploads.  Downloads from a
    remote system are not affected.

2.  Once such a file transfer has been aborted, you have NOT lost
    your connection to the remote system!  Simply issue the
    command CONT (continue) at the Telenet @ prompt.

I hope this information will save others the hours of aggravation
it has caused me.

                                Bob Freed
                                Newton Centre, MA
                                August 6, 1986

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -