[comp.unix.microport] How do I get *8* data bits *no* parity?

stever@tree.UUCP (Steve Rudek) (11/01/88)

We're running Micrport System V/AT release 2.4 and need to change the tty
default for incoming modem calls from the default (7 data bits even parity)
to 8 data bits no parity to better accomodate new callers.  About 6
months ago, under 2.2, I spent quite a bit of time experimenting with the 
gettydefs file.  As I recall, I tried changing the standard entry:

1200# B1200 HUPCL PARENB CS7 CLOCAL OPOST ONLCR # B1200 HUPCL SANE IXANY TAB3 #login: #1200

to:

1200# B1200 HUPCL CS8 CLOCAL OPOST ONLCR # B1200 HUPCL SANE IXANY TAB3 #login: #1200

but it didn't make any significant difference.  Why not?

Why does UNIX default to 7 data bits/even parity, anyway?  UUCP appears to
configure the line before calling out (once again, I'm drawing on
some fuzzy memories of experiments I ran long ago).  While I understand the
(intended) value of parity when doing file transfers, for interactive use
it seems generally ignored.  If I succeed in switching to 8 data bits will
there be any unwanted side effects I should beware of? 

I was told by one of the tech support folks at microport that the "#" in the
center of the gettydefs record delimits line condition BEFORE login from
line condition AFTER login.  Is this correct?  In general, I'd be fascinated
to hear the full story of what is really going on in a gettydefs entry.
While I can look up the supposed definition of some of these field mnemonics
(e.g., "PARENB" or "CS7") I feel that the UNIX documentation is extremely
inadequate in describing the available options and interactions in line
control settings.

logan@vsedev.VSE.COM (James Logan III) (11/02/88)

In article <130@tree.UUCP> stever@tree.UUCP (Steve Rudek) writes:
>We're running Micrport System V/AT release 2.4 and need to change the tty
>default for incoming modem calls from the default (7 data bits even parity)
>to 8 data bits no parity to better accomodate new callers.  About 6
>months ago, under 2.2, I spent quite a bit of time experimenting with the 
>gettydefs file.  As I recall, I tried changing the standard entry:
>
>1200# B1200 HUPCL PARENB CS7 CLOCAL OPOST ONLCR # B1200 HUPCL SANE IXANY TAB3 #login: #1200
>
>to:
>
>1200# B1200 HUPCL CS8 CLOCAL OPOST ONLCR # B1200 HUPCL SANE IXANY TAB3 #login: #1200
>
>but it didn't make any significant difference.  Why not?
>

Getty sets your line to seven data bits after you type in a login
name if you  don't tell it specifically how many data bits you
want.  (It has default settings so that the line is reasonable
when you don't tell it specifically what to use.)  Put CS8 after
the second pound-sign (#) like this:   

                                                        |
                                                        V
1200# B1200 HUPCL CS8 CLOCAL OPOST ONLCR # B1200 HUPCL CS8 SANE IXANY TAB3 #login: #1200

>...I'd be fascinated
>to hear the full story of what is really going on in a gettydefs entry.

It's pretty simple.  There is a line in /etc/inittab that causes
the init(1m) process to invoke getty(1m) with the specified
arguments.  One of the arguments is the "label" of a line in the
file /etc/gettydefs.  (By the way -- numbers in parenthesis refer
to UNIX manual section numbers; e.g. init(1m) refers to section
1M of the UNIX manuals entitled "System Administration Reference
Guide".) 

The lines in gettydefs(4) have the following format:

label#tty settings before#tty settings after#login prompt text#next label

(I'm doing this from memory, so please excuse me if I left out a
field...)  The "tty settings before" field contains settings that
are put into effect by calling ioctl(2) the first time the caller
types his/her login name.  As soon as the user presses return,
the "tty settings after" are set for the tty port and login(1) is
exec(2)ed, replacing the getty(1m) process.

Login(1) is called with the login name as its first parameter and
prompts the user for his/her password.  When the password is
incorrect, login continues prompting for the login-name/password
until a correct password is entered or its timeout value is
reached.  If The user presses ^D or login times out, login
dies and init(1m) starts another getty process.

Getty uses the "next label" field of the line when the calling user
presses the BREAK key.  When the BREAK key is pressed, getty uses
the line with "next label" in its "label" field and changes the
line settings to the new specification.  

Usually, the lines in gettydefs(4) form a circular linked list from
a high baud rate (like 9600) to the next lowest baud rate, down
to the lowest baud rate (like 300 baud) and back around to the
highest baud rate again.  This allows the caller to press BREAK
until getty matches the caller's baud rate.

The "login prompt text" field is the login message that getty gives
the caller.  You may change this to whatever you want, but after login
is called it uses its own "login:" prompt.

-- 
Jim Logan		logan@vsedev.vse.com
(703) 892-0002		uucp:	..!uunet!vsedev!logan
			inet:	logan%vsedev.vse.com@uunet.uu.net

guy@auspex.UUCP (Guy Harris) (11/02/88)

>As I recall, I tried changing the standard entry:
>
>1200# B1200 HUPCL PARENB CS7 CLOCAL OPOST ONLCR # B1200 HUPCL SANE IXANY TAB3 #login: #1200
>
>to:
>
>1200# B1200 HUPCL CS8 CLOCAL OPOST ONLCR # B1200 HUPCL SANE IXANY TAB3 #login: #1200
>
>but it didn't make any significant difference.  Why not?

Because SANE means "7 bits plus even parity".  Not necessarily my
definition of "sane", but what the hell....

>Why does UNIX default to 7 data bits/even parity, anyway?

Historical reasons, I presume.

>UUCP appears to configure the line before calling out (once again, I'm
>drawing on some fuzzy memories of experiments I ran long ago).

It has to, when using the "g" protocol; that requires an 8-bit data
path.

>While I understand the (intended) value of parity when doing file
>transfers,

Actually, some file transfer protocols use an 8-bit data path, and use
their own checksumming (the "g" protocol mentioned above, for one). 

>for interactive use it seems generally ignored.  If I succeed in
>switching to 8 data bits will there be any unwanted side effects
>I should beware of? 

If you set all your terminals, including dial-ups if any, to 8 bits + no
parity, there shouldn't be a problem - unless other computers dialing in
(e.g., for UUCP) are sending with parity enabled, in which case they may
have trouble logging in.  ("getty" strips the 8th bit itself, but
"getpass", used by "login", doesn't.)

>I was told by one of the tech support folks at microport that the "#" in the
>center of the gettydefs record delimits line condition BEFORE login from
>line condition AFTER login.  Is this correct?

Yes.  That's why the SANE in the "after" settings is undoing the work
you went through to set the character size to 8 bits.  Try replacing
SANE with:

	BRKINT ICRNL IXON OPOST ONLCR CS8 ISIG ICANON ECHO ECHOK

in the "after" settings.

>In general, I'd be fascinated to hear the full story of what is really
>going on in a gettydefs entry.

I got this from prowling the source code; you might try the "getty" and
"gettydefs" man pages, but they may not tell you enough.

>While I can look up the supposed definition of some of these field mnemonics
>(e.g., "PARENB" or "CS7") I feel that the UNIX documentation is extremely
>inadequate in describing the available options and interactions in line
>control settings.

UNIX documentation is often inadequate.

det@hawkmoon.MN.ORG (Derek E. Terveer) (11/03/88)

In article <130@tree.UUCP>, stever@tree.UUCP (Steve Rudek) writes:
> I was told by one of the tech support folks at microport that the "#" in the
> center of the gettydefs record delimits line condition BEFORE login from
> line condition AFTER login.  Is this correct?

As i understand it, "yes, this is true."
-- 
Derek Terveer		det@hawkmoon.MN.ORG
			w(612)681-6986	h(612)688-0667

"A proper king is crowned" -- Thomas B. Costain

jfh@rpp386.Dallas.TX.US (John F. Haugh II) (11/04/88)

In article <130@tree.UUCP> stever@tree.UUCP (Steve Rudek) writes:
>We're running Micrport System V/AT release 2.4 and need to change the tty
>default for incoming modem calls from the default (7 data bits even parity)
>to 8 data bits no parity to better accomodate new callers.  About 6
>months ago, under 2.2, I spent quite a bit of time experimenting with the 
>gettydefs file.  As I recall, I tried changing the standard entry:
>
>1200# B1200 HUPCL PARENB CS7 CLOCAL OPOST ONLCR # B1200 HUPCL SANE IXANY TAB3 #login: #1200
>
>to:
>
>1200# B1200 HUPCL CS8 CLOCAL OPOST ONLCR # B1200 HUPCL SANE IXANY TAB3 #login: #1200

SANE is biting you.  SANE contains all manner of bits you may not need.
Try not using SANE but listing the modes individually.

The System V we have here does not all you to remove modes with -CLOCAL [ a
problem with SANE is that it may turn off modem control for modems or turn
it on for hardwired terminals ] so we list the flags out the long way.

Once you have written a new gettydef you will need to see if you are getting
the correct flags by compiling the gettydefs file.  Use the '-c' option to
getty to check the flags which are going to be used.  This will save you
the effort of calling yourself on the phone.
-- 
John F. Haugh II                        +----Make believe quote of the week----
VoiceNet: (214) 250-3311   Data: -6272  | Nancy Reagan on Richard Stallman:
InterNet: jfh@rpp386.Dallas.TX.US       |          "Just say `Gno'"
UucpNet : <backbone>!killer!rpp386!jfh  +--------------------------------------

mann@intacc.uucp (Jeff Mann) (11/04/88)

In article <130@tree.UUCP> stever@tree.UUCP (Steve Rudek) writes:
>We're running Micrport System V/AT release 2.4 and need to change the tty
>default for incoming modem calls from the default (7 data bits even parity)
>to 8 data bits no parity to better accomodate new callers.  About 6
>months ago, under 2.2, I spent quite a bit of time experimenting with the 
>gettydefs file.  As I recall, I tried changing the standard entry:
>
>1200# B1200 HUPCL PARENB CS7 CLOCAL OPOST ONLCR # B1200 HUPCL SANE IXANY TAB3 #login: #1200
>
>to:
>
>1200# B1200 HUPCL CS8 CLOCAL OPOST ONLCR # B1200 HUPCL SANE IXANY TAB3 #login: #1200
>
>but it didn't make any significant difference.  Why not?
>
>I was told by one of the tech support folks at microport that the "#" in the
>center of the gettydefs record delimits line condition BEFORE login from
>line condition AFTER login.  Is this correct?  In general, I'd be fascinated

Yes, the first part of the line is the settings that getty uses before 
executing /bin/login.  It starts off in "raw" mode so that it can "adapt the
system to the speed and type of terminal being used."  However, Microport
says that "Data terminals using 8-bit protocols are not supported through
gettydefs (#316, ver 1.3, known limitation)".  That means that the change
you made above won't work, because the "autoconfigure" feature of getty can't
handle 8 bits.  This one had me stumped until I tried:

1200#B1200 OPOST ONLCR HUPCL# CS8 BRKINT ISTRIP ICRNL IXON IXOFF TAB3 OPOST ONLCR B1200 CREAD ISIG ICANON ECHO ECHOE ECHOK IXANY HUPCL#\nLog in as 'newuser' if you are one\nlogin: #300

That is, force CS8 to be used AFTER the login name has been received.  This
means that ANYONE logging in will be set to 8 bits, which is probably what
you want.  The login prompt is sent with no parity, because no data format 
is specified in the initial settings.

I don't claim to be a wizard or anything ( I'm sure a few people will have a
good laugh at my gettydef line ) but it works!

-- 
| Jeff Mann - Inter/Access Videotex, Toronto  ...uunet!mnetor!intacc!mann  |
| "A picture is worth 256 thousand words"  {utzoo, utgpu}!chp!intacc!mann  |

torsten@pcsbst.UUCP (Torsten Homeyer) (11/04/88)

In article <1215@vsedev.VSE.COM< logan@vsedev.VSE.COM (James Logan III) writes:
[..]                                                        V
<Getty sets your line to seven data bits after you type in a login
<name if you  don't tell it specifically how many data bits you
<want.  (It has default settings so that the line is reasonable
<when you don't tell it specifically what to use.)  Put CS8 after
<the second pound-sign (#) like this:   
[..]                                                        V
<1200# B1200 HUPCL CS8 CLOCAL OPOST ONLCR # B1200 HUPCL CS8 SANE IXANY TAB3 #login: #1200

	That's the solution, but put the CS8 after the SANE, because in some
	implementations SANE sets the character size.

		Torsten.
---
Name    : Torsten Homeyer         {tho@pcsbst ; torsten@homeyer}.UUCP
Company : PCS GmbH, Munich W-Germany.
UUCP  : ..uunet!unido!pcsbst!tho     ..uunet!unido!pcsbst!sws4!torsten
PRIVAT: ..unido!{pcsbst,megalon,mikros,[altger,netmbx]!oldman}!homeyer!torsten

logan@vsedev.VSE.COM (James Logan III) (11/08/88)

In article <680@pcsbst.UUCP> sws4!torsten@pcsbst.UUCP (torsten) writes:
>That's the solution, but put the CS8 after the SANE, because in some
>implementations SANE sets the character size.
>
>		Torsten.

Oooops... He's right!  Sorry about that, folks!

			-Jim

-- 
Jim Logan		logan@vsedev.vse.com
(703) 892-0002		uucp:	..!uunet!vsedev!logan
			inet:	logan%vsedev.vse.com@uunet.uu.net

gerti@ncrdk.dk (Gert Illemann) (11/08/88)

In article <130@tree.UUCP>, stever@tree.UUCP (Steve Rudek) writes:

> We're running Micrport System V/AT release 2.4 and need to change the tty
> default for incoming modem calls from the default (7 data bits even parity)
> to 8 data bits no parity ...
> ... I tried changing the standard entry: ... to:
> 1200# B1200 HUPCL CS8 CLOCAL OPOST ONLCR # B1200 HUPCL SANE IXANY TAB3 #login: #1200
> but it didn't make any significant difference.  Why not?

Because you are using SANE, that will - among other settings - give you
CS7 and PARENB

> Why does UNIX default to 7 data bits/even parity, anyway?

Most ports defaults to 7+even, because it used to be a good guess, as to what
the terminal would like. That is even today a very good guess; the majority
of terminals, used world-wide, are ASCII (more or less) based (not extended
ASCII, just plain ASCII).
As the character-width (unfortunately) still is only 8 bits in UNIX and as
it's very nice to have some measure of assurance of what you type is what the
program gets, most people prefer to use the eighth bit for parity checking.

> ...If I succeed in switching to 8 data bits will
> there be any unwanted side effects I should beware of? 

Yes ! dont use TAB3, it means "expand tabs to spaces"; normally that would
be wrong (VERY wrong sometimes) for uucp-traffic.

> I was told by one of the tech support folks at microport that the "#" in the
> center of the gettydefs record delimits line condition BEFORE login from
> line condition AFTER login.  Is this correct?

Yes, he was right there, syntax :
name# initial settings (i.e. for opening and writing the login-message) \
# final settings (i.e. sat just before login is executed) # login-message \
#next-name

>In general, I'd be fascinated
> to hear the full story of what is really going on in a gettydefs entry.
> While I can look up the supposed definition of some of these field mnemonics
> (e.g., "PARENB" or "CS7") I feel that the UNIX documentation is extremely
> inadequate in describing the available options and interactions in line
> control settings.

I wont't give you more of the story here, but, have you studied getty(1M),
termio(7), gettydefs(4), stty(1) and maybe ioctl(2), I'm sure you know what
to do.
It's more than the part-time system-administrator cares to do, I know, so
maybe you should ask your support-person(s) to do it :-)

  Gert

Gert Illemann    / gerti@ncrdk.dk  (...uunet!mcvax!dkuug!ncrdk!gerti)

				       NCR Danmark A/S, System Service Division
					Teglv{rksgade 31, DK-2100 Copenhagen O
>>DISCLAIM.ABSOLUTE<<
Nobody or -one, but I, claims to think so
as it's probably incorrect, inconsistent,
incoherent and generally untrustworthy

guy@auspex.UUCP (Guy Harris) (11/13/88)

>As the character-width (unfortunately) still is only 8 bits in UNIX

It's not just a question of UNIX, it's a question of hardware.  In the
case of asynchronous serial ports, the hardware ultimately controls how
many bits the system is willing to accept between the start and stop
bits.

Some asynchronous serial port hardware (most such hardware, I suspect)
is capable of framing characters with a start bit, 9 other bits, and a
stop bit; such hardware will treat 8 of those bits as data bits and the
9th as a parity bit.

Not all software that controls that hardware will put it in this mode,
however.  Systems with a full System V-style tty driver interface will
do so; just set CS8 and PARENB.  This should include the system in
question (it also includes SunOS 4.0 and later, and will probably
include the next BSD release, since it will at least support a
POSIX-style tty driver interface, and that permits 8 bits plus parity). 
Systems with a V7-style tty driver interface, such as current BSD
systems, won't put the hardware in that mode; the software running
inside some terminals may not do so either, in which case setting the
host up to support this doesn't help you any.

>> ...If I succeed in switching to 8 data bits will
>> there be any unwanted side effects I should beware of? 
>
>Yes ! dont use TAB3, it means "expand tabs to spaces"; normally that would
>be wrong (VERY wrong sometimes) for uucp-traffic.

If the guy wants 8-bit support for a user's terminal, rather than UUCP
or some other software that wants an 8-bit "pass-through" binary data
path, there should be no problem with setting TAB3; if the guy wants
8-bit support for a "pass-through" binary data path, the proper advice
is "don't use OPOST", not "don't use TAB3", because *any* tty driver
transformation of data on output - or input, for that matter - will be
wrong.