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 (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 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -