Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!necntc!linus!mbunix!jcmorris
From: jcmorris@mitre-bedford.ARPA (Joseph C. Morris)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Problem redirecting to COM1 in DOS 3.3
Message-ID: <30726@linus.UUCP>
Date: 2 May 88 16:32:04 GMT
References: <22210@teknowledge-vaxc.ARPA>
Sender: news@linus.UUCP
Reply-To: jcmorris@mbunix (Morris)
Organization: The MITRE Corporation, McLean, VA.
Lines: 31
Keywords: DOS 3.3 COM1
Summary: Look at CTS/DSR/DCD

In a recent article Doug Harvey writes:
>I just received the following message when trying to redirect
>output to COM1 (which is connected via null-modem to a Sun
>workstation):
>
>  c:\>  echo logon > com1  [enter]
>
>	Write fault error writing device COM1
>	Abort, Retry, Ignore, Fail? 
 [...]
>The line is configured (on the Sun, anyway) at 9600 baud, and it
>works great when using Crosstalk or Kermit 2.3.  

Check your null modem cable.  I would suspect that it fails to provide
at least one of the DSR, DCD, and CTS leads.  KERMIT will cheerfully 
transmit into a dead connector, but it's possible that DOS will not.  I
don't know if CROSSTALK requires that the leads be asserted, but if it's
like most comm programs it will ignore them.

Try strapping the null modem so that DTR (Data Terminal Ready) on each end
drives DSR (Data Set Ready), DCD (Data Carrier Detect, also sometimes called
Received Signal Level Detect or RSLD), and CTS (Clear  to Send) on the other
end of the cable.  In pinouts, that's saying that pin 20 on one end of
the null modem  cable should be connected to pins 5, 6, and 8 on the other
end.

An alternative strapping preferred by some systems (just to confuse matters)
drives each end's CTS from its own RTS lead, and drives each end's DSR and
DCD from the opposite DTR.  Strap 4 and 5 together in each plug, then strap
20 on one end to 6 and 8 on the other.

Good luck.