DTE

1
7-E-1 over EC modem link - traditional
7-E-1 DTE link
7-E-1 DTE link
7-E chars in 8-N octets in EC frames
DTE
Error controlled DCE link
DTE
UART delivers 7N chars to DTE application
UART delivers 7N chars to DTE 7N application
7-E-1 over EC modem link - MICAIOS problem
(CSCdj92333)
8N DMA link
7-E-1 DTE link
8-N chars in 8-N octets in EC frames
MICA
DTE
Error controlled DCE link
IOS
7-E chars in 8-N octets in EC frames
UART discards bad 8-N chars from IOS
MICA delivers 7E chars to IOS 8N application

• IOS 8N app receives bad chars with parity bit
  set
• client-side UART receives bad chars that fail
  even parity check

2
Example case with CSCdj92333 problem - V89888
(NIH)
MICA
7-E-1 PC
Error controlled DCE link
5300
X.25
The PC runs an async comm app (Procomm, Kermit,
etc.) which sets the COM port for 7-E-1 and makes
a (possibly EC) connection to the AS5300. The
AS5300 does an autocommand pad to make an X.25
connection to the FEP, which handles the terminal
connection into the mainframe app. MICA receives
the 7-E octets from the DCE link and passes
them as-is to IOS, which passes them as-is into
the pad connection. The FEP app strips the high
bit and passes the data onto the mainframe
(converting to EBCDIC or who knows what.) The
mainframe receives the data OK. Then the FEP
sends 7-bit ASCII back to the 5300, which passes
it to MICA which sends it out as 7-S (I.e. with
the high bit clear) onto the DCE link. When this
data is received by the COM port, the 7-S
characters that happen to have an odd number of
bits lit are rejected by the UART as having bad
parity. Hence the application fails.
MF
FEP
Although in this case the receiving
application has no problem dealing with the
octets with the high bit lit, there certainly
are other applications that must see the high
bit clear in order to work (e.g. IOS itself.)