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.