[comp.sys.sun] Serial line problems under SunOS4.0

ralph@laas.laas.fr (Ralph P. Sobek) (01/14/89)

In our lab we normally have all our consoles set at 8-bits, no parity.  We
just tried to attach two consoles to devices ttya and ttyb on our
Sun-3/60M running under SunOS4.0.  I am unable to set ttya to remain
8-bits w/0 parity, and our system engineer is not familiar with
asynchronous lines.  Our system engineer said that we have never had such
problems under 3.x, so maybe this is a problem with 4.0.  As Bob Cuningham
in article <8812051941.AA14574@kahala.hig.Hawaii.Edu>,
bob@kahala.hig.hawaii.edu (Bob Cunningham) writes:

| Here is a quick overview of most of the fixes for Sun3s:
| 
| 	*LOTS* of serial driver fixes, including some ALM-II fixes
	[The emphasis is mine.]

Our problem is that ttya wants to be 7-bits with even parity.  Initially,
everything on the screen came as 7-bits, even.  Changing /etc/gettytab
entry for std.9600 to include the option `p8' allowed the login prompt to
be issued correctly.  Adding the same option to the default entry allowed
the `Password:' prompt and the banner to be issued correctly.  After that,
the machine switchs to 7-bits, even parity.

Only when the line is physically deconnected over a period of time will
the session be carried out 8-bits, no parity according to stty.  After
logout, it will revert to the above behavior of switching to 7-bits, even
parity after the start of the next login.  Sorry for not being more
specific but I do not understand the system's behavior more precisely, but
recently even a physical disconnection was unsuccessful to keep a session
at 8-bits, w/o parity.

As an aside, ttyb declares itself to be 7-bits, even parity but does not
care if a console configured at 8-bits no-parity is connected.

A related question is how does one activate RTS/CTS flow control?

Thanks in advance,

Ralph P. Sobek			  Disclaimer: The above ruminations are my own.
ralph@laas.laas.fr			   Addresses are ordered by importance.
ralph@laas.uucp, or ...!uunet!mcvax!laas!ralph		If all else fails, try:
SOBEK@FRMOP11.BITNET				      sobek@eclair.Berkeley.EDU