From:	CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 26-JUL-1990 23:59:30.29
To:	MRGATE::"ARISIA::EVERHART"
CC:	
Subj:	Re: Help needed w/ modem <-> VMS

Received:  by crdgw1.ge.com (5.57/GE 1.70)
	 id AA06551; Sat, 21 Jul 90 04:25:42 EDT
Received: From UCBVAX.BERKELEY.EDU by CRVAX.SRI.COM with TCP; Fri, 20 JUL 90 22:57:58 PDT
Received: by ucbvax.Berkeley.EDU (5.63/1.41)
	id AA16325; Fri, 20 Jul 90 22:41:14 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
	for info-vax@kl.sri.com (info-vax@kl.sri.com)
	(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 20 Jul 90 20:07:44 GMT
From: crash!simpact!jeh@nosc.mil
Organization: Simpact Associates, San Diego CA
Subject: Re: Help needed w/ modem <-> VMS
Message-Id: <1482.26a70220@dcs.simpact.com>
References: <58324@bbn.BBN.COM>
Sender: info-vax-request@kl.sri.com
To: info-vax@kl.sri.com

In article <58324@bbn.BBN.COM>, bpalmer@bbn.com (Brian Palmer) writes:
> I'm stuck trying to add a dialup line to our Vax so that users can log in
> from home etc.  The VMS manuals say alot about adding a modem for DECNET
> but what about a standard dialup?
> 
> What's the standard config for say a Hayes compatible 2400 MNP Class 5 modem?
> 
> What are the modem settings?

Set the port to /modem /dialup/hangup .  

/disconnect is optional.  

Use a port that supports at least partial modem control; this rules out 
DMF32 ports 2 through 7,  all ports on CXA16, etc.  

Use a straight-through cable that connects at least pins 1 through 8, 
20, and 22.  Er, well, some of those are optional for some modems and/or
for some ports, but some ports won't send any data unless pin 5 (CTS) is
high, some modems want to see RTS high, etc., etc.  One slight cable mod
may be required (see below).  

Set the modem so that 

	a dropped DTR will force the modem to hang up (ie, DON'T ignore  DTR)
	CD (carrier detect) is on only when there is carrier on the line
	 (ie,  DON'T hold CD true at all times)
	DSR follows CD

That last one is a trouble point.  Many Hayes-like modems hold DSR high all the
time; this causes the VAX terminal driver to do its infamous "DTR cycling" 
trick (drops DTR every thirty seconds until carrier shows up).  If you can't 
configure the modem to make DSR follow CD you can do it in your cable:

standard wiring of DSR and CD:

	To modem (female)		To VAX port (male)

	 DSR (6) >--------------------> (6) DSR

	  CD (8) >--------------------> (8) CD

modified to correct for "DSR always on" problem:

	To modem (female)		To VAX port (male)

	 DSR (6) >--------------x  +--> (6) DSR
				   |
	  CD (8) >-----------------+--> (8) CD

I personlly like to do this in an "adapter", a male and female connector in a
little plastic box, and use this along with a "regular" straight-through
cable, rather than having some "regular" straight-through cables and some 
bizarre ones.  

You mentioned MNP.  Uh, oh. 

MNP may require flow control between the VAX and the modem, if there is a
chance that the VAX can send data out to the modem faster than the modem
can send it down the line, or vice versa.  This is tricky with MNP because,
on the one hand, MNP does compression which allows greater throughput than
the raw line speed would allow, and on the other hand, if it's doing error
correction the throughput may drop.  

VAX/VMS will do one-way hardware (CTS) flow control on ports that support 
full modem control; that is, the VAX will stop sending if the modem drops CTS,
and will resume sending when the modem raises CTS.  

	(Yes, it will, dammit.  I have seen it happen on line analyzers, I have
	found the code in the terminal driver that does it, and I've talked to
	the DEC folks who maintain the terminal driver, and they confirm that 
	it's in there for a reason and that it isn't going to go away.  So
	please DON'T send mail or news messages saying "VMS doesn't support
	hardware flow control", okay?)  

The VAX will NOT do RTS flow control -- that is, it will not drop RTS to tell
the modem that the VMS typeahead buffer is approaching fullness, though it 
will, of course, send an XOFF.  

What works for us is to set the host interface speed to a higher value than the
line can support (such as 9600) and let the modem do speed matching between the
VAX and the line, configure the modems at each end to use hardware (RTS/CTS)
flow control, and set the VAX port and the terminal at the far end to use
xon-xoff just like always.  With a 9600 link to the VAX and a 2400 phone
connection, the VAX can of course overrun the modem's buffer -- but when
necessary, the modem can tell the VAX to stop sending for a bit (by dropping
CTS). 

As for the other direction, under normal circumstances the modem can't possibly
supply data faster than it can be sent to the VAX (since we're going from a
small pipe to a bigger one, as it were).  If the VAX's typeahead buffer fills
up it'll send an xoff, which (since the modems are config'd for hardware flow
control, not xon/xoff) gets sent transparently to the terminal at the far end,
locking its keyboard until the typeahead buffer empties and the VAX sends an
XOFF. 

	--- Jamie Hanrahan, Simpact Associates, San Diego CA
Chair, VMSnet [DECUS uucp] and Internals Working Groups, DECUS VAX Systems SIG 
Internet:  jeh@dcs.simpact.com, or if that fails, jeh@crash.cts.com
Uucp:  ...{crash,scubed,decwrl}!simpact!jeh