A developer of a TCP/IP network reports the following problem. Uploads of
window or file contents are causing serious problems resulting in line
drops. This occurs during EZ read Text (T008), Read Text (T009), Select
Existing File (F017), and probably during EZ Read File Fork (F007) and Read
File Fork (F008).
The developer is currently using the Simple ASCII transport layer (ID = 2)
with 7 data bits. Unfortunately, data in the ranges <00>-<1F> and <80>-<FF>
may be contained within windows or files. In particular, if there is a
carriage return <0D> within the data, then the IBM mainframe front-end
processor (FEP) takes this as an end-of-line character, sends the packet to
CP, which sends the packet to the application, which processes it.
Meanwhile, MacWorkStation continues to send the remainder of the packet up
until the final carriage return, which it uses to signal end-of-line.
Unfortunately, the characters following the first carriage return cause CP
interrupts, leaving the virtual machine in CP mode. After some number of
interrupts, CP determines that the line is too noisy to continue and
signals the FEP to drop it.
The problem here is that they are using a protocol in an unsupported
fashion. The serial protocol driver (ID=2) that uses start and stop
characters is not designed to support the transfer of binary data, or any
data that might contain nonstandard characters. The best choice would be to
use the serial driver (ID=1) that supports binary data and should be able
to handle the transfer of carriage returns. If this is unacceptable,
request a copy of the source for serial driver version 2.